The  API gateway space is filled with vendor solutions and is super  competitive in general. Most of them specifically tackle problems  related to endpoint based APIs, and surprisingly I haven’t seen that  much of them appear when it comes to GraphQL gateway. Besides the Apollo Gateway,  we haven’t seen that many vendor solutions propose a solution to the  problem, even though we see it being covered a lot in talks and blog  posts. I’m actually surprised big cloud vendors haven’t jumped on this  yet (AWS has AppSync,  but no general purpose GraphQL gateway yet). I have a strong feeling  we’ll see some of those appear soon and if you’ve seen recent talks of  mine you might know already I have some concerns on how we should design  these. The perfect way to describe my feelings is actually a piece from  the ThoughtWorks Technology Radar:

We  remain concerned about business logic and process orchestration  implemented in middleware, especially where it requires expert skills  and tooling while creating single points of scaling and control. Vendors  in the highly competitive API gateway market are continuing this trend  by adding features through which they attempt to differentiate their  products. This results in overambitious API gateway products whose  functionality — on top of what is essentially a reverse proxy —  encourages designs that continue to be difficult to test and deploy. API  gateways do provide utility in dealing with some specific concerns —  such as authentication and rate limiting — but any domain smarts should  live in applications or services.

An other favorite of mine is a blog post by the folks at Krakend: Which I would very highly recommend as a reading on what we really want our API gateways to do, and *not* to do.

My feelings is that we’ll see some vendors try to build these “Overambitious GraphQL API Gateways” by trying to feature-pack their  gateway offering. They’ll be very appealing but won’t necessarily lead  to the best patterns over the long run. The two main things I’d want to  focus on are:

  • The GraphQL gateway should be just another service.
  • The GraphQL gateway should not know anything about business logic / resolvers that belong to the backend services.

Feature wise, I’d like to see GraphQL gateway handle these things, for example:

  • Schema validation / registry
  • Rate limiting / Query Costing
  • Circuit Breaking / Retries / Partial responses / Everything Resiliency
  • Metric collection
  • Simple data manipulations (to fit service calls into the final GraphQL schema for example)
  • Schema evolution tooling (Field usage, deprecations, sunsetting fields, etc)
  • Query execution (parallel requests, query plans, etc)

Overall I really see the appeal in a GraphQL gateway/aggregator, but we have to  resist the temptation of making it a big, centralized, overly ambitious  gateway! The GraphQL gateway in Gloo, by Solo is a very interesting proposal. I’ve also been thinking of working on a solution of my own these days 🤔

Oh also, I gave a talk in this general line of thought at GraphQL Day Toronto a few weeks ago, it’s now available on YouTube:

Any other GraphQL Gateway ideas/products I’ve missed? Let me know in the comments 👀 As always, hope you enjoyed these thoughts, thanks for  reading!

Enjoyed the post? Subscribe to Production Ready GraphQL!