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
-
@wojtek322 either way, the proper way is to handle the key relationships on the backend, not the frontend.
-
Basically graphql solves the pain on the frontend of having to query each sql table from the backend separately via multiple REST requests and then fitting the data together with ids.
This is a bit exaggerated. Sometimes a couple of tables are already merged, but basically it holds because you don’t want to send redundant data, so it‘s separated.
With GraphQL you specify what you want on the frontend and get exactly what you want, no redundant data, not wasted bandwidth and no need for manual joining. -
@retoor every rest api that is complex enough eventually needs to make a decision. Either send everything and risk that you wasted bandwidth because not all data is needed, or separate the data into multiple requests so that the frontend can ask on demand, but needs to fit it together manually.
If you wanted to serve the data in perfect structure for every conceivable use case, you would have a ridiculous amount of endpoints because they would grow exponentially. -
@retoor yes, rest apis should not be mappings to tables.
But you cant have rest endpoints delivering the exact data.
You always need to have compromises because otherwise the number of endpoints would grow into thousands.
It might work for small simple scale stuff, but any real world api is complex enough that it has to make compromises. -
@retoor the caching needs to be done on the layer which interprets the graphql requests and queries the data from the db.
You just showed an example of a case where you need to separate the data into multiple rest calls if you want to have caching on one part, but not the other.
You answered your own question, why the data can not always be delivered as it is wanted on the frontend.
Compromises. -
@retoor no idea what you want to tell me with your last comment ^^
Look, in the real world the vast majority of apis is rest. And that‘s fine. For most of them graphql would be overkill.
It would require to invest 90% of work to achieve the last 1% to being "perfect".
It’s just not worth it.
I‘m not advocating for using graphql everywhere.
I‘m just trying to explain what graphql is for and what problems it solves, because so many devs are really, really confused and misinformed about it. -
@retoor Actually it's my first time making a user service too :D
I only ever made system services for my servers and other random stuff.
And yeah it's somehow working better than expected.
Also works really nicely with combination with a conventional RSS reader, I use Akregator and if I accidentally close a notification or want to go back to one that I closed I just launch Akregator. -
I just have one question, a rhetorical one as well!
How the fuck idiots like that get the job and even more, how they become senior developers? I just can't believe it!
Seems to me that this is backend dev which one day decided to be fullstack instead with zero real experience with frontend (approach is - its fucking FE, I'll just wing it).
I mean the whole fucking point of graphql is to reduce number of requests to 1 if possible. -
@Lensflare I tend to find it helps say that graphql helps solve the issue of brittle dependencies (as in a random request in a chain fails) of requests rather than anything to do with data, that's more of a side bonus
-
Your senior dev is
1. a fucking idiot
2. trying to teach you a valuable lesson.
Probably the first one.
When my family first bought our property from a neighbor, he came over, gave me a machete to clear bushes on a hill.
I spent two weeks clearing that hill with that machete.
After two weeks, he came by and handed me a weed wacker.
"Now you know what not to do."
when your code is a mess but everything work out in the end
When you keep getting +1s on a rant you posted a month ago.
Go big or go home.
I don't really understand the flow that my senior dev wants to do for graphql. Normally graphql should be 1 request for your data with what you need but this is proposed flow.
1) Get all custom fields/columns of "products"
2) Append the custom fields in the frontend by all hardcoded default fields in my object
3) Fetch the relationships
4) Fetch the custom fields of the relationships
5) Add hardcoded default fields + Append that to my "master object"
6) Fetch the custom fields of "secondary key" that is not included in step 4 or step 1
7) append that to my master object
8) Fetch data
So the frontend needs to be rebuild the database structure and send 4 (or 5) graphql requests to load in 1 table... I don't know how to describe it anymore lol
This flow has to be redone for every table
rant