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 touched on the different pieces that are involved.
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 is 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 a 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.
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!
These can all be called via the respective APIs and shown on the central site.
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. Need to add functionality? Then it looks like you are writing a large PHP function that goes against the softwares original design. Need to maintain a local environment? Well it’s going to take time pulling in changes from team members.
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 (think create-react-app), 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 partnered with the agile methodology (or similar, touchy subject) means 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 are really running with it. More and more businesses are understanding the idea of rolling out an MVP and building on it. Introducing Sprints and weekly roll outs to the workflow. 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. Most of the fiddly stuff is handled by Webpack. Everything is very close to being plug and play.
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.
