Live data from Hacker News

Write libraries instead of services, where possible

catern.com

51–60 of 328 posts

Re: Write libraries instead of services, where possible

#51
post #44

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

Only on the FOSS world, because it is the only way to force devs to pay. There is another alternative universe where commercial software, including libraries, gets sold.

> Only on the FOSS world, because it is the only way to force devs to pay.

What about the approach that the Qt library uses, where they have a free GPL version and a paid commercial license? People might pay to avoid GPL obligations while using the library.

Re: Write libraries instead of services, where possible

#52
post #17
post #2

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

You may take a look at Fluence's ideas on that https://fluence.network It basically allows you to share your code to others in exchange for a fee. If someone builds an app or service that uses your library, and it is paid within Fluence, you will receive a fee. This works transitively.

Oh goodie another CryptoCoin.

Re: Write libraries instead of services, where possible

#53
post #44

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

Only on the FOSS world, because it is the only way to force devs to pay. There is another alternative universe where commercial software, including libraries, gets sold.

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/

Re: Write libraries instead of services, where possible

#54
I was agreeing until I got to this nonsense:

  An object in a type-safe language can contain
  capabilities for resources which it uses to
  implement its methods, without those capabilities
  being available to the code calling those methods.

  Java-style stack inspection can restrict user or
  library code to deny access at runtime to
  unauthorized methods.

  Capability-safe architectures such as CHERI prevent
  code from accessing memory that it doesn't have an
  explicit capability for.

  Software fault isolation can allow Multics-style
  "call gates", where a library has a different
  privilege level from other code.
Aside from CHERI, which requires specialized hardware, none of these actually work and none of the implementations you will find in the wild are anything but snakeoil. Just use a service, it's the only local security boundary current OSes even pretend to enforce.

Re: Write libraries instead of services, where possible

#55

My interpretation here is that this makes a ton more sense within an organization vs externally facing. The other comments regarding saas are on point. But the way you build your saas should - imo - take this approach whenever possible.

What about saas companies providing an SDK to interact with their service? There is still a service, but you interface with it through a library.

Re: Write libraries instead of services, where possible

#57

I’m working on GCP mostly using Python and I agree that it would be nice to share a library across services instead of having yet another service. However, practically speaking: - I don’t think it is possible to create a Python library that is not publicly available through pypi/pip, but can be installed in cloud functions - if the library is a service, I only need to update one service to add a new function or fix a…

You can, you just need to specify the private repo in your requirements.txt via `--extra-index-url`

We use packagecloud.io and inject the relevant token to access our private repo at CI/CD time.

Re: Write libraries instead of services, where possible

#58

Earlier quoted context omitted.

Does everything have to be about money? This is "Hacker" News, not "Monetize Everything" News.

I think you’re reading too far. The comment doesn’t imply that everything it’s about money. It’s only a question about monetizing a library.

I don't think it's a reply to just that comment. Seems like there are about as many articles on here about mediocre SaaSes as cool technical stuff.

Of course, the site was made by a vc, so maybe it really is Monetize Everything News.

Re: Write libraries instead of services, where possible

#59

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.

Libraries can also be a PITA to maintain when you need to maintain widespread platform support, including for legacy/crufy systems. I quite enjoy the freedom of owning the underlying platform with cloud deployments vs my on-prem software days.

Re: Write libraries instead of services, where possible

#60
I don't hear people talk about the design side of services vs libraries enough, but I think it's a huge part of the picture.

Many people reach for services too fast because they feel more comfortable thinking about APIs through the lens of HTTP verbs and resource URLs than they do in the comparatively infinite garden of options inside a program.

The REST paradigm, despite most people not understanding, needing, or utilizing it fully, has out-competed most other software design memes. It was well-positioned to do so, with its creator being an author on the HTTP RFCs and the internet exploding in popularity and use right as the work was published.

REST (and earlier, SOAP) also had good business/network reasons to become very well known: a business who wants you to integrate with them must tell you about their integration pattern. They need to document it and motivate it. Then people have to actually write a lot of software that works that way, over and over. Exposure spreads at the speed of business, and a broad culture of REST-knowledge was inevitable, as was an industry of teaching it. Learning "REST" has long been a compulsory part of learning web-interfacing development.

By contrast, can you name a similarly restrictive organizational zeitgeist for internal program structure?

Domain Driven Design, maybe? The broad concept of "design patterns"? "OO"? None of these are anywhere near prescriptive enough to answer the classic question, "how do I organize this greenfield project from scratch?"

Maybe someone could take a restrictive set of best practices for internal API design, write a dissertation on it, give it a great name (like NICE) and then proselytize it effectively enough to gain mindshare and improve the design options available. (This seems like an interesting marketing problem as much as it is a software design one!)

As it is though, most people just don't know any other consistent, repeatable way to break a complex system down.

Post reply on HN