Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How do most SPAs handle breaking API schema changes?

twitter.com

Post reply on HN
Print view View original

21–30 of 39 posts

Re: How do most SPAs handle breaking API schema changes?

#21

Post by chipperyman573 »

ihuman wrote: post #18
michaelt wrote: post #7

Earlier quoted context omitted.

Is it though? Depends if you're triggering it six times a year or six times a day. Some companies pride themselves on how often they deploy code to production [1]. And whether your SPA is something like Google Docs where a user could plausibly have the same document open for a week or more. [1] https://blog.newrelic.com/technology/data-culture-survey-res...

I'm not sure if that's a good example. Google Docs automatically saves the document when there's a change, so you won't loose any work if you refresh.

I may be misremembering but I actually remember GDocs telling me to reload once, so presumably they have some way of forcing reloading if they need it (I think it let me keep working locally until I reloaded, then all my stuff would be saved and synced like normal).

Re: How do most SPAs handle breaking API schema changes?

#22

Post by swalsh »

jchw wrote: post #2

Ideally, version your APIs, though for some internal APIs you definitely want to be able to make changes without bumping versions constantly. Be backwards and forward compatible as much as possible. Rolling deployments and other factors virtually guarantee mismatched versions in both directions. Many things, like adding new fields or removing old ones, can be staged in such a way that nothing breaks. Protobuf/gRPC of…

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.

Re: How do most SPAs handle breaking API schema changes?

#23

Post by H8crilA »

jrockway wrote: post #15

I 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…

Indeed, this over 30 years old problem is easily fixable by following guidelines on protocol buffers. Or any other similar technology of this sort, like ASN.1 if you like antics. Protos are just quite popular and therefore a safe commodity bet.

Re: How do most SPAs handle breaking API schema changes?

#24

Post by ellyagg »

swalsh wrote: post #22
jchw wrote: post #2

Ideally, version your APIs, though for some internal APIs you definitely want to be able to make changes without bumping versions constantly. Be backwards and forward compatible as much as possible. Rolling deployments and other factors virtually guarantee mismatched versions in both directions. Many things, like adding new fields or removing old ones, can be staged in such a way that nothing breaks. Protobuf/gRPC of…

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?

Re: How do most SPAs handle breaking API schema changes?

#26

Post by aaronharnly »

How 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?

Re: How do most SPAs handle breaking API schema changes?

#27

Post by jrockway »

aaronharnly wrote: post #26

How 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, because their error reporting code lives in the javascript bundle and they never get error reports ;)

The correct solution is probably to keep a few old versions of the Javascript bundle around, so that in-flight requests succeed even as you update the container hosting the app. I do not know of a tool that does this, but the edge case I describe above worries me, so I might write one someday.

Re: How do most SPAs handle breaking API schema changes?

#28

Post by SilasX »

ollyculverhouse wrote: post #10
michaelt wrote: post #7

Earlier quoted context omitted.

Is it though? Depends if you're triggering it six times a year or six times a day. Some companies pride themselves on how often they deploy code to production [1]. And whether your SPA is something like Google Docs where a user could plausibly have the same document open for a week or more. [1] https://blog.newrelic.com/technology/data-culture-survey-res...

Is it common to be releasing breaking API schema changes 6 times a day?

No, but it's common to underestimate the cost imposed on clients how avoidable a breaking change is.

Re: How do most SPAs handle breaking API schema changes?

#29

Post by OldSchoolJohnny »

itslennysfault wrote: post #16
chrisabrams wrote: post #6

Earlier 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.

I lol'd, Facebook has a terrible UI on every platform.

Re: How do most SPAs handle breaking API schema changes?

#30

Post by tuananh »

michaelt wrote: post #7
Kuraj wrote: post #5

> A number of responses say "have the client detect that it's running an old version and force reload." That works, but it's pretty annoying UX. Is it though? Of all reasons to force refresh, this sounds reasonable to me as it won't even happen that often. Heck, I would want to refresh if I knew a new version was available.

Is it though? Depends if you're triggering it six times a year or six times a day. Some companies pride themselves on how often they deploy code to production [1]. And whether your SPA is something like Google Docs where a user could plausibly have the same document open for a week or more. [1] https://blog.newrelic.com/technology/data-culture-survey-res...

make it silent? like chrome update?

silent download and auto install on next startup

Post reply on HN