How GraphQL will be the final nail in the coffin of the custom CMS
by Gabe Smallman, Co-Founder
Friday, May 18
I’ve never met a developer that hasn’t built their own CMS for one reason or another. It’s not long before they’re working around the clock to send said CMS to the graveyard, where it will join thousands of others. Why? It’s easier to build something than maintain and operate it. Developers are a precious resource and an internal CMS is rarely business critical, so inevitably it rots.
The answer starts with the very reason most custom CMSs wind up in the graveyard to begin with, they have a hard time supporting a wide range of display and device outputs. Desktop, mobile and kiosks are fairly common outputs developers deal with today. Developers could spend time coding additional output support as IoT becomes more prevalent, but that’s the point. It’s a time sink.
The case for using a headless CMS
Enter headless CMS which solves many of the issues we see in custom CMSs related to the data output. By decoupling data and business logic from the device and display, a headless CMS allows data to operate independently from the display layer. This delivers meaningful productivity gains and elevates a lot of the challenges developers are grappling with today.
Headless CMSs also deliver on the user/ author side of the equation as well. Because the end-user/ author experience remains independent from the developer experience, it is able to evolve over time independently from the ever-changing demands of the developer. So headless CMSs are a great start at solving the challenges facing developers today.
A paradigm shift is taking place
With IoT you can still push data and deal with the output requirements. But what happens as Microservice architectures gain traction with developers? Here the issue isn’t just about display support and end-user/ author productivity gains. Now, you’re wrestling with the amount of data your application must deliver, and perhaps more importantly how the world around you is consuming that data.
When it’s another application that is interfacing with your application a pull paradigm works better. It’s not reasonable to expect a complimentary service to deal with huge amounts of data that will only partly be used.
Isn’t it better to allow the application you are interfacing with to pull the data it requires to fulfill its current requirements? I say current because the data required will surely change as that application developer evolves their product. In fact, you want that evolution to take place independent of your time. The more flexible your application is at satisfying the needs of other applications around it, the longer it will stay viable in the marketplace.
Enter GraphQL
One of GraphQL advantages over traditional APIs is its ability to allow for more granular and relational data gathering. This more closely mirrors how developers are accustomed to obtaining data via an ORM. Over time, various leading languages will be offering deeper and deeper interfaces directly to GraphQL data. Eventually, it will just be perceived as another data store and abstracted.
The case for developing your own CMS, no matter how simple the application grows weaker.
Today, headless CMS systems, with it’s JSON-API compliant interface, solves many of the challenges and relegates all but he most heavily funded CMS efforts to the graveyard. They allow you to evolve your development approach and over time, prepare you for modern architectures.
As GraphQL’s tool set matures, allowing quicker and easier assembly of data queries, GraphQL will unlock the true power of a headless CMS, which will become an essential microservice in nearly every project with an interface made for humans.