0
1
00:00:02,920 --> 00:00:09,080
Welcome back to BackSpace Academy. In
this lecture on the API gateway I'm
1

2
00:00:09,080 --> 00:00:14,299
going to keep it quite brief insofar as the
theory behind all this and the reason
2

3
00:00:14,299 --> 00:00:19,970
being is that the the AWS associate
level certification doesn't require too
3

4
00:00:19,970 --> 00:00:22,849
much knowledge of the API gateway but
you need to understand how it all works
4

5
00:00:22,849 --> 00:00:27,170
and so the best way to do that is to get
in get your hands dirty and start using
5

6
00:00:27,170 --> 00:00:34,640
it for some examples. So the AWS API
gateway it acts as a secure front door
6

7
00:00:34,640 --> 00:00:40,129
for our applications to access data
business logic or functionality from our
7

8
00:00:40,129 --> 00:00:46,340
back-end services. Its serverless, it creates
a simple flexible fully managed
8

9
00:00:46,340 --> 00:00:50,960
pay-as-you-go service that handles all
aspects of creating and operating a
9

10
00:00:50,960 --> 00:00:57,309
robust API or application programming
interface for our application backends
10

11
00:00:57,309 --> 00:01:02,199
so how does this look from a simple
example perspective, so I've got a
11

12
00:01:02,199 --> 00:01:08,000
typical example of an architecture where
you would use the Amazon gateway and you
12

13
00:01:08,000 --> 00:01:13,070
would use it to access data in for
example an RDS instance so some sort of
13

14
00:01:13,070 --> 00:01:16,759
data source, it could be an RDS instance,
it could be Amazon s3, it could be
14

15
00:01:16,759 --> 00:01:21,320
whatever but you want to access that and
you want to access it through an
15

16
00:01:21,320 --> 00:01:27,079
application programming interface, so
what we can do is that we can have a
16

17
00:01:27,079 --> 00:01:32,329
lambda function between the Amazon API
gateway and our data source and so the
17

18
00:01:32,329 --> 00:01:38,509
Amazon API gateway, that will trigger when
it receives a request for information 
18

19
00:01:38,509 --> 00:01:43,939
or requests for data it will
trigger that lambda function and that
19

20
00:01:43,939 --> 00:01:47,659
lambda function will go to the data
source and it will retrieve that data
20

21
00:01:47,659 --> 00:01:55,880
and then for that data on to the API
gateway, now how do we manage requests
21

22
00:01:55,880 --> 00:01:59,329
and how do we make that fit in with
route 53 and cloud front and all this
22

23
00:01:59,329 --> 00:02:07,460
stuff that we we love to use, we can use
route 53 to set up a domain for our API
23

24
00:02:07,460 --> 00:02:11,900
and so for example there, we could have a
API on example.com as our domain name
24

25
00:02:11,900 --> 00:02:21,260
for our API, so requests coming in
will be in the format of a HTTP request.
25

26
00:02:21,260 --> 00:02:25,099
That could be a get request or a post
request
26

27
00:02:25,099 --> 00:02:30,439
it could be a put, delete, now don't worry
too much if you don't understand what
27

28
00:02:30,439 --> 00:02:33,829
I'm talking about as such now, developers
will definitely understand what I'm
28

29
00:02:33,829 --> 00:02:37,129
talking about
but architects you're probably going to
29

30
00:02:37,129 --> 00:02:42,200
get lost here but just understand that a
get request will be getting data, 
30

31
00:02:42,200 --> 00:02:46,849
it would be getting information from that
data source, a post requests or a put
31

32
00:02:46,849 --> 00:02:53,030
request or a delete request, that will be
changing that data generally and so 
32

33
00:02:53,030 --> 00:02:56,659
you might be writing to that data
you might be deleting and entering that
33

34
00:02:56,659 --> 00:03:02,629
data, and also we have get requests with
a query parameter and they look like get
34

35
00:03:02,629 --> 00:03:09,590
with a question mark and then the query
parameter after those. Now with post and
35

36
00:03:09,590 --> 00:03:16,060
get requests with a query parameter
CloudFront by default bypasses those
36

37
00:03:16,060 --> 00:03:20,599
completely, it doesn't go to a cloud
front distribution because it identifies
37

38
00:03:20,599 --> 00:03:27,260
those as being dynamic data and then it
shouldn't be playing with. On the other
38

39
00:03:27,260 --> 00:03:30,440
side of it we've got general get
requests and they're just getting
39

40
00:03:30,440 --> 00:03:37,239
information from our data source and so
a get request will come in to route 53
40

41
00:03:37,239 --> 00:03:42,440
into our cloud front edge location and
then it will be forwarded straight down
41

42
00:03:42,440 --> 00:03:47,569
through our cloud front distribution, if
our cloud front distribution has that
42

43
00:03:47,569 --> 00:03:52,699
information or that data, it will send it
back to through to route 53 to our end
43

44
00:03:52,699 --> 00:03:58,519
user, if it doesn't it will then go to
the API gateway to get that information
44

45
00:03:58,519 --> 00:04:02,449
which will then go and trigger that
Lander function to get that information
45

46
00:04:02,449 --> 00:04:09,040
from our data source over here in our
RDS instance if it is a post or a
46

47
00:04:09,040 --> 00:04:15,620
get I put or delete request we get
requests with a query parameter not a
47

48
00:04:15,620 --> 00:04:21,650
general get request that will be
bypassed from the CloudFront distribution
48

49
00:04:21,650 --> 00:04:26,029
and will go directly to the Amazon API
gateway and again from there the lambda
49

50
00:04:26,029 --> 00:04:29,210
the function will kick in, it will
retrieve that data and it will be sent
50

51
00:04:29,210 --> 00:04:32,780
back through
to route 53 back to our
51

52
00:04:32,780 --> 00:04:37,160
end-user. The advantage of all this is
that we are going to get the best of
52

53
00:04:37,160 --> 00:04:40,880
both worlds we're going to get high
speed low latency response from our
53

54
00:04:40,880 --> 00:04:45,920
cloud front distribution for our get
requests our dynamically updating data
54

55
00:04:45,920 --> 00:04:50,060
that will be coming from our get request
with a question mark and a query
55

56
00:04:50,060 --> 00:04:54,170
parameter those will go directly to our
Amazon gateway and they will not be
56

57
00:04:54,170 --> 00:04:58,660
affected by the CloudFront distribution,
the same with post put and delete requests,
57

58
00:04:58,660 --> 00:05:03,020
so that's going to give us the best of
both World's there and at the same time
58

59
00:05:03,020 --> 00:05:10,370
our API is only transferring the minimum
that it needs to. So these HTTP requests
59

60
00:05:10,370 --> 00:05:13,970
that are coming in are very small
they're not web pages that contain images
60

61
00:05:13,970 --> 00:05:19,790
and all sorts of stuff they are just
simply a query as to what we want to get
61

62
00:05:19,790 --> 00:05:23,120
and then what is returned is the data
and nothing else
62

63
00:05:23,120 --> 00:05:27,470
and so that's how you create really high
speed access to your data for your
63

64
00:05:27,470 --> 00:05:35,570
applications. The AWS gateway is a great
service for developers and I'd strongly
64

65
00:05:35,570 --> 00:05:39,800
recommend that although you don't need
to know a lot about it please
65

66
00:05:39,800 --> 00:05:43,430
concentrate on the next two labs because
I think that outside of just getting a
66

67
00:05:43,430 --> 00:05:47,360
certification this is one of those
services where you could really take
67

68
00:05:47,360 --> 00:05:52,310
advantage of in your own applications
outside of getting a certification
68

69
00:05:52,310 --> 00:05:55,790
I'll give you an example of this and this is
the example that we're going to go
69

70
00:05:55,790 --> 00:06:00,770
through except without the cloud front
in the final lab. So what I've got here
70

71
00:06:00,770 --> 00:06:04,580
is I've got an Amazon s3 bucket that
I've set up for website hosting and we
71

72
00:06:04,580 --> 00:06:07,820
know all about that, we've done section
two, and I don't need to explain that
72

73
00:06:07,820 --> 00:06:11,870
anymore and again we've got that hosted
with cloud front it's going to give us a
73

74
00:06:11,870 --> 00:06:16,370
really good high speed access to our
website so now where our end-user is
74

75
00:06:16,370 --> 00:06:21,350
going to go to our website and they're
going to get delivered a html5 website
75

76
00:06:21,350 --> 00:06:24,470
with its JavaScript and its CSS and
whatever and that's going to be
76

77
00:06:24,470 --> 00:06:33,350
delivered to our end-users compute
environments. The advantage of doing that
77

78
00:06:33,350 --> 00:06:39,110
is that we are now are taking advantage
of our end-users compute environment we
78

79
00:06:39,110 --> 00:06:44,869
are not we are not paying
to do that for the end user. The end user
79

80
00:06:44,869 --> 00:06:49,490
is using their own resources to do that
computing that is required which is
80

81
00:06:49,490 --> 00:06:57,259
great. So the downside is that that is
going to be a static website and so it's
81

82
00:06:57,259 --> 00:07:01,819
not going to be having a data that is
going to be updated regularly without
82

83
00:07:01,819 --> 00:07:07,849
you know uploading a new website API
gateway can provide that dynamic
83

84
00:07:07,849 --> 00:07:12,229
component of our static websites and
turn our static websites into living
84

85
00:07:12,229 --> 00:07:19,520
dynamic websites. So once our html5 and
JavaScript website is set up and it's
85

86
00:07:19,520 --> 00:07:25,099
and it's running on our clients end on
our clients computer resources that
86

87
00:07:25,099 --> 00:07:32,270
client can then issue HTTP requests to
the API gateway and again if they get
87

88
00:07:32,270 --> 00:07:37,279
requests they will go to a cloud front
service, if they're not, if they're a get
88

89
00:07:37,279 --> 00:07:42,139
with a query parameter or their post or
the're put or delete requests, they will go
89

90
00:07:42,139 --> 00:07:49,240
directly to the Amazon API gateway. So
that provides us with a great way of
90

91
00:07:49,240 --> 00:07:56,599
building really bulletproof high speed
applications with low latency with 
91

92
00:07:56,599 --> 00:08:00,619
very little cost and with very little
effort it's a completely serverless
92

93
00:08:00,619 --> 00:08:04,610
environment. So without any further ado
I'm going to finish it up there and
93

94
00:08:04,610 --> 00:08:10,119
we're going to get stuck into creating
this sort of an application.