1 00:00:00,780 --> 00:00:05,310 In this video, we are going to see how to regulate our lambda functions. 2 00:00:05,340 --> 00:00:09,240 That means you will see a lambda invocation types. 3 00:00:09,810 --> 00:00:15,240 After that, we will map these Lambda Invocation types with our course one developing serverless e-commerce 4 00:00:15,240 --> 00:00:16,020 application. 5 00:00:16,290 --> 00:00:22,950 So a will is Lambda Invocation types will be our serverless journey when developing our service ecommerce 6 00:00:22,950 --> 00:00:23,670 application. 7 00:00:25,400 --> 00:00:29,940 So a lambda function is using everywhere for various use cases. 8 00:00:29,960 --> 00:00:38,060 Sometimes we want to invoke lambda function over HTTP and other times trigger a function based on different 9 00:00:38,060 --> 00:00:38,750 events. 10 00:00:39,630 --> 00:00:45,480 It is extremely useful to understand the different ways that we can invoke lambda function. 11 00:00:46,200 --> 00:00:50,100 Here are three different ways we can invoke lambda functions. 12 00:00:50,760 --> 00:00:54,660 You can see in here a lambda has three invocation types. 13 00:00:55,110 --> 00:00:57,240 Lambda Synchronous Invocation. 14 00:00:57,240 --> 00:00:59,490 Lambda Asynchronous Invocation. 15 00:00:59,580 --> 00:01:03,330 Lambda Event Source Mapping with Pulling Invocation. 16 00:01:05,060 --> 00:01:08,690 So you can all see in location types in one image. 17 00:01:08,840 --> 00:01:15,050 Synchronous invocation is triggered by push model and execute immediately and wait response. 18 00:01:15,080 --> 00:01:17,690 We can say request response model. 19 00:01:18,560 --> 00:01:23,130 Asynchronous invocation is triggered by event model and executes. 20 00:01:23,150 --> 00:01:24,850 Asynchronous don't wait. 21 00:01:24,860 --> 00:01:30,320 Immediate response event source mapping invocation is triggered by pol based. 22 00:01:30,350 --> 00:01:33,950 That means lambda function receive multiple items. 23 00:01:35,560 --> 00:01:39,880 So let's see one by one and explain these types. 24 00:01:40,540 --> 00:01:42,850 Lambda Synchronous invocation. 25 00:01:43,000 --> 00:01:47,560 This is one of the simple Lambda Invocation model in this communication type. 26 00:01:47,590 --> 00:01:53,650 Lambda functions execute immediately when you perform the Lambda Invoke by API call. 27 00:01:53,890 --> 00:02:01,060 So when we perform a Lambda Invoke an API call, we wait for the function to process the function and 28 00:02:01,060 --> 00:02:02,710 return back to the response. 29 00:02:03,130 --> 00:02:08,650 The response data includes the function response and additional data which can be retrieved from the 30 00:02:08,650 --> 00:02:11,580 Dynamo DB or some other resources. 31 00:02:11,770 --> 00:02:13,970 But the idea is we should wait. 32 00:02:13,990 --> 00:02:16,510 A response from the synchronous invocation. 33 00:02:18,160 --> 00:02:25,220 A common scenario for synchronous invocation is the API gateway, Lambda and Dynamo DB integration. 34 00:02:25,240 --> 00:02:30,970 You can see in the Image API, Gateway, Lambda and Dynamo DB that we can perform CRUD operation for 35 00:02:30,970 --> 00:02:35,980 a particular Dynamo DB table with exposing APIs from the API gateway. 36 00:02:36,940 --> 00:02:42,820 The important thing is in here, the invocation type flag should be request response. 37 00:02:43,540 --> 00:02:50,080 This instructs a place to execute our lambda function and wait for the response of function to complete 38 00:02:50,740 --> 00:02:53,230 when we perform the synchronous invocation. 39 00:02:53,440 --> 00:03:00,280 We are responsible for inspecting the response and determining if there was an error like timeout execution 40 00:03:00,280 --> 00:03:02,470 and decide to retry invocation. 41 00:03:03,390 --> 00:03:10,500 We can perform synchronous requests most in location using a CLI SDK and many other options. 42 00:03:11,430 --> 00:03:15,590 You can see an example of synchronous invocation using a double click. 43 00:03:16,080 --> 00:03:21,480 See that we are running the lambda invoke comments on a CLI. 44 00:03:21,870 --> 00:03:28,290 As you can see that when we specify the invocation type like is request response, that means a will 45 00:03:28,560 --> 00:03:34,830 execute our function and wait for the function response in order to complete and return response. 46 00:03:35,250 --> 00:03:41,460 The important part is we are responsible for checking the request, checking the response and determining 47 00:03:41,460 --> 00:03:44,340 whether it is an error or we should try the invoke. 48 00:03:44,610 --> 00:03:50,490 So in this synchronous invocation, we are waiting response and according to this response, we are 49 00:03:50,490 --> 00:03:55,380 checking the response data and it is looking for it is getting error or not. 50 00:03:55,380 --> 00:03:59,370 If it is getting error, we are going to retry the invoke again. 51 00:04:01,080 --> 00:04:06,330 There are many devilish sources that can trigger them to function synchronously here. 52 00:04:06,330 --> 00:04:07,650 Some of them in here. 53 00:04:07,650 --> 00:04:14,070 You can see that application load will answer Amazon, Incognito, Amazon, lakes, Alexa API, Gateway 54 00:04:14,070 --> 00:04:17,970 Cloud, Front Kinesis, data streams and so on. 55 00:04:20,440 --> 00:04:25,300 So now the second invocation type is Lambda Asynchronous invocation. 56 00:04:25,840 --> 00:04:31,690 In this communication type, Lambda function works with the events and invoke by events and not this 57 00:04:31,690 --> 00:04:32,920 mode immediately. 58 00:04:33,580 --> 00:04:37,360 Basically, we can invoke a lot of function asynchronously. 59 00:04:37,540 --> 00:04:45,460 After that, Lambda sends the event an internal queue and returns a success response without any additional 60 00:04:45,460 --> 00:04:46,330 information. 61 00:04:46,900 --> 00:04:53,590 After that, a separate process reads the events from the queue and runs our lambda function. 62 00:04:54,540 --> 00:05:01,440 So you can see a common scenario for asynchronous invocation is the S3 Lambda and Dynamo. 63 00:05:01,450 --> 00:05:12,990 DB You can see in the Image HD or Amazon sense a sense trigger an event and this will be triggered the 64 00:05:13,410 --> 00:05:19,260 Islam the asynchronously and it will Islam the interact with the dynamo DB In the diagram, Amazon S3 65 00:05:19,260 --> 00:05:25,380 will call the Lambda asynchronously when a new object is written into the bucket. 66 00:05:26,010 --> 00:05:30,310 Amazon S3 has several events that can trigger to a lambda. 67 00:05:30,450 --> 00:05:36,260 For example, we can set that a new object is uploading to into bucket. 68 00:05:36,270 --> 00:05:41,640 We can trigger an event today is lambda that is executed lambda function asynchronously. 69 00:05:43,170 --> 00:05:48,690 In order to invoke a function asynchronously, we should set the invocation type parameter to event. 70 00:05:49,020 --> 00:05:56,620 So it is very important you can see an example of the asynchronous invokes using the SLA. 71 00:05:57,060 --> 00:06:03,240 We can see that we are running a double lambda invoke comment and the invocation type is event one. 72 00:06:03,240 --> 00:06:07,200 We specify the invocation type parameter value as event. 73 00:06:07,470 --> 00:06:13,290 If the function failed A the place will automatically retry the invoke device because in asynchronous 74 00:06:13,290 --> 00:06:21,690 communication the lambda is automatically triggered by the triggered invoke by twice when there is an 75 00:06:21,690 --> 00:06:27,630 error by default a double is lambda sets a retry policy for asynchronous invocations. 76 00:06:27,630 --> 00:06:35,160 Your function will be invoked twice if there is an error in order to avoid event losses when using asynchronous 77 00:06:35,160 --> 00:06:42,210 lambda, always attach a dead letter queue on the function in order to save events that weren't successfully 78 00:06:42,210 --> 00:06:42,960 processed. 79 00:06:43,910 --> 00:06:50,750 Here you can list of the services that invoke Lambda function asynchronously as you set that Amazon 80 00:06:50,750 --> 00:06:58,580 S3, Evan SAS is cloud formation, cloud watch logs and events called commit, pull, based, invokes 81 00:06:58,580 --> 00:06:59,300 and so on. 82 00:07:01,510 --> 00:07:07,540 So if you come to the last location type, which is the event source mapping with polling location, 83 00:07:08,140 --> 00:07:14,740 this is the poll based location model allows us to integrate with the wireless streams and queue based 84 00:07:14,740 --> 00:07:15,610 services. 85 00:07:16,300 --> 00:07:20,260 These services don't invoke a lambda function directly. 86 00:07:20,890 --> 00:07:29,620 Lambda will pull from the case or kinesis streams, retrieve records and invoke the functions. 87 00:07:30,590 --> 00:07:37,100 A.W. Islam the event source mapping manage the polar and performs the synchronous inverse of our function. 88 00:07:37,850 --> 00:07:41,510 Data streams or cues are read in the batch. 89 00:07:41,810 --> 00:07:48,350 The function receives multiple items when executing to function, so a batch size can configure according 90 00:07:48,350 --> 00:07:49,550 to the service type. 91 00:07:49,550 --> 00:07:54,140 And after that, the event source mapping will send data according to batch size. 92 00:07:54,620 --> 00:08:02,060 If the batch size is too large to send in one event, it has to be split up, resulting in events with 93 00:08:02,060 --> 00:08:04,940 smaller number of items than the batch size. 94 00:08:06,050 --> 00:08:12,170 So you can see in the image a common scenario for event source mapping with polling location is the 95 00:08:12,470 --> 00:08:19,850 squares and a place lambda you can see in the image almost on squares and lambda using the event source 96 00:08:19,850 --> 00:08:26,400 mapping, basically lambda function pulling events from the squares. 97 00:08:26,480 --> 00:08:30,380 Let me explain more clearly in this diagram. 98 00:08:30,380 --> 00:08:33,110 Amazon has some key records. 99 00:08:33,140 --> 00:08:38,680 This cube records can be added from other services like event SMS and so on. 100 00:08:38,690 --> 00:08:44,570 So the idea is that we have some queue message in the Amazon queue. 101 00:08:45,200 --> 00:08:53,960 After that, a lambda function, pull the events from the Amazon case and receive Q records with event 102 00:08:53,960 --> 00:08:55,520 source mapping invocation. 103 00:08:55,850 --> 00:09:02,510 So lambda function retrieve Q records according to the batch size property of polling configuration. 104 00:09:03,290 --> 00:09:09,350 Another common scenario for my source mapping with polling location is stream based processing. 105 00:09:09,710 --> 00:09:16,550 These are the kinesis and Dynamo ADB streams that can LAMDA pull the stream records with event source 106 00:09:16,550 --> 00:09:17,930 mapping in locations. 107 00:09:18,950 --> 00:09:21,440 So the base size property is very important. 108 00:09:21,440 --> 00:09:28,220 We give the example of the x and lambda and we said that the stream based processing dynamo DV streams 109 00:09:28,220 --> 00:09:33,470 and kinases streams using the event based event source mapping location. 110 00:09:33,710 --> 00:09:39,700 And here is the list of the services that invoke Lambda functions as the event source mapping. 111 00:09:39,710 --> 00:09:45,650 These are the Amazon Kinesis, Amazon Dynamo DB and Amazon Simple Queue Services. 112 00:09:47,570 --> 00:09:52,370 As you can see that we have seen several a number in location types. 113 00:09:52,790 --> 00:09:58,970 In the next video we will map these lambda location types with our course when developing Solar's eCommerce 114 00:09:58,970 --> 00:09:59,780 application. 115 00:10:00,080 --> 00:10:06,890 So a lambda invocation types is very important and they will be our serverless journey when developing 116 00:10:06,890 --> 00:10:08,330 our serverless application.