Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Write libraries instead of services, where possible

catern.com

Post reply on HN
Print view View original

31–40 of 181 posts

Re: Write libraries instead of services, where possible

#31

Post by eurekin »

cornfeedhobo wrote: post #22
slifin wrote: post #15

I hope GraalVM's Polygot runtime will eventually allow more companies to go with libraries over services in more situations for multi-language businesses. And Polylith for better reuse across projects generally.

I wish I could nuke GraalVM from the earth. It ruined my life for 2 years and I will never forgive it. It's a very stupid idea, pushed by CTOs that think Java's "write once, run everywhere" is still relevant. It literally runs every language slower and introduces all kinds of build pains. Ugh, I can't believe I had to read your comment this morning. smh

I was stumped the first time I read about Graal. It felt like 15 years too late and made zero sense to me.

Please, if you could share more about that, I'd be happy to share the pain

Re: Write libraries instead of services, where possible

#32

Post by Sanzig »

wqtz wrote: post #29

I don't get it. Can anyone kindly share where this practice can be applied to a commercial software? I am struggling to wrap my head around "how run by user" works where they are using a commercial software service.

License fees, just like the old days. Either fixed cost to license the library, a royalty based scheme (# of users/installs), or both.

Re: Write libraries instead of services, where possible

#33

Post by bee_rider »

closeparen wrote: post #6

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…

The underlying point of the post seems to be that it is better to ask the user to do more work, than the developer.

Re: Write libraries instead of services, where possible

#34

Post by leethomas »

throwaw12 wrote: post #30

"where possible" is a keyword here and easy to argue about. For example: * my logic requires a database * my logic should be isolated for compliance reasons * my logic accesses a service which is not available for everyone * my logic should be processed async and needs to store state, how do I make sure library owners have that environment * customers embedding my library are not upgrading it frequently, which leaves…

Hm, it feels like all of these except for number 2 and the last one can be solved by appropriate interfaces and documentation.

Re: Write libraries instead of services, where possible

#35

Post by mooreds »

NBJack wrote: post #27

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. Then there are the potential conflicts in your own dependencies. And let's not forget the occasional breaking change you introduced. You are now sacrificing the money saved by not hosting to maintain what will likely be a growing matrix of possible versions, underlying assumptions, and my per…

I thought the author addressed that point:

"But this assumes that slow-to-upgrade users can have negative effects on everyone else. If one user can't have a negative impact on other users, then you don't care if some users are slow to upgrade; they're only hurting themselves."

There's still the support issue, I agree. If a customer paid you money and they are on version n-10, they still expect support.

> Plus, if there was anything about your service that leveraged unique algorithmic improvements or some other proprietary tech, it is now at the mercy of anyone with a decompiler and sufficient time.

This is a valid point. My answer would be: it's all tradeoffs, but if your secret sauce is so valuable that it would be worth decompiling and can't be protected with decent pricing, license terms and lawyers, run a service.

There are plenty of technologies that are not worth decompiling for your average business customers.

Re: Write libraries instead of services, where possible

#36

Post by gjadi »

NBJack wrote: post #27

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. Then there are the potential conflicts in your own dependencies. And let's not forget the occasional breaking change you introduced. You are now sacrificing the money saved by not hosting to maintain what will likely be a growing matrix of possible versions, underlying assumptions, and my per…

> 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 services with a grace period (e.g. /v1 will be available until dec next year).

What am I missing?

Re: Write libraries instead of services, where possible

#37

Post by crazygringo »

hbn wrote: 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.

Exactly. I've never run into a situation where there was even a choice.

Is it something that relies on a private database, queue, massive processing, dedicated hardware, shared state, something geographically distributed? It's a service out of necessity.

Or is it just a bundle of quickly executing code? Then it's obviously a library.

I've never seen anybody try to turn leftPad() into a service.

Re: Write libraries instead of services, where possible

#38

Post by mooreds »

leethomas wrote: post #34
throwaw12 wrote: post #30

"where possible" is a keyword here and easy to argue about. For example: * my logic requires a database * my logic should be isolated for compliance reasons * my logic accesses a service which is not available for everyone * my logic should be processed async and needs to store state, how do I make sure library owners have that environment * customers embedding my library are not upgrading it frequently, which leaves…

Hm, it feels like all of these except for number 2 and the last one can be solved by appropriate interfaces and documentation.

On that topic, I love this article from Stripe (in 2017) about how they version their APIs: https://stripe.com/blog/api-versioning

Re: Write libraries instead of services, where possible

#39

Post by Kinrany »

closeparen wrote: post #6

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.

Re: Write libraries instead of services, where possible

#40

Post by citrin_ru »

hbn wrote: 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.

In my experience a new micro-service considered the default option for anything which could be done as a micro-service nowadays. Library API design is the lost art (almost). And the choose is not always obvious for non-technical reasons. Consider a following example: you have 3 micro-services X, Y, Z which need to interact with a platform G but this interaction requires non-trivial chunk of code. It can be done as a library or as a new adapter micro-service A which will encapsulate knowledge about platform G and will interact with X, Y, Z the way it would be easier for X, Y, Z developers to integrate. Micro-service will add network latency but will allow to make/deploy all changes only to service A. With a library one would have to test and release a new version and then ask X, Y, Z maintainers to switch to this new version. In some organizations it will be a very slow process because X, Y, Z can put an update request (from the library team) at the bottom of the backlog. With a micro-service A teams X, Y, Z would have much less power to stop/slow development.
Post reply on HN