3 ms·
The breaking changes part from the original article was clear to me. The author was saying that if you control the API and the client, it’s often quicker to rel
by lukevp 2y ago
The breaking changes part from the original article was clear to me. The author was saying that if you control the API and the client, it’s often quicker to release changes that are not backwards compatible as long as you can coordinate the release of the two. Then there’s no need to version at all. Sounds like this is harder with graphql than REST.
- nesarkvechnep 2y agoYou probably mean JSON over HTTP when saying REST but the original idea of REST is painless evolution. No vX in the URL.
- rbalicki 2y agoCertainly, if you can either force your clients to refresh their browsers or can tolerate clients breaking, that works! That might work great for internal tools, for example (as long as no work is lost when you refresh, or you can just expect your employees to redo the work). But it’s not tenable for anything that customers use.