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