Protocol Buffers & Language Interoperability

A free video tutorial from Clément Jean
Protocol Buffers and gRPC Enthusiast
Rating: 4.6 out of 5Instructor rating
5 courses
56,152 students
Protocol Buffers & Language Interoperability

Learn more from the full course

gRPC [Golang] Master Class: Build Modern API & Microservices

Better than REST API! Build a fast scalable HTTP/2 API for a Golang micro service with gRPC, Protocol Buffers (protobuf)

03:45:38 of on-demand video • Updated November 2022

Learn the gRPC theory to understand how gRPC works
Compare gRPC and REST API paradigm
Write your gRPC service definition in .proto files
Generate Server & Client Code in Golang using the protoc gRPC Plugin
Implement Unary, Server Streaming, Client Streaming & Bi-Directional Streaming API
Practice your learning with Exercises & Solutions
Implement advanced concepts such as Error Handling, Deadlines & SSL Security
Implement a full CRUD API on top of MongoDB
Get pointers to expand your learning journey and get inspired by real world gRPC services
English
Welcome to the section on gRPC deep dive. So before we get into the code, I really want to take a moment to explain to you how gRPC works, what are the foundations and etc., etc.. So I want to do this because I really think that for you it's really important to understand how the code works, how the framework works, and what are the concepts around it. So first, let's talk about Protocol Buffers, because it's the cornerstone of gRPC. This is what a protocol buffer look like. So we define some messages. For example, we have Greeting, GreetRequest and GreetResponse. And then with that, we are going to define some services. As you can see at the bottom here, we will learn how to write them later, but basically we define our API endpoints and then this will allow gRPC to generate code for us. Now we need to understand why gRPC uses Protocol Buffers. gRPC uses protocol buffers for communication, and the main reason for that is that Protocol Buffers has smaller payload size. So if you look at the JSON here, for example, we have "age" , "first_name" and "last_name". And then if we measure this online in a compressed way, it will give us 52 bytes. Okay, this is pretty small, but take a look at the Protobuf now. So if we define the same Person and we set the same values in Protocol Buffers, we will only get 17 bytes. So you can see that right away. With protocol buffers, we can save a lot of bandwidth or a lot of storage space because the messages are smaller. Additionally, passing JSON is actually quite CPU intensive and there are a lot of libraries that try to optimize that. But overall, it's still remained pretty CPU intensive and that's mostly because the format is human readable. But parsing Protocol Buffers because it's binary and because it's very, very close to how the data is actually represented in memory, it will be less CPU intensive. So that's really important because with Protocol Buffers, it will basically mean that we have a faster and more efficient communication and we can have a better efficiency with devices that are a bit weaker, such as mobile devices or even microcontrollers. And so that now we can understand why gRPC uses Protocol Buffers. We also need to see what are the supported languages. If you go to the grpc.io website, you can see that you have a section called the Docs / Languages and it will list the officially supported languages. So we have C#, C++, Dart, etc., etc. And if your language is not in the list, don't sweat it. There are actually many more language which are supported by other companies or by open source communities. So to give you an example, Apple officially supports the Swift implementation of gRPC, and I'm sure that you can find any implementation for common languages. So although gRPC as many supported languages, we have four main implementations. So there is gRPC Java, gRPC Go, gRPC C# and gRPC C. And all these implementations are pure meaning that they only use the respective language. But then we also have implementations which are based on the C implementation. So the C++, the Python and all the others are based on the C implementation. And what it means is that, for example, if tomorrow the gRPC library gets updated, the Java implementation, for example, might not get the benefit as quickly as the C++, Python, Ruby, etc., etc. but it also means that some implementation might have different features. For example, the C# implementation already has support for HTTP/3 , but all the others don't. So to summarize, it's pretty intuitive to write messages and services. Furthermore, it generates a lot of code for us and it generates this code in multiple languages. And finally, we benefit from efficient Serialization and Deserialization because the format of the data is binary and requires less CPU to be parsed. So that's all for this lecture. I will see you in the next lecture where we are going to talk about the foundation of gRPC, which is HTTP/2.