Headless CMS architecture pattern

In recent days I have come across a new term going around whilst investigating new alternatives for our current CMS architecture. CMS systems have been around for many years and whilst they have served their purpose in being able to add, update and deliver data to customers, they were designed primarily for desktop devices. With the advancement of mobile and other devices, it has become increasingly important that a cms solution be able to cope with this advancement and also account for scalability issues that one may face.


What does Headless CMS provide?

Headless CMS provides a back end only CMS system that is built with a content system and exposes a Restful API that is responsible for displaying data onto any device. With this approach it presents a presentation agnostic approach to delivering data and doesn’t tie any particular presentation to its backend.


What is in a traditional CMS?

  • Provides a method to store and maintain data.
  • Provides a CRUD UI
  • Provides presentation layer to display the data.


What is in a headless CMS?

  • Provides a method to store and maintain data.
  • Provides a CRUD UI
  • Provides Restful API to the data.


Why decouple CMS?

With traditional monolithic CMS systems the content management application and content delivery application exist together in a single application, they provide a solution for simple blog and basic websites where everything can be managed in one place.

With a decoupled CMS, we are able to separate the content management application from the content delivery application, this frees up developers to be able to choose the way they want to deliver content to users. It is important to understand that the creation of content is not the same as delivering and that the separation are clear.

In a decoupled CMS, it promotes the microservices architecture approach and you can leverage the use of event driven message queues in order to store state for content and updates to the website. By using the event driven approach when you delete a content element, then there is a call to the contentdelete event.

Event consumers will be responsible for consuming the changes produces by the event source that handles events and can be optimised through the API.


What would an architecture look like?


For a headless CMS system, we could deploy something based upon CQRS:-

CQRS stands for Command Query Responsibility Segregation. It's a pattern that I first heard described by Greg Young. At its heart is the notion that you can use a different model to update information than the model you use to read information.

From: Martin Fowler


Utilise event sourcing:-

Create an approach that is responsible for handling a sequence of events on as operations on data where each event is appended onto a read only basis to temp or permanent store. When a action takes place, the application sends a series of sequence command operations that once stored can later be replayed when executing the same series of operations on the set of data.

Heres a brief fact sheet of what it performed with event sourcing:-

  • Events are immutable
  • Task produced can run in the background
  • Improve performance and stability as no contention for processing of transactions
  • Events represent what events have occurred.
  • Append only nature to the data means that an audit trail is provided, can replay events at any time.
  • Decouple task from events and provides flexibility and extensibility.

There are however a few issues that also need to be considered:-

  • Some delay when adding events to the event store between the handler, publishing events and consumers handling the events.
  • If you need to undo a change to the data is to add a compensating event to the event store


You can read more about it here.


Microsoft Future Decoded London 2017

Today I was lucky enough to attend Microsofts future decoded event in London excel centre, as usual there was numerous talks that were of interest but as always, I had to diligently choose the ones that were of more interest to me.

For those who haven’t attended this Microsoft event before, this offers Microsofts insight into their vision of tomorrow, talks centre around what technologies and strategies Microsoft are investing in and that they would like us to pay attention to.

The keynote delivered essentially Microsofts sales pitch on their new surface, surface book and Microsoft hub devices and how they can leverage Microsoft collaborative web spaces to bring teams together from different locals. They gave a demonstration on the hub of how an individual in the audience is able to create story board sketches to the workspace, adding drawings and updating ordering of the drawings. At the same time, another team in the US is able to upload various photos to the same work space and rearrange them in any particular order.

This collaborative and seemingly lag free workspace sharing looks like an ideal solution to bring various teams together, and as I have found when working with various personnel spread over multiple locations this real-time update helps to not create bottlenecks in waiting for / delivering information to each other.

We also had a glimpse of HoloLens and Microsoft leveraging augmented reality and how it can be used in the business place. Panos Panay demonstrated how simply using the surface and the AR app, we are able to drop an augmented hub into the room, and side by side with a real hub, we can see how realistic it is and envision what it would actually look like in real life.

Demystifying .NET Core and .NET Standard

There has been much confusion about .Net Core and .Net Standard and why they have come about, I have added a good article by Microsoft about how to demystify the difference between them.

.Net Core 1 was release first and was the first iteration in the .Net Core stack to offer a new approach to developing using the .Net technology. Recently however .Net Standard has been introduced in order to provide some cross compatibly between various mobile technologies and applications. When this was announced many of the early adopter of .Net Core questioned this and the amount of time and resources already invested in applications, they demanded that .Net Standard be integrated with .Net Core.


When would we use one over the other?

This decision hinges on the technology requirement of compatibility that .Net Standard provides over the vast number of APIs available to .Net Core.
.Net Core increases the Api access surface area available however its implementation allows only those that target .Net Core applications.

.Net Standard however can be used by any application that targets the specific .Net Standard version but has a decreased Api access surface area.
An example of this would be if the .Net Standard version 1.4 was being used in a specific application, then all those applications that also target that version are able to support the .Net Standard version. On the other hand they will not have access to some Api parts such as the microsoft.netcore.coreclr.


What are the differences in the Api surface area?

.Net Standard applications include the netstandard.library, whereas .Net Core includes microsoft.netcore.app which has around 20 additional libraries that’s available to it. 
.Net standard can be added manually but some functionality will not be compatible such as Microsoft.NETCore.CoreCLR. However the trade-off is that .Net Standard increases portability and all the benefits it brings is this new age of mobile first development. It also provides a contract agreement between applications as to what versions they are targeting agree to. .Net Standard exists to run on multiple runtimes whereas .Net Core provides an increased surface area and have to specify the platform that the application is run against.


Read original article https://msdn.microsoft.com/en-us/magazine/mt842506