Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Write libraries instead of services, where possible

catern.com

Post reply on HN
Print view View original

101–110 of 181 posts

Re: Write libraries instead of services, where possible

#101

Post by genman »

sokoloff wrote: post #44
gjadi wrote: post #36

Earlier quoted context omitted.

> 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 services? I don't develop services, but I can imagine that before breaking the services, you have to poll with your biggest customers and you don't break until they are ready to move to the new version. The alternative I can imagine is to keep providing the old se…

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.

Emphasis on "are believed". This actually puts clients into risk of having breaking changes out of their control.

Re: Write libraries instead of services, where possible

#103

Post by TeMPOraL »

bigstrat2003 wrote: post #96
TeMPOraL wrote: post #88

Earlier quoted context omitted.

Because if you ship code to users (library), you lose control. You may want to change something, but your users will just tell you to go pound sand. Conversely, if you keep the implementation on your side (service), you get to control how things work and when things change, and your users don't have a say in this. It's an ownership and control issue.

I don't see the issue here. If I release my_fancy_lib 2.0.0, and I have users who only ever want to stay on the last 1.x release, that's fine. It's no skin off my nose if users choose to stay on an old version forever.

Yeah, exactly. However, if you were to make it a service, those users would have to switch to 2.0.0 or stop using it, as 1.x no longer exists.

Re: Write libraries instead of services, where possible

#105

Post by jampekka »

mooreds wrote: post #35
NBJack wrote: post #27

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. Then there are the potential conflicts in your own dependencies. And let's not forget the occasional breaking change you introduced. You are now sacrificing the money saved by not hosting to maintain what will likely be a growing matrix of possible versions, underlying assumptions, and my per…

I thought the author addressed that point: "But this assumes that slow-to-upgrade users can have negative effects on everyone else. If one user can't have a negative impact on other users, then you don't care if some users are slow to upgrade; they're only hurting themselves." There's still the support issue, I agree. If a customer paid you money and they are on version n-10, they still expect support. > Plus, if the…

In my experience the more they try to hide the sauce the worse it is.

Quite logical though if the secret is that your secret sauce is bland and off-flavor copy of a canned soup. Which it usually is.

Re: Write libraries instead of services, where possible

#106

Post by [deleted] »

__MatrixMan__ wrote: post #68
closeparen wrote: post #6

Services usually depend on databases. Libraries usually don’t. Either you need to support every storage backend your users might have, require them to write an integration layer from your generic hooks, or expect them to provision and manage new storage when using your library. In any case you are asking them to do a lot more work (manage the data) and in some sense breaking encapsulation by making them responsible f…

It's only an unreasonable amount of work if you assume that the user is managing a separate storage backend for each library. If you take the Tim Berners-Lee approach (re: https://solidproject.org/ ) then each user is only managing one storage backend: the one that stores their data. The marginal cost of hooking in one more library to the existing backend is low. We just have to get a little more fed up with all of t…

[deleted]

Re: Write libraries instead of services, where possible

#107

Post by jampekka »

inetknght wrote: post #78

I've been writing services... as libraries first. Then just wrap the library in a very simple `main()`: ``` #include "servicelib.hpp" int main(int argc, char argv) { return servicelib{argc, argv}.run(); } ``` The library can be re-used in other apps or services. Then the whole damn library is unit-testable with any arguments you throw at it. Got an OS where argv may be null? You can unit test that. Got a user who dec…

Hundred times this. Nice to hear an odd sound of sanity amisdt the architecture astronaut crowd. YAGNI.

Re: Write libraries instead of services, where possible

#108

Post by pphysch »

yjftsjthsd-h wrote: post #58
Kinrany wrote: post #39

Earlier quoted context omitted.

This shows that we lack good abstractions over storage.

The space is complex enough that I wonder if it's possible to make abstractions that aren't horribly leaky.

I blame the SQL "standard". It's a massive, unnecessary abstraction layer that only complicates attempts to build bridges between code and relational databases (which I believe is the most general-purpose paradigm).

Personally, I am working on a modern Python ORM for PostgreSQL and PostgreSQL alone.

Re: Write libraries instead of services, where possible

#109

Post by closeparen »

__MatrixMan__ wrote: post #68
closeparen wrote: post #6

Services usually depend on databases. Libraries usually don’t. Either you need to support every storage backend your users might have, require them to write an integration layer from your generic hooks, or expect them to provision and manage new storage when using your library. In any case you are asking them to do a lot more work (manage the data) and in some sense breaking encapsulation by making them responsible f…

It's only an unreasonable amount of work if you assume that the user is managing a separate storage backend for each library. If you take the Tim Berners-Lee approach (re: https://solidproject.org/ ) then each user is only managing one storage backend: the one that stores their data. The marginal cost of hooking in one more library to the existing backend is low. We just have to get a little more fed up with all of t…

I think most interesting web services are providing structured access to the same data for multiple people. A private, individual data silo wouldn't get the job done unless combined with some kind of message-passing. A silo to which users can invite peers is interesting, but it's an important characteristic of many web services that the specific read and write transactions allowed are application-defined... you don't actually want to give your collaborators general read or write access at the storage level.

For example, it's important that I can add this comment, and I can't delete your comment, but the moderators can. The "storage" software would have to know something about the business logic of a web forum to make that happen.

Re: Write libraries instead of services, where possible

#110

Post by sidlls »

Libraries and services both have maintenance costs and upgrade impedance from clients. The costs might differ, but in my experience work out to about the same overall. The correct way to determine whether a piece of software should be a library or service is by examining its intended purpose and its dependencies.

- If the software is dependent on another service or a data store, it should be a service: this provides the owners freedom to include error handling and observability that is appropriate for the service and provides protection for its dependencies against unbounded access (via observability at minimum, or human-organized contracts, etc.). Examples: software to retrieve user data from a database, software that aggregates data from a user service and an inventory service to produce a purchase history

- If the software is self-contained, e.g., it does math or "pure business logic" algorithms, it probably should be a library: performance can be optimized for one or a small handful of common use cases, error handling and observability become the responsibility of clients, and neither owners of the library or clients of it have to concern themselves with the impact to transitive dependencies (e.g., load added to a database). Examples: software that transforms user input into internal serialization formats; software that validates data, encrypts or decrypts data, or otherwise is "purely functional"

Post reply on HN