Former Facebooker here. I have some thoughts. IME I find that many people don't have the problems GraphQL is intended to solve. No shade to the author but, as one example, i don't see the word "fragment" mentioned anywhere in this post and fragments are a real issue with GraphQL.
Let me explain the problem GraphQL actually solves. FB, as we know, is an incredibly large mobile app, possibly one of the largest in terms of actual code. Here are some realities about mobile apps:
1. Once released into the wild, that app version is out there forever. At app installs in the billions this is a serious problem. So you need something that handles versioning of your API. You need something to force you think about versioning and support old versions as long as possible. Again, I don't see the word "version" anywhere in this post. Versioning doesn't seem to be a problem the author has;
2. There are a lot of common objects in the FB app. Posts, comments, etc. When these objects become sufficiently complex, you don't want individual teams pulling out random fields. This is one thing fragments are for. It allows a specialized team define the object model and allow other teams to pull out a subset of that data.
3. FB uses an in-memory graph database for almost all things so issues like N+1 queries (which are real issues if you're talking to a relational DB) don't really come up. The in-memory database has a layer over it that does things like enforce permissions and privacy policies on reads and writes. GraphQL auth is really a superset of this. So if you're querying an endpoint for a user and their blocked users (one example from the post), you probably won't have auth in your endpoint because that'll be enforced by the data access layer that already exists and be written and maintained by a team responsible for that data.
Some comments here have complained that GraphQL is a technology for an organizational problem. I would counter that by saying all technology ultimately is tied to organization. They affect each other.
The above was all done to avoid things like privacy leaks, which at FB's scale is a real problem. Speaking from experience, a significant amount of computing power and software engineering time is tied to avoid these problems by the teams responsible as well as other teams to try and detect an unintentional leak.
How I see a bunch of people use GraphQL (not necessarily the author of this blog post) is as a 1:1 map to a relational model beneath it. That doesn't make a whole lot of sense. GraphQL probably isn't for you.
I totally agree with the sentiment here, but disagree with the conclusion.
1. The rest of the world doesn't have facebooks data layer. Ergo, GraphQL is very hard for everyone who's not FB.
2. Turns out GraphQL is actually a really good data API. Whether it's a postgres/mongo/graph/REST data source. Because it's a great mid-point between something as flexible as SQL but as controlled as a REST API.
Here are 3 things that GraphQL is absolutely great at:
- Select a 2 fields out of a 100 attributes in a data model? GraphQL is great.
- Gradually deprecate an old field in a database and replace with a new one? GraphQL is great.
- Want a flexible way to filter/join/paginate regardless of the underlying storage layer? GraphQL is great.
Other API formats suck at this.
Working with GraphQL ought to feel like you're working entirely with your database and sprinking the right bits of transform/validation/authz business logic and then the API that other teams can use is "free".
GraphQL is dying as a replacement to a REST API layer. I think GraphQL will see its second wind as a data API. Microsoft and Google announced their GraphQL data APIs recently.
GraphQL will probably only make sense when it's as close as a 1:1 map to a DB beneath it. Whether relational or NoSQL or graph.
In all other cases, the GraphQL juice is not worth the squeeze.
A lot of people seem to throw everything into graphql without any thought about usage patterns and potential pain points. As a spring user of it, it's been a dream, the front end team loves it and it sure beats repetitive REST endpoints for small/medium/large verions of the same object graph. The unified error handling is great as well. Truly one of the best things to come out in the last ten years.
It depends on how you define "DB" in this context. Ex-Facebooker so I this may have changed but I doubt it. It's fairly fundamental.
At the lowest level, data is stored in MySQL so yes, that's open source. Almost nothing user-facing will talk to MySQL directly because you're bypassing all the privacy, scaling, auditing, security, etc. Some legacy systems are on different MySQL instances but we're talking internal systems, not public-facing.
The in-memory graph database on top of that, which I think you're actually referring to, is called TAO [1]. AFAIK, no, it isn't open source.
All of this is very much designed for the type of data Facebook stores and how it's used (eg "12,345 people liked this" is an easy query but listing all the things you liked can be really expensive beyond the most recent likes).
> How I see a bunch of people use GraphQL is as a 1:1 map to a relational model beneath it.
Yeah I've had trouble with some devs misunderstanding this, this seems to be the source of "omg you can run arbitrary queries" (especially if they've never used GraphQL.
You can't do anything that the GraphQL schema doesn't specify - it's not open ended SQL and joins.
Let me explain the problem GraphQL actually solves. FB, as we know, is an incredibly large mobile app, possibly one of the largest in terms of actual code. Here are some realities about mobile apps:
1. Once released into the wild, that app version is out there forever. At app installs in the billions this is a serious problem. So you need something that handles versioning of your API. You need something to force you think about versioning and support old versions as long as possible. Again, I don't see the word "version" anywhere in this post. Versioning doesn't seem to be a problem the author has;
2. There are a lot of common objects in the FB app. Posts, comments, etc. When these objects become sufficiently complex, you don't want individual teams pulling out random fields. This is one thing fragments are for. It allows a specialized team define the object model and allow other teams to pull out a subset of that data.
3. FB uses an in-memory graph database for almost all things so issues like N+1 queries (which are real issues if you're talking to a relational DB) don't really come up. The in-memory database has a layer over it that does things like enforce permissions and privacy policies on reads and writes. GraphQL auth is really a superset of this. So if you're querying an endpoint for a user and their blocked users (one example from the post), you probably won't have auth in your endpoint because that'll be enforced by the data access layer that already exists and be written and maintained by a team responsible for that data.
Some comments here have complained that GraphQL is a technology for an organizational problem. I would counter that by saying all technology ultimately is tied to organization. They affect each other.
The above was all done to avoid things like privacy leaks, which at FB's scale is a real problem. Speaking from experience, a significant amount of computing power and software engineering time is tied to avoid these problems by the teams responsible as well as other teams to try and detect an unintentional leak.
How I see a bunch of people use GraphQL (not necessarily the author of this blog post) is as a 1:1 map to a relational model beneath it. That doesn't make a whole lot of sense. GraphQL probably isn't for you.