rklaehn
commented
1 month ago Here is my attempt at a schema language for this use case: https://github.com/rklaehn/rpc-schema
Open rklaehn opened 1 month ago
rklaehn
commented
1 month ago Here is my attempt at a schema language for this use case: https://github.com/rklaehn/rpc-schema
Currently, changes in the RPC protocol require either very careful versioning, or you will run into the issue that some RPC methods will just break in a very silent/annoying way over time as you evolve the API. So you have to make sure that the RPC client and server run the exact same RPC schema. This is sometimes somewhat annoying (e.g. iroh and iroh-cli), but sometimes basically impossible (e.g. windows service installed on a remote machine that can't be updated easily).
You could just put a commit hash into the ALPN to make miscommunication impossible. But that has the downside that even something trivial like a docs update breaks the RPC communication between e.g. iroh and iroh-cli. You could also manually increase the ALPN every time you touch the RPC, but even that is a bit of a pain. E.g. you change 1 of 100 rpc methods, but by increasing the ALPN version you make communication for all 99 other rpc methods impossible. You change something about node id, and your untouched blob endpoints stop working...
Ideally you would want to do some sort of versioning per endpoint, so that only the endpoints that you actually touch get broken.
postcard-rpc has an interesting approach that creates a hash for each rpc endpoint. But it is meant for embedded use and therefore uses a u64 hash that could potentially have collisions.
unisonweb has cryptographic hash based versioning for everything, but unfortunately it is a bit of an isolated island.
Ideally you would have a way to version RPC endpoints for something like quic-rpc that uses cryptographic hashes to prevent collisions, yet is more integrated into rust than unison. (I would love to use a tiny subset unison schema, but could not find good docs).