I can’t remember when I heard about the GraphQL but it was eons ago in internet time. While discussing the clients of Platform of Trust, the idea of offering GraphQL API to data has popped up here and there.
Hype is over and those who have found good use for the GraphQL have adopted it. This makes sense since GraphQL is not the REST killer as some people indirectly claimed in the drunken moment of the hype party. Gloriuous silver bullet dreams have ended and real use cases have been found. In some industries the adoption has been fast. Some claim that the adoption of this technology has been one of the fastest in the tech universe.
GraphQL ecosystem is still a teenager?
Some of the developers and project managers do not see the GraphQL in their daily customer cases. It seems that the GraphQL ecosystem is not ripe yet.
I tend to think alike. Same goes for the people who are working with bigger corporate systems and platforms. The tooling is not as sophisticated and versatile as it is in REST world. How could it be? REST took over the API world over time and the hype around OpenAPI spec and design driven approach gave extra boost to REST APIs.
- GraphQL was developed internally by Facebook in 2012
- Publicly released in 2015.
- November 2018, the GraphQL project was moved from Facebook to the newly-established GraphQL Foundation, hosted by the non-profit Linux Foundation.
Compare that to timeline of REST:
- 2000, The term representational state transfer was introduced and defined by Roy Fielding in his doctoral dissertation
- 2002 Amazon absorbed modern non-SOAP APIs
- REST vs SOAP “war years”
- Around 2011 the amount of REST APIs exploded to new heights
- The Swagger API project was created in 2011 by Tony Tam
- In November 2015 a new organization, under the sponsorship of the Linux Foundation, called the Open API Initiative.
Remember the “spec wars” time couple of years ago? RAML, API Blueprint, Swagger were all pretty much side by side. Then in brief time Swagger became known as OpenAPI spec under the wings of Linux Foundation. In short time after 2015 OpenAPI spec became the default spec format for REST APIs. Then the tooling around winner exploded to new heights.
Copy the process and path to industry adoption and growth
I have a hunch that the same winner takes it all race for pole position is going on in GraphQL ecosystem. I admit that I’ve not taking a deep thorough look at the current tooling and buzz around GraphQL. Some of the vendors are getting traction and it’s a question of time when we find out which of the solutions are adopted most widely. GraphQL even followd the Swagger path and established GraphQL foundation to act as umbrella for the ecosystem. Again Linux Foundation was involved. There’s nothing wrong with these copy-cat actions. It worked for Swagger, why would it not work for GraphQL?
Airbnb, Apollo, Coursera, Elementl, Facebook, GitHub, Hasura, Prisma, Shopify, and Twitter together formed a new, vendor-neutral foundation that will provide unified governance and stewardship for GraphQL. From those I’ve seen a lot of buzz around Apollo and my guess is that it might be the vendor to act as the “Stripe of GraphQL”. Stripe is the example case and pioneer in (REST) API driven economy. Perhaps Apollo will take the same position in GraphQL ecosystem. What ever happens, some sort of consolidation and clear leaders and pioneers are needed in the GraphQL community.
REST is not dead
The comparison of GraphQL against REST is quite common. If you want to read rather thorough comparison, you might want to look at rather recently (Apr 2019) written “REST vs. GraphQL: A Critical Review”.
One of the lowsy things of GraphQL is the difficulty of adoption. The start is often cumbersome compared to well designed and implemented REST APIs. The reason is mostly that with GraphQL you need good domain understanding and with REST you hide it.
Another reason for the low amount of public discussion about GraphQL might be what Aidan says, “Internal APIs are not talked about as much. This might be the reason for the decline in your feed.”
None Shall Escape the API Design
Teams behind great REST APIs have used a lot of time and effort in designing the API. It has been built for a purpose and to solve a real problem. It follows the conventions and uses standards accordingly. The documentation is fluent, accurate, uptodate and provides working easy to understand code examples. The design is more often tested with mockups and testing is done by prospect customers. After the design has been found to be good enough, then the logic is implemented. The developer experience for that part is tested before spending lots of resources in the implementation. In brief, it takes shit load of effort to build a great REST API. Many of the “REST” APIs out there are not that great.
With GraphQL the adoption to support customer needs often is reactive. You put out the API and then analyse the use. Based on the real use by developers, you optimize the slow queries. Of course good approach is to do some design in advance and limit the options. Otherwise you might end up doing yet-another-sql access to database. That kind of bloated and blunt approach will result is impossible to onboard APIs with bad response experience. Narrowing the scope and options in design phase offer better changes to succeed with actual consumers.
In short, GraphQL API’s developer experience is in optimal cases both pre use designed and post use refactored. Design is there in any case. None Shall Escape the API Design - not even GraphQL.
Some more to read from 100 Days DX
- #85 - Great Developer eXperience requires fluent internal workflow
- #84 - Theory of Economics of Developer eXperience
- #83 - The Space of API Design Decisions is missing
- #82 - Purpose of API Evaluation Framework
- #81 - Should We Move to Stack Overflow?
- #80 - Four data driven ideas for improving API documentation
While you are here...
Check out Platform of Trust in which I've worked to enable best possible developer experience!