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

261–270 of 328 posts

Re: Write libraries instead of services, where possible

#261

Post by carmen_sandiego »

Invictus0 wrote: post #202
carmen_sandiego wrote: post #171

Earlier quoted context omitted.

So write your own software for your needs and sell it for a one off price? But you presumably won't because the incentive isn't great enough. Which is exactly why people milk subs. And if you're not willing to do it for the incentive of a one off price, why should anyone else be?

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.

Re: Write libraries instead of services, where possible

#262

Post by ThinkBeat »

ganafagol wrote: post #20

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

Not really.

It is a possibility that could happen, but it is not very probable.

I am certain taht millions of services are written and dies in lonely obscurity.

According to a Hulu documentary I watched recently some woman makes over 150K a month from OnlyFans.

Lots of people want that and sign up and the vast majority will not make anything.

Or the more classic moving to Hollywood to become a famous actor making $$$$, or be a rock star.

The chances your services will make billions is slim,

If you write a good library, you can sell it. I would much rather buy a library than a service. (I may be in the minority for sure).

If you give it away, and if it does prove highly popular then wrapping it in a service and offering it that way will create some income.

With that strategy you can iterate over functionality and find out what the market wants the most and create a product that is more mature as a service.

Re: Write libraries instead of services, where possible

#263

Post by pkos98 »

cultofmetatron wrote: post #157
wcarss wrote: post #149

Earlier quoted context omitted.

this sounds really neat and I'm going to go read about it! I also wanted to call out that this ~sentence has just... a bunch of things that seem like jargon/names within the community? As an outsider, I have no idea what they mean: > make a Genserver or Oban worker and mount it in the supervision tree. The Beam takes care of maintaining the process it sounds very sci-fi :)

sorry! so I'll clarify Elixir inherits a library called OTP from erlang which is a set of primitives for building massively concurrent systems. A Genserver is sort of like a Base Class for a object that runs as an independant process that plugs into OTP. By inheriting/implementing the Genserver behavior, you create an independant process that can be mounted in an OTP supervision tree which runs at the top of your app…

!Important clarification!

In the world of OTP (Open telecom platform), a process is the term for what essentially is a green-thread, not an OS process!

So it is: a) much, much more lightweight (IIRC ~ 1Kb) b) scheduled by the Erlang virtual machine (so called BEAM)'s scheduler. The BEAM's schedulers run on a per-thread-basis, inside the BEAM's process c) independently garbage collected, no mutable memory sharing

Re: Write libraries instead of services, where possible

#264

Post by thinkharderdev »

groaner wrote: post #231
ganafagol wrote: post #20

> 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 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 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.

Re: Write libraries instead of services, where possible

#265

Post by Thorentis »

ganafagol wrote: post #20

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

I detest that people have accepted this business model as being the norm. I think the bar has been lowered drastically in terms of what people are willing to pay for. If somebody launched Notepad as a Service with premium backgrounds instead of that boring, conventional white color, then you'd probably find enough people willing to pay $9.99/month for it. It's just absurd.

Re: Write libraries instead of services, where possible

#266

Post by naikrovek »

gravypod wrote: post #247
naikrovek wrote: post #242

I kinda wish that the people behind the Language Server Protocol understood this. The whole idea of that makes no sense to me at all. None. I mean, I get how it works, and why people think it's a good thing, but libraries are the better way to go in every situation that I can imagine. There is no need for the Language Server Protocol or language servers in general, and its existence only makes things more complicated…

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 defines that JSON-RPC is to be used as the communications layer. Why does JSON have to be involved?

A library naming convention could have just as easily been written which allows all the things an LSP allows. Just name the methods in your language support library the same way everyone else is and then anyone can call your library and gain support for your language. This is the same thing that's happening with language servers, except it's much cleaner and more straightforward than language servers.

What people are doing is writing their language support library in whatever language they like, then wrapping that in a JSON-RPC wrapper with the proper LSP stuff on it. Now the editors have to implement an LSP client when they already had the ability to call libraries provided via the C ABI.

Sure editors only need one piece of code to call any LSP server, but they didn't need any more code to call a library. If those editors don't implement the LSP calling code themselves, and rely on a library, they still have to call a library that they are using the LSP to avoid doing in the first place.

Nothing about LSPs enable anything that wasn't possible before. Nothing about LSPs makes anything that was possible before any simpler. It all just adds crap to the chain and everyone is calling it a "win." It's not a win. It's a loss. It's adding complexity and layers where they don't need to be, for no discernable benefit. Language support people still have to write language support code. Editor people still have to write editor support code. Except now they do it with new protocols they can add to their resume. This is resume-oriented development, that's all.

Re: Write libraries instead of services, where possible

#268

Post by gitgud »

What I think is missing in this take is the separation of concerns and encapsulation of dependencies that services bring over libraries.

For example; a pdf transformation library may require a Linux machine for with custom PDF software, maybe even accelerated graphics hardware too. With a library I have to deal with all that, but a service can encapsulate that behind a HTTP interface.

Alternatively, with a pdf transformation library, you need to deal with those dependencies and hardware requirements yourself.

Re: Write libraries instead of services, where possible

#269

Post by thinkharderdev »

thepete2 wrote: post #189
zach_garwood wrote: post #183

This is a bad take and a false dichotomy. The reasons for choosing a library or a service are so myriad and context-dependent that any generalization about which is "better" is just silliness. It's like saying, "If you have to get somewhere, running is better than walking." Sure, in the case of a race or escaping a predator, running is probably the best option. But what if you want to take in the sights or you can't…

I agree. But if we steel-man this,it could make sense for services that can be replaced by libraries. So simple services that could be replaced by a slim library on the user's machine.

Some actual examples could go along way towards making a better point. Obviously some things are better as services and other better as libraries. The question is under what circumstances to choose one model or the other. I didn't think the article really shed any light on that question.

I also think that the author (and other commenters in this thread) underestimate how much the move to SaaS is driven by what users want as opposed to what the providers want. I'm old enough the remember the pre-SaaS/pre-cloud days when everything was a library. And it was a nightmare. You have to run all of your own infrastructure and the pace of development in the products themselves was terrible. And of course it makes sense. Need to store some data? A SaaS provider can pick a storage layer that meets their needs and be done with. But of course a purveyor of enterprise software has to support every possible storage layer under the sun.

Re: Write libraries instead of services, where possible

#270

Post by thinkharderdev »

101008 wrote: post #2

I like the approach and it seems to be definitely better for everyone, but how you monetize a library?

The way they were monetized before SaaS was a thing. You sell licenses to use them. You can't 100% prevent people from using them without a license but for the most part you don't really have to. A company with real assets is generally not going to use a cracked version of proprietary libraries and expose themselves to litigation.
Post reply on HN