Live data from Hacker News

Write libraries instead of services, where possible

catern.com

61–70 of 181 posts

Re: Write libraries instead of services, where possible

#61
post #7

Is this really a common scenario where there's a choice between these 2 options that isn't obvious? I've never considered libraries and services to be two equal options of distributing functionality, and you just pick one of them. It's usually a function of practicality and monetization.

This was a really common dilemma at Amazon. The prevailing wisdom was opposite to the advice in the article though. Unless you had an exceptional reason, your functionality and data should be exposed as service, not a library.

Re: Write libraries instead of services, where possible

#62

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…

sqlite is a library

zeromq is a library

That’s all the storage you need

Re: Write libraries instead of services, where possible

#63
post #39

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…

This shows that we lack good abstractions over storage.

You cannot abstract away a 3 order of magnitude difference in bandwidth and latency.

Re: Write libraries instead of services, where possible

#65

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…

I'm maybe naive, but is it not possible to supply a repository interface for the user to implement? Bring your own glue?

The library uses only the interface to work with whatever orm/db connector exists in the client project.

If services at any given company all use a standard db library, it could even directly interface assuming your using that. I don't think we're talking about public apis and packages here.

Re: Write libraries instead of services, where possible

#66
post #39

Earlier quoted context omitted.

This shows that we lack good abstractions over storage.

It’s more like data storage needs are not one size fits all so it’s better left to the user who best knows their storage needs.

This is interesting, makes me wonder if a "dockerised" database is something people could use. I mean a database frontend with its own language/protocols/whatever that allows you to define the data structure but leaves the specific storage engine or format as a backend detail that can change from platform to platform.

Re: Write libraries instead of services, where possible

#67
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.

Ok so the benefits here are transparent upgrade. Thanks.

Re: Write libraries instead of services, where possible

#68

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 these services and then the initial cost of setting it up in the first place will be worth it. Any day now...

Re: Write libraries instead of services, where possible

#70

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…

sqlite is a library zeromq is a library That’s all the storage you need

No? If you have a horizontally scaled architecture or anything with multiple nodes, you can't just get away with "sqlite is a library".
Post reply on HN