It seems like this system can only work if the build and deployment is all done by one tool in a monorepo. What does migration from existing setups look like?
And what about services that communicate via shared infrastructure:
- A writes to Kafka topic T
- B reads from Kafka topic T
Ok so we could make the hash of A part of the topic name T, but then on every release we make a new topic and lose history?
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...
> 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.)
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?
It seems like this system can only work if the build and deployment is all done by one tool in a monorepo. What does migration from existing setups look like?
And what about services that communicate via shared infrastructure:
- A writes to Kafka topic T
- B reads from Kafka topic T
Ok so we could make the hash of A part of the topic name T, but then on every release we make a new topic and lose history?
Looking forward to future posts.