[no_wizard]

This is what I constantly tell people. Use GraphQL to efficiently create permutations of access so the data is shaped for the client more or less exactly how they need it. To that end, I often recommend that at least one UI developer is involved in approving schema changes and regularly dogfoods the GQL setup before its deployed.

I have been met with a lot of resistance around this notion for some reason.

To be honest, I fought the same argument with OpenAPI (Swagger) too.

API developers seemingly just want to chuck their schema over the wall and walk away

[mst]

I think part of this is that when an API developer tries to write frontend code, they'll naturally use the underlying schema as their frontend domain model because they're already thinking in those terms.

I definitely suffer from that problem when trying to work out what a good API for frontend would be, and frontend people often have their own blind spots which makes working together to find something actually good a tricky process.

Then again, getting REST/GraphSQL/API-of-choice designs 'actually good' is hardly a trivial problem at the best of times, so how much of this is developer biases and how much inherent difficulty isn't something I'd be confident trying to estimate.

[camgunz]

Yeah this dynamic definitely exists. I think this is because there's a big mismatch between what frontend wants ("we'd prefer a single, super fast endpoint with no params") and what backend wants ("we automatically exposed our database tables complete with RBAC, query away"). Backend engineering has more or less become all implementing this mapping layer, whether it's with graphql resolvers, db views, or whatever, but the work to be done is like 90% here.