4 ms·

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 w

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.

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.