Linux serverlinux web serverNETWORK ADMINISTRATIONS

What is RPC? gRPC Introduction.

To get better at system design, subscribe to our weekly newsletter: https://bit.ly/3tfAlYD

Checkout our bestselling System Design Interview books:
Volume 1: https://amzn.to/3Ou7gkd
Volume 2: https://amzn.to/3HqGozy

HTTP/1 to HTTP/2 to HTTP/3:

ABOUT US:
Covering topics and trends in large-scale system design, from the authors of the best-selling System Design Interview series.

source

by ByteByteGo

linux web server

20 thoughts on “What is RPC? gRPC Introduction.

  • Man amazing, your channel is a treasure, you and hussein nasser are the best channels which talk about Backend.
    Thanks.

  • Moving all our internal endpoints to gRPC, because the staff engineer that proposed it wants our backend communication protocol to be language agnostic while our whole backend stack is written Java or in the process of migrating to Java.

    The engineer that proposed it got a promotion while the migration to gRPC provided no business and engineering value other than costing the company millions in lost engineering hours.

  • shared code between client and server to establish data exchange contracts is such a basic seeming principle to me, I'm appalled it isn't used more commonly in API design.

  • great explanation, animation and easy to understand.
    i learned about gRPC as mean for communication between internal services, seems like it is also could be open for public. wonder about the security implementation though

  • wondering how you make these animations/flows? they are amazing!

  • It looks like reinventing the wheel (IDL + Stub/Skeleton + part of IIOP/CORBA). By simply injecting an HTTP layer into a concept which already exists for ~25 years.

  • So binary SOAP? Or did I miss it completely?

  • Thanks for the video. I have so much to learn. Just learning this stuff to become valuable to the Bitcoin development community someday.

  • One problem with gRPC using HTTP/2 is that it doesn't load-balance well. HTTP/2 relies on a persistent connection and sends many requests through the same connection, which means, all these requests go to one node. It overloads one node, barely using others. There are workarounds, such as forced disconnects, proxies, client-side balancing. But again, they are workarounds, meaning, they require extra effort to mitigate a design flaw. Not really a flaw, HTTP/2 is still good because it reduces overhead on connection creation, but had it used HTTP/1.1, the balancing problem wouldn't be the case.

Comments are closed.