81–90 of 181 posts
I've been writing services... as libraries first. Then just wrap the library in a very simple `main()`: ``` #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 dec…
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.
At $CURJOB, we did this but at a higher level of abstraction (an authentication architectural component, rather than a library). I think this is what the author means when they say "writing a standalone server reached through a network protocol".
We see a lot of folks who like the flexibility of consuming functionality as a service or library, as they see fit. We've even had customers who said "we chose you because now we want you as a service, but later will want you as library" or vice versa.
Flexibility isn't free, though. Versioning, support, backwards compatibility (features and performance), even offering the service all become more complex.
Earlier quoted context omitted.
This shows that we lack good abstractions over storage.
You cannot abstract away a 3 order of magnitude difference in bandwidth and latency.
The issue is coordinating changes (and, god help you, library releases) across repos is often an utter nightmare with multiple PR/merge builds
Always write a library first.
Not for any specific benefits, though these exist, but for architectural reasons. You can trivially wrap a library into pretty much everything else, but not the other way around.
In fact, on macOS/iOS I put all functionality in frameworks, as these have structure and can thus contain other frameworks and non-code resources, which is more difficult with a library.
https://blog.metaobject.com/2020/06/mpwtest-only-tests-frame...
Earlier quoted context omitted.
sqlite is a library zeromq is a library That’s all the storage you need
No? If you have a horizontally scaled architecture or anything with multiple nodes, you can't just get away with "sqlite is a library".
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.
If you can maintain a stable service API, why can't you maintain a stable library API? I don't see any inherent reason why it should be easier to change the behavior of a service rather than a library.
It's an ownership and control issue.
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.
Why do those services seem to have names that provide precious little guidance on what they are for?