Rendered at 12:22:36 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
gojkoa 19 hours ago [-]
We've been versioning UIs since 2015, after dealing with a bunch of weird bug reports that we tracked down to people keeping tabs open for months. Needs careful backend planning and backwards compatible data handling, but it's a solvable technical issue. API calls from the front-end can send the active version with calls, letting the backend understand that something older is calling and do version upgrades of envelopes and payloads, and the front-end needs to be designed to ignore extra fields, but all of that is testable, and once things are in place they give you both the protection against weird inconsistency bugs, ability to experiment (running a/b versions in parallel) and detailed monitoring to troubleshoot weird issues.
It's quite sobering to look at the list of active versions and see a long tail of what's actually connecting to our backend.
gruensk 18 hours ago [-]
Yea I’m sure it increases complexity in the backend unless the backend has mandated connection points not allowed to be changed. I wonder if an AI api endpoint would make this easier if it could intelligently route or translate btwn versions reliably
gojkoa 18 hours ago [-]
in theory yes, but in practice if each deploy is a version (and for us it is), with multiple deployments per day this becomes unsustainable to track. we settled on the backend always being "current" but supporting multiple front-end versions using the version parameter of the API calls.
codegeek 19 hours ago [-]
I have seen some older Software/SAAS UIs displaying version numbers. But letting you switch may not make sense because usually a change happens both in backend and frontend and switching versions is not something vendors want to offer due to the complexity of switching required.
al_borland 9 hours ago [-]
When there are big changes, I’ve seen a lot of sites, and even some applications, allow users to opt-in to the new version to try it out, or opt-out of the new version and return to the old one if it isn’t meeting their needs or they have a deadline and need their old workflow to meet it.
Reddit and Outlook are the two examples that come to the front of my mind, but I’ve seen many more. Even my power company did it.
This however is only for big changes, and usually just a toggle old|new, not fully versioned where a user can go back to any point in history. I would guess that would turn into a nightmare for maintenance, and unlike APIs, there is rarely code that is UI dependent… at least we hope not.
pavel_lishin 19 hours ago [-]
One counter-example is Reddit's old.reddit.com interface, compared to their new one.
gruensk 18 hours ago [-]
Def good point!
brudgers 7 hours ago [-]
For me, avoiding the upgrade treadmill is a reliable way of maintaining stable interfaces (and workflows).
Of course that lunch isn’t free.
Good luck.
toomuchtodo 20 hours ago [-]
You can if you want, it is a choice, especially if it is a consumer of a versioned API, just like you would version a mobile client.
It's quite sobering to look at the list of active versions and see a long tail of what's actually connecting to our backend.
Reddit and Outlook are the two examples that come to the front of my mind, but I’ve seen many more. Even my power company did it.
This however is only for big changes, and usually just a toggle old|new, not fully versioned where a user can go back to any point in history. I would guess that would turn into a nightmare for maintenance, and unlike APIs, there is rarely code that is UI dependent… at least we hope not.
Of course that lunch isn’t free.
Good luck.