Narrator: So we have our API right here and
for now it has two GETs and there is one little resource
right here and so what we want to do
is deploy this API to my stages.
So let's go back to resources and will do Action deploy API.
Now when we deploy an API, we have to choose a stage
and currently we don't have any stages
so we'll choose a new stage.
This stage name is going to be, for example DEV,
and stage description dev stage.
I'll just have it lower case.
Okay, and deployment description will say:
first deployment to dev.
Here we go, we deploy our code.
So now our code is now in stage and so our whole API
is under this DEV little boat right here; and so we can see
the exact same resources as we had from before,
except this time we have an URL
that we can use to invoke our stage.
So let's click on it and as we can see now,
using this URL /DEV because we are in the DEV stage,
we have a response from a Lambdai function,
statusCode 200, body Hello from Lambdai.
Amazing but what if we go to /houses,
then we get a different response
status 200, body we have beautiful houses.
So we have built and deployed a API already, a rest API.
That doesn't seem like much but we actually did a lot
and all of this is server-less.
My Lambdai functions are being invoked
as I go to different path.
Now in this deployment stage, as you can see,
we have a lot of different options.
So we will not go over all of them,
but you can have a cache, you can throttle some methods,
we'll see this later on.
We can enable logs and tracing,
so we can have CloudWatch logs, etc.
Stage variables is what I have been hammering you with,
so here we can say add a stage variable.
Alias for example, and add the value being dev.
So we know that if we use this alias variable
in our resources now we'll be able to have
like decisions and point it to the right lender function
and this is just an example to illustrate.
We could generate an SDK for Android, JavaScript, IOS, etc.
We could export our API as Swagger and so on,
or Postman Extension, or API Gateway Extension,
so we have a lot of different options
and we can use Swagger Open API3.
We can get a history of the deployments,
so as we change the resources back there
and re-devoid to the stage dev then we'll get an idea
of all the deployments that happen
and we can roll back at any time
to an earlier deployment if something went wrong.
Documentation history if we wanted to provide
documentation for API and Canary
to do this testing I told you about.
When we have, for example, 95% of our traffic
going to one API version and the other one
5% to go to the other API version and you can control this.
Obviously, if you go to your resources
you could deploy your API one more time
and we could create a new stage
and call this stage prod and this is prod API
and here deployment to prod whatever I want to say it
and I deploy and now we have two stages
and our production API can be invoked using this URL.
As we can see can get the same results as before
because we deployed the exact same API
but now we have the /prod, so we can go
to /prod/houses and get another response.
So this is it for our API, here we have deployed two stages
and we could really expand with Stage Variables
if we wanted to but for now we'll just have conceptually
the understanding that Stage Variables will allow us
to marginalize our deployment and customize
what our API gateway does.
So that's it for this lecture, I hope you liked it,
I hope that stages make sense now
and I will see you in the next lecture.