>Am I alone in thinking this is a ridiculous solution to replace traditional REST endpoints?
You're not alone. I went down the GraphQL path a year and a half ago. I was telling everyone it was going to be the future, then I got tired. GraphQL requires a lot of configuration and setup to get working right. The decent implementations of GraphQL are all proprietary solutions like Apollo. When you feel like you're spending half your time setting up a simple backend and API, it's a red flag.
Despite efforts made to improve GraphQL, things like caching are still a nightmare are in comparison to the out-of-the-box browser caching you get with a traditional REST endpoint (because GraphQL implementations all use POST by default). No plugin I tried for Apollo gave me proper caching, I even tried to hack something together at one point.
The smaller payloads are definitely great and being able to query for specific pieces of data is fantastic, but it's a lot of work and it's not perfect. I found using it can make a simple app incredibly complex, then you have to maintain the schemas, implementing data loaders requires some work to get done right. There is a reason a lot of backend developers push back against the suggestion of using GraphQL.
Don't get me started on things like authentication, file uploads and protecting your server from being DDoSed or driving up your cloud computing bill by someone creating expensive queries. There are solutions to these things, but they require more configuration and work to get right. The fact out-of-the-box someone can create a GraphQL server and essentially make themselves vulnerable to a big AWS bill or have their app brought to its knees trying to fulfill an intentionally complicated query is kind of concerning, these things should be default settings.
I went back to REST about six months ago and never looked back.
You're not alone. I recently took over an Elixir application that uses Apollo/GraphQL. To say the least, making a simple change requires traversing and updating a bunch of code in several areas. For example, if I want to add a single field in an endpoint: Update Apollo, update the GraphQL schema, update the resolvers, update types, update the schema. Makes me wonder what the advantage is. Would just love to go back to a basic REST implementation. Elixir's routing pipeline handles that so well.
Interesting. We're using apollo-server on top of an existing REST api and to add a single field our process is:
- update the graphql schema
- implement any resolvers
and we're done. More things happen in the background, but a developer doesn't have to do anything. It's all auto generated when the file is saved or a build happens.
I'm lukewarm on GraphQL myself, but good tooling can definitely go a long way here. https://hotchocolate.io/, in the Dotnet ecosystem, is one of the better versions of handling some of those longer tail items out of the box.
Rigging it up to EFCore is a pretty magical experience. Because projections are built into the language with LINQ, the two paradigms can be wired together in a pretty delightful way.
I set up GraphQL with express-graphql on the backend and then I just use fetch on the frontend. I didn't feel the need to use Apollo. It felt fairly simple.
I just define the schemas in Javascript, which works fine.
But we also use standard HTTP POST + path based routing for some things. Like file uploads.
>Don't get me started on things like authentication, file uploads and protecting your server from being DDoSed or driving up your cloud computing bill by someone creating expensive queries.
These are API Management requirements, and they require a different treatment from the traditional approach, just granting access and checking rate limits is not enough. One approach is to statically analyze the query and determine how it will affect your backend, and how much data it intends to retrieve. Products are starting to come into the market, recently IBM API Connect had this announcement about it: https://community.ibm.com/community/user/imwuc/blogs/rob-the...
I’m a huge fan of GraphQL but your comment about proprietary triggered a memory.
When searching for answers on how to do things like pagination, the answer I often got was “Oh just use this proprietary thing” and that is NOT a solution.
I’ll concede that using GraphQL in a great way requires FAR more setup than REST but the benefits are worth it, to me.
> can create a GraphQL server and essentially ... have their app brought to its knees trying to fulfill an intentionally complicated query is kind of concerning
I've seen this denial of service attack against SQL/Relational databases as well, and I imagine if it triggers more read replicas, that a large bill could be caused as well
You're not alone. I went down the GraphQL path a year and a half ago. I was telling everyone it was going to be the future, then I got tired. GraphQL requires a lot of configuration and setup to get working right. The decent implementations of GraphQL are all proprietary solutions like Apollo. When you feel like you're spending half your time setting up a simple backend and API, it's a red flag.
Despite efforts made to improve GraphQL, things like caching are still a nightmare are in comparison to the out-of-the-box browser caching you get with a traditional REST endpoint (because GraphQL implementations all use POST by default). No plugin I tried for Apollo gave me proper caching, I even tried to hack something together at one point.
The smaller payloads are definitely great and being able to query for specific pieces of data is fantastic, but it's a lot of work and it's not perfect. I found using it can make a simple app incredibly complex, then you have to maintain the schemas, implementing data loaders requires some work to get done right. There is a reason a lot of backend developers push back against the suggestion of using GraphQL.
Don't get me started on things like authentication, file uploads and protecting your server from being DDoSed or driving up your cloud computing bill by someone creating expensive queries. There are solutions to these things, but they require more configuration and work to get right. The fact out-of-the-box someone can create a GraphQL server and essentially make themselves vulnerable to a big AWS bill or have their app brought to its knees trying to fulfill an intentionally complicated query is kind of concerning, these things should be default settings.
I went back to REST about six months ago and never looked back.