‫Welcome to another lecture.
‫In this lecture we're going to learn about
‫the first type of API
‫which is commonly referred to as Remote Procedure Calls
‫or RPC in short.
‫We're first going to learn what it is and how it works,
‫and later we'll talk about its benefits, its drawbacks
‫and when to prefer this style of API over the others.
‫So what is an RPC?
‫A Remote Procedure Call is the ability
‫of a client application to execute a sub routine
‫on a remote server.
‫However, what's unique about this type of API
‫is that this remote method invocation
‫looks and feels like calling a normal local method,
‫in terms of the code that the developer needs to write.
‫This unique feature of an RPC is also commonly referred to
‫as local transparency.
‫As in the eyes of the developer
‫of the client application, a method executed locally
‫or remotely look almost exactly the same.
‫Another feature that usually comes with most
‫but not all RPC framework implementations is support
‫for multiple programming languages,
‫so that applications
‫written in different programming languages
‫can seemingly talk to each other using RPC.
‫The way an RPC works is as follows,
‫the API as well as the data types
‫that are used in the API methods
‫are declared using a special interface description language,
‫which varies between different
‫RPC framework implementations.
‫This is essentially a schema definition
‫of the communication between a remote client and the server
‫which is part of our system.
‫The value of defining the interface and the data types
‫using the specialized language
‫is once we have this interface definition,
‫we can use a special compiler or a code generation tool
‫which is part of the RPC framework
‫to generate two separate implementations of the API method.
‫One for the server application,
‫and one for the client application.
‫The server side implementation of the RPC method
‫is called the server stub,
‫and the auto generated implementation
‫on the client application side is called the client stub.
‫Those stubs take care of all the implementation details
‫of the remote procedure invocation.
‫Additionally, all the custom object types
‫that we declare using the interface description language
‫are compiled into classes or structs,
‫depending on the programming language.
‫Those auto generated object types,
‫are also commonly referred to
‫as Data Transfer Objects or DTOs in short.
‫Now at run time, whenever the client application calls
‫that particular RPC method with some set of parameters
‫the client stub takes care of then coding of the data
‫which is also commonly referred to
‫as serialization or marshalling.
‫After then coding it initiates the connection
‫to the remote server application
‫and sends the data over to the remote server stub.
‫On the other end, the server stub
‫for that particular RPC method is listening
‫to the client applications messages,
‫and when a message is received, the data is deserialized
‫and then the real implementation of the method
‫is invoked on the server application.
‫Once the server completes the operation
‫the result is then passed back to the server stub
‫which in turn serializes the response
‫and sends it back over to the client application.
‫Finally, the client stub for that particular method
‫receives the encoded response, deserializes it
‫and gives it back to the caller as the return value
‫for what looks like a local method invocation.
‫This concept of implementing an API using an RPC
‫has been around for decades
‫and the only thing that changes over time are the frameworks
‫the details of their implementation and their efficiency.
‫So our job as API developers
‫is to pick an appropriate framework
‫define the API as well as the relevant data types
‫using the frameworks interface description language
‫and publish that description.
‫At this point the client which uses our system
‫and the server which is part of our system
‫are completely decoupled.
‫When we finish designing and implementing our system
‫we can generate that stub for the server,
‫and when a new client wants to integrate with us
‫and make API calls to us, all they have to do
‫is use the publicly available frameworks tools
‫to generate their client's stub
‫based on the API definition that we published earlier.
‫Furthermore, if we pick an RPC framework
‫that supports multiple programming languages
‫then we don't limit ourselves
‫to the choice of programming language for the server side.
‫And we allow the client
‫to pick their favorite programming language,
‫to communicate with our system.
‫Now, let's talk about the benefits
‫and some of the drawbacks of picking this style of API.
‫The first benefit is of course the convenience,
‫we provide to the developers of the client applications.
‫Once they generate their stub,
‫they can communicate with our system easily
‫by simply calling methods on objects
‫which look and feel exactly
‫like calling normal local methods.
‫And all the details of how the communication is established
‫or how the data is passed between the client to the server
‫are entirely abstracted away from the developers.
‫Also any failures in the communication with the server
‫simply result in either an error or exception,
‫depending on the programming language
‫just like in the case of any normal method.
‫Now let's talk about the drawbacks of RPC.
‫The main drawback of using an RPC style
‫is unlike local methods executed on the client side,
‫those remote methods are a lot slower
‫and a lot less reliable.
‫The slowness may introduce surprising performance
‫bottlenecks because the client never knows
‫how long those remote method in vocations,
‫can actually we take.
‫However, on the surface code wise
‫they look very much like local methods
‫which are generally fast.
‫So as API designers,
‫we need to help the client application developers
‫avoid blocking their code execution
‫when we introduce methods that we know are going to be slow
‫on our end.
‫The way to do it
‫is by introducing asynchronous versions
‫for those slow methods, which is not surprisingly
‫is one of the best practices for those situations
‫that we learned in the previous lecture.
‫Now, the unreliability stems from the fact that the client
‫is located remotely running on a computer
‫that potentially belongs to a different company
‫and is using the network to communicate
‫with a server in our system.
‫So if we're not careful in designing the API
‫we can introduce some very confusing situations
‫for the client application developers.
‫For example, if we're a credit card company
‫and the client is running an online store
‫and is trying to call the debit account method
‫which is part of our API,
‫a failure or an exception in calling such a method
‫can leave them with a dilemma
‫of whether they should retry calling the method
‫and running the risk of charging the user twice
‫or not retrying it and running the risk
‫of not charging the user at all.
‫That of course comes from the fact
‫that there is no real way for the client
‫to know whether the server on our system
‫received the message and the acknowledgement message
‫simply got lost in the network
‫or the server in our system simply crashed
‫and never received the message.
‫Now, although we can't really solve
‫the unreliability problem we can mitigate the issue
‫by sticking to one of the other best practices
‫we learned in the previous lecture,
‫which is making our operations idempotent when possible.
‫Now let's talk about when we should prefer the RPC style
‫for defining our API
‫and when we should take a different approach.
‫Remote Procedure Calls are very commonly used
‫in communication between two backend systems.
‫And although there are frameworks that support RPC calls
‫from frontend clients like the web browser
‫they are usually less common.
‫So in summary, the RPC style is a perfect choice for an API,
‫we provide to a different company
‫instead of an end user app or webpage.
‫And it's also great choice
‫for communication between different components internally
‫within a large scale system.
‫The RPC API style is also a good choice
‫for situations when we want to completely
‫abstract the way the network communication
‫and focus only on the actions the client wants to perform
‫on the server system.
‫This isn't always the case for all types of APIs.
‫So in cases where we don't want
‫to abstract the network communication away,
‫and we do want to take direct advantage
‫of things like HTTP cookies or headers
‫using the RPC approach would not be a good fit
‫and there are other styles that would be a better match
‫for this use case.
‫Finally, the RPC revolves more around actions
‫and less around data or resources.
‫The way it manifests itself in the style
‫is that every action is simply a new method
‫with a different name and a different signature.
‫And we can easily define as many methods
‫or actions as we want almost without limitation.
‫However, if we are designing an API
‫that is more data centric
‫and all the operations we need are simple crowd operations
‫then there are other styles of APIs
‫that can be a much better fit for this type of scenario.
‫We're going to talk about one of those styles
‫in the following lecture.
‫In this lecture, we talked about the first type of API,
‫the Remote Procedure Call.
‫We mentioned the three components of the RPC style,
‫which is the API definition
‫typically done using the interface description language,
‫the client stub, and the server stub.
‫We also talked about some of the benefits of RPCs
‫which include local transparency
‫and full abstraction of network communication.
‫And finally, we mentioned some of the drawbacks of RPCs
‫which include slowness and unreliability.
‫Those drawbacks can be mitigated
‫by applying the best practices we learned
‫in a previous lecture.
‫I will see you guys in the next lecture.