Hacker News new | ask | show | jobs
by thinkharderdev 1925 days ago
That seems like an overly cynical explanation. There are many reasons why you would want a service instead of a library:

1. Even if the service is just a CRUD API, then you can isolate the storage layer from external users. If you just a have a library then every application needs to be able to connect to the DB.

2. You can protect mission critical resources through rate-limiting in a way that is way harder with a library.

3. Even if those are not problems, if someone has a DB connection then there is nothing really stopping them from just going around your library entirely. So random service X gets popped by an attacker. Now they can execute arbitrary queries against your DB. With a service they are still constrained to the operations exposed through the API.

4. You have a lot more freedom to change internal implementation details for a service. Need to change your DB schema (or migrate between postgres and mysql) then you can hide that behind the service interface. If you have a library out there then you have limited control over when people take version updates and it is virtually impossible to synchronize the update across all consumer of said library.
1 comments
groaner 1925 days ago
You've just described requirements that belong to a service. Congratulations, you made the right (obvious) decision.

I'm talking about writing entire services that are just wrappers around ffmpeg, pdf2html, parquet-tools, Olson tzdata, or a 10-parameter logistic regression. No stateful behavior, storage, or authoritative source of truth involved. The worst case I've seen was a service that just enumerates a bunch of values of constants (that actually never change).

There may have been some future-proofing in mind at the time, but more likely it was a solution in search of a problem.

link
thinkharderdev 1925 days ago
Fair enough, but that is why the question of service vs library is not really a question that has ONE answer. It depends on the use case.

But to push back (slightly) on your chosen examples. Dealing with binary codecs is actually something where it can make a lot of sense to wrap it in a service (even if you're just using the open source tools under the hood). It is a space that is notoriously prone to security vulnerabilities up to and including RCE vulns (https://www.cvedetails.com/vulnerability-list/vendor_id-3611...). So doing it in it's own sandbox can be a smart move. Maybe not a SaaS product per se but still something you might want to isolate as a service separated from your application server.

link