What is AWS Lambda, and how Laravel Vapor uses it

#laravel #aws #serverless

Vapor is a serverless deployment platform for Laravel powered by AWS Lambda. A lot is happening under the hood, some real magic, but the most interesting part of the whole thing is the serverless technology underneath. Let's dive into serverless as I'll try to explain what happens when you run your laravel application serverless.

If you take a look at the index.php file of your laravel app, you'll see this:

$response = $kernel->handle(
  $request = Illuminate\Http\Request::capture()
);

$response->send();

When you send a request to your application, the Kernel::handle method will process that request and send the response back to your browser.

You normally host this application on a server that waits for any incoming requests and calls index.php whenever one comes. Let's say you host it in a small DigitalOcean droplet and paying $5/month for the server.

Imagine if you can just upload that Kernel::handle method to a service, and you only pay when that method runs. You don't worry about provisioning a server, upgrading the different libraries, managing the storage, and all this work. Just upload the function and you only pay when the function runs.

That's basically what running serverless is all about.

Lambda is AWS's FaaS (Function as a service), Laravel Vapor uses it to run your Laravel applications as a function that's only invoked when needed. Upload your app to Vapor, and that's it. Never worry about servers again.

Lambda is mainly used as part of a Microservices architecture, a lambda is meant to be doing only one job:

You upload an image to S3, a lambda gets invoked & generates a thumbnail version of your image.
You send a job to queue, a lambda is invoked & processes that job.
You schedule a job and AWS invokes a lambda each time the alarm goes off.
You send an HTTP request to an endpoint, and a lambda is invoked and generates a response.
You could also invoke a lambda as per your request anytime.

This usually means you have to divide your application code into multiple different services where each service has its own code base, and you deploy these different functions to AWS and instruct it as to when to run which lambda.

A user submits an order, you instruct AWS to run the "new-order" lambda. A user asks for an invoice, you instruct AWS to run the "generate-invoice" lambda. A user asks for a list of products, you instruct AWS to run the "products-list" lambda.

While the Microservices architecture is very beneficial in many cases, it adds a lot of complexity to your project as you need to handle the "wiring" of all these services working together. Laravel Vapor takes your codebase and converts it to a single function; depends on the event that triggers this function, Vapor runs a certain part of your application. This way all the wiring is done by Laravel under the hood.

So for example; when the user visits the /api/products endpoint, Vapor will dispatch the HTTP request to the Laravel router and sends the response back. Or when a job is available on SQS, Vapor will marshal that job to a worker to process it.

That way you can have all the benefits of running serverless without having to change the way you write your Laravel applications. Vapor takes care of all the work needed to convert your Laravel app to work serverless.

How it works

As we said earlier, Vapor converts your application to a single lambda. However, to allow you to set different configuration values for your HTTP and CLI environments, Vapor creates 2 identical Lambdas on AWS.

The HTTP lambda is responsible for serving HTTP requests; you can configure the amount of memory AWS should allocate to your HTTP requests, the timeout value, and the concurrency limit.

The CLI lambda is responsible for running artisan commands, processing queued jobs, and running scheduled jobs. You can also configure memory, timeout, and concurrency limits.

For the HTTP lambda, it's invoked via the API Gateway or an Application Load Balancer. We'll talk about the difference between both services in another post.

For queued jobs, Vapor configures your laravel application to use SQS to dispatch and process jobs. The CLI lambda will be invoked whenever a job is available in SQS.

Scheduled jobs are configured using CloudWatch/EventBridge, Vapor creates a rule that runs every minute and invokes your CLI lambda with the php artisan schedule:run command.

Finally, when you run vapor:command and provide the artisan command you wish to run, Vapor invokes the CLI lambda and instructs it to run the provided command.