The Rise of the Content Mesh
Table of Contents
- What is a Content Mesh?
- Why hasn’t Content Mesh been possible before?
- Dedicated web services for specific use-cases
- An evolution of workflow and techniques
- So what next?
What is a Content Mesh?
On October 4th 2018 an article named “Delivering Modern Website Experiences: The Journey to a Content Mesh” was published by Sam Bhagwat on gatsbyjs.org. Sam introduced the concept of a Content Mesh, and broke down what it means.
In essence, the Content Mesh allows you to (from Sams article):
select best-of-breed solutions tailored to specific use-cases like e-commerce or blogging; it provides a modern framework for rapid iteration and it generates lightning fast websites out of the box.
That, is an exciting sentence.
There are have been multiple times across different projects where I have wanted to use a piece from this platform, and a piece from that service, but have been tied to a pre-set CMS with no flexibility. It looks like we have a solution!
Why hasn’t Content Mesh been possible before?
Honestly. It has been.
REST APIs have been around for years, and web developers have been able to integrated third-party services into websites. Google Analytics is a perfect example of a script that can be dropped into a site and managed elsewhere. I don’t believe it was ever a case of “it wasn’t possible”, but rather it hadn’t been widely considered. The reason it is getting traction now is because of the following points.
Dedicated web services for specific use-cases
Fully fledged CMS services still exist, they are continually being improved and built upon. However, micro-services are built to do one thing, and do it right. This means that the right tools can always be used for the job, as opposed to hacking a pre-existing functionality to do it for you (you have to love WordPress development…).
Consider an Ecommerce business for instance. Products need to be managed, payments need to be taken, as well as a blog, CRM, user data storage, and analytics. That’s a lot in one box!
One size fits all
In the past I would have directed a client to a monolithic approach, such as Magneto. It handles everything (which is great at first) but development and change is restricted by the software. This become a problem when rolling out continual changes that eventually go against the built in functionality.
So micro-services?
Now it is a different story. Each need has a service!
- Product management: Semantics 3
- Payments: Stripe
- User Data: Auth0
- Blog: WordPress
- CRM/Analytics: Segment
These can all be called via their respective APIs and used wherever required.
Each one of these services does a certain job, and it does it well. They have comprehensive documentation, and a boat load of code already written to drop into a site. It is highly likely that the individual managing the products for example, is not going to be the same person writing the blogs. By separating these areas means less distraction, and a cleaner, streamlined approach to the management of the website.
There are several benefits to this micro-service approach:
- If one service fails, the rest can still function – this allows fault isolation
- Stronger security – each service has its own credentials
- Easy integration and deployment – NPM, Netlify, etc
- Not locked-in to a specific stack – can try other services
- The website can easily be scaled – if a service isn’t working to its fullest, remove and replace
- Easier understanding – each tool explains what it does, and only what it does
An evolution of workflow and techniques
The older monolithic services are generally built on top of older technologies and have a slower development process. Why slower development?
- Need to add functionality? Then it looks like you are writing a large PHP function that goes against the products original design.
- Need to maintain a local environment? Well it’s going to take time pulling in changes from team members.
- Have a suggestion/require a bug fix? That large product moves far slower (generally) than the smaller package.
This has been addressed by more modern technologies, take React and Vue for example. These JS frameworks enable fast spin up times, super easy to start a new project (create-react-app for example), and an incredibly large community pushing improvements all the time. The open-source aspect of JS is great, with problems being solved, packaged, and stored on NPM.
These technologies mean that ideas can be brought to life in the blink of an eye (internet speed dependant). The web development community has got on board with this “packaged” concept and more businesses are rolling out MVPs quickly and then building on then. This type of mindset requires a more flexible, more scaleable set of tools. The speed of production depends on it.
Because of this, micro-services are able to fall into place easily, meaning the arrival of the content mesh. By being treated as another package on NPM, it is as easy as running a short command in a console and including into the code base.
So what next?
Obviously each project has its own set of requirements and restrictions but I would argue that the content mesh strategy can be applied to almost all cases. Once a basic framework has been created that works for you and your team, services can be introduced easily. You can replace that “one size doesn’t quite fit” solution and use whatever works best. Currently it seems only GatsbyJS comes with out-of-the-box integration, but it won’t be long before others join the race. The concept of a content mesh means the best solutions can all be used. This is definitely the right direction.
