Response to “GraphQL is not meant to be exposed over the internet”

This is a response to two articles I stumbled upon the past few weeks:

• https://devops.com/graphql-as-a-meta-layer/ (which links to the second article below)
• https://wundergraph.com/blog/graphql_is_not_meant_to_be_exposed_over_the_internet

Having worked on two large public GraphQL APIs in the past, this concerned me. Let’s start with that first article and read why GraphQL is not meant to be exposed over the internet.

In fact, most GraphQL APIs are not public. APIs.guru only charts 35 public GraphQL APIs — notable services include GitHub’s GraphQL API, Shopify Storefront and GitLab. This number is minuscule compared to the total number of public APIs, at over 24,000 according to ProgrammableWeb.

I’d argue that most APIs (all styles) aren’t public, so this is a bit of a moot point. Even if we did bite the bullet and said that is especially true for GraphQL, this doesn’t entail that the cause is that GraphQL is not meant to be exposed over the internet. (This is kind of circular isn’t it. It would be more interesting to go into why it is not meant for it, which we will later!)

Facebook, the creator of GraphQL, uses an internal GraphQL API to power all of its apps across Android, iOS and web browsers. (This is not to be confused with their public Graph API). Interestingly, if we look at Facebook’s use of GraphQL, we see these endpoints are not exposed to the public web at all.

That’s true, but then again if we were only allowed to build GraphQL APIs the way Facebook did it, we’d need to start learning Hack really quickly and build giant monolithic GraphQL APIs. Yet not everyone does it this way. Just because a technology was developed under a certain context does not invalidate it for every other use case or context.

The author then goes ahead and explains how they foresee GraphQL to become this “meta layer”, an API layer that then queries other sources of information like existing REST APIs. Notice the contradiction? On one end GraphQL is not meant to be exposed to the internet because Facebook did not do it, yet using it as a gateway to other APIs is fine, something that was never intended by Facebook in the first place! (GraphQL API in the monolith, fetching data through a rich domain layer / databases). So which is it, only building GraphQL APIs the way Facebook does it, or are we OK with using it for different purposes and contexts?

Moving on to the linked article which contains the most criticisms against using GraphQL as a public API.

You’re probably not GitHub, are you?

What are the trade-offs that GitHub is willing to accept when publicly exposing a GraphQL API? They have a whole team behind their GraphQL API, making sure you, the user, does not accidentally or intentionally break their systems. You can watch videos of them talking at conferences about the complex systems they built to secure their API and keep it stable. They’ve built tooling for GraphQL specific analytics to get better insights into API usage.

I was part of GitHub’s API team, so I want to be careful on what I’ll say here. The only thing I’ll say is that open source tooling for GraphQL is in a great place, and that keeping the API stable and secure is a lot more about everything surrounding GraphQL than GraphQL itself. GraphQL-Ruby is amazing. Sure, it is different than a REST API, maybe a bit more complex initially. However, having worked on both, at GitHub, I would not say one was harder to maintain than the other. In fact, GraphQL tooling is so great today that most of the problems highlighted in the article are solved quite elegantly.

And again, there are plenty of useful technologies that started at big companies with a lot of resources that are now used everywhere, including the smallest companies (React for example). You’re probably not X company is just as bad a reason for not using a technology than using a technology because X company does it. There’s plenty of other, better ways to evaluate if a tool or technology is right for you!

Bug bounties everywhere

Is there a reason why companies like Shopify participate in bug bounty programs? They seem to be aware of the complexity of securing a GraphQL API. They invite security experts to help them make their publicly available GraphQL API more secure. Do you realize that your GraphQL API is as vulnerable as Shopify’s?

Shopify does not participate in bug bounties only because of their GraphQL API. They were enrolled years before GraphQL was even a thing. This is a good practice with any feature, including other API styles. Are there more bounties related to GraphQL? I don’t have the data, we could probably pull some numbers here. Maybe initially due to lack of experience? That’s certainly a thing to keep in mind when picking a technology. Does it make it inherently insecure, not meant to be exposed publicly? Absolutely not.

The conclusion of the article is that the author’s business can solve some of these problems for you, using something that seems similar to the benefits you would get by using persisted and allow-listed queries, which are great tools for GraphQL APIs. In the end, both articles have a bit of a fear mongering vibe to them which I don’t think is helpful for anyone.

I’ve talked about public GraphQL APIs maybe not being the “sweet spot” for the technology before, and highlighted a few difficulties with implementing a good one. I’ve also wondered why we weren’t seeing more public GraphQL APIs 2 years ago. Anecdotally, I’ve been hearing about more and more of them, and most of the issues I mention in these articles are getting solved beautifully by the ecosystem of tooling. I’m not ready to say GraphQL is not meant¹ for it, not today at least.

¹ Unless we mean meant as in “it wasn’t invented with that in mind”, which again, doesn’t entail it cannot do these other things effectively.