#Key Takeaways
- The “Content Mesh”, coined by Gatsby’s co-founder Sam Bhagwat, is an approach to moving away from monolithic structures and adopting best-of-breed microservices to build resilient projects.
- Several services and tools can be stitched together into one layer as a “mesh”.
- A Headless CMS fits into the core of the Content Mesh by absorbing and giving out content via API to each service in the equation.
- Monolithic infrastructures are hard to maintain and upgrade, resulting in companies being unable to regularly evolve their tech stack.
- Although there are some overlaps, the Content Mesh is not the same as a Digital Experience Platform (DXP).
- To understand the Content Mesh in action, we’ve built the Hygraph Swag Store - an open source project on #DIYCommerce using Hygraph, Gatsby, Netlify, Stripe, Printful, and Postmark.
#What is the Content Mesh
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 Hygraph would use the CMS to host their content and integrate to a variety of services via webhooks or integrations if and when needed, and Hygraph 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.
#Understanding Monolith vs. Microservices
When developing server-side apps, the most common direction with monolithic services is building a layered architecture which consists of several components:
- The presentation layer - that handles HTTP requests and responding via API feeds like HTML, JSON, XML, and so on.
- The business logic
- Database access, and
- App integrations - connecting to other tools and services via API.
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.
- The ability to scale projects is horizontal since de-coupling monoliths and upgrading their capabilities is extremely difficult and resource heavy.
- Each update and change requires a deploy of the entire application.
- As more capabilities and services are added, performance and speed are sacrificed.
- There can be several conflicts between modules, and they don’t always work seamlessly with one another.
- A small issue or bug in one module can potentially bring down the entire system until found and fixed.
- Companies are unable to evolve their techstack regularly because of lock-in, compatibility, and resources required to maintain a monolithic architecture.
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.
#Headless CMS and the Content Mesh
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 Hygraph, 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.
#Content Mesh vs. Digital Experience Platform (DXP)
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.
#Benefits of embracing the Content Mesh
The microservice architecture allows businesses to fulfill their needs using best-of breed services.
- Microservices can be easily added and removed when required, making services faster to develop and easier to maintain.
- Companies can constantly evolve their tech stack without worrying about overheads, compatibility, or maintenance.
- Each service within the mesh can be worked on independently, increasing developer efficiency since they don’t have to worry about dependencies across the board.
- Each microservice can be deployed independently without affecting the rest of the application, allowing continuous deployment to be possible.
- Without investing in and being bound to expensive clunky solutions, businesses can deliver genuine omni-channel content natively and at scale.
- Marketers, developers, and product owners are free to work with their preferred stack, and easily change tools when needed.
- Each service is scalable, and easier to understand.
#Hygraph and Content Mesh in action: Building an eCommerce Store
The Hygraph 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 a small example of how you could begin to create a custom commerce experience using a variety of APIs. While we've handled the cart logic client-side with JavaScript, there are headless commerce APIs like Chec, CommerceTools, Commerce Layer and others that provide you a full suite of APIs to do all the heavy-lifting in whatever area you need.
This project is open source, so feel free to give it a spin.