HN Explorer

15 comments

[ 3.0 ms ] story [ 48.7 ms ] thread
netsharc
Odd article.. inconsistent spelling (RxJava vs rxjava) and missing words eg.: > it became apparent that the docker images I was constructing weren’t termination signals properly,

ChatGPT also does grammar checks;)

marginalia_nu
I generally don't even use regular spell checking, which with dyslexia isn't perhaps always a great combo :P

Though I mostly write for myself, so the lack of production values is part of that, that and it gives the writing a distinctly un-ChatGPT vibe.

All that said, I did correct the word salad...

vajrabum
I so have this problem. I was better before the days of edit, cut and paste in small textboxes, but still.
lambdaba
> Additionally, docker’s liveness checks broke, because the images don’t have curl in them anymore

And that's why you use Nix to build your Docker images!

ActionHank
Do you mean to install Nix and then defer to that to build the image or for the image to be configured and setup on deployment? Genuinely interested if you have any insightful docs or pages on this.
preordained
That's cool...but won't lie, I get the "Microservices" vibe reading this: https://youtube.com/watch?v=y8OnoxKotPQ
marginalia_nu
The microserviceness is very much a conceit in order to deal with an application state that is several terabytes with stateful processes that have run-times counted in weeks. That imposes constraints that are hard to satisfy without a fairly modular system, at least if there is any intention to upgrade the system regularly.
[deleted]
(comment deleted)
shermantanktop
The bit about registering individual API methods and how that reduced coupling (but also created a quasi monolith) could be worth expanding on. I’ve unified multiple related dependencies under a logical interface for testing before but this suggests that pushing farther in that direction could be interesting…perhaps lead to a declarative dependency model at the method level?
marginalia_nu
It's not methods I register, but APIs (i.e. interfaces).

An API in this case may have be sized something like this

    service LinkGraphApi {
      rpc getAllLinks(Empty) returns (stream RpcDomainIdPairs) {}
      rpc getLinksFromDomain(RpcDomainId) returns (RpcDomainIdList) {}
      rpc getLinksToDomain(RpcDomainId) returns (RpcDomainIdList) {}
      rpc countLinksFromDomain(RpcDomainId) returns (RpcDomainIdCount) {}
      rpc countLinksToDomain(RpcDomainId) returns (RpcDomainIdCount) {}
    }
This can be injected and invoked pretty much anywhere in the codebase that needs access to the link graph, from the domain ranking calculation to the site information view.

The primary difference is that where the receiving end of this code runs is completely abstracted away. You don't create a "link graph server client", you just create a client for the API and it figures out where the remote end runs transparently. The implementation for the service is also written in a way that is removed from the topology. You can basically inject it anywhere, in its own server, along another service in a larger server, all in one big blob of a monolith. All of this is abstracted away.

I'm interested in seeing where the idea leads though. Feels like I haven't quite reached the logical conclusion of the paradigm yet.