4 ms·

I'd be interested to understand how they manage their "common" library, especially the RPC bit. I find it very painful to version APIs signatures and protocols

I'd be interested to understand how they manage their "common" library, especially the RPC bit. I find it very painful to version APIs signatures and protocols: Let's say service S1 has a method "DoSomething(a, b)" and you want to add a new feature that makes is "DoSomething(a, b, c)" how do you handle that ? From what I've seen you would do "DoSomething_v2(a, b, c)" but that seems hardly sustainable: - you need a new version of the shared library for the new RPC calls - you need all services to maintain a lot of code to support different signatures And I don't think rewriting all the callers to use the new signature is really an option. Or maybe they keep previous versions of the services deployed and they have some kind of routing that would find which service supports what signature (+probably some metadata like a minimum version number ?). People of HN, what would be your advice on approaching this situation ?

scarmig 7y ago
v2 as a suffix is ugly, so I'd probably have something like v2.DoSomething(a, b, c). Beyond that, I'd typically see a single binary serving both v1.DoSomething and v2.DoSomething. Most of the code path would be shared, with v1.DoSomething calling the same method internally that v2.DoSomething does, except it provides some kind of reasonable default as the third argument. Vast majority of the code ends up shared. Clients would choose which client library they prefer to use (and they can choose to use both, if they need to for whatever reason). Ideally older versions would end up deprecated over time, but it's rarer to deprecate than add a new version.
okal 7y ago
I'm generally quite against shared libs across services for this very reason. Share patterns, sure. But code? You end up coupling services in ugly ways, because Team X has to think about how Team Y will be impacted if they need to make a change to the shared library. API clients (whatever protocol they may be using to communicate), aren't generally the hardest part of building a service. Trying to build shared ones (in my experience) is more trouble than it's worth.
vbezhenar 7y ago
You need some kind of compatibility. For example if you're using REST, you can add new parameter with default value and old clients will keep working. If you're using RPC, you need to research how it handles versioning, but generally you should be able to add new parameter with default value or add new method while keeping old clients working. You need a global update if you're changing existing method in an incompatible way, but that should be rare situation.
strokirk 7y ago
I'd really recommend listening to Rich Hikey's "Spec-ulation" talk, it's about changeing (growing and breaking) APIs. The main part starts about 20 minutes in, but the whole talk is good. https://youtu.be/oyLBGkS5ICk https://youtu.be/oyLBGkS5ICk

scarmig 7y ago

v2 as a suffix is ugly, so I'd probably have something like v2.DoSomething(a, b, c). Beyond that, I'd typically see a single binary serving both v1.DoSomething and v2.DoSomething. Most of the code path would be shared, with v1.DoSomething calling the same method internally that v2.DoSomething does, except it provides some kind of reasonable default as the third argument. Vast majority of the code ends up shared. Clients would choose which client library they prefer to use (and they can choose to use both, if they need to for whatever reason). Ideally older versions would end up deprecated over time, but it's rarer to deprecate than add a new version.

okal 7y ago

I'm generally quite against shared libs across services for this very reason. Share patterns, sure. But code? You end up coupling services in ugly ways, because Team X has to think about how Team Y will be impacted if they need to make a change to the shared library. API clients (whatever protocol they may be using to communicate), aren't generally the hardest part of building a service. Trying to build shared ones (in my experience) is more trouble than it's worth.

vbezhenar 7y ago

You need some kind of compatibility. For example if you're using REST, you can add new parameter with default value and old clients will keep working. If you're using RPC, you need to research how it handles versioning, but generally you should be able to add new parameter with default value or add new method while keeping old clients working. You need a global update if you're changing existing method in an incompatible way, but that should be rare situation.

strokirk 7y ago

I'd really recommend listening to Rich Hikey's "Spec-ulation" talk, it's about changeing (growing and breaking) APIs. The main part starts about 20 minutes in, but the whole talk is good. https://youtu.be/oyLBGkS5ICk https://youtu.be/oyLBGkS5ICk