 Thanks for the warm welcome. Hey everyone, I am Sankeet Singh. I hope everything is fine. I'm audible also, right? Okay, cool. So welcome to EuroPython guys. This is my second Python conference as a speaker. Today we are going to talk about GRPC with Python. I believe a lot of you guys might be already aware about what GRPC is, what it has to offer, but we are going to take a deep dive. And if you are a beginner, then you're at the perfectly right place. If you don't know anything about GRPC, we are going to talk a lot about it. And we are also going to see how you can set up your first GRPC server and client with Python, right? Before we start, who am I? Why I'm here? I'm Sankeet Singh. I work as a software engineer at Google. Prior to Google, I worked as a software engineer at LinkedIn. In India, I like spending some time in training students about foundations of computer science like data structures, algorithms, DBMS, networking, JavaScript, and Python as well. I'm kind of like superhero fan. So big Marvel and DC fans where you can find some references also coming up in the slides. So stay tuned for that. Let me know if you get some Easter eggs and references, okay? So what you guys can expect from this session, we are going to talk about what and why about GRPC, like what is GRPC and with our already existing solutions. Why do we need GRPC now? We are going to compare GRPC with some other conventions like REST, SO, et cetera. Also, we'll see that how you can kickstart a small sample GRPC server inclined in Python. It's going to be really easy and we will unleash the power of GRPC in very few steps. So this is going to be what your expectation from the session is, right? Okay. So first of all, before we actually take a deep dive into REST, sorry, take a deep dive into GRPC, we would like to first of all talk about REST, right? Our favorite REST. I believe all of you guys must have interacted with a REST API, REST server or maybe developed your own as well, right? REST is something which is kind of widely accepted and used. There exist dedicated frameworks like Python Django, Ruby on Rails. These frameworks support REST out of the box, right? We don't have to do a lot of configurations and change the conventions. They by default support REST and they encourage you to support REST as well, like in things like Django and Rails. If we follow REST conventions, then things get even simpler. The scaffolding operations provide us default set of REST APIs for whatever resources we want to use, right? So REST is already present with us. It's very flexible and easy to use, right? In REST, we deal everything as resources and we are kind of like very much into it that most of the, I would say, most of the people must have somewhere, somewhat in during their career, must have worked with REST. REST is something that is even compatible with browsers, right? We have pre-defined set of conventions with REST. We have pre-defined set of codes which are called as status codes for REST, right? So you guys can like check out the MDN status codes for REST. There are a bunch of them and definitely we know about 200, 404, 500. We definitely interact with them on almost daily purpose, right? So REST is already there and we are kind of used to it. It's easy, it's flexible. It gets the job done, right? Till now a lot of, I would say, big websites, applications websites, applications are already set up in REST. They are doing fine. So what's the problem now? Let's talk about it. So we'll talk about the problems and the shortcomings of REST. But first of all, there is something new already present in the market. We would like to welcome GRPC. So you guys must have already heard about RPC, remote procedure calls. So what is GRPC? GRPC is an open source RPC system developed by Google in 2015. So on and all it does the same thing that a normal remote procedure call is going to do with some added benefits as well as advantages. So GRPC uses HTTP 2.2 out of the box. We are going to talk about it and it is one of the most important reasons why using GRPC makes sense a lot because it comes with the capability of HTTP 2.2. We'll talk about it a bit later. In GRPC, we use language neutral protocol buffers. This is one of the key highlights of GRPC, right? We are already used to things like XML, JSON, et cetera, but protocol buffers are new to the picture and they change the whole landscape. GRPC is very fast, secure and has features like automatic load balancing, right? So GRPC comes up with a lot of new features. It's open source, managed by Google and we are going to discuss about all of these features. We are also going to see when we should not use GRPC. We're going to compare it with REST and a lot more, right? So the thing is, I would say the most important question is not what is GRPC. The most important question that should come into our mind is why now, like we are already there with a lot of already present conventions, RESTs, SOAP, et cetera, like why do we need to use GRPC now and what benefits it comes with, okay? So we would first of all like to discuss some problems with REST. Before we start with the problems, I would like to specifically mention that whatever I'm going to discuss here, you might not feel these as problems, right? It can depend on use case to use case that whether you feel it's a problem or I would say it is something that we should be concerned about. But yes, in my opinion, these can be problematic sometimes, right? So the first thing is the problems with JSON. So we know that in REST, already the situation is we interact the messages that we send from server to client, always it's going to be in JSON, right? We encourage JSON. What is JSON? If you don't know about JSON, JSON is JavaScript object notation. It looks a lot similar to JavaScript objects. It's just that we use it as a message format in REST, right? But the problem, the fundamental problem with JSON is we cannot do like direct type checking. Let's say you want to send a number. Sometimes you want to specifically send a strings. Type checking doesn't exist. Okay, cool. I believe the technical glitch is solved. Really sorry for that, guys. So let's just resume, let's just resume. So we were talking about we already have REST in place. So why GRPC now? So instead of like the main focus for anyone who wants to interact and learn about GRPC should not be that what is GRPC. But first of all, we need to understand that why GRPC? What are the benefits that comes with GRPC, right? And what are the, I would say shortcomings of the already present conventions and the technologies that we have. So whenever I refer to REST, then I just don't refer to the convention REST, but I also refer to the REST based APIs and everything. Okay, so we know that in REST, we use the message format as JSON. What is JSON? It's JavaScript object notation, right? I believe everybody must have at least seen or maybe used also JSON a lot of times. So the main problem with JSON comes as the issue with type checking, right? There is no strict type checking that comes out of the box of JSON. There are, I would say solutions available, but JSON by default, if you have like just out of the box supported, it's kind of difficult. Apart from that, apart from that, you need to do semantic versioning required on any API change. Like you have to specifically change the semantics of the API whenever you do a version change, right? For streaming, there is not like a lot of support directly. By default, REST comes with HTTP 1.1. Yes, you can migrate it to the later versions, but if something is coming out of the box, generally people tend to use it, right? So generally a lot of people and a lot of technologies and a lot of companies still are stuck on HTTP 1.1. You need to do manual validations for the requests and responses, right? And this is directly correlated with the issues of JSON having like the type checking issues with JSON, right? So this takes a bit of extra effort to do these manual validations. Apart from that, there's a very significant problem that comes with REST, that is maintenance of client-side libraries and implementation is required. For example, if somebody wants to consume a REST API in Python, then there is a separate set of libraries that they need to use. But instead of Python, let's say if somebody wants to consume REST API in let's say JavaScript or maybe in C-sharp or maybe in Java, then for each corresponding text stack, you have separate set of client-side libraries. Now having separate set of client-side libraries brings a lot of challenges. For example, there may be a case that few of the client-side libraries are using the latest versions and the latest updates that are coming in REST, but not everyone is using it. Apart from that, the maintenance is done by different communities and different organizations. So they are not going to be always consistent in their efforts, right? So these implementations of the different implementation of these client-side libraries can be also considered as one of the major problems with REST. Again, as I said, you might feel that like all of these things, that all of the problems that I've discussed are kind of like opinionated, right? Maybe for your use case, you don't feel like these as a set of problems. You don't feel like, okay, this is something that we need to care about. Maybe the scale that you are targeting or maybe the audience that you are targeting or the application that you are building is not gonna be affected a lot by these issues. But yes, they do exist. And maybe sometimes down the line, you are going to face it, okay? So, and then here comes GRPC to the rescue. All the things that we discussed about REST, GRPC solves a lot of them, if not everything. So the main and the best part about GRPC is the first two points. That is GRPC comes with HTTP 2.0 support by default. So all the features around multiplexing and the fast data transfer around HTTP 2.0 comes out of the box. You don't have to make an extra effort to change your version of your version. Apart from that, the key highlight about GRPC is the protocol buffers, the use of protocol buffers instead of JavaScript object notation that is JSON. Protocol buffers, we are going to discuss a lot of things around protocol buffers, but protocol buffers are the major game changer. Due to protocol buffers only, we are going to be able to create strict API contracts. So all these strict API contracts that we are able to build, we will be able to build using protocol buffers only. So protocol buffers brings a lot of features to GRPC. And these protocol buffers have their own built-in code generators, right? These code generators are maintained by Google. We are going to talk about it. But it's like that, you don't have to separately maintain different client-side libraries. We are going to see how is that gonna happen. But these code generators are really very helpful. Apart from that, GRPC comes with some extra features like inbuilt load balancing. And for streaming, it has support for unity streaming, streaming from server side, streaming from client side and even bi-directional streaming as well. So if you want to just build a quick chat app also, things are gonna work extremely fine with GRPC. And apart from like all of these bunch of features, HTTP 2.0 protocol buffers, all of these things combine to one of the most important feature that is, GRPC is faster than REST, right? So you can check out some of the Stack Overflow articles that I have linked in the speaker notes for the presentation. Then you will find that in normal situations, you will find in production servers, GRPC works around seven to 8% faster than REST. And all of the features that we discussed just now for GRPC, that is protocol buffers, having HTTP 2.0, having the features of load balancing, all of these features combined helps GRPC to be faster than REST, right? So how is it faster? As I said, the usage of HTTP 2.0 does a lot of things. Apart from that, you have support for inbuilt load balancing as well. If you want to do streaming, there are four different types of streaming that is supported. And apart from these three things, here comes protocol buffers. We will also refer protocol buffers as proto buffs, right? So what protocol buffers do is, protocol buffers serializes and deserializes data into binary, thus reducing the size of messages, right? So whatever message we want to transfer in GRPC, the message format is going to be protocol buffers. And these protocol buffers are going to serialize and deserialize your data into binary format. How this is going to help? This binary format is going to be extremely small in size. I'm going to show an example that how small it becomes, but due to this, the overall message format becomes less bulky. Hence a bit faster, the transfer is a bit faster over the network. So here's an example. I have taken this example from one of the, I would say very interesting medium articles. I have referred that article also in the speaker notes. So here you can see, if you want to serialize a spring medium like this, by protocol buffers, the binary looks something like this, this small. But let's say if you want to serialize something medium with XML, we know our favorite XML, it's going to look something like this, this extremely huge for just a small string medium. And if you want to send it serialized by JSON, then it will look something like this, right? So you can see protocol buffers are doing an immense amount of compression in terms of data, like the serialization to binary is going to make your data extremely light, extremely small, hence it's going to be faster, right? So if you see the official documentations that were like given by Google, then protocol buffers are Google's language neutral. So that means it's gonna be language-independent, platform neutral, that means platform-independent, extensible mechanism for serializing structured data, right? Think XML, just like XML, but a bit faster, smaller and simpler, right? Why smaller? Because it is going to serialize it into binary format. Due to this fact, it is going to be lightweight and hence will be transferred faster over the network and it's really simple to prepare. You define how you want your data to be structured once, then you can use special generated source code to easily write and read your structured data to and from a variety of data streams and using a variety of languages. So as I said, due to the intervention of these protocol buffers, what you'll do, you'll just maintain protocol buffers like this. You are just going to prepare protocol buffers like this and then there are dedicated code generators that are given to us by Google only, which are going to generate client-side code for you that will help you to interact with these protocol buffers directly, right? Now, you can see most of the languages like Python, Objective-C, C++, all of these languages are available. They have also introduced support for Kotlin, Dart, Go, Ruby and C-Sharp, right? So you can see if you want to just use a simple protocol buffer, you will be automatically be given a code generated like this, right? So let's talk more about it. So what has happened is Google has taken upon themselves that all of the client-side libraries, you don't have to maintain any community, it doesn't have to maintain, it will be maintained directly by Google, whether it be Node, C-Sharp, Ruby, Python, Java, everything, these protocol buffers will be having their dedicated code generators again maintained by Google, which are going to generate client-side codes for you to consume any GRPC-based, I would say APIs, and you don't have to bother about the fact that whether you are having the latest version of GRPC, the latest version of the HTTP or the rest of the features that they are going to use, everything is going to be maintained by Google. So if you want to see some coding implementation that how things work with GRPC, then you can see all you have to do is set up a basic proto, right? This basic proto is going to get set up. So I have prepared a basic proto off to do. Most of us must have done some to-do-based, to-do app-based implementation. So if you want to implement your own to-do in using protocol buffers and GRPC, what you have to do is you have to first of all define what kind of APIs and I would say RPC service you are going to expose. So we are going to have two RPCs, one is create to-do and the second one is read to-dos. Create to-do is going to take a to-do item as input and it is going to return the to-do item and read to-dos is going to take a to-do request and it is going to return to-do items. So if you see how to-do item looks like, so it's a message format, you can see with protocol buffers, the main benefit is these are strict in terms of type. Like if let's say you want ID to be of integer only, then it will make sure that whenever the client is consuming these protocol buffers or server is using these protocol buffers, every time the value assigned to the ID is always integer. So you are having strict type checking. This makes your APIs strict, right? You can see even you can define strings and there are multiple data types that are supported by protocol buffers. And if let's say you have to set up an array of objects, you can use this repeated property. If you want to have something optional, for example, in this to-do request, we can have an optional ID. So you can just put the parameter optional and this ID is going to be optional. That is it's not mandatory to send ID when you want to send a to-do request. So this is like a basic proto setup that you have to do. Once you have set up the proto, what you have to do is, you can use the code generators for, so for every language, you will be having dedicated code generators for Python. You can install the GRPC tools. And there we have the protoc compiler, which is going to help you to generate these codes for that is going to be compatible for Python, right? And what you can do is, you can just start implementing your RPC. So here you can see, we are going to implement the create to-do and read to-do RPC. If you see, then this to-do protocol buffer to GRPC, this to-do PB2 GRPC object, this is going to get created with the help of those compilers. And you will get this method add to-do services to server, right? All you have to do is just pass your to-do service and the server object and then just set up your secure port. Let's say we are going to set up the port as AT-AT and we can start the server. This is as simple as that. If you have to consume the protocol buffers, all you have to do is just create the object and you can just make a call to the server. So using protocol buffers is as simple as that. You can just set up your secure channel from the client to the server. You can use this insecure channel function and you will be able to set up a basic stub using this stub you can make a call to whatever RPC you want to create. So let's say you want to call the create to-do RPC, you can create the to-do item and send this to-do item and the to-do request in your RPCs. So you can refer to this code implementation in order to set up your basic Python server, right? And you can see you will just set up your server and your client and you can call the server from the client and things should be done. So if you talk, we have talked a lot about the pros and if you talk about the cons of GRPC, then I would say if you have something very simple and very specific to implement, then GRPC can be a bit overwhelming for the starters and rest is I believe more simple than GRPC. GRPC is not as flexible because it makes your APIs and contracts strict, but again, there are pros like you will be able to get more efficiency, you will get features like load balancing, et cetera. So that was it for today's session. Really sorry for the technical glitch, guys. I hope you guys enjoyed the session. If you guys have any questions, then feel free to ask. It was a great time interacting with you guys and thanks, EuroPython, for giving the opportunity to me as well. Thank you, guys. Thank you. Thank you.