graphql
How do most SPAs handle breaking API schema changes?
31–39 of 39 posts
Re: How do most SPAs handle breaking API schema changes?
#32This doesn’t magically cure everything, but switching from REST to GraphQL can help make a lot of versioning-type issues disappear.
absolutely true in my experience also
Re: How do most SPAs handle breaking API schema changes?
#33I use grpc-web and protocol buffers. Renaming fields doesn't matter -- if the client and server disagree about the name of a key, it doesn't matter, because the transport layer uses the tag number, not the name. (Compare this to JSON, where changing the name does break clients.) Adding fields also doesn't matter, but this is where it starts to get tricky. If a client sends a request without a field that the server ex…
You can also remove a field by reserving the tag number and optionally the name. New binaries will fail to compile but previously persisted values can still be read back by old binaries. Also ensures no one uses the same tag number later and reads bad data.
Re: How do most SPAs handle breaking API schema changes?
#34Earlier quoted context omitted.
Even Facebook does this when you have left it open in a tab for too long. [edit]: spellcheck failed.
> Even Facebook Like they're the example we should look to. They do all sorts of hacky stuff.
They do lots of stuff, but they don't seem to break their user's usage due to reloading if you leave a window open forever.
Re: How do most SPAs handle breaking API schema changes?
#35Earlier quoted context omitted.
Not sure if this is standard, but what I usually do is bump the version only on a breaking change. So if I add a field, nothing new happens. Remove a field, or fundumentally change the output, then I bump it up.
Would you care how often you make breaking changes on your API if you control the client and it's your only consumer?
Yes, if especially if "you" is a company or engineering department. It can be difficult trying to figure out how to best deprecate a micro-service endpoint if you aren't quite sure what other services are using it and if logging is lacking.
Re: How do most SPAs handle breaking API schema changes?
#36How do you even handle SPA updates themselves? Apps may reference static resources (JavaScript, CSS, images) which get updated with a new version. Those resources could be clobbered by a deploy, or be uglified, or be versioned. Do you keep the old static resources in place forever, or for a period of time? Or force a reload? Or do you just let clients break and make users reload?
Yeah, the tooling around this is pretty bad. For example, you might release a container that has index.html and main.abc1234.js. index.html has to be parsed before the JS bundle is requested. If you do a release in that intermediate time, the javascript will 404 and your site won't load because in the new container, the only bundle that exists is main.def2345.js. I think people additionally assume this never happens,…
Yeah, and if you do dynamic loading of resources (images, templates, etc), I think the window of 404ing is much longer than just the index.html parse time — essentially, the span of a user session...
Re: How do most SPAs handle breaking API schema changes?
#37How do you even handle SPA updates themselves? Apps may reference static resources (JavaScript, CSS, images) which get updated with a new version. Those resources could be clobbered by a deploy, or be uglified, or be versioned. Do you keep the old static resources in place forever, or for a period of time? Or force a reload? Or do you just let clients break and make users reload?
Yeah, the tooling around this is pretty bad. For example, you might release a container that has index.html and main.abc1234.js. index.html has to be parsed before the JS bundle is requested. If you do a release in that intermediate time, the javascript will 404 and your site won't load because in the new container, the only bundle that exists is main.def2345.js. I think people additionally assume this never happens,…
Edge caching is a solution.
Re: How do most SPAs handle breaking API schema changes?
#38Earlier quoted context omitted.
Yeah, the tooling around this is pretty bad. For example, you might release a container that has index.html and main.abc1234.js. index.html has to be parsed before the JS bundle is requested. If you do a release in that intermediate time, the javascript will 404 and your site won't load because in the new container, the only bundle that exists is main.def2345.js. I think people additionally assume this never happens,…
Edge caching is a solution.
Yeah, I think that's a reasonable solution. It doesn't guarantee 100% accuracy, but it increases the chance that something will load.
Re: How do most SPAs handle breaking API schema changes?
#39We use API versioning. Works like a charm! If you don't currently have API versioning, just put the breaking changes behind /v2/ and start versioning.
I guess the hard thing is that you lose versioning granularity at that level. If you made a mistake with your v2 rollout and the fix is breaking, do you bump to v3 or append the correct field? Do you leave the bug in the response still so that users can decide to depend on it? You can’t delete. What would the user thing about bumping from v3 to v12 in a really short amount of time as the API is in flux? Stripe’s date…
I've never come across your scenario. I would say if you need to fix v2 with a breaking change, then v2 must be broken to begin with. All that being said, going to v3 is not a problem either. I have a few APIs where we went up to v7 after 2 years of operation without issues.