Did you know content management systems (CMS) originated in ancient Egypt? It’s true, Google it! Well, in fact, it’s not quite true. Content management has come such a long way since its humble beginnings, however, that it almost seems, as if it truly did start thousands of years ago. In the meantime, as developers we have gone through countless development languages and frameworks; as end consumers of content we have gone through a number of platforms and completely changed our habits of how we consume content. The most incredible part, however, is that the CMS has survived and adapted to it all. How far we have come As so many things, it all began with the advent of modern Internet, i.e, the 90s. In those days content on the Internet was created by people comfortable with HTML, as it was the only way to create websites. Jane would open her text editor, write to her heart’s content, and save the file as an HTML file on the server. As websites in those days were exclusively text, this worked like a charm! Remember Yahoo, the website that aggregated hyperlinks to the coolest sites around the Web? Exactly! Shortly thereafter, Jane thought about adding images into the mix because “a picture is worth a thousand words”. In addition, with the proliferation of the Internet and websites, more and more people, including those without the technical know-how of creating websites, were getting dragged into the mix. Blogging was the hot thing and various marketing folks and journalists were starting to create content for online consumption. The web was picking up speed but also quite a bit of complexity along the way. Simultaneously, a separation between those who could build websites and those managing content for them developed. Keep this in mind, as this separation will be a recurring theme. Thus, over time, a content management system, or CMS, was born! Wordpress (est. ~2003), Drupal (est. ~2002), and were doing their best to solve the issues of self-publishing media-rich content and collaborative content management processes. many others This worked marvelously for some years as we continued to create an ever increasing number of websites largely consumed on desktop computers. A developer would take care of custom styling during the website setup. A content manager would create their content in the CMS alongside the layout and press . Piece of cake! publish Until one day Apple released the iPhone and wrecked havoc on the established world order; welcome smartphone! Shortly thereafter the iPad followed and, along with it, every other device manufacturer coming out with their own versions of the smartphone and tablet, ushering in a new era of content consumption. Gone were the days of consuming content on a desktop, in were the days of mobile web and native mobile applications. Not long after content also started appearing on wrists around the world in smartwatches, in virtual reality headsets or augmented reality gadgets, even on Internet-connected washing machines. Safe to say that within a decade our behavior of consuming content on a desktop screen at home or work was completely flipped on its head. An era of multi-platform content management began. The rise of the new — headless CMS When it comes to content management systems, the new requirements on content meant that change was afoot in the industry. The challenges were manifold. Should each platform have a separate CMS or should one CMS publish content to all platforms? How to accommodate the multitude of hardware devices and screen sizes? How to support platforms that were nascent but had the apparent potential to become ubiquitous, such as virtual reality, augmented reality, and others? In addition, of course, the CMS still had to support the habits of old: publishing media-rich content and collaborative content management processes. As is natural, people thought taking an existing idea, namely, an idea of a CMS as it had evolved by then, and squeezing and shoving it into the requirements of the new world order was going to do the trick. It certainly did — largely at a cost of terrible user experience, as everyone has surely experienced looking on a mobile device at a website clearly built for the web. Website of the Party Parrot cult. To be fair, the website is responsive and this is a fake non-responsive mock-up. Forgive me, migthy parrot. While legacy content management systems grappled with the problem the way they knew best, developing themes and plugins for responsive websites and native applications, a brand new school of thought emerged. Instead of trying to squeeze content coupled with presentation into new platforms, let’s separate those two concerns and leave content management to content managers and presentation and layout of that content to developers. Again, the separation between those who managed content and those who took care of the technical side emerged. Thus, a headless CMS was born! A key differentiating factor of a headless content management system is that it is, in fact, two things to two different sets of people: to developers it is, effectively, a database returning pure data, in this case content via an API, which returns pure JSON; it is a fully-featured CMS to those tasked with managing content, complete with translation, support for various roles and workflows, tightly controlled permissions, etc. While content managers have the right tools to succeed in their work, developers are unobstructed by built-in presentation expectations and have the freedom to build native experiences for any platform currently existing or forthcoming. This separation of concerns creates effective collaboration patterns between developers and content managers. Remember how this separation was one of the original problems the content management systems of yore tried to solve. The catch with modern headless CMS By now, there are many headless CMS out there, as well as legacy players catching on and making native APIs available to the general public. It’s an exciting time as content management systems are moving towards supporting all and any content consumption platform! There is just one catch — none of the headless CMS or legacy CMS actually support multi-platform content distribution natively. While the idea to expose pure content via an API is sound, the obstacle to true multi-platform content distribution lies with the choice of Representational State Transfer, or REST, as a way of transporting data. Although REST is in theory platform agnostic, its application, especially in the early days, which is to say mid-aughts, has centered around the Web. Hence the accepted practice of creating dedicated URLs to expose so-called resources or endpoints. Imagine a blog with authors and posts. With REST you would most likely create two endpoints: one for authors and one for posts, each of which would store relevant data about these objects. The fundamental idea is that by accessing these endpoints with a given command one is able to perform actions (GET, PUT, DELETE, POST) on documents stored at those endpoints. Thus, it follows, that the endpoints dictate what actions are possible and what data is or isn’t available. In our example, you wouldn’t be able to know anything about an author’s posts without also retrieving data from the posts endpoint. This has largely worked well during the desktop-based web only days. The pain has increased drastically, however, since the explosion of platforms and devices we are experiencing currently. Imagine you have built a screen for a smartwatch app that pulls latest news stories from a REST endpoint built at some point in the past. Given the screen size limitation, at most you might be able to show a title for two or three stories. Your REST endpoint returns the following: stories “allStories”: [{“subtitle”: “After penguins street riot in Antarctica demanding the finest burgers made by cats, Cat Burger Company opens first location to smashing success\n”,“translations”: [{“title”: “Cat Burger Company Expands to Antarctica Catering to Strong Penguin Demand”,“body”: “lorem ipsum\n”,“language”: “EN_US”},{“title”: “Cat Burger Company expandiert in die Antarktis Catering für starke Pinguin-Nachfrage”,“body”: “lorem ipsum DE\n”,“language”: “DE_DE”},{“title”: “Cat Burger Company se développe en Antarctique pour répondre à la forte demande de pingouin”,“body”: “lorem ipsum FR\n”,“language”: “FR”},{“title”: “Cat Burger Company breidt uit naar Antarctica voor catering aan de sterke Penguin-vraag”,“body”: “lorem ipsum NL\n”,“language”: “NL”}],“last3Stories”: [“Scientific Research Proves Cats Are Burger Experts\nYou Won’t Believe These 7 Truths About Cats and Burgers\nA Cat Burger Company Announces 3rd Quarter Results; Price Skyrockets”],“publishDate”: “2018–02–13T22:00:00.000Z”,“headerImage”: {“url”: “ ",“height”: 333,“width”: 500,“fileName”: “_048”},“platform”: “Android”,“authorName”: “Cat Burgermeister”}] https://media.graphcms.com/U6VRGMogRDmndHKCdfYK Instead of directly getting just a subset of the fields you can fit on a smartwatch screen, you have now unnecessarily used extra bandwidth for fetching the fields that you won’t even render. In addition, you may have the same effect, if you need to collect extra data from other endpoints. All this resulting in extra development work for the developer and decreased performance of the application for the content consumer. Now, multiply this by the number of platforms to appreciate the magnitude of the challenge. The future of headless CMS Our choice of GraphQL instead of REST as the data transport method is no accident. GraphQL flips the concept of resources or endpoints on its head and instead allows the client itself — whether an Android app, Apple Watch, Samsung washing machines, an Oculus device, whatever — to dictate exactly the data it needs. In other words, it eliminates all completely unnecessary bandwidth load, as well as extra effort of data aggregation, in cases where data is compiled across multiple endpoints. Equally as important, our GraphQL endpoint significantly streamlines technology stacks. First, because GraphQL is simply a data transport layer between your backend and frontend, you may choose to shuffle parts of either at will. Suppose a new content distribution platform is introduced. Your technology stack will accommodate it easily. It may be you decide to remove or add parts to your backend to service new needs of your product. Again, GraphQL, as the in-between data transport layer, gives you the flexibility to evolve with ease instead of being tied down tomorrow to technology choices of today. Second, by relying on open-source frontend clients such as Apollo or Relay, you don’t have to manage a variety of proprietary SDKs of various headless CMS or legacy content management systems. This piping work is already done for you, so you can focus on building your inital product. To be fair, if you are building a simple website or mobile application, this is not something you need to worry about. If, on the other hand, you truly are in the business of multi-platform publishing, you will greatly benefit from the freedom of not having to constantly update each platform’s SDK and QAing and fixing resulting bugs in your applications. These are the fundamental benefits of a GraphQL API endpoint instead of a REST endpoint as they directly relate to the CMS use case. There are a number of other benefits GraphQL provides, such as auto-generated documentation, type-safety, and others that are beneficial but don’t directly address the needs of content management systems. You can . learn more about GraphQL generally and those specific benefits here Conclusion We are proud to be the first headless CMS to offer true native multi-platform support to your digital projects. We believe that the benefits of a GraphQL API — improved development workflow and streamlined technology stacks — are the logical next step for headless CMS. From the challenges of old — publishing media-rich content and collaborative content management practices — to the challenges of the future, such as easily supporting any content distribution platform that may not even exist yet, we are excited for the possibilities GraphQL brings to content management. GraphCMS — The GraphQL CMS If you have not had the opportunity to try for yourself yet, we encourage you to do so now! We offer a variety of pricing plans to fit your needs, as well as free trials and a forever Free plan for small hobby or test projects. Getting started is quick, especially if you have existing projects in other CMS, and help is always at your side. to learn more about our work together! GraphCMS Click here
