And write unix-style cli tools that can be piped to and from. Make them eat and spit something structured like JSON.
Isn’t powershell a generalized version of that idea?
Write libraries instead of services, where possible
51–60 of 181 posts
Re: Write libraries instead of services, where possible
#52Related: Who Does That Server Really Serve? https://www.gnu.org/philosophy/who-does-that-server-really-s...
Stallman performs the vital function of pinning the Overton Window to the left, which benefits those of us with more nuanced views. I'm not going to run my own mail server in 2023, etc.
> I'm not going to run my own mail server in 2023, etc.
But many do. It’s still not that hard.
Re: Write libraries instead of services, where possible
#53i get the benefit of offloading the admin costs onto your consumers, but, as always, the devil is in the details. i've met both cases where a library should've been a service, and vice versa. this advice is way too broad and abstract to be practical
Re: Write libraries instead of services, where possible
#54Why not both ?
Re: Write libraries instead of services, where possible
#55Is 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.
In my experience a new micro-service considered the default option for anything which could be done as a micro-service nowadays. Library API design is the lost art (almost). And the choose is not always obvious for non-technical reasons. Consider a following example: you have 3 micro-services X, Y, Z which need to interact with a platform G but this interaction requires non-trivial chunk of code. It can be done as a…
This is making technology objectively worse to solve people problems, and this only expands.
More software needs iron clad leadership and control. Any organization that lacks this can’t help but produce shit software. There has to be a single person with real decision making power than can force upgrades and prioritization of work, and they need to be able to axe people or teams who can’t hack it.
Re: Write libraries instead of services, where possible
#56And write unix-style cli tools that can be piped to and from. Make them eat and spit something structured like JSON.
Isn’t powershell a generalized version of that idea?
It's a specialized version of that idea.
Problem with libraries are that they tie the user to a specific language/OS. A cli tool eating and spitting ASCII/UTF-8 is about as cross platform as it gets.
Re: Write libraries instead of services, where possible
#57And write unix-style cli tools that can be piped to and from. Make them eat and spit something structured like JSON.
Isn’t powershell a generalized version of that idea?
No actually, it tries to be a kitchen sink and is the opposite of the UNIX concept of pipelines with small purpose built utilities.
Re: Write libraries instead of services, where possible
#58Services 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.
The space is complex enough that I wonder if it's possible to make abstractions that aren't horribly leaky.
Re: Write libraries instead of services, where possible
#59It'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. Then there are the potential conflicts in your own dependencies. And let's not forget the occasional breaking change you introduced. 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 per…
> 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 changes will always require modifying the thin client.
The biggest pitfall, though, is that you have to actually put thought into the thin client design. “Thin” is an emergent property of a well thought out client. You can’t just “touch thin_client.java” and think because you named it “thin” that it’s inherently decoupled from the service. You have to actually put thought into it.
Your example is exactly right. The service can support either v1 or v2 depending on the version of the thin client.
The main other technique is to have the thin client communicate in a relatively abstract and generic manner. For instead a “write()” endpoint that accepts an “options” dictionary.
“write()” is so generic that it probably won’t have to change, and changes in behavior can be modified by shoving stuff into dict, perhaps with a “version” field to instruct the server how to interpret the call.
When you add a new feature, you can bump the thin client to v2 and shove new options in the dict. Then the server can support v1 and v2. But also, you can modify the server to handle v1 differently. E.g the absence of a “disable_new_feature” key automatically opts v1 callers into the new feature.
I think the details are are really coupled into what you are engineering and what you want to roll out. There’s no magic bullet, and this increases the complexity of your code. Good engineering in my opinion is deciding when these approaches are worth it and how they should be implemented.
Re: Write libraries instead of services, where possible
#60Those aren't "either or" things. Usually services are exposed through libraries. And a library requires a service if it has a canonical or centralized storage or processing, which can't be done locally.
Now, sure, we do stupid things as services, for sure. But people often do it to monetize the service, or control the users. And so that'll never change.
I recall someone making an "async HTML5 AJAX blink service" as a joke for this trend.