Call by Hash
garnix.io
garnix.io
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.
> 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...
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.)
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?
There are ways around that - views, functions, triggers, etc. (have had to do similar twice this year.) But it can be a faff, definitely.