Earlier quoted context omitted.
> Some part of your organizations chaos is going to reflect in code, and honestly I'd rather it be in a big ball of frontend than in the data models, infrastructure, etc. I disagree. I like my frontend to be as dumb as possible. It gets data and reacts to it as simple as possible. Seen too many frontends with a lot of data logic and it becomes extremely brittle, harder to test. These are the ones where the frontend d…
That's why I like GraphQL, you get exactly the data you request, no transformation necessary.
This is what I'm referring to.
So you still need to write some new graphql resolvers on the backend and update your graphql schema. Not much different from writing some new REST api endpoints or expanding an existing endpoint.
But if you use GraphQL then I agree on the benefit and approach still of having as much of your data logic on the backend. And with GraphQL you have a schema that is readily available, auto-documented and available for frontend devs to use for current and future components.
Which is better than having that logic on the frontend IMO.