4 ms·

> It's all fun and games until you hit version n+1 or n+2, and often realize how slow many customers are to upgrade the library. How is that different with ser

• sokoloff 3y ago
  Many changes are believed to be non-breaking and so you can be running only one version in prod. (Most of the changes believed to be non-breaking are non-breaking.) With a library, you end up with many different minor or point versions running without control over it.
  • gjadi 3y ago
    Ok so the benefits here are transparent upgrade. Thanks.
  • genman 3y ago
    Emphasis on "are believed". This actually puts clients into risk of having breaking changes out of their control.
• materielle 3y ago
  The idea is to link a thin client library into the user’s code. Then the thick client is controlled server side by the devs. If you design the thin and thick client intelligently, you can make a lot of changes to the system by merely modifying the thick client (which you control), without needing to update the thin client. Problems tends to come in a few flavors, namely that this increases complexity and that some changes will always require modifying the thin client. The biggest pitfall, though, is that you have to actually put thought into the thin client design. “Thin” is an emergent property of a well thought out client. You can’t just “touch thin_client.java” and think because you named it “thin” that it’s inherently decoupled from the service. You have to actually put thought into it. Your example is exactly right. The service can support either v1 or v2 depending on the version of the thin client. The main other technique is to have the thin client communicate in a relatively abstract and generic manner. For instead a “write()” endpoint that accepts an “options” dictionary. “write()” is so generic that it probably won’t have to change, and changes in behavior can be modified by shoving stuff into dict, perhaps with a “version” field to instruct the server how to interpret the call. When you add a new feature, you can bump the thin client to v2 and shove new options in the dict. Then the server can support v1 and v2. But also, you can modify the server to handle v1 differently. E.g the absence of a “disable_new_feature” key automatically opts v1 callers into the new feature. I think the details are are really coupled into what you are engineering and what you want to roll out. There’s no magic bullet, and this increases the complexity of your code. Good engineering in my opinion is deciding when these approaches are worth it and how they should be implemented.
  • gjadi 3y ago
    I don't quite understand what you are saying. As per the article, the advantage of a library over a service is that you don't have the burden of maintaining the said service. How having a thin client and a server helps? I also don't see how "shoving new options in the dict" can help. From my POV, if the client needs to be updated to benefit from the new features, then there is no way around it, work has to be done. From there, I much prefer having sensible name, parameters, etc. from a library that can be leveraged by static typing rather than a documentation for a JSON API (I know API-as-specs exist but I've never used, maybe that's why I think that).
    • chii 3y ago
      > From my POV, if the client needs to be updated to benefit from the new features, then there is no way around it, work has to be done. But the point is they don't have to update even if there's changes. They can update at their leisure.
      • gjadi 3y ago
        Same as not linking with the new lib? I understand it may be different if the software is distributed through the package manager of linux distribution because you have to follow what's provided by the distribution. But for a commercial software you can probably bundle your own libraries in executable or compile it statically. But I am not familiar with the difficulties of the above process so I am probably missing something.
• zja 3y ago
  You have the same problem with services and libraries when you’re introducing a breaking change. With services you can make non-breaking changes like security patches on the server side, without needing to coordinate with a customer.
  • LtWorf 3y ago
    And with libraries you can't make breaking changes? The fact that I don't need to recompile everything whenever libcurl or libssl has a security fix proves otherwise.
    • fl0ki 3y ago
      That's not a great example given OpenSSL versions are famously backwards-incompatible. Older versions get ABI-compatible security patches because people put in the time to backport all of them to every version still supported, in many cases by distro package maintainers. It's exactly the situation libraries should generally avoid, because there are maintainance costs for older versions of the library as well as migration costs for all of its users. https://wiki.openssl.org/index.php/Versioning https://wiki.openssl.org/index.php/Versioning
      • LtWorf 3y ago
        Well given that i upgrade but not downgrade… what's your point?
        • fl0ki 3y ago
          The point is that someone is paying the cost of maintaining the library's ABI surface area even if it's not you. In a thread specifically for developers considering how to offer an interface to their software, I think it's only fair to recognize the costs of those different approaches. In that regard, OpenSSL is an extremely bad example, or an extremely good example of what not to do.
• grogenaut 3y ago
  Simple answer is YOU control the deploy of a server in miroservices, so YOU decide when it goes live. You aren't playing spreadsheet telephone at scale to get everyone even im an internal org to update. If you're smart you have your callers send version information and you usually just add fields, only removals or renames cause version issues. If you're having everyone use a library they control when they update the logic and you have less telemetry when some wierd corner of your company is using out of date logic.
  • osigurdson 3y ago
    Such an odd technical solution to a political problem.