Headless servers is not a new term, however Headless CMS sounds new. After reading the blog post on SilverStripe, Headless CMS and SilverStripe we wanted to share a case study of a headless server, and how we used it on a cross platform mobile software.
We've been designing a software system for a mobile app providing guided walks in Tasmania. Walks are categorised in to regions, durations, and grades. Each of the walks have their own information, links to maps, data presented in various UI components like accordions, popups, toggle areas with slide up / downs, image sliders, swiped screens etc. The app is going to have 100s of walks and 1000s of different sorts of data, and the data had to be dynamic, and an admin can send an update of the contents and all the subscribers of the app would receive the latest updates.
What we designed was a headless CMS, with a REST API to return data over an HTTP connection. The following diagram explains the technology stack and how the connections work with.
This project is a perfect example of a headless CMS, and here's how we benefited.
Cross Platform: The CMS only does manage information about walks, and assets, and provides an API to retrieve that information visa a RESTFUL API. It doesnt know, where / how the information is being used or rendered. It can be IOS, Andriod, Phones, Tabs (different screen sizes).
Performance & scalability: We use static file caching for all the API calls, the calls are structured into each data object type. A network call endpoint looks like http://mysite.com/api/Walk which returns all the information about the walk objects. The CMS only refreshed a cache if there is a change in the last edited objects timestamp, which it stores as a hash key on the generated caches. With this the first user would only trigger the feeds, and everyone else would be using a cached text file.
Fast frontend: We've ditched all template processing from the cms, and keep it all to JSON/text. This helps us to respond to any call quite quickly. Also as these API calls are being made from mobile devices we wanted to keep the size of the responses to a minimum.
Leaving the View to a thirdparty: Angular is itself an MVC JS library, and works perfect with ionic. After we ditched the views from the CMS, we feed the data to angular, and designed a model within angular. All the views and the logics are handled after that in angular.
We will be also looking to use the GraphQL module to improve the performances and as an upgrade of the CMS down the line.