Learn More
Resend Email
7
wojtek322
4h

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
Favorite
Ranter
Comments
  • 4
    4h
    He doesn’t understand graphql. As you said correctly, it should be one request to get all the required data. That‘s the whole point of graphql. You describe the structure of what you want and you don’t have to deal with piecing together all the little fragments by matching ids.
  • 1
    4h
    For step 6, its a secondary key part of the hardcoded default fields but not defined in the db as a secondary key and there is no relationship to that table
  • 2
    3h
    id just do it right and show it, maybe with benchmarks with his idea

    then get fired ofc
  • 2
    3h
    @wojtek322 either way, the proper way is to handle the key relationships on the backend, not the frontend.
  • 0
    2h
    Graphql is kinda bs imo. Collecting and format the exact right data is kinda what our job is in the backend. I know that frontend people like all the data and querying in the frontend directly but that's not how we are married.
  • 1
    2h
    Wait shouldn’t this all be backend based using one request? Or maybe my dumbass can’t grasp the complexity of his brilliant strategy involving all these requests. Or I’ve been doing development wrong all this time
  • 1
    2h
    @retoor looks like you don’t understand graphql either.
    With graphql you still need to SELECT and JOIN the correct data on the backend (speaking with SQL terminology)
    People have this misconception that graphql is sql on the frontend. It’s not.
  • 0
    1h
    @Lensflare that's correct, i don't get it at all. Like seriously. The idea is that you can combine different data sources to one right? Well, that's kinda exactly what is the job of an backender. Graphql is a kind of everything module I guess.
  • 1
    1h
    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.
  • 1
    1h
    @retoor
    > The idea is that you can combine different data sources to one right?

    No, not really.
    You "combine" related data into a graph, where the relations are given by the connections of the graph.
  • 0
    1h
    @Lensflare yeah, exactly. But that's a non argument since who exports just database tables trough rest? Rest should be IO for certain actions and yes - fetching combined data. That's my point, graph doesn't bring anything to the table what you couldn't with rest. Specify the query client side, well, if there's something i don't want...
  • 0
    1h
    @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.
  • 0
    1h
    @Lensflare it's literally described on this extensive wikipedia page: https://nl.wikipedia.org/wiki/...

    It really sounds as an solution to skip building a decent back-end.
  • 1
    1h
    @Lensflare no, the rest system delivers exactly the data what is needed by the front-end. If it's not made that way, it's just stupid. Rest endpoints should not be a direct mapping to tables or something. It should not be needed to do many calls, that means that the design is flawed.
  • 0
    1h
    @retoor
    > It really sounds as an solution to skip building a decent back-end.

    If that’s the message of the article, then the authors didn’t really understand what graphql is for, too.
  • 0
    1h
    @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.
  • 0
    1h
    @Lensflare I also don't understand it what benefits it has to rest. Everything should be clearly described what rest does. Describing less is not an option. Also, I imagine that using GraphQL cancels all the http advantages by doing everything on the same endpoint. One endpoint to fetch all data. Can't imagine how the caching code looks like.
  • 0
    1h
    @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.
  • 0
    58m
    @Lensflare I don't have a question. A backend not as wel described as a REST backend is just not the same, especially not if it uses the same endpoint making it unclear by design. I honestly thought everyone was done by graphql by now.
  • 0
    51m
    @Lensflare also, mr real world applicaiton swiftii, it's perfectly usable to have get parameters specifying what you want related to extra data. ?with_prices=1&currency=euro&including_vat=0. But in your 'real world application'-world that is an extra endpoint. Hmm, that is where it goes wrong.
  • 1
    38m
    @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.
  • 1
    33m
    @Lensflare thanks for the explaination, now it can go on a fire together with everything that Fb has made. Especially REACT burns very well i assume.

    All vauluntairy graphql devs have a boyfriend btw, but not if they're a girl.
  • 1
    16m
    @retoor yeah, it blows my mind that meta (facebook at that time) managed to invent something actually good and useful.
    I hate meta and it makes me sick that I like something that they made.

    I guess that‘s how you (and probably many others) feel about Apple and Swift 😅
  • 1
    5m
    @Lensflare you don't hear me complain about Swift. When i bash a language, i want to hurt multiple people. If I bash swift, not enough people get hurt.
  • 1
    4m
    @retoor what a burn, lol 😅
  • 0
    2m
    @retoor One more thing about graphql:

    There was a short time (about a decade ago) when I thought that everybody should use graphql instead of rest. I was an idiot.
Related Rants
devRant © 2021 Hexical Labs LLC
Privacy Policy  |  Terms of Service
Add Comment