4 ms·

We've been using gRPC and Protocol Buffers for the last couple of years. We write APIs using the Protobuf interface definition language, then generate client li

We've been using gRPC and Protocol Buffers for the last couple of years. We write APIs using the Protobuf interface definition language, then generate client libraries and server side interfaces. Then it's a matter of implementing the server by filling in the blanks.

stunt 7y ago
We've used Apache Thrift for the same reason on some projects.
kminehart 7y ago
I love protobuf for this reason. Personally I've opted for Twirp instead of gRPC, as gRPC has a lot of baggage, and streaming is really not necessary for me. We've had to drop-in-replace, or add a validation or access layer service for something, and using protobuf has made this super easy. Anything interacting with that service is none the wiser.
- vyshane 7y ago
  gRPC has been solid for us on the JVM, and streaming has been great when consuming from Apache Flink jobs, integrating with message queues, receiving push notifications and so on. For async work it's useful to have more than just request/response. I've been playing the FoundationDB Record Layer for a personal project of mine, and with this setup I can generate not only the API implementation, but also the models used by the persistence layer: Protobuf (Messages) -> gRPC -> Scala/Monix -> Protobuf (Models) -> FoundationDB
  - praneshp 7y ago
    > Protobuf (Models) Sounds really cool! Is this something that comes out of the box or generated by your own plugins?
    - vyshane 7y ago
      FoundationDB Record Layer uses protocol buffers out of the box. They leverage the fact that you can evolve protobuf messages in a sane way. That's their equivalent of doing database schema migrations.
praneshp 7y ago
Are you writing internal APIs or exposing some to external developers also? Are those external developers able to start from JSON and make a request?
- vyshane 7y ago
  Both. And if your external clients rather consume a JSON/REST API, it's easy to derive that from a gRPC API. You can do it right there in your protobuf definition. It's actually easier to do it that way than to deal with OpenAPI's wall of yaml.

stunt 7y ago

We've used Apache Thrift for the same reason on some projects.

kminehart 7y ago

I love protobuf for this reason. Personally I've opted for Twirp instead of gRPC, as gRPC has a lot of baggage, and streaming is really not necessary for me. We've had to drop-in-replace, or add a validation or access layer service for something, and using protobuf has made this super easy. Anything interacting with that service is none the wiser.

vyshane 7y ago
gRPC has been solid for us on the JVM, and streaming has been great when consuming from Apache Flink jobs, integrating with message queues, receiving push notifications and so on. For async work it's useful to have more than just request/response. I've been playing the FoundationDB Record Layer for a personal project of mine, and with this setup I can generate not only the API implementation, but also the models used by the persistence layer: Protobuf (Messages) -> gRPC -> Scala/Monix -> Protobuf (Models) -> FoundationDB
- praneshp 7y ago
  > Protobuf (Models) Sounds really cool! Is this something that comes out of the box or generated by your own plugins?
  - vyshane 7y ago
    FoundationDB Record Layer uses protocol buffers out of the box. They leverage the fact that you can evolve protobuf messages in a sane way. That's their equivalent of doing database schema migrations.

praneshp 7y ago

Are you writing internal APIs or exposing some to external developers also? Are those external developers able to start from JSON and make a request?

vyshane 7y ago
Both. And if your external clients rather consume a JSON/REST API, it's easy to derive that from a gRPC API. You can do it right there in your protobuf definition. It's actually easier to do it that way than to deal with OpenAPI's wall of yaml.