22 ms·

Write libraries instead of services, where possible

635 points by catern 6y ago

sid6376 6y ago
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.
- inter_netuser 6y ago
  why weird? It also doesn't have to be C, just anything that compiles to a native binary lib.
- pedro2 6y ago
  Not everyone's cup of tea, but on Linux gobject-introspection allows for automatic or semi-automatic generation of bindings for X languages. .NET also -- and this is only my interpretation -- is following that path.
  - viferga 6y ago
    I also think it's the way to go: https://github.com/metacall/core https://github.com/metacall/core
the_arun 6y ago
If it is common service used across the company, writing service makes sense as teams can use different programming languages to consume it. Libraries expect everyone to use same language or that library has to be recreated in other languages & managed.
shadowgovt 6y ago
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.
101008 6y ago
I like the approach and it seems to be definitely better for everyone, but how you monetize a library?
- randlet 6y ago
  You can sell a library just as well as any other piece of software I think.
  - freeone3000 6y ago
    Not really. Your market is different. Instead of selling to business managers seeking to solve a problem, you're selling to developers. Developers tend to like solving problems themselves, and you're competing versus free.
    - chrisrhoden 6y ago
      The definition being used here for libraries and services has both being marketed to developers. We're talking about APIs, not a web product with a UI etc. Services, in this article, doesn't refer to things that can only be built as services (e.g. because it queries a proprietary dataset) but those that might optionally be built as services (e.g. fetching and processing otherwise accessible data) and could, as easily, be built as a library.
    - selfhoster11 6y ago
      There's an ecosystem of paid libraries and tools around Java and C#. While developers might like to solve problems of their own, standards compliance is one place that they likely wouldn't want to tread their own path if they can help it. They've got work to do, and deadlines.
    - pjmlp 6y ago
      On the Sony, Nintendo, Microsoft, Apple and Google developer ecosystems there are plenty of shops selling libraries. Basically where most devs selling commercial software live on.
    - 6y ago
jasode 6y ago
>People say, "services are easy because you can upgrade them centrally, so you can avoid slow-to-upgrade users making everyone's lives worse." > But this assumes that slow-to-upgrade users can have negative effects on everyone else. Is the above a reference to Moxie Marlinspike's comments[1]? So would a concrete example of your abstract essay be that communication should be a client utility that uses an XMPP library[2] instead of Signal's services? [1] https://signal.org/blog/the-ecosystem-is-moving/ https://signal.org/blog/the-ecosystem-is-moving/ [2] https://xmpp.org/software/libraries.html https://xmpp.org/software/libraries.html
smitty1e 6y ago
Why not embrace the healing power of a project that can be deployed as a service AND a library?
ganafagol 6y ago
> 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 you a billionaire. Sad but reality.
- veenusav 6y ago
  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.
- deleted 6y ago
  [deleted]
- bogdanoff_2 6y ago
  Is SaaS really the only viable (or "unicorn") business model? Do people not sell software licenses anymore? (In theory nothing prevents you from making your license require recurring payment as well)
  - tobmlt 6y ago
    *Most who sell licenses seem to be moving their old stuff/cash-cow-behemoths/etc to saas as quickly (slowly) as possible. -certainly there are exceptions. Exceptions seem more likely with smaller older companies with different priorities.
  - indigochill 6y ago
    I suspect it's the same reason game devs are hot for streaming. When the code only runs on machines you control, piracy becomes impossible. By contrast, trusting people to respect licenses on code on their computers is how piracy happens. In my opinion this is a feature, not a bug, but the business reason is clear for why all commercial software is moving towards the SaaS model.
geophile 6y ago
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?
- chrisrhoden 6y ago
  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.
  - geophile 6y ago
    Yes, we are both saying "use a library when possible". I am mystified by the need to write or read such an article. It seems akin to "don't use an airplane to go to the corner store for a dozen eggs".
- human 6y ago
  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.
ChrisMarshallNY 6y ago
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.
hamsterbooster 6y ago
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.
- jacobr1 6y ago
  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.
numlock86 6y ago
> 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 ...
zzbzq 6y ago
1990s advice on a 1990s website. It's the opposite. We need to move away from package hell by splitting our work in two opposite directions: on the one hand, we should move back to large, effective standard libraries; on the other hand, we should move toward more services, fewer library packages. A project shouldn't need more than a few packages, usually for something like a database connection protocol. Working with libraries is the worst part of the job.
- Ericson2314 6y ago
  This is one of the worst ideas I've ever read on this site. But I'm glad you wrote it, as this is the epitome of a sentiment I've many times seen lurking. - Standard libraries always go bad over time as idioms change and they don't have a policy for breaking changes - Services do not compose as easily as libraries. Composition is key to code reuse. I understand most off the industry deals with terrible libraries, and many of you long for simpler times, but the proliferation of complexity will occur with or without the NPMs of the world, as the industry grows and functions in a economy that doesn't care about externalities, including endemic stupid extra complexity.
- collyw 6y ago
  I am trying to maintain an absolute pile of shite because the previous lead dev needed to reinvent every wheel in an undocumented untested way. On boarding developers takes longer. Bugs are more difficult to fix. You are in my opinion a bad developer for having that attitude. Being able to know when and when not to use a library is an important skill. As with everything, it's a trade off and you seem to not be aware of one side.
cam- 6y ago
Counter argument, don't deploy your code on other people's hosts.
- xmaayy 6y ago
  Got it, buy the cheapest possible 600$ server, pay 200$/month to collocate it (also do a cost benefit of different facilities), be responsible for all hardware failures and availability issues.
  - cam- 6y ago
    One issue I have seen in distributed systems is where a library is on another customer/teams hosts and brings them down due to a bug in the library. The other customer/team has no way to fix the bug and is dependent on getting the attention of the company/team who vended the lib in the first place. One I remember is where a library had a bug which created 0 byte files and exhausted the inodes causing an outage. Cloud systems have become cheap enough and flexible enough that protecting your customers by not putting your bugs on their hosts is not as big as a lift as it used to be when you had buy bare metal servers or explicit VMs.
  - collyw 6y ago
    > the cheapest possible 600$ server Surely $600 dollar servers all cost the same
thinkingkong 6y ago
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.
- wkfavdpb 6y ago
  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.
mkl95 6y ago
Good advice. I will take a modular monolith over a frontend that consumes a series of services any day. Black boxes are fun until funny things start to happen inside them.
wodenokoto 6y ago
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 bug - a service can be called by other non Python services. With that being said it is much, much easier writing code that import a library than call out to a service. And it is also much, much easier to test.
- jacobr1 6y ago
  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.
- BerislavLopac 6y ago
  > 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 Of course it is possible. You can set up your own PEP 503 [0] compliant repository, even unreachable outside your VPC, and use pip to install from it. One caveat: on GCF you can -- if I'm not mistaken -- only install Python-only libraries; but if you use Cloud Run you can install anything inside your container. There are servers for hosting your own PEP503 repo, such as devpi [1] -- but ultimately you only need a Web server to serve the file index. [0] https://www.python.org/dev/peps/pep-0503/ https://www.python.org/dev/peps/pep-0503/ [1] https://www.devpi.net/ https://www.devpi.net/
bcoates 6y ago
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.
- eru 6y ago
  However, if your user agrees to be limited (because it prevents them from making mistakes), we have fairly reliable methods. But yes, they require the user of your library to cooperate.
- catern 6y ago
  >none of these actually work and none of the implementations you will find in the wild are anything but snakeoil This is wrong. The foundation of the modern web is safe Javascript implementations. BPF/eBPF is another widespread technology using isolation mechanisms like this. All of these techniques work. As I mentioned in the very next sentence, only the first in that list is common, but that doesn't mean the rest don't work. If you have found some fundamental hole in NaCL or CHERI or JVM security which makes them ineffective, feel free to publish your results.
  - bpodgursky 6y ago
    I think you are talking about different things. I have absolutely decompiled obfuscated third-party Java libraries, fiddled with a few variables or method signatures, and recompiled + used them. JVM security has nothing to do with this.
viferga 6y ago
Why don't doing both at the same time? https://youtu.be/2RAqTmQAWEc https://youtu.be/2RAqTmQAWEc
wcarss 6y ago
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.
- ahepp 6y ago
  SOAP doesn't have anything like the restrictions rest has, does it?
  - lostcolony 6y ago
    It doesn't, but also, services were far less common compared with libraries when it was popular.
  - zo1 6y ago
taeric 6y ago
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 service, it would be a lie to claim this is easier, but it is a bit more approachable. Now, a difference, I believe, really comes in to whether or not there is state associated with what you do. If there is, and it is not something that makes sense to move close to the user, then a service is pretty much required. If there is no state, make sure that is not artificially done by just moving to all state being managed by the user.
- erfgh 6y ago
  You have a disagreement. You don't have a disagree.
  - esperent 6y ago
    Hard disagree. Language is fluid, get used to it.
  - sethammons 6y ago
    Take ~6min to watch Stephen Fry Kinetic Typography - Language. It is my favorite take on changes in English and addresses verbing of nouns directly. https://www.youtube.com/watch?v=J7E-aoXLZGY https://www.youtube.com/watch?v=J7E-aoXLZGY
  - jmchuster 6y ago
    Sorry that we confuse you non-native speakers. Contemporary american english has much greater flexibility with deverbal nominalizations.
  - christophilus 6y ago
    They’ll hand out a disagree to anyone these days.
- 6y ago
jrockway 6y ago
I don't think there's a one size fits all solution here, and there are constraints that the author isn't seeing. In favor of a service are cases where users want plugins, and the upstream doesn't want to maintain them. An example is anything that touches DNS, like cert-manager, external-dns, things like that. There are thousands of DNS hosts, and they each have their own API. So nobody wants to provide support for all of them out of the box -- the upstream maintainer's entire life will become approving PRs for obscure DNS services. The maintainer can't test them, because they don't have an account, so can't own the quality of the final product anymore. Therefore, nobody does this. Services are an answer to this problem -- the thing you actually want to use defines an API for DNS services, and the DNS provider gives you a program that can receive messages to update DNS, and everyone is happy. You just run it as a sidecar, and you can update it when your DNS provider changes their API, and update the other thing whenever they add a new feature that you want. The coupling is loose, so you don't get the same perfect reliability as a purpose-built "update foocorp dns whenever an ingress rule adds a hostname", but it's pretty good. (I honestly don't know if this is actually how cert-manager and external-dns work. I use cert-manager and it builds in libraries for the DNS providers I use, with the caveat that they aren't accepting any more. I don't use external-dns, but I heard some rumblings about making a standard a few years back for this sort of thing. Didn't check in on the status of either. It's just a hypothetical example ;) Libraries are unhelpful here because there are a billion programming languages, and the upstream provider will never choose your programming language of choice as their priority. Additionally, container builds are hard and I've never heard of anyone with a reliable way of taking some sort of upstream project and building it with local add-ons at every upstream commit, tagging stable versions in parallel with the upstream, etc. Definitely possible, but out of reach of the average container operator. Things like Go without dynamic linking (a feature I agree with, BTW), and container builds make services more critical for the plugin type use case. (My dream is to just write libraries in something that compiles to WebAssembly and use that to implement a plugin system in applications that need it. Some people are kind of sort of doing this; Envoy for example.) On the other hand, sometimes you need the deep integration that only libraries can provide. It's popular to use sidecars to add network features like distributed tracing and mTLS; linkerd and Istio are examples. But these are exactly the use cases where you should use libraries instead of services. You need to see the TLS handshake so that your application can make authorization decisions based on the peer that you're connected to. To do distributed tracing, you need to copy the X-B3-Trace-Id header out of the incoming HTTP request into the outgoing HTTP request. Libraries can do that for you, but services can't. In summary, the answer on library or service is "it depends". Hopefully this comment adds a little more nuance than the original article.
abeppu 6y ago
I think context is really important here. Multiple comments in this thread jump to the concern that it is much harder to monetize a library -- but in an era where many developers are enthusiastic about service oriented architecture, it's also worth considering the decision between services and libraries for functionality which will only be exposed inside of an organization. One other dimension not discussed in the article is how the scale of use varies over time. A service operator needs to ensure the service scales to support its use. But some use cases are extremely spiky (e.g. when something is invoked by a batch job processing many TB of data among many workers). Even if the service is able to dynamically scale based on load, that's not frictionless or without cost to the team operating the service, and can cause a degradation of service provided to other users. By contrast, if one provides a library, any given use case can be responsible for providing the capacity to support themselves. A last dimension of libraries vs services within an organization is attributing value and cost. This is a double-edged sword. When providing a service, the team that operates the service may have some clear costs to continue to run it. Just providing the service can make you look like a cost center. If you do the extra work to make sure use cases are distinguished and trackable (e.g. use cases have separate credentials used in calling the service), then perhaps these costs (and "value" in the form of request volume) can be tied to callers. When providing a library, the team that provides it both doesn't appear as a cost center, but also it may not have a straight forward way of knowing how intensively their library is being used and therefore how much value it has provided to the org.
surajrmal 6y ago
Services allow you to interop with all languages, they let you avoid worrying about threading models of the program your operating within, and they don't have access to all of they sandbox the code being run allowing you to avoid worrying about the code doing something nefarious with access it gets from running inside your process. On top of this, people just seem to be fat more okay with not having source access to a service than they do using proprietary libraries (which from a security perspective makes sense to me). If there was a standard threading model, language agnostic interop with clear evolutionary properties (perhaps a channel based one), and a generic mechanism for sandboxing libraries folks could use then maybe they would consider providing libraries more. Some sort of hybrid between COM, wasm, and optimized in process grpc is more or less what I'm trying to describe. This doesn't exist, however, and moving your library out of process solves this issue neatly so it's not a surprise that's what's happening.
KptMarchewa 6y ago
I don't really understand this comparison. Point of having a service is not only exposing computation - more usually, it's exposing a centralized database. How is library useful in this context? Unless, the author is talking about writing, for example, a number multiplication library vs number multiplication service... but then the advice is obvious. EDIT: also, this stuff about accessing memoty, denying access at runtime makes me think that it was written for a different times. Nowadays, who creates new stuff that's not isolated by VM or container layer?
amelius 6y ago
And please write your library in all languages.
TheRealPomax 6y ago
libraries don't make you money, services do. Libraries get your name in a license in the "open source licenses" tucked 20 menus deep in an app's hidden dev options.
artembugara 6y ago
Write libraries AND services, where it makes sense. I wrote a Python library to scrape google news [0] We also have it as a service [1] Want to know why? Because devs who can't pay won't pay. Businesses who can pay will rather pay for a service (API in our case), and not care about maintaining it. [0] https://github.com/kotartemiy/pygooglenews https://github.com/kotartemiy/pygooglenews [1] https://newscatcherapi.com/google-news-api https://newscatcherapi.com/google-news-api
- asdff 6y ago
  The hidden message of the mantra "just self host your own" is that it takes you time to set that up. If you aren't familiar with that process from past experiences, you now have to get those man hours somehow for selfhosting, and suddenly that free self-hosted solution is not so free if you value your time over $0/hr. That's where I think services should come in. Only with no phoning home crap or cruft, just give me a hosted version of a bare bones cli app that I can access anywhere from any device. Give me my own instance of tiny tiny RSS or something else that's very lightweight and commonly selfhosted for $1 a month, and I'll happily pay up to avoid having to spend a few hours vetting hosting options and setting this up myself.
- pillefitz 6y ago
  How does the liscence agreement with Google look like, you just pay per Query? Does Google prohibit caching? Just curious as I remember reading nightmare stories of companies basing their business model on Google services (maps).
brundolf 6y ago
Libraries are better for end-users, services are better for the businesses building them. When a service could just as easily be a library (which isn't always the case, to be fair), it's not a question of best-practice, it's a question of power-balance and incentives.
cultofmetatron 6y ago
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 service and error handling in the event of a crash. I'm basicly getting all the best advantages of a monolith * one codebase to navigate, our team is TINY * all functionality is in libraries And all the advantages of microservices without the associated costs. (orchestration, management etc) * bottleneck use cases can live on their own nodes * publish subscribe to dispatch background jobs * services that each focus on doing one thing really well We've accomplished this all through just libraries and a little bit of configuration. At no point so far have we had to.. * setup a message broker (phoenix pubsub has been fine for us. we can send messages between different processes on the server and to the clients themselves over channels) * setup external clusters for background workers. (Oban was drop in and jsut works. I'm able to add a new worker without having to tell devops anything. the supervision tree allocates the memory for the process and takes care of fault tolerance for me. That leaves me to focus on solving the business problems) * setup a second github repo. Its a monorepo and at out scale, its fine. We have one library for communicating to the database that every system just uses. Eventually we'll probably have to start rethinking and building out separate services. But I'm happy that we're already able to get some of teh benefits of a microservice architecture while sticking to what makes monoliths great for mvps. It will be awhile before we need to think about scaling out web service. It just works. Leaves me more time to work on tuning out database to keep up!
- fiddlerwoaroof 6y ago
  BEAM will automatically distribute processes across a cluster, right?
  - cultofmetatron 6y ago
    not automatically but its pretty easy to configure in your supervision tree file. I don't know the details because whatever happens by default has taken care of our needs so far. IT does automatically distribute processes across all the cores on a cpu though.
divyekapoor 6y ago
After building embedded library codebases that have had version skew across clients (sometimes over several years worth of code), the library approach just stops evolving after a certain point - the backward compatibility mess is a drowning morass. There is no control on the upgrade cycle, old infra can't be turned down, performance is a risk, upgrades are a risk, every deploy has "foreign code" and the potential for a dependency mismatch. Services work - use them. Unless performance is of the utmost concern, say no to libraries.
Evidlo 6y ago
Isn't this exactly what the Sans I/O project is about? https://sans-io.readthedocs.io/ https://sans-io.readthedocs.io/
l8again 6y ago
Clearly, it makes sense on the "sellers" side to make it into a service - the article pretty much conceded to that. However, this issue is also created by the "buyers" side as well. To give a concrete example - prometheus is an open source alternative for observability. But if you have a small team and want to release early, you will still go to DataDogs, and splunks of the world. Of course, you can say but that's fine. But there are others that could have been a library. Yes, but libraries also come with a maintenance overhead (security, patches, etc.).
q3k 6y ago
Meanwhile, any time I receive a piece of functionality as a blackbox .so library from a vendor, the first thing I do with it is wrap it in a gRPC host so I can easily call it from the rest of my codebase.
billiam 6y ago
I'd love to see a somewhat scientific analysis of the fully considered TCO of services and libraries of similar complexity, usage, and function.
quelsolaar 6y ago
Question: When people build services that internally communicate using web requests, are people using HTTP, or HTTPS?
Kinrany 6y ago
Services have another benefit: they can be used in any language. That is, until WASM becomes easy enough to both author and embed!
zach_garwood 6y ago
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 sweat in your clothes? Running would be a bad choice, even though it's faster. There are just too many variables in the real world to make any sort of blanket statement about which approach is "better."
- thepete2 6y ago
  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.
  - thinkharderdev 6y ago
    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.
msluyter 6y ago
Curious what people's experiences are wrt library development within an enterprise. I've been at organizations where basically everything was done via services and there was very little library usage, and I always thought that was suboptimal. Now I'm at a place where we utilize lots of libraries and they seem to pose pretty significant costs of their own. A typical example is if we need to do something that the library doesn't support, we're faced with an unpleasant choice of updating the library itself or doing some sort of workaround/hack. The former shouldn't be that difficult, but in cases where a library was written by a different team, updating can be painful if you don't have someone with experience with the library/domain on your team, or if you have to jump through approval hoops. I suppose this is more an ownership/organizational problem and applies to services as well, but somehow dealing with library dependencies feels more onerous.
- mmmpetrichor 6y ago
  Exactly. Integrating external libraries into another system is much harder than leveraging e.g. a RESTAPI. The OP seems to be saying that Service oriented architecture (SOA) is worse. It's definitely not. There's no "better" or "worse" here. It's just two different options with different costs of integration and interoperability. the service architecture is going to have additional maintenance overhead but provide cheaper and easier interoperability.
asdfasgasdgasdg 6y ago
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.
- thinkharderdev 6y ago
  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.
max_ 6y ago
Reading this sounded like an implicit description of the Unix philosophy[0] Software would improve alot if these ideas where reanimated. [0]: https://en.m.wikipedia.org/wiki/Unix_philosophy https://en.m.wikipedia.org/wiki/Unix_philosophy
antihero 6y ago
I don't get it, what if you want to use a different language to your clients? What if you want to have state shared across an entire company and spin up/down bits individually?
abraxas 6y ago
Yeah, the "everything service" mentality is getting a little out of hand. The most recent, egregious example I heard of is the "language server" in VS Code. What used to be a plugin/library functionality has now been turned into a distributed computing problem with all its warts and gotchas. I've no idea who makes these decisions on a project like that and how they justify them.
naikrovek 6y ago
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 than they need to be.
- gravypod 6y ago
  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 same language. In addition the programming languages that our editors/tools are written in cannot always interface with each other clearly (cffi is not supported in every language). 5. "All" programming languages that people use today have some networking stack that can be used to open TCP sockets and send data. Given these facts it would be easy to conclude that: If you want editor developers to focus on writing text editors and you want tooling developers to focus on writing tooling but you also want your text editors to support advanced functionality that is already implemented in your tooling the easiest way to send that information is over TCP. The other options are: 1. Don't have advanced languages for "All" languages. 2. Force everyone in the world to use one programming language. 3. Force all tooling in the world to be written in one programming language. 4. Force everyone to implement another cross-language communication system (ex: cffi) in "All" languages. Unfortunately these options are more complex then just defining an API and sending messages back and forth.
  - naikrovek 6y ago
    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.
mbar84 6y ago
A service is a bundle of code and resources. Where possible, unbundle code and resources. Wherever you can provide the resources externally, you can now reuse the code. Let's write a manifesto.
nly 6y ago
MaxMind provide both.
janee 6y ago
I think the cost of maintaining an upgrade path for libraries that doesn't piss off your users is non trivial compared to a service I agree you shift work to users, but at what cost? Either an angry or resentful user base or jumping through countless complex edge cases to deal with usage problems you didn't forsee or intend to happen. I'd happily take managing and maintaining a centralised service over a lib in most cases.
softwaredoug 6y ago
A service is great when you want to let the services dev cycle run independent of yours. There’s good use cases for this: - an auth service that keeps up with security bugs - a recsys that keeps deploying newer and better recsys into your app In these cases the service continues to fulfill the same contract, but they keep getting better independent of your dev cycle. In effect a service is a kind of “push” model of dependency. I push my improvements into your app as soon as they’re ready. Crucially you let me do this because it’s an area you’ve given complete trust to another team to manage for you for a variety of reasons. Libraries, OTOH, are a “pull” model. You pull the dependency into your code base when you’re ready to absorb the changes. There’s less benefit to letting the dependency evolve on its own and you want to decide when to pull in updates. Crucially in services the promise is more abstracted. I’ll give you “good recommendations” whereas libraries can be more “add two numbers”. With the service it’s more about the interface being stable over time, and while this is true with libraries, the API can evolve more fluidly. These aren’t hard and fast lines, it I think both are valuable and have their pros and cons.
- charris000 6y ago
  100% agree with this. Determining the "direction" of dependency like this is one of the main considerations around implementing something as a library or a service. I've built services that expose the latest/current version of an underlying library, with various versions of that library used in products across the company. There is also a question of overhead - calling a library is almost always SO much faster and lighter than calling out to some service, especially if we're talking JSON or XML over HTTP.
revskill 6y ago
service to me is just library.main.call() ?
gitgud 6y ago
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.
neartheplain 6y ago
I’ve seen many unnecessary services-that-should-have-been-libraries. Usually the result of organizational structure and career ambition; it’s more high-profile to launch a new service than to write a new library. Coworker jokingly called one egregious case the “Promotion Service”, as that seemed to be the main function of the service for the team which developed it.
strogonoff 6y ago
> But if you didn't have the service in the first place - if there was only the library, containing all the functions, doing whatever the service was supposed to do in the first place - you wouldn't have this problem. Users who don't upgrade would suffer whatever problem exists in the initial version of the library, and everyone else would be fine. While I tend to prefer a library over a service where possible, there’s an implication I didn’t see mentioned: if your use case involves communication between library instances (or collaboration on shared data) at runtime, you might have to choose between requiring users to only run matching versions of the library (complicates library use) or implementing very strong backwards compatibility (preferable, but can seriously complicate iteration, especially during early stages).
soheil 6y ago
I remember people talked about libraries a decade or so ago, but now people use the term package instead. Can someone shed some light on the difference between the two if any and when they started diverging?
TeeMassive 6y ago
This reminds me one this section from The Art of Unix Programming http://www.catb.org/esr/writings/taoup/html/ch04s04.html http://www.catb.org/esr/writings/taoup/html/ch04s04.html > One consequence of the emphasis that the Unix programming style put on modularity and well-defined APIs is a strong tendency to factor programs into bits of glue connecting collections of libraries, especially shared libraries (the equivalents of what are called dynamically-linked libraries or DLLs under Windows and other operating systems). >If you are careful and clever about design, it is often possible to partition a program so that it consists of a user-interface-handling main section (policy) and a collection of service routines (mechanism) with effectively no glue at all. This approach is especially appropriate when the program has to do a lot of very specific manipulations of data structures like graphic images, network-protocol packets, or control blocks for a hardware interface. Some good general architectural advice from within the Unix tradition, particularly applicable to the resource-management challenges of this sort of library is collected in The Discipline and Method Architecture for Reusable Libraries [Vo]. >Under Unix, it is normal practice to make this layering explicit, with the service routines collected in a library that is separately documented. In such programs, the front end gets to specialize in user-interface considerations and high-level protocol. With a little more care in design, it may be possible to detach the original front end and replace it with others adapted for different purposes. Some other advantages should become evident from our case study. >There is a flip side to this. In the Unix world, libraries which are delivered as libraries should come with exerciser programs. >APIs should come with programs, and vice versa. An API that you must write C code to use, which cannot be invoked easily from the command line, is harder to learn and use. And contrariwise, it's a royal pain to have interfaces whose only open, documented form is a program, so you cannot invoke them easily from a C program — for example, route(1) in older Linuxes. -- Henry Spencer >Besides easing the learning curve, library exercisers often make excellent test frameworks. Experienced> Unix programmers therefore see them not just as a form of thoughtfulness to the library's users but as an indication that the code has probably been well tested. >An important form of library layering is the plugin, a library with a set of known entry points that is dynamically loaded after startup time to perform a specialized task. For plugins to work, the calling program has to be organized largely as a documented service library that the plugin can call back into.
deleted 6y ago
[deleted]
bern4444 6y ago
A comment on the website. I know on HN its popular to have minimal sites. But this is just rediculous. While I also dislike medium, they get the spacing right. This site is awful to read. Generally lines shouldn't be longer than 700px or so (+/- 100px). Its harder for the eye to stay on the same line when its longer than that. One line of CSS can fix this and vastly improve the experience. The font size is tiny, I have to zoom in 50% to easily read. While I can do that, its annoying to have to do so. That's another 1 line CSS fix. And then one final line of css to center everything. I'm not asking for an entire site redesign, but literally 3 lines of CSS can vastly improve the end user experience. CSS needed: body { max-width: 700px; font-size: 20px; margin: auto; } Edit to add: http://bettermotherfuckingwebsite.com/ http://bettermotherfuckingwebsite.com/ for a good minimal example site.
tonfreed 6y ago
Not what I expected when I clicked onto it. I was going to go on a rant about how much I hate the "monolith at any cost" crowd at the moment.

635 points by catern 6y ago

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.

inter_netuser 6y ago
why weird? It also doesn't have to be C, just anything that compiles to a native binary lib.
pedro2 6y ago
Not everyone's cup of tea, but on Linux gobject-introspection allows for automatic or semi-automatic generation of bindings for X languages. .NET also -- and this is only my interpretation -- is following that path.
- viferga 6y ago
  I also think it's the way to go: https://github.com/metacall/core https://github.com/metacall/core

the_arun 6y ago

If it is common service used across the company, writing service makes sense as teams can use different programming languages to consume it. Libraries expect everyone to use same language or that library has to be recreated in other languages & managed.

shadowgovt 6y ago

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.

101008 6y ago

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

randlet 6y ago
You can sell a library just as well as any other piece of software I think.
- freeone3000 6y ago
  Not really. Your market is different. Instead of selling to business managers seeking to solve a problem, you're selling to developers. Developers tend to like solving problems themselves, and you're competing versus free.
  - chrisrhoden 6y ago
    The definition being used here for libraries and services has both being marketed to developers. We're talking about APIs, not a web product with a UI etc. Services, in this article, doesn't refer to things that can only be built as services (e.g. because it queries a proprietary dataset) but those that might optionally be built as services (e.g. fetching and processing otherwise accessible data) and could, as easily, be built as a library.
  - selfhoster11 6y ago
    There's an ecosystem of paid libraries and tools around Java and C#. While developers might like to solve problems of their own, standards compliance is one place that they likely wouldn't want to tread their own path if they can help it. They've got work to do, and deadlines.
  - pjmlp 6y ago
    On the Sony, Nintendo, Microsoft, Apple and Google developer ecosystems there are plenty of shops selling libraries. Basically where most devs selling commercial software live on.
  - 6y ago

jasode 6y ago

>People say, "services are easy because you can upgrade them centrally, so you can avoid slow-to-upgrade users making everyone's lives worse." > But this assumes that slow-to-upgrade users can have negative effects on everyone else. Is the above a reference to Moxie Marlinspike's comments[1]? So would a concrete example of your abstract essay be that communication should be a client utility that uses an XMPP library[2] instead of Signal's services? [1] https://signal.org/blog/the-ecosystem-is-moving/ https://signal.org/blog/the-ecosystem-is-moving/ [2] https://xmpp.org/software/libraries.html https://xmpp.org/software/libraries.html

smitty1e 6y ago

Why not embrace the healing power of a project that can be deployed as a service AND a library?

ganafagol 6y ago

> 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 you a billionaire. Sad but reality.

veenusav 6y ago
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.
deleted 6y ago
[deleted]
bogdanoff_2 6y ago
Is SaaS really the only viable (or "unicorn") business model? Do people not sell software licenses anymore? (In theory nothing prevents you from making your license require recurring payment as well)
- tobmlt 6y ago
  *Most who sell licenses seem to be moving their old stuff/cash-cow-behemoths/etc to saas as quickly (slowly) as possible. -certainly there are exceptions. Exceptions seem more likely with smaller older companies with different priorities.
- indigochill 6y ago
  I suspect it's the same reason game devs are hot for streaming. When the code only runs on machines you control, piracy becomes impossible. By contrast, trusting people to respect licenses on code on their computers is how piracy happens. In my opinion this is a feature, not a bug, but the business reason is clear for why all commercial software is moving towards the SaaS model.

geophile 6y ago

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?

chrisrhoden 6y ago
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.
- geophile 6y ago
  Yes, we are both saying "use a library when possible". I am mystified by the need to write or read such an article. It seems akin to "don't use an airplane to go to the corner store for a dozen eggs".
human 6y ago
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.

ChrisMarshallNY 6y ago

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.

hamsterbooster 6y ago

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.

jacobr1 6y ago
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.

numlock86 6y ago

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

zzbzq 6y ago

1990s advice on a 1990s website. It's the opposite. We need to move away from package hell by splitting our work in two opposite directions: on the one hand, we should move back to large, effective standard libraries; on the other hand, we should move toward more services, fewer library packages. A project shouldn't need more than a few packages, usually for something like a database connection protocol. Working with libraries is the worst part of the job.

Ericson2314 6y ago
This is one of the worst ideas I've ever read on this site. But I'm glad you wrote it, as this is the epitome of a sentiment I've many times seen lurking. - Standard libraries always go bad over time as idioms change and they don't have a policy for breaking changes - Services do not compose as easily as libraries. Composition is key to code reuse. I understand most off the industry deals with terrible libraries, and many of you long for simpler times, but the proliferation of complexity will occur with or without the NPMs of the world, as the industry grows and functions in a economy that doesn't care about externalities, including endemic stupid extra complexity.
collyw 6y ago
I am trying to maintain an absolute pile of shite because the previous lead dev needed to reinvent every wheel in an undocumented untested way. On boarding developers takes longer. Bugs are more difficult to fix. You are in my opinion a bad developer for having that attitude. Being able to know when and when not to use a library is an important skill. As with everything, it's a trade off and you seem to not be aware of one side.

cam- 6y ago

Counter argument, don't deploy your code on other people's hosts.

xmaayy 6y ago
Got it, buy the cheapest possible 600$ server, pay 200$/month to collocate it (also do a cost benefit of different facilities), be responsible for all hardware failures and availability issues.
- cam- 6y ago
  One issue I have seen in distributed systems is where a library is on another customer/teams hosts and brings them down due to a bug in the library. The other customer/team has no way to fix the bug and is dependent on getting the attention of the company/team who vended the lib in the first place. One I remember is where a library had a bug which created 0 byte files and exhausted the inodes causing an outage. Cloud systems have become cheap enough and flexible enough that protecting your customers by not putting your bugs on their hosts is not as big as a lift as it used to be when you had buy bare metal servers or explicit VMs.
- collyw 6y ago
  > the cheapest possible 600$ server Surely $600 dollar servers all cost the same

thinkingkong 6y ago

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.

wkfavdpb 6y ago
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.

mkl95 6y ago

Good advice. I will take a modular monolith over a frontend that consumes a series of services any day. Black boxes are fun until funny things start to happen inside them.

wodenokoto 6y ago

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 bug - a service can be called by other non Python services. With that being said it is much, much easier writing code that import a library than call out to a service. And it is also much, much easier to test.

jacobr1 6y ago
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.
BerislavLopac 6y ago
> 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 Of course it is possible. You can set up your own PEP 503 [0] compliant repository, even unreachable outside your VPC, and use pip to install from it. One caveat: on GCF you can -- if I'm not mistaken -- only install Python-only libraries; but if you use Cloud Run you can install anything inside your container. There are servers for hosting your own PEP503 repo, such as devpi [1] -- but ultimately you only need a Web server to serve the file index. [0] https://www.python.org/dev/peps/pep-0503/ https://www.python.org/dev/peps/pep-0503/ [1] https://www.devpi.net/ https://www.devpi.net/

bcoates 6y ago

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.

eru 6y ago
However, if your user agrees to be limited (because it prevents them from making mistakes), we have fairly reliable methods. But yes, they require the user of your library to cooperate.
catern 6y ago
>none of these actually work and none of the implementations you will find in the wild are anything but snakeoil This is wrong. The foundation of the modern web is safe Javascript implementations. BPF/eBPF is another widespread technology using isolation mechanisms like this. All of these techniques work. As I mentioned in the very next sentence, only the first in that list is common, but that doesn't mean the rest don't work. If you have found some fundamental hole in NaCL or CHERI or JVM security which makes them ineffective, feel free to publish your results.
- bpodgursky 6y ago
  I think you are talking about different things. I have absolutely decompiled obfuscated third-party Java libraries, fiddled with a few variables or method signatures, and recompiled + used them. JVM security has nothing to do with this.

viferga 6y ago

Why don't doing both at the same time? https://youtu.be/2RAqTmQAWEc https://youtu.be/2RAqTmQAWEc

wcarss 6y ago

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.

ahepp 6y ago
SOAP doesn't have anything like the restrictions rest has, does it?
- lostcolony 6y ago
  It doesn't, but also, services were far less common compared with libraries when it was popular.
- zo1 6y ago

taeric 6y ago

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 service, it would be a lie to claim this is easier, but it is a bit more approachable. Now, a difference, I believe, really comes in to whether or not there is state associated with what you do. If there is, and it is not something that makes sense to move close to the user, then a service is pretty much required. If there is no state, make sure that is not artificially done by just moving to all state being managed by the user.

erfgh 6y ago
You have a disagreement. You don't have a disagree.
- esperent 6y ago
  Hard disagree. Language is fluid, get used to it.
- sethammons 6y ago
  Take ~6min to watch Stephen Fry Kinetic Typography - Language. It is my favorite take on changes in English and addresses verbing of nouns directly. https://www.youtube.com/watch?v=J7E-aoXLZGY https://www.youtube.com/watch?v=J7E-aoXLZGY
- jmchuster 6y ago
  Sorry that we confuse you non-native speakers. Contemporary american english has much greater flexibility with deverbal nominalizations.
- christophilus 6y ago
  They’ll hand out a disagree to anyone these days.
6y ago

jrockway 6y ago

I don't think there's a one size fits all solution here, and there are constraints that the author isn't seeing. In favor of a service are cases where users want plugins, and the upstream doesn't want to maintain them. An example is anything that touches DNS, like cert-manager, external-dns, things like that. There are thousands of DNS hosts, and they each have their own API. So nobody wants to provide support for all of them out of the box -- the upstream maintainer's entire life will become approving PRs for obscure DNS services. The maintainer can't test them, because they don't have an account, so can't own the quality of the final product anymore. Therefore, nobody does this. Services are an answer to this problem -- the thing you actually want to use defines an API for DNS services, and the DNS provider gives you a program that can receive messages to update DNS, and everyone is happy. You just run it as a sidecar, and you can update it when your DNS provider changes their API, and update the other thing whenever they add a new feature that you want. The coupling is loose, so you don't get the same perfect reliability as a purpose-built "update foocorp dns whenever an ingress rule adds a hostname", but it's pretty good. (I honestly don't know if this is actually how cert-manager and external-dns work. I use cert-manager and it builds in libraries for the DNS providers I use, with the caveat that they aren't accepting any more. I don't use external-dns, but I heard some rumblings about making a standard a few years back for this sort of thing. Didn't check in on the status of either. It's just a hypothetical example ;) Libraries are unhelpful here because there are a billion programming languages, and the upstream provider will never choose your programming language of choice as their priority. Additionally, container builds are hard and I've never heard of anyone with a reliable way of taking some sort of upstream project and building it with local add-ons at every upstream commit, tagging stable versions in parallel with the upstream, etc. Definitely possible, but out of reach of the average container operator. Things like Go without dynamic linking (a feature I agree with, BTW), and container builds make services more critical for the plugin type use case. (My dream is to just write libraries in something that compiles to WebAssembly and use that to implement a plugin system in applications that need it. Some people are kind of sort of doing this; Envoy for example.) On the other hand, sometimes you need the deep integration that only libraries can provide. It's popular to use sidecars to add network features like distributed tracing and mTLS; linkerd and Istio are examples. But these are exactly the use cases where you should use libraries instead of services. You need to see the TLS handshake so that your application can make authorization decisions based on the peer that you're connected to. To do distributed tracing, you need to copy the X-B3-Trace-Id header out of the incoming HTTP request into the outgoing HTTP request. Libraries can do that for you, but services can't. In summary, the answer on library or service is "it depends". Hopefully this comment adds a little more nuance than the original article.

abeppu 6y ago

I think context is really important here. Multiple comments in this thread jump to the concern that it is much harder to monetize a library -- but in an era where many developers are enthusiastic about service oriented architecture, it's also worth considering the decision between services and libraries for functionality which will only be exposed inside of an organization. One other dimension not discussed in the article is how the scale of use varies over time. A service operator needs to ensure the service scales to support its use. But some use cases are extremely spiky (e.g. when something is invoked by a batch job processing many TB of data among many workers). Even if the service is able to dynamically scale based on load, that's not frictionless or without cost to the team operating the service, and can cause a degradation of service provided to other users. By contrast, if one provides a library, any given use case can be responsible for providing the capacity to support themselves. A last dimension of libraries vs services within an organization is attributing value and cost. This is a double-edged sword. When providing a service, the team that operates the service may have some clear costs to continue to run it. Just providing the service can make you look like a cost center. If you do the extra work to make sure use cases are distinguished and trackable (e.g. use cases have separate credentials used in calling the service), then perhaps these costs (and "value" in the form of request volume) can be tied to callers. When providing a library, the team that provides it both doesn't appear as a cost center, but also it may not have a straight forward way of knowing how intensively their library is being used and therefore how much value it has provided to the org.

surajrmal 6y ago

Services allow you to interop with all languages, they let you avoid worrying about threading models of the program your operating within, and they don't have access to all of they sandbox the code being run allowing you to avoid worrying about the code doing something nefarious with access it gets from running inside your process. On top of this, people just seem to be fat more okay with not having source access to a service than they do using proprietary libraries (which from a security perspective makes sense to me). If there was a standard threading model, language agnostic interop with clear evolutionary properties (perhaps a channel based one), and a generic mechanism for sandboxing libraries folks could use then maybe they would consider providing libraries more. Some sort of hybrid between COM, wasm, and optimized in process grpc is more or less what I'm trying to describe. This doesn't exist, however, and moving your library out of process solves this issue neatly so it's not a surprise that's what's happening.

KptMarchewa 6y ago

I don't really understand this comparison. Point of having a service is not only exposing computation - more usually, it's exposing a centralized database. How is library useful in this context? Unless, the author is talking about writing, for example, a number multiplication library vs number multiplication service... but then the advice is obvious. EDIT: also, this stuff about accessing memoty, denying access at runtime makes me think that it was written for a different times. Nowadays, who creates new stuff that's not isolated by VM or container layer?

amelius 6y ago

And please write your library in all languages.

TheRealPomax 6y ago

libraries don't make you money, services do. Libraries get your name in a license in the "open source licenses" tucked 20 menus deep in an app's hidden dev options.

artembugara 6y ago

Write libraries AND services, where it makes sense. I wrote a Python library to scrape google news [0] We also have it as a service [1] Want to know why? Because devs who can't pay won't pay. Businesses who can pay will rather pay for a service (API in our case), and not care about maintaining it. [0] https://github.com/kotartemiy/pygooglenews https://github.com/kotartemiy/pygooglenews [1] https://newscatcherapi.com/google-news-api https://newscatcherapi.com/google-news-api

asdff 6y ago
The hidden message of the mantra "just self host your own" is that it takes you time to set that up. If you aren't familiar with that process from past experiences, you now have to get those man hours somehow for selfhosting, and suddenly that free self-hosted solution is not so free if you value your time over $0/hr. That's where I think services should come in. Only with no phoning home crap or cruft, just give me a hosted version of a bare bones cli app that I can access anywhere from any device. Give me my own instance of tiny tiny RSS or something else that's very lightweight and commonly selfhosted for $1 a month, and I'll happily pay up to avoid having to spend a few hours vetting hosting options and setting this up myself.
pillefitz 6y ago
How does the liscence agreement with Google look like, you just pay per Query? Does Google prohibit caching? Just curious as I remember reading nightmare stories of companies basing their business model on Google services (maps).

brundolf 6y ago

Libraries are better for end-users, services are better for the businesses building them. When a service could just as easily be a library (which isn't always the case, to be fair), it's not a question of best-practice, it's a question of power-balance and incentives.

cultofmetatron 6y ago

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 service and error handling in the event of a crash. I'm basicly getting all the best advantages of a monolith * one codebase to navigate, our team is TINY * all functionality is in libraries And all the advantages of microservices without the associated costs. (orchestration, management etc) * bottleneck use cases can live on their own nodes * publish subscribe to dispatch background jobs * services that each focus on doing one thing really well We've accomplished this all through just libraries and a little bit of configuration. At no point so far have we had to.. * setup a message broker (phoenix pubsub has been fine for us. we can send messages between different processes on the server and to the clients themselves over channels) * setup external clusters for background workers. (Oban was drop in and jsut works. I'm able to add a new worker without having to tell devops anything. the supervision tree allocates the memory for the process and takes care of fault tolerance for me. That leaves me to focus on solving the business problems) * setup a second github repo. Its a monorepo and at out scale, its fine. We have one library for communicating to the database that every system just uses. Eventually we'll probably have to start rethinking and building out separate services. But I'm happy that we're already able to get some of teh benefits of a microservice architecture while sticking to what makes monoliths great for mvps. It will be awhile before we need to think about scaling out web service. It just works. Leaves me more time to work on tuning out database to keep up!

fiddlerwoaroof 6y ago
BEAM will automatically distribute processes across a cluster, right?
- cultofmetatron 6y ago
  not automatically but its pretty easy to configure in your supervision tree file. I don't know the details because whatever happens by default has taken care of our needs so far. IT does automatically distribute processes across all the cores on a cpu though.

divyekapoor 6y ago

After building embedded library codebases that have had version skew across clients (sometimes over several years worth of code), the library approach just stops evolving after a certain point - the backward compatibility mess is a drowning morass. There is no control on the upgrade cycle, old infra can't be turned down, performance is a risk, upgrades are a risk, every deploy has "foreign code" and the potential for a dependency mismatch. Services work - use them. Unless performance is of the utmost concern, say no to libraries.

Evidlo 6y ago

Isn't this exactly what the Sans I/O project is about? https://sans-io.readthedocs.io/ https://sans-io.readthedocs.io/

l8again 6y ago

Clearly, it makes sense on the "sellers" side to make it into a service - the article pretty much conceded to that. However, this issue is also created by the "buyers" side as well. To give a concrete example - prometheus is an open source alternative for observability. But if you have a small team and want to release early, you will still go to DataDogs, and splunks of the world. Of course, you can say but that's fine. But there are others that could have been a library. Yes, but libraries also come with a maintenance overhead (security, patches, etc.).

q3k 6y ago

Meanwhile, any time I receive a piece of functionality as a blackbox .so library from a vendor, the first thing I do with it is wrap it in a gRPC host so I can easily call it from the rest of my codebase.

billiam 6y ago

I'd love to see a somewhat scientific analysis of the fully considered TCO of services and libraries of similar complexity, usage, and function.

quelsolaar 6y ago

Question: When people build services that internally communicate using web requests, are people using HTTP, or HTTPS?

Kinrany 6y ago

Services have another benefit: they can be used in any language. That is, until WASM becomes easy enough to both author and embed!

zach_garwood 6y ago

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 sweat in your clothes? Running would be a bad choice, even though it's faster. There are just too many variables in the real world to make any sort of blanket statement about which approach is "better."

thepete2 6y ago
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.
- thinkharderdev 6y ago
  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.

msluyter 6y ago

Curious what people's experiences are wrt library development within an enterprise. I've been at organizations where basically everything was done via services and there was very little library usage, and I always thought that was suboptimal. Now I'm at a place where we utilize lots of libraries and they seem to pose pretty significant costs of their own. A typical example is if we need to do something that the library doesn't support, we're faced with an unpleasant choice of updating the library itself or doing some sort of workaround/hack. The former shouldn't be that difficult, but in cases where a library was written by a different team, updating can be painful if you don't have someone with experience with the library/domain on your team, or if you have to jump through approval hoops. I suppose this is more an ownership/organizational problem and applies to services as well, but somehow dealing with library dependencies feels more onerous.

mmmpetrichor 6y ago
Exactly. Integrating external libraries into another system is much harder than leveraging e.g. a RESTAPI. The OP seems to be saying that Service oriented architecture (SOA) is worse. It's definitely not. There's no "better" or "worse" here. It's just two different options with different costs of integration and interoperability. the service architecture is going to have additional maintenance overhead but provide cheaper and easier interoperability.

asdfasgasdgasdg 6y ago

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.

thinkharderdev 6y ago
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.

max_ 6y ago

Reading this sounded like an implicit description of the Unix philosophy[0] Software would improve alot if these ideas where reanimated. [0]: https://en.m.wikipedia.org/wiki/Unix_philosophy https://en.m.wikipedia.org/wiki/Unix_philosophy

antihero 6y ago

I don't get it, what if you want to use a different language to your clients? What if you want to have state shared across an entire company and spin up/down bits individually?

abraxas 6y ago

Yeah, the "everything service" mentality is getting a little out of hand. The most recent, egregious example I heard of is the "language server" in VS Code. What used to be a plugin/library functionality has now been turned into a distributed computing problem with all its warts and gotchas. I've no idea who makes these decisions on a project like that and how they justify them.

naikrovek 6y ago

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 than they need to be.

gravypod 6y ago
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 same language. In addition the programming languages that our editors/tools are written in cannot always interface with each other clearly (cffi is not supported in every language). 5. "All" programming languages that people use today have some networking stack that can be used to open TCP sockets and send data. Given these facts it would be easy to conclude that: If you want editor developers to focus on writing text editors and you want tooling developers to focus on writing tooling but you also want your text editors to support advanced functionality that is already implemented in your tooling the easiest way to send that information is over TCP. The other options are: 1. Don't have advanced languages for "All" languages. 2. Force everyone in the world to use one programming language. 3. Force all tooling in the world to be written in one programming language. 4. Force everyone to implement another cross-language communication system (ex: cffi) in "All" languages. Unfortunately these options are more complex then just defining an API and sending messages back and forth.
- naikrovek 6y ago
  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.

mbar84 6y ago

A service is a bundle of code and resources. Where possible, unbundle code and resources. Wherever you can provide the resources externally, you can now reuse the code. Let's write a manifesto.

nly 6y ago

MaxMind provide both.

janee 6y ago

I think the cost of maintaining an upgrade path for libraries that doesn't piss off your users is non trivial compared to a service I agree you shift work to users, but at what cost? Either an angry or resentful user base or jumping through countless complex edge cases to deal with usage problems you didn't forsee or intend to happen. I'd happily take managing and maintaining a centralised service over a lib in most cases.

softwaredoug 6y ago

A service is great when you want to let the services dev cycle run independent of yours. There’s good use cases for this: - an auth service that keeps up with security bugs - a recsys that keeps deploying newer and better recsys into your app In these cases the service continues to fulfill the same contract, but they keep getting better independent of your dev cycle. In effect a service is a kind of “push” model of dependency. I push my improvements into your app as soon as they’re ready. Crucially you let me do this because it’s an area you’ve given complete trust to another team to manage for you for a variety of reasons. Libraries, OTOH, are a “pull” model. You pull the dependency into your code base when you’re ready to absorb the changes. There’s less benefit to letting the dependency evolve on its own and you want to decide when to pull in updates. Crucially in services the promise is more abstracted. I’ll give you “good recommendations” whereas libraries can be more “add two numbers”. With the service it’s more about the interface being stable over time, and while this is true with libraries, the API can evolve more fluidly. These aren’t hard and fast lines, it I think both are valuable and have their pros and cons.

charris000 6y ago
100% agree with this. Determining the "direction" of dependency like this is one of the main considerations around implementing something as a library or a service. I've built services that expose the latest/current version of an underlying library, with various versions of that library used in products across the company. There is also a question of overhead - calling a library is almost always SO much faster and lighter than calling out to some service, especially if we're talking JSON or XML over HTTP.

revskill 6y ago

service to me is just library.main.call() ?

gitgud 6y ago

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.

neartheplain 6y ago

I’ve seen many unnecessary services-that-should-have-been-libraries. Usually the result of organizational structure and career ambition; it’s more high-profile to launch a new service than to write a new library. Coworker jokingly called one egregious case the “Promotion Service”, as that seemed to be the main function of the service for the team which developed it.

strogonoff 6y ago

> But if you didn't have the service in the first place - if there was only the library, containing all the functions, doing whatever the service was supposed to do in the first place - you wouldn't have this problem. Users who don't upgrade would suffer whatever problem exists in the initial version of the library, and everyone else would be fine. While I tend to prefer a library over a service where possible, there’s an implication I didn’t see mentioned: if your use case involves communication between library instances (or collaboration on shared data) at runtime, you might have to choose between requiring users to only run matching versions of the library (complicates library use) or implementing very strong backwards compatibility (preferable, but can seriously complicate iteration, especially during early stages).

soheil 6y ago

I remember people talked about libraries a decade or so ago, but now people use the term package instead. Can someone shed some light on the difference between the two if any and when they started diverging?

TeeMassive 6y ago

This reminds me one this section from The Art of Unix Programming http://www.catb.org/esr/writings/taoup/html/ch04s04.html http://www.catb.org/esr/writings/taoup/html/ch04s04.html > One consequence of the emphasis that the Unix programming style put on modularity and well-defined APIs is a strong tendency to factor programs into bits of glue connecting collections of libraries, especially shared libraries (the equivalents of what are called dynamically-linked libraries or DLLs under Windows and other operating systems). >If you are careful and clever about design, it is often possible to partition a program so that it consists of a user-interface-handling main section (policy) and a collection of service routines (mechanism) with effectively no glue at all. This approach is especially appropriate when the program has to do a lot of very specific manipulations of data structures like graphic images, network-protocol packets, or control blocks for a hardware interface. Some good general architectural advice from within the Unix tradition, particularly applicable to the resource-management challenges of this sort of library is collected in The Discipline and Method Architecture for Reusable Libraries [Vo]. >Under Unix, it is normal practice to make this layering explicit, with the service routines collected in a library that is separately documented. In such programs, the front end gets to specialize in user-interface considerations and high-level protocol. With a little more care in design, it may be possible to detach the original front end and replace it with others adapted for different purposes. Some other advantages should become evident from our case study. >There is a flip side to this. In the Unix world, libraries which are delivered as libraries should come with exerciser programs. >APIs should come with programs, and vice versa. An API that you must write C code to use, which cannot be invoked easily from the command line, is harder to learn and use. And contrariwise, it's a royal pain to have interfaces whose only open, documented form is a program, so you cannot invoke them easily from a C program — for example, route(1) in older Linuxes. -- Henry Spencer >Besides easing the learning curve, library exercisers often make excellent test frameworks. Experienced> Unix programmers therefore see them not just as a form of thoughtfulness to the library's users but as an indication that the code has probably been well tested. >An important form of library layering is the plugin, a library with a set of known entry points that is dynamically loaded after startup time to perform a specialized task. For plugins to work, the calling program has to be organized largely as a documented service library that the plugin can call back into.

deleted 6y ago

[deleted]

bern4444 6y ago

A comment on the website. I know on HN its popular to have minimal sites. But this is just rediculous. While I also dislike medium, they get the spacing right. This site is awful to read. Generally lines shouldn't be longer than 700px or so (+/- 100px). Its harder for the eye to stay on the same line when its longer than that. One line of CSS can fix this and vastly improve the experience. The font size is tiny, I have to zoom in 50% to easily read. While I can do that, its annoying to have to do so. That's another 1 line CSS fix. And then one final line of css to center everything. I'm not asking for an entire site redesign, but literally 3 lines of CSS can vastly improve the end user experience. CSS needed: body { max-width: 700px; font-size: 20px; margin: auto; } Edit to add: http://bettermotherfuckingwebsite.com/ http://bettermotherfuckingwebsite.com/ for a good minimal example site.

tonfreed 6y ago

Not what I expected when I clicked onto it. I was going to go on a rant about how much I hate the "monolith at any cost" crowd at the moment.