Introducing executeAsEvent0:00
The last execution method I want to show you is executeAsEvent. ExecuteAsEvent really is fire and forget. We looked at executeAsync, which we learned is kind of async, but not really. You do eventually have to wait for the promise to settle, otherwise it won't be fired. ExecuteAsEvent, you fire and forget. You actually can't get the response back. Let's see what the docs have to say about this. We're in the AWS Lambda documentation and we're looking at invoke. This is the API method that invokes your function. It says you can do it synchronously and wait for the response, or asynchronously.
Async invoke semantics0:40
This is the API method that invokes your function. It says you can do it synchronously and wait for the response, or asynchronously. To invoke it asynchronously, set the invocation type to event. That's what Sidecar's doing, invoke as event. If we scroll down here to the asynchronous part, it says Lambda adds events to the queue before sending them to your function. When you invoke your function as an event, it actually goes into a queue managed by AWS and then it gets invoked. They invoke it at least once, but they could do it multiple times, so you do need to be aware of that.
Setting up axios example1:41
Let's take a look at an example of this. We're going to change a bunch of stuff up. We're going to add a package.json here, put an empty object in it, then we will change into sidecar and say npm install axios. We're going to use axios to make a request. Those node_modules are there. Let's go to our helloWorld function and down in the package, instead of just shipping the one file, we'll just ship the whole directory. We still have browser in there, but that doesn't matter. Now we're shipping the whole directory with the node_modules included.
We still have browser in there, but that doesn't matter. Now we're shipping the whole directory with the node_modules included. Let's look at this index.js. What do we want to do here? Let's go ahead and sleep for 500 milliseconds again. Up here, let's say axios equals require(axios). Down here, we're going to await axios.get and we'll pull it off the event. We'll pass through a URL that we're basically just going to ping. We also need to await this. Now what's going to happen is our handler is going to sleep for 500 seconds and then
We also need to await this. Now what's going to happen is our handler is going to sleep for 500 seconds and then it's going to fire off a GET request to the URL that we pass on the event. Basically what we're doing here is we're simulating some sort of processing work and then some sort of processing complete notification. Lambdas can run for 15 minutes, so you can do a whole lot of processing in 15 minutes. We're just going to sleep for 500 milliseconds. Let's go ahead and deploy this function. We'll get out and we'll say php artisan sidecar deploy activate. Now we're going to get a public URL from our app because we're actually going to ping back
Wiring ping callback route3:33
We'll get out and we'll say php artisan sidecar deploy activate. Now we're going to get a public URL from our app because we're actually going to ping back to this very application. I'm going to use expose because I really like expose and I guess I don't have a license on this computer. I'm going to copy the public URL here and let's jump back to web.php. This is our function and I think we're looking for ping. We're looking for ping on the event. We're going to pass through which URL we want to ping and we're going to ping pong. We'll make a new route down here just so we don't end up in an infinite loop.
Demonstrating fire-and-forget4:49
500 milliseconds. The real question is, is that lambda function being run at all? If we look at expose, we see all of these pongs coming in. Let me put these side by side so we can see it all happen at once. I'm going to start expose over so we get a clean screen. Now let's watch it. I'm going to refresh on the left and we should see the pongs come in after about half a second on the right. Here we go. We see Laravel's returning hello to the browser and then a little bit later the pongs are
Here we go. We see Laravel's returning hello to the browser and then a little bit later the pongs are coming in. Let's make this even more clear. Let's sleep for five seconds before we return anything. Let's redeploy and reactivate and we'll restart expose and refresh. Now it's come back to the browser really quickly and we still haven't seen the pong. There it is. About five seconds later, you see the pong come in but our response came back super quick and that's because our response isn't being blocked by the invocation.
Choosing execution methods5:54
About five seconds later, you see the pong come in but our response came back super quick and that's because our response isn't being blocked by the invocation. To recap, execute as event is great when you don't need the response. If you don't need the response, don't even wait on it. If you're only running one function and you want to run it synchronously, you should use execute. If you're running many of the same function, you should use executeMany. You can also use executeAsync. ExecuteAsync is great but you do need to wait for it to settle. You do need to kick off the queue like we talked about in the last video.
