When RESTful architecture isn't enough...

REST has always been my preferred interface architecture, but it doesn't always fit every use case. Some times, it's better to use an RPC interface instead.

gRPC has brought with it some awesome features and tooling, and is often a better solution for RPC.

This video was sponsored by Acorn Labs. You can deploy your own version of the calculator API using the URL below.

Video Links:

Join this channel to get access to perks:

00:00 Intro
00:27 What is RPC
02:32 gRPC & Protocol Buffers
05:46 Building a gRPC server
12:54 Error handling
15:47 Repeated
17:07 Building a gRPC Client
18:59 One last thing

[dreamsofcode]

To deploy your own version of the calculator service, use the following link :)

[yairlevi]

This is probably one of the best tutorials I've seen for non-noob programmers who just want to learn a new tech quickly and know the terminology already. awesome!

[КонстантинСавин-кя]

You are doing great content! Love to see gRPC with Rust as for GO or Python you can find in the documentation.

[snoupix]

I'm very proud that I'm following you for a while, you're making really great content. Keep it up ! :)

[Tachi]

Worth noting that Protobuf isn't really an advantage specific to gRPC, as it's perfectly fine to use a binary serialization format like CBOR or Protobuf in RESTful APIs too

[animanaut]

looks like somebody picked up the dropped ... SOAP 🤣
bad joke, i know, but this video triggered some dejavu's for me
good video, as always. thx

[davidrieger]

This is an impeccable video. High level explanation and a clear and pretty step-by-step example implementation. Well done.

[goisenate]

So we're back 20+ years to SOAP with WSDL and XSD.
This is not a bad thing per se but let's agree this is not an innovation.
Yes, ProtoBuf is pretty efficient compared to the clunky XML messages in SOAP.
And I'm excited about the Subscription capabilities in gRPC. Your videos are well-done and informative, so I'd be grateful for a video on Pub/Sub with gRPC.

On the other hand, in gRPC, we lose the whole hypermedia concept of REST/HATEOAS/HAL.
In well-done RESTful APIs you don't care about IDs and what endpoint to call because the resourse you GET contains hypermedia links with the exact endpoint to call (including the ID). To me, that was a truly remarkable shift in mindset when designing APIs.

In closing, I appreciate this video. It illustates well that RESTful thinking does not fit to all problems, building a calculator being one of them.
Thanks!

[justinclarketx]

I've been thinking about learning gRPC in Go for weeks now, and this video is perfect! Thank you!

[evanbelcher]

Protos are one of my favorite parts about dev at Google. Cods generation and static typing for not just DTOs but also method definitions is a gamechanger for internal services.

[sohhamm]

gRPC is great, but REST fits most of the real world use case. We need more native tooling around gRPC

[jo-pouradier]

Super great video as always ! I wasjust looking for a video about RPC and LSP two days ago and here is yours! perfect timing, thanks !

[ThePhiliposophy]

I am sure you get this all the time: Your tech presentations are the most polished and visually appealing that I could find on YT. And that's only the cherry, but it's a big fat tasty cherry (for me at least). The cake is the content and how concise and easy to understand you present it. And the frequency of uploads is also spot on!

[shelbydoolittle]

The main problem with grpc is that it requires your clients to add a step to their build process. It's also difficult to debug as values on the wire are very difficult for humans to read. And adding a build step to your own project is not zero cost as well. Just wait until you get confusing errors because you're running stale protobuf definitions.

Generally I am a big fan of RPC interfaces. I don't do REST because you need to fit your problem to the REST format instead of modeling your API as relatively normal functions.

Would love for these videos to talk about some.of the drawbacks of whatever tech you're discussing in addition to the benefits. There are few technical resources that honestly discuss drawbacks.

[buzzebee]

Re your points around 5:00 and open api specs. If you write your spec using a composition tool like boats then it's a lot nicer to write a good spec first in small chunks, then compile that into a full open API spec for your project, and use a good code generator to create a fully typed interface for your frontend and backend which has temporary mock data and automatic contract testing built in.

Its a really nice way to work. It means your fe team can work on inplementing any endpoints whilst your backend team work in parallel to wire them up.

Not super relevant to a gRPC video, but it's something I think apps where rest makes more sense can benefit from looking at.

[berndackenfutter]

Cap'n'Proto is also worth mentioning -- from one of the original authors of protobuf, with the added benefit of server-side RPC chaining (hence the claim "infinitely faster than protobuf"). And it loads definitions at runtime, rather than having a mandatory compile-step.

[dn]

gRPC is great for internal server <-> server but I think it falls short everywhere else.

[tobb]

gRPC: Huh, that's cool.
Using `touch` to trigger a file watcher: OMG THIS IS SO GENIOUS!

[jamesdcarroll]

I remember writing COM and Corba idl files for the exact same reasons/promises. Good times.

[peterndungu]

Valorant the multiplayer game from riot games uses grpc with protobufs to synchronise players e.g such as when the server receives information when a player is hit it does an rpc call to the client to reduce player health and such. Read this in their technology article whereby they were trying to reduce the latency between the different players connected to the same server infact switching to this if i remember well reduced the latency i think by 30%.
Interesting stuff