A lot of people in this thread are criticizing GraphQL.
The reality is that GraphQL is a great tool for one job: building APIs that scale across thousands of engineers, billions of users, and many megawatts of machines. This is what we use GraphQL for at Meta.
To make it work well, it takes dedicated teams building infrastructure that makes the DevX great. It takes many years to build this out across various backends, clients, and internal tools. We have open sourced some of this infra — the GraphQL spec, Relay, GraphiQL, etc.
But there are many tools we built that we have not open sourced yet, largely because they’re tightly coupled to our internal ORMs, runtimes, error handling, authentication and security systems, and so on. I wish we open sourced more of our GraphQL stack, so more people could experience the awesome DevX we have internally.
At the same time, GraphQL is a tool. No tool can be used all the time for everything. Meta’s 3rd party APIs still use REST for this reason; some internal services use Thrift; etc.
It’s up to you to evaluate the tools available to build the way that makes sense for your business. Because some parts are available off the shelf, but others often need to be built in house, it is up to you to understand that cost and evaluate whether it is worth it for your use cases.
My hope is that as time goes on, more dev tools startups come in the fill the gap in tooling around client libraries, auth, security, and so on to make GraphQL a good choice at smaller scales, too. The DevX is that good when you get it right.
GraphQL is particularly useful for data intensive applications. That is what we use it for. I frequently see people try to use it for simpler applications and give up quickly because it does have a steep learning curve, if you are trying to do it right both on server and client.
The reality is that GraphQL is a great tool for one job: building APIs that scale across thousands of engineers, billions of users, and many megawatts of machines. This is what we use GraphQL for at Meta.
To make it work well, it takes dedicated teams building infrastructure that makes the DevX great. It takes many years to build this out across various backends, clients, and internal tools. We have open sourced some of this infra — the GraphQL spec, Relay, GraphiQL, etc.
But there are many tools we built that we have not open sourced yet, largely because they’re tightly coupled to our internal ORMs, runtimes, error handling, authentication and security systems, and so on. I wish we open sourced more of our GraphQL stack, so more people could experience the awesome DevX we have internally.
At the same time, GraphQL is a tool. No tool can be used all the time for everything. Meta’s 3rd party APIs still use REST for this reason; some internal services use Thrift; etc.
It’s up to you to evaluate the tools available to build the way that makes sense for your business. Because some parts are available off the shelf, but others often need to be built in house, it is up to you to understand that cost and evaluate whether it is worth it for your use cases.
My hope is that as time goes on, more dev tools startups come in the fill the gap in tooling around client libraries, auth, security, and so on to make GraphQL a good choice at smaller scales, too. The DevX is that good when you get it right.