I apologize for bumping an old thread. I'm curious if your recommendation has changed any since 2018.
I have several projects that match the IPC and stateful use cases you mention that I'm going to try building on capnproto as a learning experience. I'm also interested, though, in an option to have only one service definition and schema language, one code generation toolset, etc. The only hesitance I have in replacing gRPC with capnproto for the stateless, kubernetes deployed, auto-scaled type of system is this old thread which seems to be one of the few that mentions this subject. My current understanding of how pipelining is implement is that it only works for returned interfaces. That is, an interface method defined as `foo @1 (bar :String) -> (baz :String)` would not present me the option of pipelining that value through subsequent operations. If I wanted to "opt-in" to pipelining support then I would need to convert the return value to an interface type like what is done in the calculator example of the rust RPC implementation. If that's the case then that means I can support less stateful interactions by only ever defining methods that return concrete types as a way of forcing the RPC implementation to avoid pipelining. This is equivalent to only defining unary methods in gRPC or using one of the streaming signatures to "opt-in" to a stateful interaction. I'm new to capnproto so this description is fishing for clarification or disagreement. Another way to talk about this might be to ask "what would be required to support a stateless subset of capnproto even if it meant losing many of the advantages of the RPC model?". If it comes down to "use a subset of the schema language (e.g. only define unary APIs) and implement a protocol aware reverse proxy" then that's a fairly accessible amount of work for a contributor to take on and document. After that, the other concerns like metrics gathering or integration of growing open standards is a matter of building code generation plugins. I'm curious to hear thoughts from folks with more capnproto experience. On Wednesday, September 5, 2018 at 2:47:13 PM UTC-5 [email protected] wrote: > Hi, > > While Cap'n Proto is certainly capable of replacing gRPC here, obviously > Google has a lot more people working on the gRPC ecosystem, and so more > infrastructure has been built out there. With Cap'n Proto you will have to > do more things yourself. If your needs fit well into the model supported by > common gRPC infrastructure, this may not be worth it to you. On the other > hand, if you have a more unusual use case, then you might find you have to > build custom solutions either way, in which case Cap'n Proto's more > fundamental benefits (serialization performance and object capabilities) > may make it a better choice. > > Cap'n Proto is especially powerful for: > > * State*ful* services, where nodes across a cluster need to control and > hold on to the state of other nodes. For example, Sandstorm.io (startup I > founded) built a cluster-scaleable version of Sandstorm called "Blackrock" > which is itself a container orchestrater designed to run many heterogeneous > container instances on behalf of individual end users. This is a > fundamentally stateful thing, since each container is serving a specific > user with specific state and can't simply be interchanged with others. > Using Cap'n Proto as the underlying communications protocol made this a lot > easier to manage. > > * IPC use cases, where services are running on the same machine and can > communicate via unix sockets or even shared memory. Cap'n Proto's CPU > performance shines here (while its somewhat higher bandwidth usage becomes > irrelevant). Running multiple services on the same machine isn't really in > style right now, but my current employer, Cloudflare, does a lot of it -- > every one of the machines in our edge network runs an identical set of > services so that any one machine can handle any kind of request on its own. > > But if you're doing a standard kubernetes microservices thing... probably > going with gRPC is going to be a lot easier right now. > > -Kenton > > On Wed, Sep 5, 2018 at 7:18 AM, shinzui <[email protected]> wrote: > >> Hi, >> >> I just started evaluating Cap'n Proto as an alternative to gRPC in a >> microservice architecture, and I am having a hard time finding material on >> deploying services that are using Cap'n Proto RPC. Is anyone using Cap'n >> Proto RPC with kubernetes and a service mesh? How do you load balance your >> services? How do you capture metrics? Is the protocol suitable for >> cloud-native apps? >> My naive first look makes me think that it's not suitable for a >> microservice architecture with a lot of stateless services. I would >> appreciate any pointers to prove me wrong. >> >> Thank you. >> > -- >> You received this message because you are subscribed to the Google Groups >> "Cap'n Proto" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> Visit this group at https://groups.google.com/group/capnproto. >> > > -- You received this message because you are subscribed to the Google Groups "Cap'n Proto" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/capnproto/403ddef7-c48e-4c6a-8751-60e84d34d3efn%40googlegroups.com.
