[WD-42]

Yup. Especially when your api really only has 1 (possibly 2 in the case of a mobile app) real clients. People like to pretend their apis are generic but they aren’t. There’s a good argument to stop writing generic apis for your single application.

[hansonkd]

Typically the endpoints clients are multiple frontend developers. If the frontend is blocked for every page they need waiting on the backend to expose data that massively increases the costs of features and reduces the time for delivery.

[bunderbunder]

This sounds like more of an org chart problem or a value chain management problem than a technical problem.

[throwup238]

That's why we have Conway's law.

[bunderbunder]

Yeah. And a gentle nudge that Conway's Law is about lines of communication in general, not specifically the org chart.

I used to be in charge of the stored procedures that served as the API to a shared database system used by many teams. (So, not exactly the same thing, but I'd argue that the sprocs vs ORM debate isn't entirely dissimilar from the REST/RPC vs GraphQL debate.) My turnaround time for getting database API changes into staging for application teams to play with was typically less than one work day. But that happened because I had a lot of latitude to just get things done, because the company valued rapid delivery, and therefore made sure we had what we needed to deliver things rapidly, both from a technical and a business process perspective. This was in a very highly regulated industry where every change required paperwork that would be audited by regulators, too.

I've also worked at places where this sort of thing took ages. Typically the worst places for work backing up were organizations that used Scrum, because the whole "sprints" thing meant that the _minimum_ time to get something from another team was about 1.5 times the sprint duration. And even then you could only manage that if you could deliver a request that already met all of that particular team's requirements for being able to point it, and could convince their Product Owner that it was a higher priority than whatever their pet project is this quarter, and the stars align so that you perfectly time the submission of your request with respect to that team's Scrum process's frame rule.

The thing I want to point out here is that absolutely none of that bullshit was ever the API technology's fault.

[DangitBobby]

Frontend devs can write fake API calls which return the data they expect in the meantime.

[WD-42]

This happens anyway.

[hansonkd]

Not nearly as often with Graphql and happens less and less as your backend and data models stabilizes.

Most of our frontend features now don't have backend changes and we were able to increase the ratio of frontend to backend devs.

[blowski]

My experience is that the problem is avoided in theory, but not in practice.

Making a good API on a large system with many clients is always difficult. GraphQL makes it easier in theory, but if you have average level devs working on it, they’ll make a bigger mess than if they use simple REST. The latter will still be complex, but at least it’s easier to have observability.

[ethbr1]

Aka never underestimate the power of additional complexity to drive bad use, absent familiarity.