71–80 of 181 posts
Is this really a common scenario where there's a choice between these 2 options that isn't obvious? I've never considered libraries and services to be two equal options of distributing functionality, and you just pick one of them. It's usually a function of practicality and monetization.
Earlier quoted context omitted.
> It's all fun and games until you hit version n+1 or n+2, and often realize how slow many customers are to upgrade the library. How is that different with services? I don't develop services, but I can imagine that before breaking the services, you have to poll with your biggest customers and you don't break until they are ready to move to the new version. The alternative I can imagine is to keep providing the old se…
The idea is to link a thin client library into the user’s code. Then the thick client is controlled server side by the devs. If you design the thin and thick client intelligently, you can make a lot of changes to the system by merely modifying the thick client (which you control), without needing to update the thin client. Problems tends to come in a few flavors, namely that this increases complexity and that some ch…
As per the article, the advantage of a library over a service is that you don't have the burden of maintaining the said service. How having a thin client and a server helps?
I also don't see how "shoving new options in the dict" can help. From my POV, if the client needs to be updated to benefit from the new features, then there is no way around it, work has to be done. From there, I much prefer having sensible name, parameters, etc. from a library that can be leveraged by static typing rather than a documentation for a JSON API (I know API-as-specs exist but I've never used, maybe that's why I think that).
Services usually depend on databases. Libraries usually don’t. Either you need to support every storage backend your users might have, require them to write an integration layer from your generic hooks, or expect them to provision and manage new storage when using your library. In any case you are asking them to do a lot more work (manage the data) and in some sense breaking encapsulation by making them responsible f…
This shows that we lack good abstractions over storage.
Earlier quoted context omitted.
It’s more like data storage needs are not one size fits all so it’s better left to the user who best knows their storage needs.
This is interesting, makes me wonder if a "dockerised" database is something people could use. I mean a database frontend with its own language/protocols/whatever that allows you to define the data structure but leaves the specific storage engine or format as a backend detail that can change from platform to platform.
That's more or less a description of SQL.
Earlier quoted context omitted.
It’s more like data storage needs are not one size fits all so it’s better left to the user who best knows their storage needs.
This is interesting, makes me wonder if a "dockerised" database is something people could use. I mean a database frontend with its own language/protocols/whatever that allows you to define the data structure but leaves the specific storage engine or format as a backend detail that can change from platform to platform.
A clean room implementation would likely yield different results but there appears to be some appetite for a solution.
Maintain the library, modifying the service on as it is affected.
So this effectively comes down to “write a library” as tfa suggests. But there’s no reason the library can’t then be the core of a service.
``` #include "servicelib.hpp" int main(int argc, char argv) { return servicelib{argc, argv}.run(); } ```
The library can be re-used in other apps or services.
Then the whole damn library is unit-testable with any arguments you throw at it. Got an OS where argv may be null? You can unit test that. Got a user who decided to use --iamstupid instead of --iamawesome? You can unit test that too. Want to set up environment variables? Well that's not thread safe, but your test harness can do it before it instantiates the library object.
Want to use semver? You can. I use git commit checksums for versions and automatic tagging to semver. It's more annoying but superawesome.
Of course the prevalent reason to make a service is that it can be monetized to Hell and back again. Does it fit the customer's needs? Who cares, as long as they have no clue what they will end up paying until it is too late to migrate away.
If users want something with long-lasting support and enhancements, that’s going to take work. The people who do this work are going to need to earn a living.
There are lots of ways to accomplish this. Advertising, altruism, one time purchases. But charging for a service can be a perfectly reasonable way of making it sustainable.
You write a library, then wrap a thin service interface around it. Distribute the lib as needed. Publish the service as needed. Maintain the library, modifying the service on as it is affected. So this effectively comes down to “write a library” as tfa suggests. But there’s no reason the library can’t then be the core of a service.