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
-
we looked into it for a project, but decided that it doesn't provide any benefits for us compared to an "old-fashioned" RESTful API.
it _might_ be a good choice in situations where the frontend changes very often, but the backend (for some reason) not, but in general - i don't think it will become a "big thing". -
The benefit is if the consumer applications have wildly different and unpredictable requirements, and your data is composed from different sources.
In our case we had a larger company with their set of 30+ consumer applications that were fetching data from us. Some of the data was in our local database, while some had to be fetched via queries in realtime on demand. With graphql we could just assemble this as needed, of course taking care to optimize the queries with caching and making sure the database is queried as few times as possible per resolve via joins and projections. It varies how well the different libraries help you with this.
It's completely pointless if you are consuming from your own dataset with 1 client and the datacontract rarely/never changes. -
Instead of building and providing countless endpoints to fetch data and letting the FE make many requests and then fiddle together all the data, with GraphQL you just have one endpoint and the FE asks for what it needs and gets it in the correct, desired structure.
If you have some plain, simple, non-hierarchical data from just a few sources, you should keep REST.
Current state of NPM packages...
I know I am that kind of user 😂
GraphQL question here!
So i recently noticed (few years after everyone?) That graphql seems popular... I decided to try it out, but after playing with it a bit, the conclusion I came to is, that it's a great idea from FE point of view, but for the backend not so much.. a simple sql to return data to ui turns into a bunch of parts, all independant and with even the simplest relationship to some other entity the whole thing becomes very not optimized and when googling about it, all i found were some very awkward libs for work arounds to force everything into 1 optimized query again... But wait, i already have 1 optimized query in my rest api 😆
I don't understand if I'm missing the brilliance of graphql that everyone saw, or is everyone fell for the hype and use a stupid tool and pretend it's cool? 🫣
question
graphql