[terracottage]

The one thing I would ask this person is how big and complex a system they've built like this.

Because if you optimize all the slack out of a system, you have no room to manoeuvre. In this case, you need to update all your code and dbs all at once if any type changes. Because it's all linked.

In my experience this is not feasible one you reach a certain size. You need to be able to upgrade parts in isolation while keeping the majority working without touching it.

[theobr]

Without a strongly inferred type system, all of the things you’re describing around “changing everything to change one thing” are just as much a problem.

In a well typed system, you can choose how deep you want your changes to go.

Let’s say you choose to rename a field in db, I.e. “imageUrl” -> “profilePicURL”. Upon making this change, you will receive type errors on the client consuming it.

At this point, you can make a choice. You can go address all the furthest end consumers, which is what you imply is necessary here. You can just as easily re-shape the data being returned though.

return { …user, imageUrl: user.profilePicUrl }

I firmly believe we’re nearing the “best of both worlds” here :)

[chii]

> You need to be able to upgrade parts in isolation while keeping the majority working without touching it.

having no slack means you get told about this problem during compile time, rather than having the need for an experienced developer who understands the entire system and is able to do the above without the help of a compiler.

[eurasiantiger]

With GraphQL, the idea is to never change existing behaviour, but to use directives to flag them deprecated and direct devs to change to using the new type/field/query/whatever. This gives a guarantee about not breaking existing things.