Second post in a series of 3 articles by Ludovic Coullet (@lcoullet) about Progressive Web Apps (PWA). How can you turn all or part of your site into a PWA? What’s the point? How do you go about it...
- Part 1: PWA and Drupal, an Overview
- Part 2: Decoupling
- Part 3: Example of a PWA with Drupal 8 and Gatsby
The most radical way to build a PWA with Drupal is through total decoupling.
Let’s Behead Drupal!
If you’re still wondering what that means, you can check out this article.
The main idea is to use Drupal only as a storage system and a content entry interface. That’s what it does best: role management, Views, complex workflows, the flexibility of content types and taxonomies!
This content is exposed via an API (REST or GraphQL), with or without authentication depending on your needs.
Drupal 8 can natively expose its resources as a REST API. But extra modules like JSON API can provide data formatted according to a standard model. On that topic, we recently learned that this module will be integrated into Drupal 8.7!
There are already distributions geared toward decoupling that include the necessary modules to start a project on the right foot:
- Contenta CMS
- Lightning (Acquia)
That’s where Drupal’s role ends. The display logic is handled elsewhere—mainly in the user’s browser, and less and less on the server side!
React, VueJS, and Friends
When you say client side processing, you mainly mean JavaScript. You could manage with just the language itself and its features, maybe with a bit of jQuery, but it would take a long time…
For several years, different JS frameworks have shared the market for dynamic content display from external sources:
These are just the best known, but there are others that use different languages or JS variants, compiled down to JavaScript so that all browsers can understand them:
The range is vast! At bluedrop.fr, we’ve chosen to focus on 2 solutions depending on the need:
- VueJS for simple setups or progressive decoupling;
- React for large-scale projects and full decoupling.
These are also two of the three technologies most in demand among the projects we're involved in.
These technologies are mainly based on the concept of reusable web components that group display, style, features in the same place, and can communicate with each other and be easily assembled.
A small example of a counter with VueJS—here’s the definition of a component containing the view and the business logic:
// Definition of a new component called `button-counter`
Vue.component('button-counter', {
data: function () {
return {
count: 0
}
},
template: '<button v-on:click="count++">You clicked me {{ count }} times.</button>'
})
and how you use it:
<div id="components-demo">
<button-counter></button-counter>
</div>
These components can accept parameters that modify their display and behavior (called Props in Vue or React).
For example: a header component that could receive color parameters depending on the site section you’re on.
With decoupling, the main goal is to create components to which you pass a URL (your API endpoint and a method), and which then display, say, a list of the latest news, a news detail, a menu, and so on.
These technologies mean you don’t have to reinvent the wheel, and they integrate perfectly with other tools (like webpack), which lets you deliver the most optimized production version possible with a pre-configured service worker. Very pleasing for performance testing tools!
For complex projects, another type of component (called stores) manages application state centrally, avoiding a lot of problems.
For example: Redux and Vuex for our two main frameworks.
But... (because there’s always a but)
At the end of the line, you end up with an almost-empty HTML file that links to a stylesheet and especially to lots of JS files that will query the API and fill in the initial blank space. This is usually the case with what’s called a SPA (Single Page Application).
If we’re building a pure business application protected by authentication, bookmarked by everyone in a company, it’s not really a problem.
But if the site in question needs good ranking and SEO, it’s a disaster.
Indeed, search engine crawlers will not get past the HTML they initially receive.
Google recently addressed this in a series of videos explaining their position. Basically, even though Google can execute the JS to get the rendered content, it takes time—a lot more than server-generated HTML.
SPAs are handled in two steps. When it encounters such a page, Google puts a pin in it, thinking it will come back later when it has more time and resources to run the JS and crawl the generated content. But Google remains vague on how long that pause might last...
Maybe this will be fixed in the future—but for now, finding a solution is crucial.
SSR to the Rescue
SSR or server-side rendering is a technique that lets your users and search engine robots see pages that already contain part or all of the content your JS would have generated.
The benefits are:
- performance;
- SEO.
For real-time content, it may not be fully up to date, but the page skeleton and meta-data will be there. Once the page is loaded, JS takes over to fetch the right data in a process very fittingly called hydration.
It’s the best of both worlds, but as explained in the linked article, it’s more complex and comes with a cost.
And you need a server (usually running NodeJS) to generate all this. For static sites, pages must be pre-generated before uploading to the server.
Luckily for us, there are now solutions that make this easier, like Gatsby, which we’ll discuss next time!
To be continued...
SSR or server side rendering is a technique that allows you to provide your users and search engine bots with pages that already contain some or all of the content that your JS could have generated.