The term “Content Mesh” was coined by Sam Bhagwat, Gatsby’s co-founder, when describing how the modern digital project landscapes propel companies into stitching together multiple tools and services into one common layer - the mesh. The idea is that companies can combine best-of-breed services into working seamlessly together to deliver exceptional customer experiences on the frontend.
The idea stems from the migration from monolithic services to a microservices approach, where there are fewer restrictions on the capability, lack of vendor lock-in, and reduction in building “hacky” solutions to achieve something the system wasn’t intended for.
For instance, looking at the monolithic services within the CMS space, Wordpress was designed to be a blogging platform. By using a variety of plugins, add-ons, and custom scripts, Wordpress can power an eCommerce site. Magento on the other hand, was intended to be an eCommerce site, but to enable blogging, again, would require development effort into making it happen.
Adding capabilities to these services are definitely possible, but the cost of doing this results in bloating the project, reducing performance, needing specialists, time, maintenance, and a certain level of lock-in because its time consuming and painful to improve or de-couple a monolith when the time comes. As a result, companies end up sacrificing the ability to modernise their tech stack on the fly, and require considerable in-house resources to constantly upgrade and maintain their platforms.
The content mesh moves away from this approach by combining several services from multiple vendors into one “mesh” layer.
This is where the Headless CMS comes into play.Since they’re designed without a UI or a backend compatibility specification, they’re just a way to manage data.
Teams can simply add and remove services as they see fit, since their CMS, at the core of the mesh, is headless, and doesn’t dictate any control over the frontend, backend, or compatible services. For instance, a company using GraphCMS would use the CMS to host their content and integrate to a variety of services via webhooks or integrations if and when needed, and GraphCMS would have no control over dictating the UI, frontend, or capabilities of the developers.
If the team needs to add search functionality, they can integrate with Algolia. Need payments, Stripe can be added to the mix. Similarly Segment can be put in for analytics, VWO for A/B Testing, Gatsby for static site generation, and Netlify for deployment, and the possibilities are quite literally endless. At any time, any of these services can be independently edited, removed, or upgraded, without needing to overhaul and maintain the entire infrastructure layer.
So, in summation, the “content mesh” is the practice of moving away from an all-in-one solution of a monolith, to a microservices approach where companies can take the best-of-breed solutions that do certain things exceptionally well, and stitch them together to create a suite of tools that fulfil their business needs the best.
When developing server-side apps, the most common direction with monolithic services is building a layered architecture which consists of several components:
This was an easy approach in the past when the API-based landscape was in hits beginning, and the landscape wasn’t flooded with integrations for every possible use case. However, over time, monolith architectures are starting to have their limits tested.
On the other hand, microservices take a completely different approach to building and maintaining digital projects. The core idea is to move away from using an “all in one” solution that claims to do everything well, and opt for splitting apps into a set of smaller connected services that do one or few things exceptionally well.
Each microservice is a small app that has its own infrastructure and business logic, and seamlessly connects together via API. Some might even implement a web UI for better understanding and integrations. This allows companies to build exceptional omni-channel projects, since some services would work better on mobile or wearables, while others would work better on web. All these services would independently enhance the end user experience, and effortlessly share data and content via API, with intermediary communication to the backend via an API Gateway.
Similar to a DXP, the headless CMS often finds itself at the core of the content mesh.
Headless CMS and APIs compile and deliver content into the “mesh”, that can be a combination of several services like search, authentication, analytics, forms, chatbots, personalisation, payments, etc. Everything comes together on the mesh layer and is finally deployed via CI/CD and hosting like Netlify, Zeit Now, CircleCI, and so on.
This leaves developers and content creators to continue working with their preferred tools and services independently. In the case of GraphCMS, content editors can define, create, and edit content on the fly. Developers are free to use their preferred frameworks like REact, Angular, and Vue. Depending on the business case, several other APIs can be integrated natively or via webhooks to power eCommerce, forms, booking, personalisation, and so on. All of this can be deployed via a service like Netlify, and if and when the time arises, any of these tools can be independently upgraded or replaced to match business needs without an infrastructure overhaul.
In contrast, a monolithic CMS would aim to achieve this within a single platform, and while it would eventually work, there are certain sacrifices made on services usable, APIs compatible, and infrastructure restrictions. Since a monolith would handle everything within the hosting, presentation, content editing, and database on its own, the lock-in and maintenance alone would be a massive overhead.
For a better visualisation of how the content mesh comes into play, Gatsby themselves have put together an easily understandable architecture that can be viewed here.
There seem to be striking overlaps between the Content Mesh and Digital Experience Platforms (DXPs). In another academy page, we’ve covered what a DXP is and how a Headless CMS and DXP are inter-reliant. They both take on this modular approach where best-in-class services integrate with one another to create better digital experiences.
However, the key differentiation to understanding the difference is a matter of perspective.
A DXP is a suite of products used by companies to deliver better Customer Experiences (CX). A DXPs highest goal is for these customer-obsessed companies to understand, acquire, retain, and satisfy their customers.
On the other hand, the Content Mesh approach enables companies to have a modern tech stack that makes it easier to maintain their infrastructure - leading to better developer efficiency, easier workflows, better capabilities, and reduced overheads.
Whilst most DXPs tend to include user-centric services, microservices within the mesh may not always do so.
And since DXPs themselves can be monolithic in some regards, the concept of the content mesh itself is against that approach.
One way to approach this differentiation could be to assume that embracing the content mesh, allows companies to compile better and more effective DXPs as a next step.
The microservice architecture allows businesses to fulfill their needs using best-of breed services.
The GraphCMS Swag store is powered by a half-a-dozen APIs, all designed to deliver their part in the overall eCommerce architecture. Let’s take a deep dive into the different APIs and see what they do; Printful, Gatsby, Netlify, Apollo Server, Stripe, and Postmark.
This project is open source, so feel free to give it a spin.