Ranter
Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
Comments
-
Use graphql when you are a frontend developer who has no idea how backends works and also want your software to be barely usable
-
dnsProbe3935yI am a full stack dev and recenly did a POC around GraphQL for one of my upcoming Projects. I know the support for GraphQL is not really good for NET, but for NodeJS is pretty good. There are a couple of benefits I did like, for example, I don't don't have to declare a new endpoing everytime I have to write an API and underfetching and overfething problem it solves. What I didn't like was the idea to declare a seperate GraphQL schema in addition to my DB schema and when consuming the endpoint every call needs to declare the list of fields it needs.
-
I'll use graphql when I don't have access to a reliable and well maintained API gateway that handles consolidation in a way that doesn't break things constantly, and I have to deal with a large number of heterogeneous APIs on my client.
After using graphql, I will say I have mixed feelings. It has good points in terms of parallelizing requests, and is reasonably easy to set up. Used well, it can dramatically reduce the number and complexity of FE deployments.
I've run into the following issues:
1. It induces a significant perf hit to transaction time vs a solid API gateway written in/for a more robust language/runtime
2. Using it in a FAAS scenario generally exacerbates problem 1 with an exponent
3. The buffering schema abstraction is a cool idea, but doesn't replace sane API versioning and deprecation efforts
4. A poor resolver implementation makes problem 1 even worse, and is more likely given the nature of the runtime used and the front-endedness of the people writing it (ime)
5. Mutations become architecturally problematic as they don't generally need to encapsulate more than one API per update, and when that occurs Kafka/ETL is generally a more sound approach for maintaining source of truth in the distributed backend. At best it usually becomes client-mutation with extra server hardware.
6. Client-side graphql implementations are lumbering package whales. Change my mind 🍿
7. I have ethical concerns regarding facebook. It's the "is it ethical to benefit from Nazi science" thought exercise, but obviously to a much lesser degree.
It's a tool at the end of the day, there's times where it makes sense, and times when it's a golden hammer.
Full stack devs, who use both: When to you choose GraphQL over REST and vice versa? What has taught you the reasons why?
Just trying to avoid the gotchas on a critical project coming up.
question