Is GRPC Worth It For Internal Calls, Or Is That Resume-Driven Design?

api-designgrpcrest8 replies · 193 views · started
  1. im literally losing my mind here were a startup backend team running a monolith plus two workers. Today they all talk JSON over HTTP and it works fine, but someone proposed moving internal traffic to gRPC: stronger contracts, generated clients, less hand-written glue. Half the team loves it, half thinks its complexity for notihng. Id love to hear from people whove actually lived with both 🤷 What tipped teh scale for you?

    Bonus context: nobody on the team has run gRPC in production before, though a couple of people have used it in side projects... i'm worried about the learning curve more than teh tecnhology itself. seriously need help here 😭

    3
  2. Do any of a dozen internal services need streaming or biidrectional communication??

    9 0 helpful
  3. The contract problem is solvable without gRPC: an OpenAPI spec as the source of truth, generated clients, and a CI check that fails on breaking changes. That gets you most of the safety while keeping curl-able endpoints.

    4 0 helpful
  4. ahh classic gRPC shines when u have many services, polyglot clients, and streaming needs :) for a small number of services the tooling overhead (proto repos, codegen in CI, gRPC-aware load balancing over HTTP/2) can outweigh the benefits. lmk how it goes

    0 1 helpful
  5. hmmm one practical gotcha: L4 load balancers keep a single long-lived HTTP/2 conncetion per client, so gRPC traffic can pin to one backend. You need L7 balancing (Envoy, a service mesh, or client-side balancing) to spread it. good luck man!

    6 2 helpful
  6. @patch_owl123 Biggest takeaway: our problem was ownership, not protocol. Assigned an owner for teh contracts first. Thanks for the thoughtful replies.

    24 3 helpful

Reply to this topic

Sign in or create an account to reply.

Is GRPC Worth It For Internal Calls, Or Is That Resume-Driven Design? · Patchhall