Should I have multiple GraphQL instances or just a single one?

Question

My company runs a microservice architecture that has 50+ services that are powered by a single GraphQL endpoint, which orchestrate the calls among our services, powering our Android & iOS applications for our end-users.

We're in process of creating a new product that's going to not be used by those end-users, but for companies that offer goods for our end-users through our apps. TL;DR: things like showing performance data regarding their sales through our platform.

Since the data requirements for this new product and our apps are hardly different, we're under discussion of creating a new GraphQL endpoint just for this product, because we're afraid of turning the original GraphQL layer on a monolith that would behave as a single point of failure in case of a disaster, for instance.

Looking into GraphQL's website, Facebook posts, Apollo's Principled Graphql, etc etc, it's quite easy to see the "single endpoint" phrase somewhere. I'd like to know until when this is still valid.

Anyone recommendation/opinion, or even testimonials on who have been on this discussion as well is appreciated. In case your company had this discussion before, what was the final decision made, what was taken into consideration?

Answer 1

I'd suggest maybe thinking about the problem differently.

You have a couple of problems you're dealing with, if I am understanding this correctly:

• You are about to expose internal APIs - or something close to your internal APIs - to external parties for the first time
• You're concerned about the impact of one on the other (e.g. DDoS on the external bringing your internal processes to a halt)
• You're unsure how to best architect GraphQL to share similar functionality across related but potentially different APIs

Is that a good summary?

I'd suggest you should look at an API gateway to protect your external API, regardless of what you choose with your API implementations. You need the authentication and authorisation anyway.

The API gateway also gives you some control over how to route your API calls. If you chose to have identical APIs for internal and external, you could have a pool of these API implementations for redundancy, and only allow the API gateway to load balance between a subset of these. That would mean that even if they were flat out, you should have some reserved capacity to deal with internal requests. (If the load is actually on your back end data sources then that's another issue entirely!)

If you're looking at way to build separate GraphQL APIs that operate completely independently but reuse functionality, you could look at something like Apollo to do this, but I'm not a GraphQL expert.

As I mentioned above, though, your concern about a single point of failure probably needs to consider your back end(s). Regardless of how you segregate your gateways, proxies, GraphQL endpoints and so on, if they're all hitting the same database then a disaster is probably going to bring down your internal and external APIs at the same time.

Hope that gives you food for thought.

Answer 2

In case you came across this question, as I noticed it's on the top of results on Google, I also posted this as a Github issue on the graphql-spec repository and got some good responses from core maintainers of the spec. You can want to check it out: https://github.com/graphql/graphql-spec/issues/569

I'll mark this as the accepted answer for now.