Oh, it’s a contract? Amazing, I guess that means you can just update the contract and nobody is stuck doing busywork anymore. Nope? I guess then either your frontenders need to learn your backend stack, lest they be stuck waiting for someone to do the busywork for them. I feel like I’m repeating myself, because I am. Please don’t quote out of context
> Now tell me:
> - what will you do when your glorious ad hoc GraphQL query ands up bringing the database to its knees?
> - what will happen when your glorious GraphQL schema doesn't have all the data the frontend needs?
Sound like interesting, challenging, and satisfying problems for the backenders to work on. Certainly more so than adding/removing fields from serialisers. These also seem like much more rare problems than the small data requirement changes that are the backbone of frontend work.
I’d rather work on speeding up the things that slow down development and deal with performance when it becomes a problem. I dunno, maybe our experience differ, and in you world your app is relatively static and performance is crucial, but the world I exist in involves stakeholders constantly wanting minor changes, performance has never been a problem, and development is constantly blocking because of frontend/backend blockers on our “rest” api and capacity on either side being wasted at various times because of that blocking.
Sure, sometime someone’s going to write a horrendous graphQL query where the answer is going to be “sorry, we can’t make that perfomant so we have to disallow it”, but that’s a: solvable and b: going to happen a lot less often than your frontend is going to need an extra field (or no longer need a field, but since nothing breaks these change requests rarely come through and your backend is eternally querying and sending unused data over the wire)
Why would frontenders need to learn the backend stack? Do you even know what REST is?
Riddle me this: what happens when frontend developers need data not exposed by the GraphQL schema? Do the need to learn the backend stuff as well? If not, why would they need that for REST?
> satisfying problems for the backenders to work on. Certainly more so than adding/removing fields from serialisers.
Because GraphQL automagically knows how serialize-deserialize any schema, riiiight.
> but the world I exist in involves stakeholders constantly wanting minor changes
So. How do you deal with those changes? Oh, let me see: you change schemas, you write new serializers/deserializers etc.
> development is constantly blocking because of frontend/backend blockers on our “rest” api and capacity on either side being wasted at various times because of that blocking.
For some reason you blame your failing processes on technology. Fix the process.