21–30 of 181 posts
I hope GraalVM's Polygot runtime will eventually allow more companies to go with libraries over services in more situations for multi-language businesses. And Polylith for better reuse across projects generally.
this sounds very nice on paper (it sounds common sense trivial utopia that everyone sets out to do anyway, but somehow life, entropy and deadlines get in the way), but ... is there a bigger real life project using something like this?
I hope GraalVM's Polygot runtime will eventually allow more companies to go with libraries over services in more situations for multi-language businesses. And Polylith for better reuse across projects generally.
Ugh, I can't believe I had to read your comment this morning. smh
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…
I think this sentiment is a partial cause of the trend towards self-hostable, downloadable software too. The customer has a cost when they operate a library instead of consume a service, no doubt. They also get more control (no surprise upgrades, availability is their responsibility) and assurances (no worries about the service suddenly being end of lifed).
When you use a library from an outside source, if you update that library, it might break your build. When you use an outside service, they might break your system at a time of their choosing.
Well sure, but if this is important to you, you might consider a contract with the company that lays out cases and conditions where breakage is acceptable.
Yeah but then who is responsible for maintaining the library? If you have a bunch of internal teams that depend on your library and there is an issue or a feature request, you're back to the same position of being the one that does the work to implement. Better to have a service IMO, you can get telemetry out of it and scale it out or replace internals without having to worry about who will get affected.
I still don't get what advantage exactly you are expecting.
Scaling it is only ever a problem for the service; you don't even have to think about it in a library. You can get telemetry from a library just as well as from a service; your users may find that a bit invasive, but it's still way less invasive than calling your service. And you can replace the internals of whatever, without having to worry about who will get affected, that's what defines internals.
Yeah but then who is responsible for maintaining the library? If you have a bunch of internal teams that depend on your library and there is an issue or a feature request, you're back to the same position of being the one that does the work to implement. Better to have a service IMO, you can get telemetry out of it and scale it out or replace internals without having to worry about who will get affected.
I don't see any inherent reason why it should be easier to change the behavior of a service rather than a library.
You are now sacrificing the money saved by not hosting to maintain what will likely be a growing matrix of possible versions, underlying assumptions, and my personal favorite: weird customer deployment scenarios that break your library functionality. Bonus points if you are developing in a language without strong typing, or need to integrate with a dependency manager.
Plus, if there was anything about your service that leveraged unique algorithmic improvements or some other proprietary tech, it is now at the mercy of anyone with a decompiler and sufficient time.
I suspect the author may change their mind if exposed to scaled up solutions and technologies.
Earlier quoted context omitted.
When you use a library from an outside source, if you update that library, it might break your build. When you use an outside service, they might break your system at a time of their choosing.
>When you use an outside service, they might break your system at a time of their choosing. Well sure, but if this is important to you, you might consider a contract with the company that lays out cases and conditions where breakage is acceptable.
* my logic requires a database
* my logic should be isolated for compliance reasons
* my logic accesses a service which is not available for everyone
* my logic should be processed async and needs to store state, how do I make sure library owners have that environment
* customers embedding my library are not upgrading it frequently, which leaves us to support 15 years of libraries
* ...