Live data from Hacker News

Write libraries instead of services, where possible

catern.com

21–30 of 328 posts

Re: Write libraries instead of services, where possible

#21
This makes no sense. In order to build a service, you need a library (or something very much like it) supporting it.

If you need a library, and can use a library, yay, you're done, it's the simplest and fastest thing possible. If, for some reason, the logic you need can't be run locally, then you need a service. Find or build one and use it. You will pay in application complexity, dealing with the possibility that the service is down/unreachable. You will also pay in latency.

Why is this "not even wrong" article at the top of Hacker News?

Re: Write libraries instead of services, where possible

#22
This isn't a new concept at all, but I can't remember where I've read this before.

It is quite sensible. I'm a believer in SDKs. An SDK abstracts the backend. Gives everybody a lot more control over their own domain.

Of course, the requirement, is that the SDK needs to be super-high quality. It also needs to expose a fairly generic API that may not actually map directly to the service it abstracts/replaces.

Re: Write libraries instead of services, where possible

#23
This is very sound advice.

That being said it's incredibly hard to follow this advice in environments which encourage a polyglot stack and 'the best tool for the job' mindset. The moment you have more than one language in your stack it becomes easier to build services than to maintain libraries in each language. You can of course write native C libraries with bindings to different languages but that's a bit weird.

It's also requires more discipline to maintain abstractions and boundaries properly with libraries in large code bases but that's another story.

Re: Write libraries instead of services, where possible

#24
This is a good overview of the trade-offs between service and library. Highlighting a couple more things that I didn't notice the author mentioning:

- the author questions why one cares if users are slow to upgrade your library. That depends on what your library is doing. If you really don't need a concern yourself, you're fine. If, however, your library includes a security hole that makes it possible for people to turn software consuming your library into a botnet that attacks third parties, you aren't legally liable, but it doesn't feel good to go down in history as the people who facilitated that exploit. And it's worth remembering that even PNG encoding and decoding libraries have been in this category.

- in general, a library is going to constrain my choice of language to something compilable against a stable API. and the ecosystem of compilation tools and software vending being what it is, it is still, in many ways, quite a bit easier to get functionality in front of users by running it as a service behind an HTTPS API then by releasing it as a compilable binary and trusting all of your potential audience is going to go to the hassle of gluing your bespoke make tooling to there bespoke make tooling. if you constrain the problem to a narrower ecosystem you can avoid this hassle, but then you constrained your user base to a narrower ecosystem.

Re: Write libraries instead of services, where possible

#25

This makes no sense. In order to build a service, you need a library (or something very much like it) supporting it. If you need a library, and can use a library, yay, you're done, it's the simplest and fastest thing possible. If, for some reason, the logic you need can't be run locally, then you need a service. Find or build one and use it. You will pay in application complexity, dealing with the possibility that th…

You’re right but your service could be exposed with a public API and still have your library public.

I think the best of both worlds is to have an open-source library and a service. People can choose the one they prefer. And you can still make money from selling the service.

Re: Write libraries instead of services, where possible

#26

This makes no sense. In order to build a service, you need a library (or something very much like it) supporting it. If you need a library, and can use a library, yay, you're done, it's the simplest and fastest thing possible. If, for some reason, the logic you need can't be run locally, then you need a service. Find or build one and use it. You will pay in application complexity, dealing with the possibility that th…

Looking over the rest of the conversation here, there's a clear bias in a lot of areas to build services when a library would suffice.

You're agreeing with the article, and seem to be suggesting that your agreement represents a universal viewpoint, but it does not seem to.

Re: Write libraries instead of services, where possible

#27
Totally agree that library is easier to maintain and for developer to use. However, services are a lot easier to monetize and allow the company to collect any data they want. I can't think of any billion dollar companies that release their core library to the users.

Re: Write libraries instead of services, where possible

#28
> A service has constant administration costs which are paid by the service provider. A properly designed library instead moves these costs to the users of the library.

What really happens is that users pay money to some service provider that has said administration costs and margins for providing said library as a service. Users don't want costs related to maintaining a library or infrastructure that it needs to provide its service to them. That's why things like AWS and Azure exist.

Unless of course SaaS providers are your "users" in this case ...

Re: Write libraries instead of services, where possible

#29

> A service has constant administration costs which are paid by the service provider. A properly designed library instead moves these costs to the users of the library. I agree with the articles point, but this introduction, right there, is why it's not happening. SaaS turns your startup into a unicorn and yourself into a rich person. Or at least that's what you are hoping/aiming for. A library is not going to make y…

It is a reality. Another point is that piece of code does not mean everything. When it run on an optimised platform, it will give much value. For example, a multi-core algorithm. When it is a service, that can be ensured. Also, the Library and the beneficiary application run on same memory space (normally). So the lib code can cause crashes or can hack privacy. Another thing is your secret-sauce is public now. So it can be copied or reverse engineered.
Post reply on HN