Headless websites: mirroring or caching?
Did you know the impact that mirroring and caching can have on headless Drupal setup? The answer might surprise you.
When building a headless CMS, we use a combination of the CMS itself (we love Drupal for its great editor functionality), a backend technology for serving the API and HTML+JS+CSS, and of course the frontend technology itself (go React+Typescript!).
This stack and setup is awesome, but when the size of the website grows beyond a certain critical mass, we can add caching or mirroring in order to speed things up and improve the general architecture. Let's see how.
Caching
Caching is "dumb": if you ask it the same question twice, the first time it asks Drupal, but from the second time onwards it just parrots 🦜🦜🦜 the old answer. Parroting the old answer is really fast 🏎️🏎️🏎️, so we don't need to wait for the slower 🕑🕑🕑 Drupal API call.
If the underlying content has changed, well, c'est la vie I guess. For this reason Drupal has to send signals to the cache when content is published in order to invalidate the appropriate cache entries.
Mirroring
Mirroring 🪞🪞🪞 builds and maintains a full copy of the data in another system, in our case ES, because ES is very very fast 🚀🚀🚀 and because it allows search 🔍🔍🔍 functionality that Drupal does not have (synonyms, auto-completion, fuzziness, etc.).
The frontend uses the mirror in all cases, and never looks at the underlying CMS. If content is not present in the mirror, we return a "Not found" error, even if in the meanwhile maybe the CMS got that content but it has not been synchronized ⇔⇔⇔.
Mistakes in cache invalidation and mistakes in the synchronization end up looking very similar, because you either see old content or miss content, but the full difference between mirroring and caching is huge.
Mirroring is much better than caching:
✅ first of all, you gain new functionality from the mirror, in our case advanced search and querying. For this reason, very often we already have ES in place because we need search functionality, so taking the next step and using ES as a mirror is not a lot of work.
✅ stability goes up. Backend web technologies such as .Net and ES are very solid and almost never break. Mirroring makes it possible to increase uptime because even if Drupal has a moment of heavy load or instability, the .Net+ES combo basically never breaks (you can run a .Net application for months or years without ever restarting it, with Drupal this is a bit less likely)
✅ we achieve loose coupling. Even if the Drupal is not available, the internal network has issues, etc. .Net can always serve content from ES. We have removed the direct coupling from .Net to Drupal, for improved uptime
In short, headless websites with NoSQL mirroring are faster, have more functionality, and have the lowest possible coupling between CMS and frontend.