3 ms·
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 mul
by shermantanktop 3y ago
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 3y agoIt'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.