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 fro

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