On October 4th 2018 an article named “Delivering Modern Website Experiences: The Journey to a Content Mesh” was published by Sam Bhagwat. 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.”
To me, 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 integrate 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 due to 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 – a staple of WordPress development.
Consider an E-commerce business for instance. Products need to be managed and payments need to be taken at the core, but there will also be 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 changes are restricted by the software. This becomes a problem when rolling out continual changes that eventually go against built-in functionality.
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 the respective APIs and shown on the central site.
Each of the services mentioned above does a specific job, and it does it well. They have comprehensive documentation and a boatload 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 – you 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 software’s 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 make it 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 means that ideas can be brought to life in the blink of an eye – internet speed dependent. 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 rollouts to the workflow. This type of mindset requires a more flexible, more scaleable set of tools, which the speed of production depends upon.
Due to the flexibility and scalability, 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 for the Content Mesh?
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. I for one am excited to use content meshes in B2B website development marketing in 2019.