4 ms·
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 getAll
by marginalia_nu 3y ago
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.