Comment by Tabular-Iceberg | Hacker News Reader

Comment by Tabular-Iceberg | Hacker News Reader

Parent Full thread

Tabular-Iceberg

> A library can be stateful or have a data store but that means the user of that library has to be aware of changes beyond the API and hat to operate this data store.

No, it does not mean that at all. Where are you getting this idea from?

> Users of a service only have to worry about the API that it exposes

Users of a library only have to worry about the API that it exposes too. What kind of libraries have you been using?

> Note that a service equivalent to libpng should probably not exist and be a library instead. A more reasonable service would be a wishlist service that keeps track of every customers wishlist and sends notifications to customers when products on their wishlist get discounted or are back in stock.

What's the difference between the two? The only difference that I can see is that the libpng and libwishlist wouldn't waste a network round-trip and lots of serialization and deserialization compared to a png service or whishlist service.

Let's say you want to add redis for caching purposes. If a service does that, users of that service don't have to be aware of it. If a library does that, users of the library do have to be aware of that.

Same problem applies, if your library suddenly wants to access another service (like S3 or some other AWS service).

You can of course maintain a stable API in a library and you should but that restricts the changes you can do to that library. A service I could rewrite in another language without users noticing.

Why do you need to make the dependence on Redis a part of the public API? You don't do that with the service API, so why do you have to do it with the library API?

If you're going to rewrite it in another language, what difference does it make if it was a library to begin with? There's no point in making all the upfront work in both the service and all the clients making them talk on the network on the off chance you need to do a rewrite in another language, when you need to rewrite the API layer too. The only thing that would over after the rewrite is the client code. Doing it risks having wasted time doing a network API level on both client and server for nothing, not doing it just risks having to do it when you need it. Doing a rewrite "without users noticing" has no real benefit here.

> Why do you need to make the dependence on Redis a part of the public API? You don't do that with the service API, so why do you have to do it with the library API?

Where does the redis instance come from? How does the library get access to it?

These are problems the library author cannot solve and end up being problems for the user. Much like monitoring of that redis instance will also become a problem for the user.

> Where does the redis instance come from?

Same place as it would if it was a microservice. Someone has to provision it, this is not automatic just because you use microservices.

> How does the library get access to it?

How does the microservice get access to it? A common way seems to be reading a host and port from an environment variable. Nothing is preventing a library from reading from an environment variable too.

> Much like monitoring of that redis instance will also become a problem for the user.

Again, this is something you still need someone to do for the microservice. None of these things are automatically solved by microservices. There are all kinds of automation tools for these things, but they work the same whether you use microservices or not.

Reply on news.ycombinator.com