[This is Portugal specific therefore this post is in portuguese]

O Automóvel On-line permite pedir pela Internet vários atos de registo sobre veículos e respetivos reboques e receber na sua
residência/sede, sem deslocações, o Certificado de Matrícula/Documento Único Automóvel.
Para este tutorial é necessário ter Cartão de Cidadão e um leitor.

Quando se acede ao site aparece o seguinte erro:

E063 - A área à qual tentou aceder é reservada e apenas acessível para utilizadores com um certificado digital válido.
Por favor, instale um certificado antes de tentar aceder a esta área do site.
Antes de voltar a tentar, por favor feche esta janela.

Os passos para contornar este erro são:

1. Fazer download e instalar a aplicação [Autenticação.gov](https://www.autenticacao.gov.pt/).

2. Fazer download do [Firefox 90.0](https://ftp.mozilla.org/pub/firefox/releases/90.0/mac/en-US/) já que não funciona nas versões mais recentes e instalar.

3. Ir às configuraçõe do Firefox e pesquisar por "cert".

4. Clicar em "security devices" e clicar em "Load".

5. No Module Name colocar "autenticacao.gov" e apontar o ficheiro para "/usr/local/lib/libpteidpkcs11.2.0.0.dylib".

6. Iniciar a aplicação "Autenticação.gov", ligar o leitor de cartões e inserir o Cartão de Cidadão.

7. Ao entrar no [automovelonline.mj.pt](https://www.automovelonline.mj.pt/) aparece um aviso com os dados e certificados para aceitar.

8. Depois de aceitar é só colocar o Pin de Autenticação do Cartão de Cidadão e usar o portal.

[This is Portugal specific therefore this post is in portuguese]
O Automóvel On-line permite pedir pela Internet vários atos de registo sobre veículos e respetivos reboques e receber na sua 
residência/sede, sem deslocações, o Certificado de Matrícula/Documento Único Automóvel. 
Para este tutorial é necessário ter Cartão de Cidadão e um leitor.
Quando se acede ao site aparece o seguinte erro:
E063 - A área à qual tentou aceder é reservada e apenas acessível para utilizadores com um certificado digital válido. 
Por favor, instale um certificado antes de tentar aceder a esta área do site. 
Antes de voltar a tentar, por favor feche esta janela.
Os passos para contornar este erro são:
<ol dir="auto">
<li>
Fazer download e instalar a aplicação <a href="https://www.autenticacao.gov.pt/" rel="nofollow">Autenticação.gov</a>.
</li>
<li>
Fazer download do <a href="https://ftp.mozilla.org/pub/firefox/releases/90.0/mac/en-US/" rel="nofollow">Firefox 90.0</a> já que não funciona nas versões mais recentes e instalar.
</li>
<li>
Ir às configuraçõe do Firefox e pesquisar por "cert".
</li>
<li>
Clicar em "security devices" e clicar em "Load".
</li>
<li>
No Module Name colocar "autenticacao.gov" e apontar o ficheiro para "/usr/local/lib/libpteidpkcs11.2.0.0.dylib".
</li>
<li>
Iniciar a aplicação "Autenticação.gov", ligar o leitor de cartões e inserir o Cartão de Cidadão.
</li>
<li>
Ao entrar no <a href="https://www.automovelonline.mj.pt/" rel="nofollow">automovelonline.mj.pt</a> aparece um aviso com os dados e certificados para aceitar.
</li>
<li>
Depois de aceitar é só colocar o Pin de Autenticação do Cartão de Cidadão e usar o portal.
</li>
</ol>

[This is Portugal specific therefore this post is in portuguese]
O Automóvel On-line permite pedir pela Internet vários atos de registo sobre veículos e respetivos reboques e receber na sua
residência/sede, sem deslocações, o Certificado de Matrícula/Documento Único Automóvel.

Como autenticar no Automóvel Online em macOS

A couple of weeks ago I remembered it would be super cool to have the real-time visitors of my website directly on my MacBook Pro Touch Bar, so I decided to do it.

## First step: the API

I used [Next.JS](https://nextjs.org/) to draft a simple API endpoint that gets the data from Google Analytics and replies in JSON with the data I want to consume on the Touch Bar, already in the correct structure.


``` js
const {google} = require('googleapis');
const key = require('./auth.json');

export default async (_, res) => {
 const scopes = 'https://www.googleapis.com/auth/analytics.readonly'
 const jwt = new google.auth.JWT(key.client_email, null, key.private_key, scopes);
 const view_id = 'XXXXXXXX';

 process.env.GOOGLE_APPLICATION_CREDENTIALS = './auth.json';

 const analytics_res = await google.analytics('v3').data.realtime.get({
 auth: jwt,
 ids: 'ga:' + view_id,
 metrics: 'rt:activeUsers',
 dimensions: 'rt:medium',
 prettyPrint: true
 });
 
 res.status(200).json({
 realtime: analytics_res?.data?.totalsForAllResults?.['rt:activeUsers']
 });
}
```

To do this I used the `googleapis` package and created the credentials [here](https://console.developers.google.com/iam-admin/serviceaccounts). 


``` json
{
 "type": "service_account",
 "project_id": "<project_id>",
 "private_key_id": "<private_key_id>",
 "private_key": <private_key>,
 "auth_uri": "https://accounts.google.com/o/oauth2/auth",
 "token_uri": "https://oauth2.googleapis.com/token",
 "auth_provider_x509_cert_url": "https://www.googleapis.com/oauth2/v1/certs",
 "client_x509_cert_url": "<client_x509_cert_url>"
}
```

If you have questions about Google APIs authentication, [this post](https://flaviocopes.com/google-api-authentication/) can be useful.

## Second step: Apple Script

I used a little tool called [JSON Helper](https://apps.apple.com/us/app/json-helper-for-applescript/id453114608) available in the Mac App Store for free and which allows to consume JSON files in Apple Scripts.

```
tell application "JSON Helper"
	set json to fetch JSON from "https://myapi.com/api/analytics"
	set users to realtime of json
 set final to "" & users & " users"
end tell
```

This script fetches the URL and prints the number to the screen with the word users.
## Third step: Adding to the Touch Bar

I've been using [MTMR](https://github.com/Toxblh/MTMR) (My Touchbar My Rules) to customize my Touch Bar. The application uses a JSON description file to add different buttons and informations to the Touch Bar. I used a block called `appleScriptTitledButton` which executes the Apple Script in the `source` attribute in an interval defined in the `refreshInterval` attribute. In this case, I used 10 seconds since the Google Analytics API has [some limits](https://developers.google.com/analytics/devguides/reporting/core/v3/limits-quotas). Also, when I click the button with the real-time users it automatically opens the Google Analytics website on my preferred browser.

```
{
 "type": "appleScriptTitledButton",
 "refreshInterval": 10,
 "source": {
 "filePath": "/Users/Shared/MTMR/analytics.scpt"
 },
 "align": "left",
 "width": 100,
 "bordered": false,
 "action": "openUrl",
 "url": "https://analytics.google.com/"
 },
```

If you have any question let me know on [Twitter](https://twitter.com/rgllm).

A couple of weeks ago I remembered it would be super cool to have the real-time visitors of my website directly on my MacBook Pro Touch Bar, so I decided to do it.
<h2 dir="auto">First step: the API</h2>
I used <a href="https://nextjs.org/" rel="nofollow">Next.JS</a> to draft a simple API endpoint that gets the data from Google Analytics and replies in JSON with the data I want to consume on the Touch Bar, already in the correct structure.
<div class="highlight highlight-source-js notranslate position-relative overflow-auto" dir="auto" data-snippet-clipboard-copy-content="const {google} = require('googleapis');
const key = require('./auth.json');

export default async (_, res) =&gt; {
 const scopes = 'https://www.googleapis.com/auth/analytics.readonly'
 const jwt = new google.auth.JWT(key.client_email, null, key.private_key, scopes);
 const view_id = 'XXXXXXXX';

 process.env.GOOGLE_APPLICATION_CREDENTIALS = './auth.json';

 const analytics_res = await google.analytics('v3').data.realtime.get({
 auth: jwt,
 ids: 'ga:' + view_id,
 metrics: 'rt:activeUsers',
 dimensions: 'rt:medium',
 prettyPrint: true
 });
 
 res.status(200).json({
 realtime: analytics_res?.data?.totalsForAllResults?.['rt:activeUsers']
 });
}"><pre class="notranslate">const {google} = require('googleapis');
const key = require('./auth.json');

export default async (_, res) =&gt; {
 const scopes = 'https://www.googleapis.com/auth/analytics.readonly'
 const jwt = new google.auth.JWT(key.client_email, null, key.private_key, scopes);
 const view_id = 'XXXXXXXX';

 process.env.GOOGLE_APPLICATION_CREDENTIALS = './auth.json';

 const analytics_res = await google.analytics('v3').data.realtime.get({
 auth: jwt,
 ids: 'ga:' + view_id,
 metrics: 'rt:activeUsers',
 dimensions: 'rt:medium',
 prettyPrint: true
 });
 
 res.status(200).json({
 realtime: analytics_res?.data?.totalsForAllResults?.['rt:activeUsers']
 });
}</pre></div>
To do this I used the <code class="notranslate">googleapis</code> package and created the credentials <a href="https://console.developers.google.com/iam-admin/serviceaccounts" rel="nofollow">here</a>.
<div class="highlight highlight-source-json notranslate position-relative overflow-auto" dir="auto" data-snippet-clipboard-copy-content="{
 &quot;type&quot;: &quot;service_account&quot;,
 &quot;project_id&quot;: &quot;&lt;project_id&gt;&quot;,
 &quot;private_key_id&quot;: &quot;&lt;private_key_id&gt;&quot;,
 &quot;private_key&quot;: &lt;private_key&gt;,
 &quot;auth_uri&quot;: &quot;https://accounts.google.com/o/oauth2/auth&quot;,
 &quot;token_uri&quot;: &quot;https://oauth2.googleapis.com/token&quot;,
 &quot;auth_provider_x509_cert_url&quot;: &quot;https://www.googleapis.com/oauth2/v1/certs&quot;,
 &quot;client_x509_cert_url&quot;: &quot;&lt;client_x509_cert_url&gt;&quot;
}"><pre class="notranslate">{
 "type": "service_account",
 "project_id": "&lt;project_id&gt;",
 "private_key_id": "&lt;private_key_id&gt;",
 "private_key": &lt;private_key&gt;,
 "auth_uri": "https://accounts.google.com/o/oauth2/auth",
 "token_uri": "https://oauth2.googleapis.com/token",
 "auth_provider_x509_cert_url": "https://www.googleapis.com/oauth2/v1/certs",
 "client_x509_cert_url": "&lt;client_x509_cert_url&gt;"
}</pre></div>
If you have questions about Google APIs authentication, <a href="https://flaviocopes.com/google-api-authentication/" rel="nofollow">this post</a> can be useful.
<h2 dir="auto">Second step: Apple Script</h2>
I used a little tool called <a href="https://apps.apple.com/us/app/json-helper-for-applescript/id453114608" rel="nofollow">JSON Helper</a> available in the Mac App Store for free and which allows to consume JSON files in Apple Scripts.
<div class="snippet-clipboard-content notranslate position-relative overflow-auto" data-snippet-clipboard-copy-content="tell application &quot;JSON Helper&quot;
	set json to fetch JSON from &quot;https://myapi.com/api/analytics&quot;
	set users to realtime of json
 set final to &quot;&quot; &amp; users &amp; &quot; users&quot;
end tell"><pre class="notranslate"><code class="notranslate">tell application "JSON Helper"
	set json to fetch JSON from "https://myapi.com/api/analytics"
	set users to realtime of json
 set final to "" &amp; users &amp; " users"
end tell
</code></pre></div>
This script fetches the URL and prints the number to the screen with the word users.
<h2 dir="auto">Third step: Adding to the Touch Bar</h2>
I've been using <a href="https://github.com/Toxblh/MTMR">MTMR</a> (My Touchbar My Rules) to customize my Touch Bar. The application uses a JSON description file to add different buttons and informations to the Touch Bar. I used a block called <code class="notranslate">appleScriptTitledButton</code> which executes the Apple Script in the <code class="notranslate">source</code> attribute in an interval defined in the <code class="notranslate">refreshInterval</code> attribute. In this case, I used 10 seconds since the Google Analytics API has <a href="https://developers.google.com/analytics/devguides/reporting/core/v3/limits-quotas" rel="nofollow">some limits</a>. Also, when I click the button with the real-time users it automatically opens the Google Analytics website on my preferred browser.
<div class="snippet-clipboard-content notranslate position-relative overflow-auto" data-snippet-clipboard-copy-content="{
 &quot;type&quot;: &quot;appleScriptTitledButton&quot;,
 &quot;refreshInterval&quot;: 10,
 &quot;source&quot;: {
 &quot;filePath&quot;: &quot;/Users/Shared/MTMR/analytics.scpt&quot;
 },
 &quot;align&quot;: &quot;left&quot;,
 &quot;width&quot;: 100,
 &quot;bordered&quot;: false,
 &quot;action&quot;: &quot;openUrl&quot;,
 &quot;url&quot;: &quot;https://analytics.google.com/&quot;
 },"><pre class="notranslate"><code class="notranslate">{
 "type": "appleScriptTitledButton",
 "refreshInterval": 10,
 "source": {
 "filePath": "/Users/Shared/MTMR/analytics.scpt"
 },
 "align": "left",
 "width": 100,
 "bordered": false,
 "action": "openUrl",
 "url": "https://analytics.google.com/"
 },
</code></pre></div>
If you have any question let me know on <a href="https://twitter.com/rgllm" rel="nofollow">Twitter</a>.

A couple of weeks ago I remembered it would be super cool to have the real-time visitors of my website directly on my MacBook Pro Touch Bar, so I decided to do it.

How I added Google Analytics real-time visitors to my MacBook Touchbar

Every dynamic website consists of two main parts: the backend and the frontend. The backend, which in marketing websites is commonly a Content Management System (CMS), allows the website owners to manage as much content as needed without handling code changes. The frontend displays all of that content for the website users.

At Pixelmatters, we use a variety of CMS and frameworks to build websites. One of these solutions is WordPress, in which we have built large scale projects like [Rubrik](https://www.pixelmatters.com/work/rubrik-corporate-website-design/), using it for both the backend and frontend. This approach is very convenient however, there a lot of advantages of decoupling the two parts, especially performance. For these reasons, we decided to adapt our WordPress stack to use a more headless approach with newer technologies. This post aims to describe how we adapted our marketing websites stack maintaining high-quality standards.

## 🗿Our old stack and the monolithic way to use WordPress

We’ve used WordPress before with marketing websites at Pixelmatters. It allows our clients to edit website content independently and adding flexibility without compromising the overall design. These websites are built using this CMS, serving both as the backend and frontend, or what is called a monolithic approach.

On our old stack, the backend uses a combination of WordPress hooks and ACF to create custom blocks that are assigned to [custom page templates](https://developer.wordpress.org/themes/template-files-section/page-template-files/). The frontend is built on a custom theme that uses [Timber](https://github.com/timber/timber), a plugin that adds [Twig Template Engine](https://twig.symfony.com/) support in WordPress, allowing us to separate PHP files and component/HTML files.

![](https://cdn-images-1.medium.com/max/5600/1*aueQ84-lH7hfNrE54MEwTg.png)

## 🎭 The future of WordPress is headless

WordPress come a long way since the first introduction 17 years ago, evolving from a simple blog publishing platform to a fully-featured CMS, to an online store managing system. This freedom to use WordPress in very distinct scenarios resulted in increasing use of the CMS which is present now in more than 30% of the top 10 million sites, according to [W3Techs](https://w3techs.com/technologies/history_overview/content_management/all). These numbers allied with the large community caused more and more growing knowledge about WordPress itself, especially in marketing teams. However, WordPress is built in old technologies and its restrictive architecture doesn’t offer the possibilities that sometimes we need while working on client websites, especially when it comes to performance optimization, one of the key points [Google takes into account while ranking a website](https://developers.google.com/web/updates/2018/07/search-ads-speed).

Since the introduction of the REST API in WordPress, it can be used in a headless way, allowing developers to use it as a backend (where it really shines) and separating the frontend, where we can use frontend-focused technologies. This way the model and the controller are bundled together on the WordPress side, handling all data manipulation and database interaction and the frontend only interact with the REST API.

This way we ensure the correct separation of concerns since the frontend and the backend interact via endpoints making it possible to host them in separate servers specifically optimized for their purpose. A backend server optimized for PHP applications and a frontend server optimized to deal with Node.js applications. With this separation, we also ensure that exploiting the website through the backend becomes more difficult since it’s largely hidden from the public. Commonly exploited WordPress routes, like _wp-login.php_ or _xmlrpc.php_ are no longer available to the public.

In addition to this, using WordPress as a headless CMS makes it possible to use modern JS libraries like ReactJS, Vue.js, or Angular delivering highly dynamic web apps. This also future-proofs the website implementation, letting us redesign the site without re-implementing the CMS itself, and allows us to deliver more performant websites with minimum effort by shifting display logic to the client-side and streamlining the backend.

## 💁 Choosing the frontend framework

When it comes to creating a website, there’s no shortage of JS frameworks that allow us to create beautiful and functional frontends. However, when it comes to running WordPress headless it can become easy to get bogged down with the particulars of WordPress and the process of fetching data using the WordPress API. For this reason, one of the things we set up as a goal from the beginning was to choose a framework that natively supported the WordPress API. This led us to choose [GatsbyJS](http://gatsbyjs.org/), an open-source framework based on React with native support for modern technologies like GraphQL and Progressive Web Apps that have a lot of advantages.

It offers support for multiple data sources making it possible to combine, for example, data from WordPress and databases, APIs, or even Markdown files. The support for the WordPress REST API is done trough [gatsby-source-wordpress](https://www.gatsbyjs.org/packages/gatsby-source-wordpress/), which automatically pulls the data and makes all endpoints available for the frontend.

On the performance side, GatsbyJS brings some out of the box optimizations. It generates all the pages content during the build process making the website fast and once loaded. Gatsby prefetches resources for other pages so clicking around the site feels almost instantaneous.

On the other hand, the way GatsbyJS works and the reason why it can do these performance optimizations is the fact that it fetches all the needed data to populate the pages during the build process. This means that for each WordPress data update the frontend needs to rebuild, resulting in a big disadvantage for websites with a lot of content changes, for example, news websites.

## 🏛️ Defining an architecture

Early on the first project, we decided to use this new stack it was defined that in order to maintain a scalable and robust codebase we needed to correctly structure both the backend and the frontend before starting the development since this was a completely new way to work. This way we could ensure and maintain the project quality while introducing new features. Furthermore, this architecture could be reused in other projects, maintaining the same structure, and allowing developers to work on multiple projects using WordPress and GatsbyJS.

## 📝 Backend Architecture

In the WordPress backend, we follow an architecture similar to what we used on monolithic installations. We have a set of WordPress page templates and then we assigned custom ACF components to that page templates. Usually, these components are directly mapped to React components on the frontend. We also create Custom Post Types to define custom data structures, and that use the same components imported on the common pages.

## 🖼️ Frontend Architecture

On the frontend, we use a common Gatsby architecture. The framework pulls the data from WordPress REST API. This data includes posts, pages, custom post types, menus, and global options like for example logos. Thus, we ensure that the client has total flexibility on the backend to change any content that it’s loaded on the frontend. After pulling this data, during development, Gatsby transforms the WordPress REST API into a GraphQL API to be used on the project.

![](https://cdn-images-1.medium.com/max/5600/1*neO1VfbkrUo3qJXg2xvHmQ.png)

During the production build, Gatsby pulls only the data used on the frontend and transforms it into JSON files that are then loaded by the pages, ensuring we only load necessary data.

We also developed an architecture for the frontend components taking into account the WordPress structure itself and the way Gatsby works internally, resulting in the following types of components:

- **Layout** — The layout is the global component and the parent of all other components;

- **Views** — Views are connected to the router and directly mapped to WordPress page templates. So, for example, if we have a Contact Us page template we have a Contact Us View in the frontend that is responsible to fetch all the data used on the page through a GraphQL query and to importing all the children Partials and View Components used;

- **Partials** — Partials are reused across all the site with a particular difference to View Components, this type of component include the data fetch, which means they can connect to external data sources. On GatsbyJS we do this using [GraphQL Static Queries](https://www.gatsbyjs.org/docs/static-query/), commonly used for menus and sidebars that need to be independent of the page;

- **Global Components** — Components reused across all the websites and imported on Views or Partials.

## 🔮 Future improvements

We’re now working on a new version of this stack to implement WPGraphQL and removing the middle step of transforming the WordPress REST API into a GraphQL API. This will be done using the upcoming gatsby-source-wordpress V4, rewritten from the ground up using WPGraphQL for data sourcing as well as a custom plugin WPGatsby to transform the WPGraphQL schema in Gatsby-specific ways.

![](https://cdn-images-1.medium.com/max/5600/1*TcULMcaQvvXsOkwyX7RvHQ.png)

## 🚀 Results and conclusions

While the monolithic way to use WordPress is very convenient this new stack has proven to offer more advantages than disadvantages. We’ve now shipped two client websites using this stack and we noticed two big benefits. The first one is obviously the performance, we are getting really good results out of the box and without the need to assign specific tasks for this. For example, on one website we got from 24 to 93 points on Google PageSpeed Performance without any specific optimization, just using native GatsbyJS features.

![](https://cdn-images-1.medium.com/max/5600/1*uSDIevfx2XkygLy6A8EfWQ.png)

The second benefit is the use of new technologies that allow us to make the websites more dynamic. For example, we had recently to ship a new functionality in one website where the user has a favorite store, which is chosen taking into account their preference and location, and this selection is shared across all the website allowing the components to render specific information for that user. While this is also possible in a common WordPress website, the effort to do this is exponentially higher. Marketing websites become true interactive experiences for users. The backend becomes only the system of record and “state machine”, but back-and-forth interaction happens in real-time in the browser.

On the other hand, this type of stack requires some client education since they’ve to understand how all the stack works. One of the main things it’s the use of WordPress plugins and mirroring those plugins to the frontend. The two parts of the website are isolated, which means that if for example, you install a new plugin for custom buttons on WordPress those buttons will not be available on the frontend and require additional development. Also, another thing that comes to a lot of times is the build time. When publishing or editing a new page, clients need to understand that the frontend needs to rebuild and that is not instantaneous, though this is improved a lot with [Gatsby Incremental Builds](https://www.gatsbyjs.org/blog/2020-04-22-announcing-incremental-builds/).

In conclusion, we believe this new approach brought us a lot of benefits on our marketing websites stack, however, there are still a couple of pain points that we hope to solve with time.


Every dynamic website consists of two main parts: the backend and the frontend. The backend, which in marketing websites is commonly a Content Management System (CMS), allows the website owners to manage as much content as needed without handling code changes. The frontend displays all of that content for the website users.
At Pixelmatters, we use a variety of CMS and frameworks to build websites. One of these solutions is WordPress, in which we have built large scale projects like <a href="https://www.pixelmatters.com/work/rubrik-corporate-website-design/" rel="nofollow">Rubrik</a>, using it for both the backend and frontend. This approach is very convenient however, there a lot of advantages of decoupling the two parts, especially performance. For these reasons, we decided to adapt our WordPress stack to use a more headless approach with newer technologies. This post aims to describe how we adapted our marketing websites stack maintaining high-quality standards.
<h2 dir="auto"><g-emoji class="g-emoji" alias="moyai" fallback-src="https://github.githubassets.com/images/icons/emoji/unicode/1f5ff.png">🗿</g-emoji>Our old stack and the monolithic way to use WordPress</h2>
We’ve used WordPress before with marketing websites at Pixelmatters. It allows our clients to edit website content independently and adding flexibility without compromising the overall design. These websites are built using this CMS, serving both as the backend and frontend, or what is called a monolithic approach.
On our old stack, the backend uses a combination of WordPress hooks and ACF to create custom blocks that are assigned to <a href="https://developer.wordpress.org/themes/template-files-section/page-template-files/" rel="nofollow">custom page templates</a>. The frontend is built on a custom theme that uses <a href="https://github.com/timber/timber">Timber</a>, a plugin that adds <a href="https://twig.symfony.com/" rel="nofollow">Twig Template Engine</a> support in WordPress, allowing us to separate PHP files and component/HTML files.
<a target="_blank" rel="noopener noreferrer nofollow" href="https://camo.githubusercontent.com/289b1884cf022c880cb077739429190049dfae6ce2490787e09b815a7cb1e16a/68747470733a2f2f63646e2d696d616765732d312e6d656469756d2e636f6d2f6d61782f353630302f312a6175655138342d6c483768664e724535344d457754672e706e67"><img src="https://camo.githubusercontent.com/289b1884cf022c880cb077739429190049dfae6ce2490787e09b815a7cb1e16a/68747470733a2f2f63646e2d696d616765732d312e6d656469756d2e636f6d2f6d61782f353630302f312a6175655138342d6c483768664e724535344d457754672e706e67" alt="" data-canonical-src="https://cdn-images-1.medium.com/max/5600/1*aueQ84-lH7hfNrE54MEwTg.png" style="max-width: 100%;"></a>
<h2 dir="auto"><g-emoji class="g-emoji" alias="performing_arts" fallback-src="https://github.githubassets.com/images/icons/emoji/unicode/1f3ad.png">🎭</g-emoji> The future of WordPress is headless</h2>
WordPress come a long way since the first introduction 17 years ago, evolving from a simple blog publishing platform to a fully-featured CMS, to an online store managing system. This freedom to use WordPress in very distinct scenarios resulted in increasing use of the CMS which is present now in more than 30% of the top 10 million sites, according to <a href="https://w3techs.com/technologies/history_overview/content_management/all" rel="nofollow">W3Techs</a>. These numbers allied with the large community caused more and more growing knowledge about WordPress itself, especially in marketing teams. However, WordPress is built in old technologies and its restrictive architecture doesn’t offer the possibilities that sometimes we need while working on client websites, especially when it comes to performance optimization, one of the key points <a href="https://developers.google.com/web/updates/2018/07/search-ads-speed" rel="nofollow">Google takes into account while ranking a website</a>.
Since the introduction of the REST API in WordPress, it can be used in a headless way, allowing developers to use it as a backend (where it really shines) and separating the frontend, where we can use frontend-focused technologies. This way the model and the controller are bundled together on the WordPress side, handling all data manipulation and database interaction and the frontend only interact with the REST API.
This way we ensure the correct separation of concerns since the frontend and the backend interact via endpoints making it possible to host them in separate servers specifically optimized for their purpose. A backend server optimized for PHP applications and a frontend server optimized to deal with Node.js applications. With this separation, we also ensure that exploiting the website through the backend becomes more difficult since it’s largely hidden from the public. Commonly exploited WordPress routes, like wp-login.php or xmlrpc.php are no longer available to the public.
In addition to this, using WordPress as a headless CMS makes it possible to use modern JS libraries like ReactJS, Vue.js, or Angular delivering highly dynamic web apps. This also future-proofs the website implementation, letting us redesign the site without re-implementing the CMS itself, and allows us to deliver more performant websites with minimum effort by shifting display logic to the client-side and streamlining the backend.
<h2 dir="auto"><g-emoji class="g-emoji" alias="tipping_hand_person" fallback-src="https://github.githubassets.com/images/icons/emoji/unicode/1f481.png">💁</g-emoji> Choosing the frontend framework</h2>
When it comes to creating a website, there’s no shortage of JS frameworks that allow us to create beautiful and functional frontends. However, when it comes to running WordPress headless it can become easy to get bogged down with the particulars of WordPress and the process of fetching data using the WordPress API. For this reason, one of the things we set up as a goal from the beginning was to choose a framework that natively supported the WordPress API. This led us to choose <a href="http://gatsbyjs.org/" rel="nofollow">GatsbyJS</a>, an open-source framework based on React with native support for modern technologies like GraphQL and Progressive Web Apps that have a lot of advantages.
It offers support for multiple data sources making it possible to combine, for example, data from WordPress and databases, APIs, or even Markdown files. The support for the WordPress REST API is done trough <a href="https://www.gatsbyjs.org/packages/gatsby-source-wordpress/" rel="nofollow">gatsby-source-wordpress</a>, which automatically pulls the data and makes all endpoints available for the frontend.
On the performance side, GatsbyJS brings some out of the box optimizations. It generates all the pages content during the build process making the website fast and once loaded. Gatsby prefetches resources for other pages so clicking around the site feels almost instantaneous.
On the other hand, the way GatsbyJS works and the reason why it can do these performance optimizations is the fact that it fetches all the needed data to populate the pages during the build process. This means that for each WordPress data update the frontend needs to rebuild, resulting in a big disadvantage for websites with a lot of content changes, for example, news websites.
<h2 dir="auto"><g-emoji class="g-emoji" alias="classical_building" fallback-src="https://github.githubassets.com/images/icons/emoji/unicode/1f3db.png">🏛️</g-emoji> Defining an architecture</h2>
Early on the first project, we decided to use this new stack it was defined that in order to maintain a scalable and robust codebase we needed to correctly structure both the backend and the frontend before starting the development since this was a completely new way to work. This way we could ensure and maintain the project quality while introducing new features. Furthermore, this architecture could be reused in other projects, maintaining the same structure, and allowing developers to work on multiple projects using WordPress and GatsbyJS.
<h2 dir="auto"><g-emoji class="g-emoji" alias="memo" fallback-src="https://github.githubassets.com/images/icons/emoji/unicode/1f4dd.png">📝</g-emoji> Backend Architecture</h2>
In the WordPress backend, we follow an architecture similar to what we used on monolithic installations. We have a set of WordPress page templates and then we assigned custom ACF components to that page templates. Usually, these components are directly mapped to React components on the frontend. We also create Custom Post Types to define custom data structures, and that use the same components imported on the common pages.
<h2 dir="auto"><g-emoji class="g-emoji" alias="framed_picture" fallback-src="https://github.githubassets.com/images/icons/emoji/unicode/1f5bc.png">🖼️</g-emoji> Frontend Architecture</h2>
On the frontend, we use a common Gatsby architecture. The framework pulls the data from WordPress REST API. This data includes posts, pages, custom post types, menus, and global options like for example logos. Thus, we ensure that the client has total flexibility on the backend to change any content that it’s loaded on the frontend. After pulling this data, during development, Gatsby transforms the WordPress REST API into a GraphQL API to be used on the project.
<a target="_blank" rel="noopener noreferrer nofollow" href="https://camo.githubusercontent.com/08fda3fc92bfe1b08fe370b1a68d942799ae3c7d411717aa67262d096ddaefdb/68747470733a2f2f63646e2d696d616765732d312e6d656469756d2e636f6d2f6d61782f353630302f312a6e654f315666626b72556f33714a5867327876486d512e706e67"><img src="https://camo.githubusercontent.com/08fda3fc92bfe1b08fe370b1a68d942799ae3c7d411717aa67262d096ddaefdb/68747470733a2f2f63646e2d696d616765732d312e6d656469756d2e636f6d2f6d61782f353630302f312a6e654f315666626b72556f33714a5867327876486d512e706e67" alt="" data-canonical-src="https://cdn-images-1.medium.com/max/5600/1*neO1VfbkrUo3qJXg2xvHmQ.png" style="max-width: 100%;"></a>
During the production build, Gatsby pulls only the data used on the frontend and transforms it into JSON files that are then loaded by the pages, ensuring we only load necessary data.
We also developed an architecture for the frontend components taking into account the WordPress structure itself and the way Gatsby works internally, resulting in the following types of components:
<ul dir="auto">
<li>
Layout — The layout is the global component and the parent of all other components;
</li>
<li>
Views — Views are connected to the router and directly mapped to WordPress page templates. So, for example, if we have a Contact Us page template we have a Contact Us View in the frontend that is responsible to fetch all the data used on the page through a GraphQL query and to importing all the children Partials and View Components used;
</li>
<li>
Partials — Partials are reused across all the site with a particular difference to View Components, this type of component include the data fetch, which means they can connect to external data sources. On GatsbyJS we do this using <a href="https://www.gatsbyjs.org/docs/static-query/" rel="nofollow">GraphQL Static Queries</a>, commonly used for menus and sidebars that need to be independent of the page;
</li>
<li>
Global Components — Components reused across all the websites and imported on Views or Partials.
</li>
</ul>
<h2 dir="auto"><g-emoji class="g-emoji" alias="crystal_ball" fallback-src="https://github.githubassets.com/images/icons/emoji/unicode/1f52e.png">🔮</g-emoji> Future improvements</h2>
We’re now working on a new version of this stack to implement WPGraphQL and removing the middle step of transforming the WordPress REST API into a GraphQL API. This will be done using the upcoming gatsby-source-wordpress V4, rewritten from the ground up using WPGraphQL for data sourcing as well as a custom plugin WPGatsby to transform the WPGraphQL schema in Gatsby-specific ways.
<a target="_blank" rel="noopener noreferrer nofollow" href="https://camo.githubusercontent.com/7b06375d19f3907d4707e205da68b7e14279ae6fc9b78c9a6c09aa0d4057bd65/68747470733a2f2f63646e2d696d616765732d312e6d656469756d2e636f6d2f6d61782f353630302f312a5463554c4d636151767658734f6b77795837527648512e706e67"><img src="https://camo.githubusercontent.com/7b06375d19f3907d4707e205da68b7e14279ae6fc9b78c9a6c09aa0d4057bd65/68747470733a2f2f63646e2d696d616765732d312e6d656469756d2e636f6d2f6d61782f353630302f312a5463554c4d636151767658734f6b77795837527648512e706e67" alt="" data-canonical-src="https://cdn-images-1.medium.com/max/5600/1*TcULMcaQvvXsOkwyX7RvHQ.png" style="max-width: 100%;"></a>
<h2 dir="auto"><g-emoji class="g-emoji" alias="rocket" fallback-src="https://github.githubassets.com/images/icons/emoji/unicode/1f680.png">🚀</g-emoji> Results and conclusions</h2>
While the monolithic way to use WordPress is very convenient this new stack has proven to offer more advantages than disadvantages. We’ve now shipped two client websites using this stack and we noticed two big benefits. The first one is obviously the performance, we are getting really good results out of the box and without the need to assign specific tasks for this. For example, on one website we got from 24 to 93 points on Google PageSpeed Performance without any specific optimization, just using native GatsbyJS features.
<a target="_blank" rel="noopener noreferrer nofollow" href="https://camo.githubusercontent.com/8c10c7fbc0cdc7a844f5d536e9f2feb05cd68186cef0213aa76ca4ed7758484a/68747470733a2f2f63646e2d696d616765732d312e6d656469756d2e636f6d2f6d61782f353630302f312a755344496576667832586b79674c79364138456657512e706e67"><img src="https://camo.githubusercontent.com/8c10c7fbc0cdc7a844f5d536e9f2feb05cd68186cef0213aa76ca4ed7758484a/68747470733a2f2f63646e2d696d616765732d312e6d656469756d2e636f6d2f6d61782f353630302f312a755344496576667832586b79674c79364138456657512e706e67" alt="" data-canonical-src="https://cdn-images-1.medium.com/max/5600/1*uSDIevfx2XkygLy6A8EfWQ.png" style="max-width: 100%;"></a>
The second benefit is the use of new technologies that allow us to make the websites more dynamic. For example, we had recently to ship a new functionality in one website where the user has a favorite store, which is chosen taking into account their preference and location, and this selection is shared across all the website allowing the components to render specific information for that user. While this is also possible in a common WordPress website, the effort to do this is exponentially higher. Marketing websites become true interactive experiences for users. The backend becomes only the system of record and “state machine”, but back-and-forth interaction happens in real-time in the browser.
On the other hand, this type of stack requires some client education since they’ve to understand how all the stack works. One of the main things it’s the use of WordPress plugins and mirroring those plugins to the frontend. The two parts of the website are isolated, which means that if for example, you install a new plugin for custom buttons on WordPress those buttons will not be available on the frontend and require additional development. Also, another thing that comes to a lot of times is the build time. When publishing or editing a new page, clients need to understand that the frontend needs to rebuild and that is not instantaneous, though this is improved a lot with <a href="https://www.gatsbyjs.org/blog/2020-04-22-announcing-incremental-builds/" rel="nofollow">Gatsby Incremental Builds</a>.
In conclusion, we believe this new approach brought us a lot of benefits on our marketing websites stack, however, there are still a couple of pain points that we hope to solve with time.

Every dynamic website consists of two main parts: the backend and the frontend.

From monolithic to headless: how and why you should adapt your WordPress stack

I've been thinking about having a blog for a long time. From time to time I see/discover something that I want to share and social networks are not the most appropriate place all the time.
After reading this article [Every developer should have a blog. Here’s why, and how to stick with it.](https://www.freecodecamp.org/news/every-developer-should-have-a-blog-heres-why-and-how-to-stick-with-it-5fd55a247fbf/) I decided to create mine.

"A blog is useful for many reasons. It can become a source of leads, it can be the place where, in the future, you might sell your products if you want to become an indie developer, or it can simply be the place where you have your audience and express your ideas."

You can expect here content mainly about tech and software engineering.

I've been thinking about having a blog for a long time. From time to time I see/discover something that I want to share and social networks are not the most appropriate place all the time. 
After reading this article <a href="https://www.freecodecamp.org/news/every-developer-should-have-a-blog-heres-why-and-how-to-stick-with-it-5fd55a247fbf/" rel="nofollow">Every developer should have a blog. Here’s why, and how to stick with it.</a> I decided to create mine.
"A blog is useful for many reasons. It can become a source of leads, it can be the place where, in the future, you might sell your products if you want to become an indie developer, or it can simply be the place where you have your audience and express your ideas."
You can expect here content mainly about tech and software engineering.

I've been thinking about having a blog for a long time.

Writing

Como autenticar no Automóvel Online em macOS

How I added Google Analytics real-time visitors to my MacBook Touchbar

From monolithic to headless: how and why you should adapt your WordPress stack

Every developer should have a blog, so this is mine