3 ms·

Lovely idea, I'm curious to hear more about the deployment experiences. > combining the above system with socket-activation and scale-to-zero servers That sou

Lovely idea, I'm curious to hear more about the deployment experiences. > combining the above system with socket-activation and scale-to-zero servers That sounds good at first, but less and less reasonable the more I think about it First because each deployment comes with overhead, and given enough public users you will have people relying on every single version of your API, and therefore lugging around a deployment for each version. Very expensive. Second, this micro-versioning may cause compatibility issues. What happens if someone mistakenly sends a request to a 2 year-old service, which fails to understand the new fields in the database, or sends alert emails to old addresses, or tries to use a cloud API that's not available anymore...

zimpenfish 3y ago
> you will have people relying on every single version of your API If you put the API version into the access token, you can bump people upwards when they refresh / restart, then delete the old API when the token expiry comes around. > Second, this micro-versioning may cause compatibility issues. If you control the FE deployment, this isn't a problem. If you don't want to sync up the FE/BE deployments -- say it's an iOS app and you don't want to do an app store push every time you deploy to BE) -- you could use a backend-for-frontend layer or WAF which proxies to the correct backend version (based on the access token version ^ as up there.)
- BoppreH 3y ago
  I was thinking of more genral API versioning, not just for web services. Like example.com/api/v2/ on steroids. And what happens with services sharing stateful resources? When the database schema is at version 10, a service expecting version 2 would be trouble, no?
  - zimpenfish 3y ago
    > When the database schema is at version 10, a service expecting version 2 would be trouble, no? There are ways around that - views, functions, triggers, etc. (have had to do similar twice this year.) But it can be a faff, definitely.

zimpenfish 3y ago

> you will have people relying on every single version of your API If you put the API version into the access token, you can bump people upwards when they refresh / restart, then delete the old API when the token expiry comes around. > Second, this micro-versioning may cause compatibility issues. If you control the FE deployment, this isn't a problem. If you don't want to sync up the FE/BE deployments -- say it's an iOS app and you don't want to do an app store push every time you deploy to BE) -- you could use a backend-for-frontend layer or WAF which proxies to the correct backend version (based on the access token version ^ as up there.)

BoppreH 3y ago
I was thinking of more genral API versioning, not just for web services. Like example.com/api/v2/ on steroids. And what happens with services sharing stateful resources? When the database schema is at version 10, a service expecting version 2 would be trouble, no?
- zimpenfish 3y ago
  > When the database schema is at version 10, a service expecting version 2 would be trouble, no? There are ways around that - views, functions, triggers, etc. (have had to do similar twice this year.) But it can be a faff, definitely.