The solution, created by Tomas Billborn, developer at Rebel & Bird, consists of standalone microservices. Using microservices makes it easier to replace each component when a new tool is better, cheaper, or faster, whether it is a new search engine, a ticketing system, or a publishing tool.
Should any individual micro-service go down, the site will still work. Traditionally, the site goes down when a service stops working. However, if, for example, the publishing tool breaks down, the site will still work because all pages are static pages that lie in the cloud, and if some third-party integration goes down, the rest of the site still works.
Our solution with interconnected microservices has two other significant benefits from traditional solutions. On the one hand, the infrastructure is optimized to present pages as quickly as possible, even for users who do not have a perfect connection. On the other hand, we have now created the basis for a code store that shortens the time from planning to launch for each new site.
The conductor of the solution is a minimal web application (here an Azure Web App) whose task is to receive updates and ensure that the most up-to-date content is delivered to the cloud.
It does this by telling the publishing tool (in this case, Contentful) when there is some new material. If Gatsby is not already busy building static pages from a previous update, it will download the content via GraphQL and build. The static html pages are then uploaded to the cloud (Azure Storage in this case).
Once the new site has been built for Azure Storage without any problems, it turns to a content delivery network (a CDN) and says, “Be good! Here is the updated site, replace all your cached pages. “
All real-time content and other third-party integrations (for example, price data in a business system) are retrieved from one or more service layers and integrated into the static real-time HTML pages.
The fact that all static content is prebuilt pages makes the solution quick. But we have a lot of other tricks that make it even faster.
As part of our data-driven process, Gatsby retrieves traffic data from Google Analytics. This information then uses Guess.js to predict which pages are most likely to visit from that particular page. So the page loads lightning fast when the visitor clicks on it.
For the pictures, we do this. First, we create a space where the image should be, then an extremely low-resolution version of the image is loaded, and finally, an image file that matches the resolution that the visitor has on their screen is loaded. Someone with a retina screen gets a significantly higher-resolution version of the image than someone with a simple mobile phone. Most people with fast connections do not notice this process, but for example, those who sit on the train and surf with 3G can see the changes.
This solution makes the site faster but, above all, more stable even for users who do not have access to the fantastic infrastructure found in, for example, Stockholm’s inner city.
For groups that address users all over the world, this is a brilliant, efficient, and cost-saving model.