4 ms·

What made GraphQL become important?

by ysavir 3y ago

hot_gril 3y ago
We had a NodeJS backend and an iPhone/Android app frontend communicating over JSON-over-HTTP with an OpenAPI spec. It was a social-like app with endpoints like /getUsers, /getPost, /makePost, whatever. There were lots of cross-references, such as a post having the posting user, and we were just sending IDs from the backend so the frontend could look up the referenced objects on its own. The idea was the frontend would cache things, avoiding tons of lookups. This is probably what a backend-backend interaction would look like, but it wasn't suitable for frontend. Frontend dev team didn't want to own this much logic and started asking for nested objects in the API, usually with only a few fields. Like they needed the poster's handle and avatar for each post, and they'd only request more detail when visiting the profile. So we started cramming it all in there. A bit wasteful and tedious, not the end of the world, but GraphQL would have been a much more elegant solution. Also, frontend and backend teams were on opposite sides of the world. If backend team added a new endpoint but missed something the frontend needed, it'd be a full day before they heard back. So it was best to err on the side of sending too much info back then remove parts of it later.
- endisneigh 3y ago
  This is a good example of why planning is important. The front end team should have stubbed out the backend, iterated as they liked, and told the backend team we need these requests for these pages Graphql is popular in part due to communication dysfunction.
  - hot_gril 3y ago
    They did some stubbing as needed, but that doesn't change how it's still messy and tedious for the backend team to support so many different combinations of data instead of just handing them a GQL. Also, to be frank, frontend team was paid a lot less per head than backend team. Their expertise was just in building the UI according to what the backend team and designers gave them, and they were very good at that. Stubbing wasn't an efficient use of their time.
  - pcthrowaway 3y ago
    I'd love to know more about how better planning could have made GraphQL not so useful here. I think I've encountered the same (or a similar) issue when the front-end needs some data that conditionally relates several objects in your data model. None of your openAPI endpoints cleanly map to the "bag of data" you need, but you can have the server bolt on additional data from other models in response to certain types of requests, and the front-end can construct its components based on that. However, this gets ugly. The alternatives, as I see it, are to have the frontend make multiple requests, sometimes in sequence, and then compose the data it needs from the separate responses, or to altogether abandon REST for a JSON RPC (something like tRPC might really shine here). Or to use GraphQL, which simplifies things greatly as the frontend can now request the data it needs in the structure it needs it, and Apollo server or whatever you have on the backend can service those requests and plan the optimal path to fetch and transform the data. Caveat, I've never actually implemented this pattern on a backend, it's just something I've considered after running into the above issues, so I admit I could just be misunderstanding how GraphQL can be useful in this problem space. But I'm curious if there are other patterns for this problem that, as I believe you were suggesting, could eliminate the problem without adding GraphQL into the mix
  - john-radio 3y ago
    If you're in the business of always designing a new backend API for every new service or page, then yeah, backend needs to be at the table from the beginning and the backend API can accommodate the design. Part of the point of frameworks like GraphQL, though, is that it lets your backend avoid that kind of churn. A feature attached to a node becomes usable by every authorized call that references that node, not just the specific endpoint they it was implemented for.
    - hot_gril 3y ago
      Exactly. You don't need GQL to alleviate this, but in hindsight it would've been worth the cost.

What made GraphQL become important?

by ysavir 3y ago

What made GraphQL become important?

We had a NodeJS backend and an iPhone/Android app frontend communicating over JSON-over-HTTP with an OpenAPI spec. It was a social-like app with endpoints like /getUsers, /getPost, /makePost, whatever. There were lots of cross-references, such as a post having the posting user, and we were just sending IDs from the backend so the frontend could look up the referenced objects on its own. The idea was the frontend would cache things, avoiding tons of lookups. This is probably what a backend-backend interaction would look like, but it wasn't suitable for frontend. Frontend dev team didn't want to own this much logic and started asking for nested objects in the API, usually with only a few fields. Like they needed the poster's handle and avatar for each post, and they'd only request more detail when visiting the profile. So we started cramming it all in there. A bit wasteful and tedious, not the end of the world, but GraphQL would have been a much more elegant solution. Also, frontend and backend teams were on opposite sides of the world. If backend team added a new endpoint but missed something the frontend needed, it'd be a full day before they heard back. So it was best to err on the side of sending too much info back then remove parts of it later.

endisneigh 3y ago
This is a good example of why planning is important. The front end team should have stubbed out the backend, iterated as they liked, and told the backend team we need these requests for these pages Graphql is popular in part due to communication dysfunction.
- hot_gril 3y ago
  They did some stubbing as needed, but that doesn't change how it's still messy and tedious for the backend team to support so many different combinations of data instead of just handing them a GQL. Also, to be frank, frontend team was paid a lot less per head than backend team. Their expertise was just in building the UI according to what the backend team and designers gave them, and they were very good at that. Stubbing wasn't an efficient use of their time.
- pcthrowaway 3y ago
  I'd love to know more about how better planning could have made GraphQL not so useful here. I think I've encountered the same (or a similar) issue when the front-end needs some data that conditionally relates several objects in your data model. None of your openAPI endpoints cleanly map to the "bag of data" you need, but you can have the server bolt on additional data from other models in response to certain types of requests, and the front-end can construct its components based on that. However, this gets ugly. The alternatives, as I see it, are to have the frontend make multiple requests, sometimes in sequence, and then compose the data it needs from the separate responses, or to altogether abandon REST for a JSON RPC (something like tRPC might really shine here). Or to use GraphQL, which simplifies things greatly as the frontend can now request the data it needs in the structure it needs it, and Apollo server or whatever you have on the backend can service those requests and plan the optimal path to fetch and transform the data. Caveat, I've never actually implemented this pattern on a backend, it's just something I've considered after running into the above issues, so I admit I could just be misunderstanding how GraphQL can be useful in this problem space. But I'm curious if there are other patterns for this problem that, as I believe you were suggesting, could eliminate the problem without adding GraphQL into the mix
- john-radio 3y ago
  If you're in the business of always designing a new backend API for every new service or page, then yeah, backend needs to be at the table from the beginning and the backend API can accommodate the design. Part of the point of frameworks like GraphQL, though, is that it lets your backend avoid that kind of churn. A feature attached to a node becomes usable by every authorized call that references that node, not just the specific endpoint they it was implemented for.
  - hot_gril 3y ago
    Exactly. You don't need GQL to alleviate this, but in hindsight it would've been worth the cost.