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: https://www.krakend.io/blog/what-is-an-api-gateway/ 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!