- Now let's review an introduction to Amazon API Gateway.
With Amazon API Gateway, we get a fully-managed service
for creating, publishing, deploying,
and running APIs at any scale.
The service itself will automatically scale
to support the level of requests that are passing through,
and so an API Gateway essentially acts
as a front door to backend services.
We can centrally manage a number of things
at the gateway rather than duplicating
those efforts across various backend services.
And so API Gateway does support Rest and WebSocket APIs.
All we have to do is, within the API Gateway,
we define our resources
and we define methods for those resources
and then we define what backend service
will handle that method.
Now our backend applications can run just about anywhere,
including but not limited to EC2, ECS, Lambda, and so on.
So we have a lot of flexibility, a lot of choices
to where we actually put our backend services,
and in fact, it could be that we have different services
running in different places for different reasons.
And so API Gateway also gives us a number of tools
to centrally manage things like traffic management,
rate limiting, for example.
We also get tools to perform
authentication and authorization.
We could leverage something like Amazon Cognito
if we wanted our users to log in with Facebook,
login with Twitter, and Google, and so on.
We could also write out own custom
authentication and authorization methods in Lambda.
We also have built-in caching
so we don't necessarily need to set-up
a separate cache somewhere else.
We can leverage built-in caching through
the API Gateway service itself.
And then we also have the ability to use API Gateway
as a proxy to other AWS services
such as S3 or Kinesis and more.
So let's take a look at a diagram here.
You'll see that all we have to do is, again,
through the API Gateway service we create a gateway,
and then once we have that gateway,
we simply define, within that,
we simply define our resources
and the various methods underneath those resources.
Right?
And so once we define those, we then define
the various backend services that will handle those methods.
And again, those could be handled by applications
running directly on EC2, and those would be
behind a load balancer.
We could have applications running in Lambda
or functions within Lambda.
So, a pattern here could be that you have
particular resources and methods
that are then passed on to Lambda.
Now, remember that Lambda gives us the ability
to create functions, and we call them functions for a reason
because functions do, each function will do one thing,
one specific kind of work.
Now, technically it would be possible for you
to create one function that handles all of the methods
for a particular resource, but in my experience,
doing that kind of thing actually becomes hard to maintain.
What's more likely that you would do
is create a Lambda function per method, right.
So you imagine all of the restful API methods
that would exist on any particular resource,
you would create a Lambda function
for each one of those methods.
And then we could also use containers
running within Amazon ECS or EKS,
and so again, those containers would also, in that case,
be behind some type of elastic load balancer.
And so these, all of this here,
would be our applications, right.
We would be running our applications,
our custom code, on one of these services,
and like I mentioned earlier,
we can also use API Gateway to act
as a proxy for other services like S3.
We could API Gateway to act as a proxy for Kinesis and more.
We're not limited to those two.
There are other services that we could wire in.
And so the benefit of using an API Gateway
is that we can centralize common things.
Again, we may have each one of these services may require
some type of authentication and authorization,
and we can centralize that here at the API Gateway.
We might want to perform request tracing
and access request logging.
We may want to perform some type of caching,
and so again, a number of things
that we can centralize at the gateway itself.
So if you are planning to build a restful API,
if you are looking to migrate APIs into AWS,
or what I've seen is organizations who are building
new microservices while still relying on legacy monoliths.
And so it could be that you put both of those together
behind one API Gateway, and then as time goes on,
you swap out the monolith for microservices
and then your end users are never the wiser
because they always hit the same end point, right.
So if you're thinking about those kinds of things,
I would highly recommend that you
take a look at Amazon API Gateway.