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

271–280 of 328 posts

Re: Write libraries instead of services, where possible

#271

Post by groaner »

thinkharderdev wrote: post #264
groaner wrote: post #231

Earlier quoted context omitted.

It doesn't even take oodles of money from a SaaS platform to motivate turning a library into a service. Even in in-house development, developers are often motivated to build services and have internal customers take dependencies on them so that they can expand influence and demonstrate ownership in a way that gets noticed by senior leadership and put them in line for promo. It also opens up the possibility for stakeh…

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 li…

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.

Re: Write libraries instead of services, where possible

#272

Post by Invictus0 »

carmen_sandiego wrote: post #261
Invictus0 wrote: post #202

Earlier quoted context omitted.

And the end result of this whole thing is too-expensive software that no one is willing to pay for and doesn't get used, and no one's problem is actually solved. And then when the "startup" fails, the code is of course not turned into a library, and it all starts again.

If you think an $x one-time payment is a great reward for making y, then make y and charge $x. Seems like a free opportunity to me. If it's really so simple, you can easily undercut those doing the subscription model. Unless, of course, $x is not actually that motivating a fee for the work. In which case, it's a bit entitled to expect others to work for a fee that doesn't spur you into action either.

It has nothing to do with entitlement. It has to do with the fruit of the labor not being worth the price necessary to remunerate that labor.

Re: Write libraries instead of services, where possible

#273

Post by christophilus »

erfgh wrote: post #105
taeric wrote: post #65

I have a hard disagree here. Though, I suspect it is a matter of what your code is doing. First, my objection, though. Pushing this "to the users" is in no way easier to support. It is easier to abandon, but support is a different thing. You will have support contacts. And, due to the distributed nature of the deployment, you will have a much harder time isolating your code from the environment it is in. With a servi…

You have a disagreement. You don't have a disagree.

They’ll hand out a disagree to anyone these days.

Re: Write libraries instead of services, where possible

#274

Post by gravypod »

naikrovek wrote: post #266
gravypod wrote: post #247

Earlier quoted context omitted.

The reason LSPs exist is very simple: 1. There are N editors in the world (vim, emacs, vscode, ...) and there are M programming languages (c, c++, java, python, ...). 2. Most programming language developers write tooling to make their language ecosystem nice. (gofmt, cargo, ...) 3. Most programming language developers like writing in their programming language. 4. Not all N editors or M languages are written in the s…

So why can't you just write your language support library in whatever language you like, wrap that in something that supports the C ABI if it doesn't already, then call that from your editor? If you're going to use a language server, then you have to write code to call the LSP. Why not just call a library? Why does there need to be a server involved? Why does there need to be pipes, or network traffic involved? LSP d…

> So why can't you just write your language support library in whatever language you like, wrap that in something that supports the C ABI if it doesn't already, then call that from your editor?

You can! This is called "defining an API" and this is basically what an LSP is. The downsides of using the C ABI like I said is not all programming languages use the C ABI. To work around this you have suggested writing a wrapper transforms to/from this API that follows the C ABI calling conventions in each language you want to support. To see how fun of an endeavor this is you can look at things like libgit2 [0] which spend a lot of time maintaining bindings for each language. While these bindings do absolutely work they are:

1. Difficult to maintain (look at some issues [1, 2, 3])

2. Completely duplicates effort (test frameworks, integration testing, etc cannot be automated).

If you instead separate into services the lsp team could maintain a whole test suite that your service could be run against. You would provide an LSP + a corpus that has certain features and the test framework could do a set of operations to talk to this system.

If you use a dsl to describe the protocol you can automatically generate server/client libraries to use to talk to/implement an lsp (and other services!) I'm a huge fan of gRPC for this reason: write a single dsl and now everyone can talk to/implement your service.

You can define shared debugging tools. For example ebpf can be used to debug any networked application in linux regardless of what it's implemented in. Similar tools can now be developed at an application protocol level for all LSPs to make development easier without tying the infrastructure to a single language or ABI.

The crux of the issue is: service boundaries solve the exact same thing that C ABI/ffi solve with the following benefit:

1. No dependency on any language-specific implementation of a protocol or API.

2. TCP is supported everywhere and you can get a bunch of free monitoring features from using it. It's also pretty darn fast now especially to localhost.

3. Easy to plug into an TCP server regardless of your runtime environment. Do you need to host your source code on a linus system when your dev environment is running in windows in Visual Studios? No problem!

> Language support people still have to write language support code. Editor people still have to write editor support code.

Correct! Except it's which code gets duplicated. Could LSPs been implemented as .so & dlls that followed the C ABI calling conventions passing HSOURCE_FILE* back and forth in process? Yes! Would it have been easy to implement that for all languages in a safe and secure way that can run in an adversarial environment and allow different people to manage and debug different implementations while sharing standardized tooling? No, not easily.

[0] - https://github.com/libgit2/libgit2#language-bindings

[1] - https://github.com/nodegit/nodegit/issues

[2] - https://github.com/libgit2/git2go/issues

[3] - https://github.com/libgit2/pygit2/issues

Re: Write libraries instead of services, where possible

#275

Post by thinkharderdev »

asdfasgasdgasdg wrote: post #194

Decent engineering advice, but not such good economic advice. And therein lies the rub. It's very hard to get people to do that which will make them less money.

I'm not so sure about that. The great thing about software before SaaS (as a business model) was that selling another copy was basically zero marginal cost. And of course there were the extremely lucrative "professional services" you could reap because installing an enterprise software package on-prem was a nightmare.

Maybe it's just that the open source ecosystem covers most of the low-hanging fruit for things that could be libraries. And things that are big and complicated and require their own databases and such are easier to run as services for the actual user.

Re: Write libraries instead of services, where possible

#276

Post by ngrilly »

cultofmetatron wrote: post #141

Phoenix is practically built with this idea in mind. My startup is built out of a single phoenix monolith. Only external dependency is postgres. Despite this, I've managed to completely avoid all the typical scaling issues of a monolith. Need a service or background worker? I juts make a Genserver or Oban worker and mount it in the supervision tree. The Beam takes care of maintaining the process, pubsub to said servi…

How do you keep track of background jobs? Is the queue persisted on disk somewhere? If it's not and a background worker crashes for some reason, then is the job lost?

Re: Write libraries instead of services, where possible

#277

Post by thinkharderdev »

groaner wrote: post #271
thinkharderdev wrote: post #264

Earlier quoted context omitted.

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 li…

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…

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.

Re: Write libraries instead of services, where possible

#278

Post by naikrovek »

gravypod wrote: post #274
naikrovek wrote: post #266

Earlier quoted context omitted.

So why can't you just write your language support library in whatever language you like, wrap that in something that supports the C ABI if it doesn't already, then call that from your editor? If you're going to use a language server, then you have to write code to call the LSP. Why not just call a library? Why does there need to be a server involved? Why does there need to be pipes, or network traffic involved? LSP d…

> So why can't you just write your language support library in whatever language you like, wrap that in something that supports the C ABI if it doesn't already, then call that from your editor? You can! This is called "defining an API" and this is basically what an LSP is. The downsides of using the C ABI like I said is not all programming languages use the C ABI. To work around this you have suggested writing a wrap…

This still doesn't seem superior to library calls from a complexity point of view.

On one hand you have a library to secure. On the other hand you have the same library (or at least the same logic and methods) now with a JSON-RPC server wrapping it, and both need to be secured.

I would feel a lot better if it weren't JSON, I guess. Binary protocols are just SO MUCH FASTER and require so much less memory. Parsing JSON is fast, sure. Reading and writing binary is probably 3 orders of magnitude faster, and it's easier to read and write binary, in my experience. (I also don't understand why protobuf exists.)

Re: Write libraries instead of services, where possible

#279

Post by jaxn »

scruple wrote: post #71
chin7an wrote: post #53

Earlier quoted context omitted.

A few libraries in the Java world have this model. They haven't produced unicorns but seem to be pretty stable businesses - jOOQ(1), hibernate(2) etc. I'm researching DB libraries for work and so those are the ones I recalled immediately, but I think there are some commercial UI ones too. [1] https://www.jooq.org/ [2] http://hibernate.org/orm/support/

Sidekiq [0], as well. Though that's a Ruby background processor. [0]: https://sidekiq.org/

Graphql.pro is a paid library for ruby as well.

Re: Write libraries instead of services, where possible

#280

Post by whiskeytuesday »

machiaweliczny wrote: post #254
cultofmetatron wrote: post #141

Phoenix is practically built with this idea in mind. My startup is built out of a single phoenix monolith. Only external dependency is postgres. Despite this, I've managed to completely avoid all the typical scaling issues of a monolith. Need a service or background worker? I juts make a Genserver or Oban worker and mount it in the supervision tree. The Beam takes care of maintaining the process, pubsub to said servi…

I can recommend watching this[0] to understand BEAM design better. [0] - https://www.youtube.com/watch?v=JvBT4XBdoUE

+1, probably my favourite talk on the BEAM too, even allowing for the fact that listening to Joe Armstrong himself was always a distinct pleasure.
Post reply on HN