During our everis innovation session, first reactions to GraphQL were "here comes yet another hype" and "isn't this just replacing apples by pears?".

However, as we continued with the demos and discussed its benefits in-depth, there were at least a few words of acknowledgement, surprise and even hunger for going ahead with some real-life PoCs on GraphQL (nothing personal, George Lucas!).

All in all, GraphQL will be an interesting alternative for projects and will satisfy the following conditions:

  • Client screens requiring data coming from different datasources but in an aggregated manner to avoid N+1 calls
  • Strong focus on end-user performance, aiming to minimise the bits over the wire, due to high concurrency or poor latency
  • Not a typical CRUD application, but a complex querying application, such as a dashboard-based or search-based application
  • Many consumption scenarios requiring different versions of the same data
  • Low risk project and will be a first attempt to use this technology, ideally an internal non-business-core application.

Finally, it would be worth mentioning that it doesn't need to be necessarily either one or the other. You could easily expose a /graphql endpoint together with a /rest endpoint over the same base URL, allowing clients to decide which they prefer to use in each scenario. Alternatively, GraphQL could work as a Gateway in front of your REST APIs, which may or may not be exposed to end consumers.

This would definitely be an architectural decision to make for each specific case, but it's good to bear in mind that there might be hybrid scenarios in which both REST and GraphQL can work together.

So, as we come to the end of this GraphQL series, what are your thoughts or experience with GraphQL?

Will it actually become the new REST?

You can find more information about GraphQL and try out your own examples in: