For the longest time all Open Source LAMP Content Management Systems were completely separate ecosystems. Each of them were creating islands of their own to host their own content repository and exclusive templating engines and so on.

Even if the systems themselves were Open Source, systems like WordPress and Drupal (up to version 7) were essentially locking developers and customers to their exclusive bubble. There were efforts to bridge content management tools with protocols like CMIS (Content Management Interoperability Services) that allowed different content management systems to inter-operate over the internet.

CMIS is, and continues to be an Open Standard that is supported by many products. The trouble with CMIS is that it is somewhat complicated to implement - this has left it used by enterprise heavyweights, but not so much on the dime a dozen CMS projects that make up the mass of the web.

In the mid 2010's mainstream Open Source CMSes started to gain HTTP driven APIs, known as RESTful APIs. REST APIs are an improvement over the custom interfaces in uniformity and CMIS in ease of use, they're not as open as the projects would like you to think they are.

CMS REST APIs are Proprietary, while GraphQL is a Standard

REST is a not a standard, but an architectural style. This is why there is no "official" REST specification like there is for CMIS (itself based on the SOAP protocol). By large this is of little significance to developers working with RESTful interfaces, but on a higher level it represents a problem.

If you've bought into a CMS with the promise of full decoupling, then moving from a CMS to another with a project specific REST API is hardly trivial. The concepts behind different CMSes are different, which can make it hard to describe them in the same API. But essentially this leaves developers and clients alike in the position that they are tied to a certain REST API, be in the one from Drupal, eZ Platform or WordPress.

The GraphQL standard initiated by Facebook, essentially combines the best parts of a REST API and CMIS for CMS developers. It's easy to use and provides a complete definition that all tools should conform to. This makes it possible for developers to truly decouple from the backend and their respective ecosystems. Learning the basics of GraphQL is a skill that is fully transferrable between CMSes.

The switch between a standards compliant Content API as such as Contentful, a CMS driven one or a completely custom built one can be trivial to do. And if it's not, then the vendor will need to fix their GraphQL implementation to conform to the specification.

The GraphQL standard is not exclusive to any specific system and it does not state how things should be stored or whatever, it just defines how they should be exposed to the outside world.

GraphQL is young, but used by billions daily at Facebook

GraphQL is a young standard, only published in September 2015. Yet it's already powering billions of request daily at Facebook and is being adopted by respected publishing establishment such as the Financial times: GraphQL at the Financial Times

At this point the CMS vendors are only starting to pick up on the standard, and there are some implementations already in place for CMSes as well as frameworks they are built on as well as completely new systems built on the standard from ground up:

With the GraphQL specification in place, moving forward with GraphQL for public facing properties in 2016 is something that is feasible to do. For read operations on a JavaScript powered Front End built with React or Angular, or a mobile application - GraphQL is a solid technology choice.

Moving your CMS backend from the proprietary REST API to a standard like GraphQL is something that is quite a bit further down the road. Open Source CMSes come and go, but large commercial web vendors like Google and Facebook are likely to be around with longer term investments in open standards for years to come.

This is why GraphQL is likely a better long term investment than any CMS specific REST API.