How do most SPAs handle breaking API schema changes? E.g., a user loads your app, then you deploy a new version of the backend where the API has changed, such that their client is now going to send requests that are formatted incorrectly for the new backend.
Conversation
I've seen a combination of versioned API (via resource or header) and keeping these other API versions alive for some duration (days/weeks/months, depending on the clients in question)
2
a) sending down/comparing an API version and a persistent banner message that a "newer version of the app is available and please reload"; could either be polled or per request
b) try to catch that class of errors and throw up a modal
c) pretend it doesnt happen/denial
same pattern is needed for API-backed mobile apps (I haven't updated the app on my phone, but API is updated) if you're looking for other prior art outside of JS-land
1
1
Not a total remedy, but GraphQL attacks this problem head-on. Monitor the fields in use by the "old" query and turn them off when appropriate.
2
Dunno if many SPAs does it, but, keeping on the user session (like localStorage) at which API version are you hitting and update that when the user reloads or sign in.
2
To me this is exactly why hypermedia is king. At some point your old API should send a packet that triggers a migration of clients. In some cases that migration is going to required loading in new code for sure and that will need some kind of reload, but...
1
if your client is loosely coupled to your data structure and actually implements tooling to read from some kind of spec (eg OpenAPI) to ‘understand’ your endpoint profiles, it simply would need to be told that there’s an updated spec








