‫Hey, welcome back.
‫In this lecture,
‫we're going to learn about the API Gateway component,
‫which is an architectural building block
‫and design pattern
‫used pretty much by all large scale systems in the industry.
‫But before we talk about what an API Gateway can do for us,
‫let's first understand the problem we're trying to solve.
‫Let's imagine we're building a video sharing
‫and streaming system where users can upload their videos,
‫and also watch and comment on other people's videos.
‫In the beginning,
‫all we have is one service in our system
‫that serves the frontend to the user
‫in a form of HTML and JavaScript,
‫and also takes care of the user profile,
‫channel subscriptions, notifications,
‫video storing and streaming,
‫and comments left for each video.
‫Additionally, this service needs to implement security
‫because if a particular user wants to upload a new video,
‫delete an existing video,
‫or update their profile,
‫we first need to make sure that that user
‫is properly authenticated and authorized
‫to make those changes.
‫Over time, we realized that this one service code base
‫becomes too big and complex for us
‫to develop and maintain,
‫so we apply the organizational scalability principle
‫and split this one service into multiple services.
‫Each one for only one purpose.
‫The consequences of this change
‫are that the single API we originally exposed
‫is now split into multiple APIs
‫implemented by each service.
‫So now, we need to update the frontend code
‫that runs on the client's web browser
‫to be aware of the internal organization
‫of our system,
‫consisting of different services.
‫And make calls to different services
‫depending on the task.
‫For example, when a user wants to simply go to the homepage
‫and see the latest activity on the website,
‫the client code would have to call the Frontend Service
‫and the Users service.
‫And when a user wants to watch a particular video,
‫they would need to also make a call to the Frontend Service
‫to load the different pages.
‫Then call the Video Service to load the actual video,
‫and then call the Comments Service
‫to get all the comments that other users left
‫on that particular video.
‫Now, because we split our system
‫into multiple services
‫and the client application code
‫makes separate calls to each service,
‫each service needs to reimplement its own security,
‫authentication, and authorization,
‫which adds a lot of performance overhead and duplication.
‫So to eliminate all those redundancies,
‫decouple the client application
‫from the internal organization of our system,
‫and simplify our external API,
‫we add an additional abstraction
‫in a form of a service called API Gateway.
‫An API Gateway is an API management service
‫that sits in between the client
‫and the collection of backend services.
‫The API Gateway follows a software
‫architectural pattern called API composition.
‫In this pattern,
‫we compose all the different APIs of our services
‫that we want to expose externally into one single API
‫the client applications can call by sending a requests
‫to only one single service.
‫The API Gateway creates an abstraction
‫between the client and the rest of our system
‫that provides us with a lot of benefits.
‫The first benefit of the API Gateway
‫is that it allows us to make internal changes
‫to our system completely seamlessly and transparently
‫to our API consumers.
‫For example, if we have both desktop and mobile users,
‫at some point,
‫we may want to split our Frontend Service
‫into two different services
‫that serve different data depending on the device
‫the request originated from.
‫And similarly, we can split our video streaming service
‫into two separate services.
‫One for high resolution video,
‫optimized for desktops,
‫and another for lower resolutions,
‫optimized for mobile devices.
‫The second benefit of having an API Gateway
‫in the front door to our system,
‫is we can consolidate all the security,
‫authorization, and authentication
‫in one single place.
‫So if we have a malicious user
‫trying to impersonate another user,
‫we can stop their request at the API Gateway.
‫While a real user can be successfully authenticated
‫at the API Gateway
‫where we can perform an SSL termination
‫and forward the decrypted request
‫to the rest of the services.
‫Additionally, we can allow a user
‫to perform different operations
‫depending on his permissions and role.
‫A few examples of such operations
‫that we can allow to some users
‫and disallow to other users
‫include viewing private videos,
‫deleting, or uploading new videos, and so on.
‫As part of the security feature,
‫we can also implement rate limiting at the API Gateway
‫to block denial of service attacks from malicious users.
‫Now, another benefit of the API Gateway
‫is it can improve the performance of our system.
‫Besides the fact that we save a lot of overhead
‫of authenticating every request from the user
‫at each service
‫by performing all the security and authentication
‫in a single place,
‫we can also save the user from making multiple requests
‫to different services.
‫This feature is called request routing.
‫For example, when a user wants to watch a particular movie
‫without the API Gateway,
‫the user would have to make three calls to our system.
‫One, to load the frontend page
‫from the Frontend Service,
‫then, load the video from the Video Service,
‫and then make another call to the Comments Service
‫to load all the comments that other users left
‫for that particular video.
‫By having the API Gateway in between the user
‫and our services,
‫the client code can make a single call to the API Gateway,
‫which would route the request
‫to all the appropriate services,
‫and aggregate all the responses
‫into one single response.
‫Another way the API Gateway can improve our performance
‫is by caching study content,
‫as well as responses to certain requests.
‫This, of course, reduces the response time to the user
‫because if we already have the cached responses
‫for particular requests,
‫we can return it immediately from the API Gateway
‫without the need to make requests to the different services.
‫Another added benefit we get from routing all the traffic
‫through one single service is monitoring and alerting.
‫By adding monitoring logic
‫into our API Gateway,
‫we can gain real-time visibility
‫into the traffic pattern
‫and the load on our system.
‫This also allows us to create alerts
‫in case the traffic suddenly drops
‫or increases unexpectedly.
‫This feature helps us
‫in improving our system's observability and availability.
‫Finally, the API Gateway
‫allows us to perform protocol translation
‫in one single place.
‫For example, externally, we can expose a rest API
‫that uses JSON to represent different objects.
‫But internally, some of our services
‫may use different RPC technologies or different formats
‫to represent their objects.
‫At the same time, we may even have
‫some legacy services
‫that support all their protocols like HTTP 1
‫and represent their objects using XML.
‫Now, on the other hand,
‫externally, we may also integrate with other systems
‫that may bring us additional revenue.
‫For example, we may integrate
‫with a digital advertising company
‫that may want to run ads on our videos.
‫Or maybe another system
‫wants to host their videos on our platform,
‫and simply request them on demand
‫to embed them on their webpages.
‫All those companies may already have systems
‫that support only particular protocols,
‫and they may be reluctant
‫to make big changes to their system
‫to support our API's protocols and formats.
‫In this case,
‫we can simply extend our API
‫to support their protocol and formats
‫at the API Gateway,
‫and perform the appropriate translation
‫to call our services using the existing implementation.
‫So now that we listed all the great benefits
‫of an API Gateway,
‫and mention all the quality attributes
‫that the API Gateway provides us with,
‫such as security, performance, and high availability
‫that we get through monitoring,
‫let's talk about a few best practices and anti-patterns
‫of using this architectural building block.
‫The first important consideration
‫in using this design pattern
‫is making sure that our API Gateway
‫doesn't contain any business logic.
‫While security caching and monitoring
‫are nice added features,
‫the main purpose of an API Gateway
‫is API composition and routing of requests
‫to different services.
‫Those services are the ones
‫that make the business decisions,
‫and are performing the actual tasks.
‫If we make the mistake and follow the anti-pattern
‫of adding business logic to our API Gateway,
‫and making it too smart,
‫we may end up again with a single service
‫that does all the work
‫and contains an unmanageable amount of code.
‫Which is actually the problem we wanted to solve initially
‫by splitting our system into multiple services.
‫The next thing to consider
‫is since all the traffic to our system
‫now goes through the API Gateway,
‫our API Gateway may become a Single Point of Failure.
‫We can easily solve the scalability,
‫availability, and performance aspect
‫by simply deploying multiple instances
‫of our API Gateway service,
‫and placing them all behind a load balancer.
‫But another thing to consider
‫is if we push a bad release
‫or we introduce a bug
‫that may crush our API Gateway service,
‫our entire system becomes unavailable to the clients.
‫So we need to be extra careful
‫to eliminate any possibility of human error,
‫and deploy new releases to the API Gateway service
‫with extreme caution.
‫Now, finally, we do need to acknowledge
‫that adding an additional service
‫that our client needs to go through
‫any time a request is sent to our system
‫does add a little bit of performance overhead.
‫Now, while overall,
‫by having an API Gateway,
‫we typically benefit more
‫than we sacrifice in terms of performance.
‫But in certain situations,
‫we may be tempted to over-optimize
‫and bypass the API Gateway.
‫But this is an anti-pattern that we should try to avoid.
‫For example, in the case
‫that the user service team
‫wants to make a change in their API.
‫If they know that the only service
‫that calls them externally is the API Gateway,
‫they can simply make the changes in the API Gateway service,
‫and then safely release their new changes.
‫However, if other external clients
‫can call the service directly,
‫then the Users Service team
‫will have to be a lot more cautious and slower
‫in releasing those changes.
‫This is because they will have to go
‫and update each client's code
‫before they can release their change.
‫This, again, tightly couples the service
‫to external client's code,
‫which is the problem we solve
‫by using the API Gateway to begin with.
‫So now that we know all the do's and don'ts
‫of using an API Gateway in our system,
‫let's summarize what we learned in this lecture.
‫In this lecture,
‫we learned about a very important
‫architectural building block and design pattern
‫of large scale systems.
‫We'll learn about some of the benefits of an API Gateway,
‫such as API composition, security,
‫caching, monitoring, and so on.
‫And finally, we talked about a few considerations
‫for correctly using an API Gateway.
‫Those considerations were keeping the business logic
‫out of the API Gateway,
‫being extra careful,
‫and making modifications to the API Gateway.
‫And finally, not breaking
‫the API Gateway abstraction externally.
‫I hope you already learned a lot so far,
‫so I will see you soon in the next lecture.