1
00:00:00,130 --> 00:00:02,480
<v Instructor>So let's talk about API Gateway.</v>

2
00:00:02,480 --> 00:00:04,720
API Gateway is a way for us to

3
00:00:04,720 --> 00:00:07,080
build, deploy, and manage APIs,

4
00:00:07,080 --> 00:00:10,370
and APIs are interfaces we can expose

5
00:00:10,370 --> 00:00:13,100
to other people within our company

6
00:00:13,100 --> 00:00:15,200
or in the outside world.

7
00:00:15,200 --> 00:00:17,400
So the goal of this whole serverless thing

8
00:00:17,400 --> 00:00:19,600
really is to deploy APIs

9
00:00:19,600 --> 00:00:22,060
and so we've seen from before that

10
00:00:22,060 --> 00:00:24,740
we have AWS Lambda as a compute source

11
00:00:24,740 --> 00:00:26,460
that can automatically scale,

12
00:00:26,460 --> 00:00:27,330
that is serverless,

13
00:00:27,330 --> 00:00:29,470
and that runs function as a service,

14
00:00:29,470 --> 00:00:32,000
but we also saw in the past section

15
00:00:32,000 --> 00:00:35,840
that we can use DynamoDB as a serverless database,

16
00:00:35,840 --> 00:00:38,560
provision tables, and interact directly

17
00:00:38,560 --> 00:00:40,590
with AWS Lambda, for example,

18
00:00:40,590 --> 00:00:44,170
to do operations such as create, read, update, and delete.

19
00:00:44,170 --> 00:00:45,675
So we have a computing side

20
00:00:45,675 --> 00:00:48,360
and we have a serverless database side.

21
00:00:48,360 --> 00:00:50,600
Now, how about the clients?

22
00:00:50,600 --> 00:00:52,770
Well the clients needs to interface

23
00:00:52,770 --> 00:00:55,720
and with our Lambda and our DynamoDB

24
00:00:55,720 --> 00:00:58,240
and the client is our application.

25
00:00:58,240 --> 00:01:00,730
I would love to have is something in between

26
00:01:00,730 --> 00:01:03,410
and that something is Amazon API Gateway

27
00:01:03,410 --> 00:01:06,780
that will take the client request as REST API

28
00:01:06,780 --> 00:01:09,030
and then translate those and pass them on

29
00:01:09,030 --> 00:01:10,710
to the Lambda functions.

30
00:01:10,710 --> 00:01:13,050
The reason we have an API Gateway is

31
00:01:13,050 --> 00:01:14,850
that we can have more control over

32
00:01:14,850 --> 00:01:16,810
what the client can and cannot do

33
00:01:16,810 --> 00:01:19,200
and we can defer to business logic

34
00:01:19,200 --> 00:01:23,600
in how these requests should be handled to AWS Lambda.

35
00:01:23,600 --> 00:01:25,250
So overall, it makes sense.

36
00:01:25,250 --> 00:01:28,860
API Gateway is going to have an integration

37
00:01:28,860 --> 00:01:31,450
with Amazon Lambda and overall that gives you

38
00:01:31,450 --> 00:01:32,680
no infrastructure to manage

39
00:01:32,680 --> 00:01:36,299
and that gives you a serverless REST API.

40
00:01:36,299 --> 00:01:38,750
AWS API Gateway is great because

41
00:01:38,750 --> 00:01:40,210
you can handle versioning.

42
00:01:40,210 --> 00:01:43,560
So if your API evolves from v1 to v2

43
00:01:43,560 --> 00:01:45,820
you can do that with API Gateway.

44
00:01:45,820 --> 00:01:48,320
You can also handle different environments.

45
00:01:48,320 --> 00:01:50,640
So if we have dev environment, test environment,

46
00:01:50,640 --> 00:01:53,080
prod environment, all of these can exist

47
00:01:53,080 --> 00:01:56,310
in our API Gateway and we can manage deployments.

48
00:01:56,310 --> 00:01:58,760
API Gateway will also have tight integration

49
00:01:58,760 --> 00:01:59,750
with security.

50
00:01:59,750 --> 00:02:01,890
So we can remove the security concerns

51
00:02:01,890 --> 00:02:03,609
out of our AWS Lambda function

52
00:02:03,609 --> 00:02:06,670
and have them taken all the way through

53
00:02:06,670 --> 00:02:08,170
to the API Gateway

54
00:02:08,170 --> 00:02:09,870
and we'll see in great details

55
00:02:09,870 --> 00:02:11,752
how the API Gateway integrates security

56
00:02:11,752 --> 00:02:13,730
with other components.

57
00:02:13,730 --> 00:02:15,710
API Gateway is great because also we can create

58
00:02:15,710 --> 00:02:18,006
API keys, and we can handle request throttling

59
00:02:18,006 --> 00:02:20,720
if we're selling our API to people,

60
00:02:20,720 --> 00:02:22,789
and it has a very tight and neat integration

61
00:02:22,789 --> 00:02:25,180
with something called Swagger/Open API,

62
00:02:25,180 --> 00:02:28,000
and that allows us to import some files,

63
00:02:28,000 --> 00:02:29,320
and define quickly our APIs,

64
00:02:29,320 --> 00:02:32,762
and even export them as SDKs for example.

65
00:02:32,762 --> 00:02:35,400
API Gateway can also help us transform

66
00:02:35,400 --> 00:02:37,411
and validate requests and responses,

67
00:02:37,411 --> 00:02:41,910
and, as I said, generate SDK and API specification.

68
00:02:41,910 --> 00:02:44,600
Finally, it also has an embedded caching layer

69
00:02:44,600 --> 00:02:46,640
you can implement so you can cache

70
00:02:46,640 --> 00:02:50,390
your API responses and limit the load that happens

71
00:02:50,390 --> 00:02:52,420
on your Lambda function.

72
00:02:52,420 --> 00:02:54,760
In terms of API Gateway integration,

73
00:02:54,760 --> 00:02:56,210
it has a lot of them.

74
00:02:56,210 --> 00:02:57,810
You have to separate them between

75
00:02:57,810 --> 00:03:00,310
outside your VPC and inside your VPC.

76
00:03:00,310 --> 00:03:01,559
So outside your VPC you can run

77
00:03:01,559 --> 00:03:02,820
AWS Lambda function,

78
00:03:02,820 --> 00:03:04,810
and that's, by the way, the most popular and powerful

79
00:03:04,810 --> 00:03:06,170
type of combination,

80
00:03:06,170 --> 00:03:09,330
but also EC2 instances, load balancers,

81
00:03:09,330 --> 00:03:11,810
any AWS service, as a matter of fact,

82
00:03:11,810 --> 00:03:14,395
and you can even proxy the request

83
00:03:14,395 --> 00:03:18,320
from API Gateway all the way to a HTTP endpoint

84
00:03:18,320 --> 00:03:19,280
that you may control.

85
00:03:19,280 --> 00:03:24,280
You can have a front layer to your existing HTTP APIs.

86
00:03:24,690 --> 00:03:27,040
Now inside of VPC you can enable, again,

87
00:03:27,040 --> 00:03:28,910
Lambda integration when Lambda is the pod

88
00:03:28,910 --> 00:03:30,130
within your PC,

89
00:03:30,130 --> 00:03:32,860
and also EC2 endpoints in your VPC.

90
00:03:32,860 --> 00:03:35,230
So that's it for the API Gateway integrations

91
00:03:35,230 --> 00:03:36,490
and a quick overview.

92
00:03:36,490 --> 00:03:39,270
I think API Gateway overall is a huge service

93
00:03:39,270 --> 00:03:40,620
and very complicated to learn

94
00:03:40,620 --> 00:03:43,330
and master overall so this is going to be an overview,

95
00:03:43,330 --> 00:03:45,370
but in the next lecture I wanted to go straight on,

96
00:03:45,370 --> 00:03:48,370
hands on, so we can get an idea of how API Gateway works,

97
00:03:48,370 --> 00:03:49,620
'cause it probably will be much clearer

98
00:03:49,620 --> 00:03:51,230
than a bunch of text on slides.

99
00:03:51,230 --> 00:03:52,780
So see you in the next lecture.

