Introduction to RPC - Remote Procedure Calls

so today let's talk about one of the most interesting thing that revived itself after a decade remote procedure calls finally called as rpcs they are widely adopted to do inter-service communication over the network the core highlight that sets rpcs apart is that it is designed to make a network call look just like a local function call it does this by abstracting out all the complexities like serialization decentralization and transport in this video let's take a look into what rpc is where does it fit what are stubs how communication happens between the services and conclude with going through the advantages and disadvantages of using rpcs but before we move forward i'd want to talk to you about a code based course on system design that i have been running since march 2021 right if you're looking to learn system design from the first principles this course is for you yeah because this is a cohort based course it will not just be me rambling a semi-optimized solution thinking it's the most amazing solution out there instead it will be a collaborative environment where every single person who is part of the cohort will can pitch in his or her ideas and we will evolve our system around that right every single problem statement comes with a brainstorming session where we all together brainstorm and evolve our system that's where everyone understands the kind of trade-offs we made while making that decision instead of just saying hey we'll use a particular queue we'll have the justification why we use only that queue why we use that particular database why sequel why not nosql right how are we leveraging throughput how are we ensuring that our system skills that's the highlight of this course this course is taken by more than 500 engineers to date spanning nine countries and seven cohorts right people from all top companies have taken this course and the outline is very intriguing it's very exciting so we start with week one around we start with the core foundation of the course where we design online offline indicator then we try to design our own medium then we go into database where we go in depth of database logging and take and see few very amazing examples of data log or database logging in in action and how do we ensure that our system scales through that then the third week is all about going distributed where we design our load balancer i'll have oculus of the actual code of a toilet balancer and understand how pcb connections are managed and how simple it is to build load balancer then week 4 is about all about social networks week five is all about building your own storage engines like we'll build that intuition on if you were to ever design your storage agent how would you do that right then week six is about building high throughput system seven is about building uh ir systems basically information retrieval systems and adopt designs where we design our own message brokers like sqs where we design distributed task scheduler and we conclude the course with week 8 where we talk about the super clever algorithms that has powered or that has made those systems possible right i have also attached a video verbatim as is from my first code where we designed and scaled instagram notifications i will highly encourage you to check this video out right and now back to the video so say we have two services and they want to talk to each other one acts as the client another one access the server and the most standard way to do this communication is when your client needs something it makes a request to the server and server responds back right and this happens over any communication protocol like let's say tcp udp pick your favorite right this is not rpc this is not rpc specific instead like this design is is a very common way through which two components in the network will talk to each other right and this is how the entire distributed system is built right so then what's what's that that makes rpc different so let me give you an example let's say when some when you are writing an application you have an authentication service and you have a notification service so authentication service uh whenever someone tries to log in you want to send that user an otp otp sending is handled by the notification service so now what needs to happen is that your authentication service needs to talk to the notification service how will this communication happen right so this is where rpc come into the picture so in order to understand or in order to uh in order to see how beautiful rpc is let's let's take a look into the code of it like how would you write the code to do this so your login method would look something like this def login you take email and password you write your basic code to generate access token and at the end you put in notification underscore otp in brackets email so send an email otp to this particular user right so this is how you would write the code but how will you implement the notification underscore otp method is where the magic happens so for example if you are using rest like the most common way to do any communication right now is rest right and what you will do that you will write the function notification underscore otp that would make an http call which is a rest based http call to the notification service on the endpoint which is exposed by that service right for example that service is running on host or with a domain name notification dot abc dot internal would make http colon slash slash notification dot abc dot internal slash email slash otp and then you will pass it the email id there to send otp now here is that what's the problem here like like everyone would do that right but what's the problem the core problem here is now this is not just one api call your service might be interacting with with 50 other services and you would have to write that same thing again and again what making that http call right for example if you're using python you will use hypothetically let's say you're using request library right so at every place you are making that request library call and like with a better low level practice you might want to you would be abstracting few things out but still you would have to write that that particular piece of python code to invoke that http api and then get the response now apart from that you would also have to handle cases like for example what if your network is unreliable and your request fails or you need to do retry or your client is down or sorry right or your server is down and then you would have to do that retry handle failures send error message to the user do exponential backup what not right so here and this is just the login service that has to do all of this in order to talk to notification service let's say there is recommendation service also wants to talk to notification service it also needs to do these exact same things the worst thing that would happen over here is let's say one service is written in golang another one is written in java third one is written in python every language has its own way of talking http with other services like further python has request library java something else golang has nets less http package so there is no standardization right so this is what brings out as a problem to be addressed okay why is there no standardized way to talk to to establish communication between two services why do every single one has to write everything from scratch and like handle all of these things unnecessarily like this could well be abstracted why can't there be a standard to do so which is where rpc comes into the picture so what if we abstract out the repetitive and mundane tasks like communication protocol i don't want to use pcb i want to use let's say udp but but when someone says no i want to use tcp but with http 1.1 or tcp with http 1.0 there is so so many so many choices to make right so what if we abstract out this repetitive task or repetitive and mundane task to be honest like communication protocol object creation failures retries then when you are sending payload you might want to compress it you would want to support a continuous streaming of request when you are uploading large files more than a gb you would want to stream and not make individ individual http request so many things to take care of why can't there be one solution that abstracts these things out and let us the developers focus on writing the actual business logic this is how rpc was conceptualized so rpc is the way to standardize the communication between services no matter which language are you using no matter how you are invoking what your ecosystem is it's all it's all uniform right that's the best part so the code that we just saw def login email password wrote the uh access token code and then you wrote notification underscore otp email now this notification underscore otp bracket email when you pass an email to send notification to a user this looks like a normal function call right earlier we thought of implementing it with python request library making an http call now but what if this itself is a network call it looks like a local function call but internally it hides the complexity of making a remote network call right this is exactly what rpc is all about right so it makes our code so beautiful that you feel like making a local network call your if you are you if you are using an id you can do that same sort of autocomplete like you are you are interacting with native objects will go into detail of it like what i mean by that in case you don't understand we will go through that but it makes your you know function called so native that you will feel here it's a local call only but instead behind the scene it has abstracted out the complexities and made it a network called handling all sorts of optimization and performance bottleneck right so what looks like to you as a local call in instead uh in reality it is actually a network call that happens over the network right and here it basically is there to hide the complexity of remote call we we should not be even worrying how that call happens it just happens right so rpc is obviously because it's a network call it is magnitude slower than local procedure calls but you don't feel like develop actually that's one of the concerns of using rpc where if you don't know that this is an rpc call then and you are invoking it bluntly you might shoot up your response time you just need to be aware that hey this is the rpc call but this is the local uh procedure call so just be aware when you are using it and what it actually abstract out for us is rpc abstract out marshalling like for example when you are invoking the function notification underscore otp and passing email into this someone needs to take an email is what i want to send to this server and that server need to understand that hey notification underscore otp is the method called on your end give me the response back right so who does this rpc manages this for us so much laying on marshalling network packet movement everything is abstracted by rpc but before we jump into what rpc is let's take a small detour and understand what stub is like whenever you will read about rpc one thing that you will always hear the term is stub like and obviously it seems like a pretty weird thing to say in a technical context but that's the terminology that the cs research that the cs researchers went with let me clear these things out what stubs are so login is the the function login is on the authentication service right notification underscore otp function is on the notification service now this someone someone needs to convert the notif the information for example notification underscore otp is the function email is what is being passed over here someone needs to convert this and basically marshal this particular thing into something serializable send into a format that is understandable by both like authentic like you have login service you have notification service right and someone invoke the function notification underscore otp bracket email or basically while passing email as an argument someone needs to take this information and basically create a format out of it which is understandable by the server also by the notification service also right this this who does this the responsibility of this is done by stub now it's not just about converting from authentication to notification service format but also from notification service car response to convert it back and give it out as a native object to authentication service so request and response the conversion of both is what stub plays that important part here so the flow here would be let's say you have the authentication service written in golang you have notification service written in java right authentication service has its own little running rpc runtime java has its own little running rpc runtime so what would happen is where would stub commit to the picture when in the authentication service you invoke notification underscore otp this converts or this the first thing that it interacts with is the stub so the stub what it would do is it would understand it hey notification underscore otp is invoked with email being passed as an argument let me create a very compressed format so that i can send it over the network to the notification service notification service so stop once it converts it into a format it sends it to the notification service notification service receives it then the stub on the notification service understand what has been sent and then it converts it into the native object of notification service in java so golang's struct gets converted into java's class right and then once it understands it then takes the then it takes the necessary action right now notification service main work third party api to send email notification or whatnot will not go into that but assume the notification service is doing its part well once it has triggered that otp then it would then would create the response it would send it back to the authorizator but how it would create the response go to the stub stub would marshal it into a format would send it so that stuff in the authentication service understands it and then it would convert it back right so stub is the one that takes care of converting the method the request type the response type into the form that is used by the rpc system the best part here is that you may create a struct in golang which says that send notification request and you define a response format send notification response as a struct in golang you would define send notification request as a class in java send notification response as a class in java now what would happen is you would like normally invoke a function call you would pass in the parameters create that thing and invoke the function internally it would convert it into a network call and go and fire it then your send notification request struct gets converted into send notification request class in java or the object of that in java then you can normally access it how you normally access the object and its property in java you do your computation basically send the otp and what not you create a response object right which is send notification response object it gets converted it gets serialized into a stream format that java object converts it into golang struct so for you it's pretty seamless you don't really have to think about hey now i got a json payload now i want to convert it into an object now i got a json response i want to convert it into this kind of responsibility you don't have to do that that is all abstracted out from you which is where it gives you like such a beautiful way to write code that it like that's the beauty of rpc it though it makes your remote procedure call appear local right so and that's where stub stubs comes into the picture now we'll see what stuff like why why like how do we even configure it so most stuffs the the most common way of configuring stubs is like for example every single rpc implementation what it would give you is it would give you a way to define the interface language right and this interface language would be what where you define the types for example send notification request is a type send notification response is a type this type needs to be present in golang struct and in java classes so there has to be a common way through which you define this right so that is the interface description language now every rpc would have its own implementation but if i take the most famous implementation right now it's grpc and it uses the protobuf format to do so so what you will do is you will define a common way right you will define it in a normal protofile on like this is the service this is the rpc let's say i'm invoking a function i'm sorry i'm declaring a function power part of a particular service with type message or with type send notification request having a particular set of member fields so imagine like think of it like your class definition but instead of defining it in a class in a particular language you define it in a common proto or you define it in a common basically protobuf format and it's pretty human readable very simple to do so and it's more like just declaration you are not defining what needs to be done it's just declaring that hey this is the interface that both the services would expose and would implement right so what you do as the first step is you write this interface definition in the form in the format of the or the compiler that the language understands for example if you are using grpc you will write it in the proto format right now when we when we are done writing this what we do is we then write a server program that implements this interface so which means let's say you write so from the interface definition language what you actually first do is you run a generator so what generator would do is the generator would take this protofile or would take this interface definition file and would create a java code for you it would not write the business logic but it would write the necessary piece of components that is required for it to make a network call do the retry everything that it would want to it would write all of it would generate all of them by reading this proto file or by by reading your interface definition it would create this in the working java file right and it went then all you have to do is you just have to implement with the the the functions that you have defined uh the the functions that have not been implemented which is let's say in this case the power function or the send notification or dpa function right you just have to take care of the writing of the business logic everything else which is generated as part of the gigantic file that would be generated that is all generated to take care of you making a request and basically getting a response failures retries and whatnot and so now your job is once you generate the stub and now this is what the stub is right your stub generator so these are called stub generators so from interface definition you run a stop generator that creates this this auto generated stub that takes care of marshalling unmarshalling and invoking the network right and now all your job is that on the notification service because that's the interface so notification service needs to implement it and you would write and then you would uh generate the same thing on your golang site or on your authentication service side as well and now what the the beauty here is that the proto format is common your java then when you run a generator with java is the output it would create java code when you provide golang as the output it would create working golang code right so now this is the beauty of it so now what would happen is you have the structs in golang send notification request send notification response as a struct in golang and same thing as classes so now when you're making a call you can use those things as pretty straightforward local objects although they are although it would be seamlessly transitioned into a remote call but you still are only focusing like you are invoking like a normal function call right this is the core idea behind stubs and how it makes things seamless so it the stub generator is the one that does all the magic you define a common thing in your interface language pick any depending on the rpc that you are using you would pick one and then with the go file or with java uh it would be automatically generated and then you would start using that right okay so now how does the communication in rp7 here the biggest myth like and like i talked to a few people and everyone for some reason says are you using http yeah so then rest no like http address they are not synonyms right so what rpc says is rpc anyway it's an ad then it's a network call right two services or two machines talking to each other will happen over a network so rpg can use any protocol that it wants so tcp udp anything but more importantly than that it can use any advanced protocol like any layer 7 protocol like http also it can use http 1 http 2 whatever it wants to use it can use right so there is no restriction it's not that as soon as you are making an http call it has to be a rest no that's what grp basically that's what grpc comes into the basic that's why rpc comes into the widget can use any application level protocol http one http to even web socket who's stopping from implementing this over web sockets it's just a network call right so everything is pretty abstracted out you can use web sockets raw tcp connections anything to do it right but the idea here is rpc runtime would pick its own network or would have its own preference for example grpc says i will only use http 2 as my transport layer grpc will use http i will use http 2 for transport if you would want to write your own gr if you do want to write your own rpc you say that i want to talk to web sockets only you can very well do that no one's stopping you from doing that right that's why we need to understand that the transport is totally separate and uh the way we would want to communicate it's all abstracted out using grpc okay now let's go through the final section of it why are pc right why did this thing suddenly revive itself after 10 years okay so why remote procedure calls you would have seen the core highlight of this is that it's very easy to use because it makes a remote function call just like normal routine local procedure call it gives you this native classes to play with which is generated by your own interface definition so you don't have to write the code again into multiple languages it gives you strong api contract like for example what you typically let let's take an example of rest you wrote a request you uh uh you you filed a request you got a response someone added a new field in the response you need to explicitly handle that why can't this be done automatically through native objects why do you want to like json you got it and you convert it into your native objects and then you use it and then you would want to make the changes there don't don't why do you want to fall into such complications doing that same situation this lesson again and again abstracting it out is the best way to do it so now with rpc what you get is you get very strong api contact you exactly know what you are sending you exactly know what you are getting no matter how many iterations happen you would know what you are signing up for right second is invoking a remote call is just like a local it's just like a local functional call so it boost massive dev productivity you don't have to worry about making a request.post and then you pass the url and then you send it and whatnot it's all abstracted out with the stubs that you generate so it it massively boosts the overall developer productivity and you can actually shift things much faster in a much efficient way third most rbc framework like grpc supports modern languages so for example you define the protofile in sorry you you define an interface definition in your protofile you can create golan code out of it java code out of it c plus plus code out of it not just pick your favorite language like most modern rpc framework supports all modern languages so which means that if you pick an rpc system you can create code for all the languages out there you don't have to write it it's auto generated best part you don't have to do that mundane task of doing this and decelerating again and again it's all auto generated then most mundane tasks are abstracted for example failures retries payload converts into native objects like for example you send json and then it needs to convert it into that native object so that you can use it all of that is abstracted you don't have to worry about it at all right mundane tasks are abstracted and the network protocol is abstracted multiplexing is done you don't have to worry about those stuff anymore it's the rpc system that takes care of it right you get performance out of the box for example compression of payloads you get basically connection pooling because you can have raw pcb connection the service you can do connection pooling gives you massive performance gain you can do multiplexing you can do streaming you can do efficient payload transfer just like comparison you can apply some advanced plus with the format in which it is sent you can very well define a very compressed format like for example protobuf itself is highly compressed format in sending it you get efficiency out of the box then security is just a plug because here with rpc with inter-service communication your security itself can be abstracted for example https based communication over network uh needs to be encrypted evenly though it is inter-service communication you can very easily do that just configure it at your rpc level you don't have to do it on every single http request that you are making here it's all abstracted in this one rpc system and the another big big advantage which is why you would see most of the companies that offer apis or they expose apis they typically expose a good companies expose it in uh rpc format so what they do like they expose http endpoints but behind the scenes they have rpcs so what happens is that you don't need to write client libraries you saw we have proto files proto files create stubs for multiple languages this way if you have a grpc or if you have an rpc server you can just ask or you your client can directly connect with you or can directly talk to this grp uh can talk to this rpc server and with that the profile that you have can generate your client libraries for you for example a great example of that is slacks api slacks api are all rpc they are http endpoints but they are rpc based so you would see they have a very different way of defining endpoints and that is because they are rpc based so now any slack client that you see in golang python java they are all auto generated they don't need to spend time writing the code for that client anytime something changes it's all it's all definition based big advantage and here another solid advantage that you get is multi-language communication for example golang struck java classes they want to talk to each other doing it via common json serializing and decelerating why do we want to put that effort rpc abstracts it out for you massive advantages that you get by using rpc now obviously grass is not always green what are the concerns while using rpc so stubs needs to be regenerated whenever the signature changes this is one big thing that you always have to think about that when if let's say you defined your protofi with some methods and some members in it you change something now this change needs to be calculated on both the services for example authentication service and motivation service so whenever something changes on the stop everything needs to be redeployed but that is still okay because you don't have a generator who would do that part but still you would have to redeploy your service right was first concern second is testing rpc is non-trivial it's not difficult but it is not intuitive also so writing test suits for rpc it looks simple but you just need to be very of the fact that it is a remote call you might need to test on few edge cases and it's it becomes for a normal developer in a day-to-day life transitioning from rest to rpc might feel a little weird third is getting started is a little challenging because unlike rest where you just start a http server start exposing endpoints with like with basically resource-based endpoints and done with rpc you have to write i uh you have to write an interface definition in a protofile create basically generate the stubs then integrate it and then implement it and all takes some time to do it right and then the fourth one browser support is limited not all browser supports rpc so that's why your javascript server communication will happen over http like it could look uh behind the scene you can implement an rpc server but it would not be a pure rpc communication it will be a normal rest in not rest but normal http function invoked internally it might get converted into rpc and do that part but pure rpc implementation so what imp what benefits you get out of rpc in general you might not see from your uh from your client or from your javascript client or you are from your browser to your server but within server so inter service communication will be seamless when you go for rpc this does not mean you always have to use rpc you have to pick your battles if your expertise do that if you don't then skip it right so yeah that's it for this one i hope you learned something amazing with rpc uh so i found a bunch of uh myths floating around that's why i thought okay let me do a very very clear deep dive on rpc what rpcs are why are they used now you would have a very clear idea about it what i've also done is uh you you can visit my github i very recently created a very simple rpc hello world in golang which implements an advanced calculator i'll just link it it's a very basic code base but you would understand key where the difference lies right and how to basically implement it so what i would highly encourage you to do is i would highly encourage you to implement a hello world in grpc grpc is the most famous one out there just implement a hello but you will understand far more than just going through some theoretical so just write a basic hello world of grpc and see the beauty of it like like you don't like if you have used rest then you use grpc you'll understand how much simple grpc makes obviously uh getting started is a little challenging but it's worth the efforts to be really honest all right chala that's it that's it for this one i hope you guys if you guys like this video i'd rather it's a very intense deep dive but if you guys like this video give this video a massive thumbs up if you guys like the channel give this channel a sub i post three in-depth engineering videos every week and i'll see you in the next one thanks saturn

Channel: Arpit Bhayani

Views: 28,785

Keywords: Arpit Bhayani, Computer Science, Software Engineering, System Design, Interview Preparation, Handling Scale, Asli Engineering, Architecture, Remote Procedure Call, RPC, gRPC, why gRPC, gRPC explained, RPC explained, REST vs RPC, Interservice Communication, Microservices, when to use gRPC, Java RMI, gRPC easy explanation, RPC easy explanation, Advnatages of RPC, Disadvanatges of using RPC, Are RPC efficient?, stubs in RPC, stubs in RPC explained, does RPC use HTTP?

Id: eRndYq8iTio

Length: 33min 4sec (1984 seconds)

Published: Fri May 13 2022