1. 11
  1. 7

    This article was a bit thin for me. It boils down to comparison between OpenAPI and gRPC, and the argument is the size/complexity of the description. However, it doesn’t take into account size of the supporting infra, complexity of tooling/debugging techniques (even tho it does mention that one can’t curl anymore to do check). Would be interesting to hear other people (especially from Ops side of world) experiences after switching to gRPC – did things become more complex?

    1. 10

      Absolutely. I regret using it at my current job. Documentation is imo very poor for more advanced use cases. REST/HTTP/1.1 is well understood, easy to debug and performance is more than enough if you’re not google/facebook/twitter. Furthermore, its very well supported by lots of tooling. E.g. k8s doesn’t have a gRPC health check without downloading some binary and putting it in every single one of your containers. I think the main issue I have with gRPC is the insistence on HTTP/2 when HTTP/1.1 would have worked fine. I have more issues with gRPC as well, I need to write a blog post.

      1. 2

        I have more issues with gRPC as well, I need to write a blog post.

        Please do! I’ve avoided gRPC itself, but for example I’m a fan of capnproto.

        1. 1

          shouldn’t the comparison be between protbuf and capnproto instead ? afaik, capnproto provides a serialization / deserialization framework rather than a rpc framework…

          1. 1

            Capnproto has some libraries that only provide serialization. It’s mostly that plus awesome RPC

      2. 2

        I haven’t thought too much about how necessary this would be with gRPC, but we had a fairly similar binary protocol at work for service-to-service communications that ALSO exposed an HTTP+JSON bridge for curlability, which worked really well!

        1. 2

          It never even actually talked about gRPC, just Protobufs. I built a microservice function using Protobufs without gRPC, they are not equivalent.

          1. 1

            Conflating these two was a huge source of pain on the project I’m on at work; protobufs have been a nightmare while grpc itself has been fine. (Not helpful at all but not actively slowing us down the way protobuf did.)

            1. 1

              Wild – I had the inverse experience, where protobufs have been useful and neat but gRPC hell every step of the way. We swapped out gRPC for Twirp (which still uses protobufs), and things are happy.

              1. 2

                YMMV as always; contributing factors in this case included:

                • we’re on the JVM
                • we already had been using a much more thorough and descriptive way of declaring the shape of our data (clojure.spec)
                • encoding efficiency was very far from being a being a performance bottleneck
                • these were all internal APIs that were always being called from other Clojure codebases rather than being a public endpoint called by who-knows-what clients
                1. 1

                  I don’t think protobufs are a good choice without a multi-language environment. If everything is using the same language, then just share a service library.

                  In my (limited) experience with it, we were adding a microservice layer in Go that talks to a couple Ruby services. Being able to spec out data types and generate code for each platform is really nice.

          2. 2

            Twitch apparently had issues with grpc, and made their own thing instead.

            1. 3

              We were also using it at work, and switched off of it. The complexity wasn’t worth it.

              We replaced it with a combination of things, mostly a JSON schema/code generator that I wrote in ~500 lines of python, and plain HTTP or Unix domain socket requests.

              It doesn’t do the same things as GRPC, but it covers the same pain points (documentation and syncing APIs across languages), and the fact that it’s both tiny and maintained in-house makes it malleable – if it doesn’t do what we want, we fix the framework.

              1. 2

                That article is 18 months old now, although it links to grpc-go issues that are two years older than the article. I wonder if anything has improved in gRPC / grpc-go in those two years, or in the 18 months since.

              2. 2

                What about streaming?