- 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.
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.
https://dev.to/michaelstaib/get-started-with-hot-chocolate-a...
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.
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...
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.
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
so it's not unique to GraphQL
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.