I’ve been using grpc/protobuf with Java and Scala. Overall I like it, but the grpc Java library does feel like it comes with a lot of opinions baked in. As an example, I was looking in to implementing automatic retries on the client side for certain classes of error. Grpc Java has some experimental retry support, but it seemed tightly coupled to their also-opinionated way of doing service discovery. I can see why you might want the server to inform clients how to do retries, keepalives, etc. But for less sophisticated operations (read: me) it is frustrating and over complicated. Why can’t I just specify a retry policy when creating a client stub?
Still, it’s better than anything else I’ve seen.
But I do long for a simpler alternative. Is that Cap’n proto? Seems like for Java there is only 3rd party support for serialization only, and not RPC.
This results in cool things like promise pipelining. It is very interesting how it can simplify interface design, and there are examples on the RPC page[0].
This seems to go completely unmentioned on the home page, other than the word “capability system” in the very first sentence.
What does capability based security mean for a data interchange format? The notion hardly makes any sense to me.
From the homepage: “Think JSON, except binary.”
What would JSON look like with capability-based security?
> You can work with results without actually having the results, e.g. before the results exist
This sounds exactly like promises, or perhaps a functional effect system. What does this have to do with data serialization?
If you're happy with protobuf but just not with gRPC, you can check out Twirp [1] and DRPC [2]. Both aim to be simpler alternatives while keeping protobuf for serialization. Their development is Go focused though.
That said I also haven’t found anything better either and the technology is popular enough that I stick with it and just work around the limitations.
For your specific case I highly recommend ignoring the built in GRPC retry nonsense and using the Java failsafe library retry policies instead. That has worked well for my team at least.
what's what opinions are - they necessarily must be wrong to some people. Otherwise, it'd just be called facts!
Capnproto tried to do too much with distributed objects and RPC, I was looking into it years ago but it still seems like the C++ impl is the only one that supports those advanced concepts.
Caveats:
1) I needed to work in C++ and Java
2) I was transporting serialized messages over ZeroMQ
It is missing many nice-to-have features however and is also apparently unmaintained, with the last release 16 months ago...
Parametric type polymorphism AKA generics.
I regularly think of Cap'n Proto when working with gRPC or GraphQL, despite not ever having had the chance to use it in a real project.
There's a list at https://capnproto.org/ under "other advantages".
- It has yet to escape the ZeroVer versioning scheme and produce a “stable” API.
- Maturity for languages other than C++ can be a bit spotty.
- The RPC protocol is cool, but apparently most of it was never implemented. The C++ implementation only implements “level 1.”
Cap’n Proto is undeniably cooler than Protobuf, although in practice I worry primarily about maturity and support.
great to see he is still pushing cap'n proto forward!
Edit: oh you do mean sandcats..
Also, I need to make a web site for KJ.
I used Protobufs for awhile and really didn’t like the C options.
