6 ms·

There are many reasons for why a library might not be sufficient. The most common one is that what you’re doing is stateful and requires some sort of data store

by DasIch 5y ago

There are many reasons for why a library might not be sufficient. The most common one is that what you’re doing is stateful and requires some sort of data store. That has a huge impact because now you need to set up the data store and potentially perform migrations, which means you may need to change how you do deployments. It may introduce a bottleneck such as number of connections to that store, so you now have limitations to think about when scaling.

Tabular-Iceberg 5y ago
Why can't a library be stateful or have a data store? If you're using libpng to edit an image on your disk you are working with both state and a data store. Yet plenty of applications do this every day without feeling a need to call it over a network. And if you have to set up and migrate a client/server DBMS for the library, wouldn't you also have to do the exact same steps as if it was running as its own process somewhere the network?
- pm90 5y ago
  > And if you have to set up and migrate a client/server DBMS for the library, wouldn't you also have to do the exact same steps as if it was running as its own process somewhere the network? You would not. The HTTP (say) API objects are versioned separately from the DB (or any internal implementation detail) of the service. This is abstraction: your API interfaces don’t change despite any internal changes. To illuminate this a bit more suppose you do share such a library anyways. Having 2 independent services let’s you upgrade each of them independently. You aren’t forced to update all of them at once.
  - Tabular-Iceberg 5y ago
    > You would not. The HTTP (say) API objects are versioned separately from the DB (or any internal implementation detail) of the service. This is abstraction: your API interfaces don’t change despite any internal changes. This is exactly the same as how libraries are supposed to be written. A stable public API so the user doesn't have to bother with internal implementation details. > Having 2 independent services let’s you upgrade each of them independently. You aren’t forced to update all of them at once. You aren't forced to do that with libraries either. You don't have to statically link them at compile time, you can load them whenever you please.
- DasIch 5y ago
  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. > And if you have to set up and migrate a client/server DBMS for the library, wouldn't you also have to do the exact same steps as if it was running as its own process somewhere the network? No only the team doing it has to. Users of a service only have to worry about the API that it exposes, which should ideally never change in backwards incompatible ways and if it does, you make sure everyone calling the API understands it and migrates and you break backwards compatibility only after everyone has migrated. As a user the implementation details of other services I don’t work on, don’t concern me. 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.
  - Tabular-Iceberg 5y ago
    > 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.
    - DasIch 5y ago
      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.

by DasIch 5y ago

Tabular-Iceberg 5y ago

Why can't a library be stateful or have a data store? If you're using libpng to edit an image on your disk you are working with both state and a data store. Yet plenty of applications do this every day without feeling a need to call it over a network. And if you have to set up and migrate a client/server DBMS for the library, wouldn't you also have to do the exact same steps as if it was running as its own process somewhere the network?

pm90 5y ago
> And if you have to set up and migrate a client/server DBMS for the library, wouldn't you also have to do the exact same steps as if it was running as its own process somewhere the network? You would not. The HTTP (say) API objects are versioned separately from the DB (or any internal implementation detail) of the service. This is abstraction: your API interfaces don’t change despite any internal changes. To illuminate this a bit more suppose you do share such a library anyways. Having 2 independent services let’s you upgrade each of them independently. You aren’t forced to update all of them at once.
- Tabular-Iceberg 5y ago
  > You would not. The HTTP (say) API objects are versioned separately from the DB (or any internal implementation detail) of the service. This is abstraction: your API interfaces don’t change despite any internal changes. This is exactly the same as how libraries are supposed to be written. A stable public API so the user doesn't have to bother with internal implementation details. > Having 2 independent services let’s you upgrade each of them independently. You aren’t forced to update all of them at once. You aren't forced to do that with libraries either. You don't have to statically link them at compile time, you can load them whenever you please.
DasIch 5y ago
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. > And if you have to set up and migrate a client/server DBMS for the library, wouldn't you also have to do the exact same steps as if it was running as its own process somewhere the network? No only the team doing it has to. Users of a service only have to worry about the API that it exposes, which should ideally never change in backwards incompatible ways and if it does, you make sure everyone calling the API understands it and migrates and you break backwards compatibility only after everyone has migrated. As a user the implementation details of other services I don’t work on, don’t concern me. 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.
- Tabular-Iceberg 5y ago
  > 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.
  - DasIch 5y ago
    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.