It almost seems like at this point GraphQL is not even an exciting new thing. I'm seeing more and more GraphQL job postings (Looking for an engineer with 10year+ experience 😎), and so many new people, even new developers being told they need to learn GraphQL to be successful. Looking at Google trends, this makes sense:

https://medium.com/@mahnitin2176/evolution-of-the-api-graphql-state-3f90e92db07b

Libraries have matured, companies are using it in production for years now, so what's next? Here's a few things I'm excited about and where hope seeing some improvements on this year.

Transport Specific Implementations / Optimizations

The GraphQL specification does not mention any specific transport or serialization formats. While this is good news since this allows us to be creative with these variables, it also feels like that's an area we are a bit afraid of playing with since no real recommendations are given. I see a lot of potential in adapting GraphQL implementation to specific transports, especially when it comes to performance, something that is not trivial when maintaining GraphQL servers.

In fact that's been a pretty big criticism of GraphQL over the years. Why are we making one giant request when that's not as cacheable, hard to parallelize, and based on problems seen with HTTP/1 ? One thing we don't talk about is that we can keep a lot of GraphQL benefits, while moving away from that 1 large HTTP/1 request pattern. There's a lot of ideas around that concept, most famously the @defer and @stream directives, which allow a client to annotate certain fields/fragments to tell the server to send us the fastest initial response possible, and defer or stream the rest results back over time. The great thing here is that we gain a lot of what a classic endpoint-base HTTP/2 API would give us, but with the same exact declarative querying and tooling the GraphQL type system and query language gives us. In fact, I can totally see a GraphQL over HTTP/2, or over a long running connection working perfectly fine if benchmarks can prove that multiple smaller requests would be advantageous to you versus computing everything in a process over a single HTTP request. Vulcain comes to mind, which could be quite close to what I'm describing.

It even feels like subscriptions has been something that's been lagging a little bit behind the rest of the specification because it is so dependent on the transport used. The specification is simple to follow, but the details in the transport layer are scary and hard to get right. I'm hoping we'll see more companies and GraphQL implementation take more risks 🀘

Special mention to the graphql-over-http specification (work in progress), a great step towards paying a bit more attention to transport concerns with GraphQL APIs.

Alternative Execution Algorithms / Engines

The GraphQL execution engine is what allows a server to support a myriad of different client needs, but it comes with quite a large overhead. Every improvement to the execution algorithm has the potential to improve the performance of a lot of GraphQL APIs out there.

One thing I'm particularly excited about are compiled queries. There's some cool stuff coming that could definitely reduce that over head by a lot. Here's another one by Zalandos.

More Focus on GraphQL's Tradeoffs

My bet is that we'll start talking a lot more about GraphQL's tradeoffs this year as more and more companies have been maintaining GraphQL APIs for a while now. This is not a bad thing, but simply starting to be honest with the technology we're using so we can start focusing on solutions. I already feel this from discussions with other engineers in the industry.

Overall I'm excited to see GraphQL mature as a technology and looking forward to what the community will achieve this year πŸš€

Enjoyed the post? Subscribe to Production Ready GraphQL!