Skip to main content

  • March 22, 2021

Best Uses of Laravel Vapor

As a Solutions Architect at Happy Cog, I often find myself in the weeds working with complex server architectural configurations in our clients’ AWS platforms. You may often find me setting up complex infrastructure by code with AWS Terraform, deploying fleets of EC2 instances powered by Continuous Integration pipelines, and working to curate complex load balancing solutions for our clients who receive unexpected bursts of views from our marketing campaigns (the list goes on).

I find this type of work exciting and fun to solve the highly specialized problems that arise to reach the conclusion of a server rollout. I wouldn’t be surprised to hear that some don’t want to deal with such complexities in their site pipelines, or have the bandwidth to figure it out. This is where Laravel Vapor helps alleviate some of this headache for users, and I’ve had the ability to give it a test drive internally on a test project before working directly with it on a recent client launch of ours.

In this article, I’ll touch briefly on some of the pros and cons, and provide insight for the best use case using it with your Laravel — or even Laravel Lumen — set up. (If you’re not familiar with some of these platforms, you can read more about Laravel or Laravel Lumen, or browse the Laravel Vapor docs.)

Abstraction from the distraction

If you’re not up to speed with the latest workflows or administration screens in AWS, it can become confusing (and fast) how to navigate and configure the various microservices offered by AWS to power a fully scalable website with Laravel. This is where the power of Vapor comes in, taking that complex “wizard behind the curtain” logic away, and instead providing multiple abstracted paths to publish your Laravel application to be distributed across unlimited AWS Lambda endpoints. With the ability to distribute traffic across AWS Lambda functions, connected to AWS API Gateway public endpoints, the user never gets hit with server timeouts and the system can handle any spike in traffic of almost any size. As the bandwidth demand increases, the load increases to handle it, providing horizontal scalability for an application with very minimal effort by your developers or DevOps teams.

Cloud storage from above

Since AWS offers true serverless scalability, we’re able to capitalize on this with storing file uploads and file assets from our Laravel application directly to dedicated S3 buckets. S3 provides the possibility to store unlimited amounts of client assets at varying storage types, without the headache of filling up a more expensive physical server as the assets grow with time, or having to either sync assets between servers or set up a shared filesystem

We can also handle file uploads by the user, to allow for triple 9 data storage — designed to provide 99.999999999% durability and 99.99% availability of objects over a given year. If the data center suffers an outage or problem, our S3 data can sustain the concurrent loss of data in two facilities which allows our clients to sleep easier at night, and keep our DevOps team dreaming of serverless PHP architecture.

Caching with Redis & database storage

What really had me interested in Laravel Vapor was the ability to leverage ElastiCache Redis clusters attached to our Laravel application. By using the native Laravel storage driver, I can assign a Redis cluster to the deployment, allowing me to cache constant API calls directly to Redis with very little overhead or worry from the DevOps department. Watching your applications’ workers scale within seconds of demand is pretty exciting, and since Vapor isn’t just about deployments, we can leverage multiple types of serverless databases directly from the Vapor dashboard.

Multiple environments & deployment rollbacks

I enjoyed the ability to quickly deploy multiple environments, such as a “staging,” “dev,” or “production” environment stanza in my Vapor yaml file and target those environments with the help of a specific Vapor environment file for additional handling of environment variables. I also added dynamic updates of the deployment into our internal Slack channel, so that PMs, devs, and other stakeholders are updated with new releases. Or, just a separate playground for when I’m testing new features out prior to pushing to the client production environment. Each environment has its own vanity URL — which is just an AWS endpoint for the cluster — which gives me the ability to share links directly or even assign a domain to it. If a mistake happens, we can easily rollback a deployment in the Vapor dashboard. I can assure you that the time it takes to rollback a deployment with Vapor is a walk in the park compared to the hands-on effort required if you were working directly with AWS.

Pipeline friendly

While Vapor provides the ability to connect via their CLI, having to run commands locally may not scale well with multiple members of your team. Using the Vapor API token in your pipeline, you can run the Laravel artisan commands to deploy to the environment of your choice. We’ve connected this pipeline to merge requests, so that any member of the team can work on a feature and see it deployed all within Github or Gitlab. Sprinkle in some Slack updates on success or failure, and you have some pretty neat magic to impress your project manager and help keep stakeholders up-to-date when new features are released to dev, staging, or production depending on your pipeline flow. Since we’re just using artisan commands to trigger the Vapor deployment, we have a lot of options to help extend this depending on the needs of the project or client.

Scratching the surface

My project’s use of Vapor barely scratched the surface of all of the options that Vapor provides, but it did meet the very specific requirements that my Laravel project consisted of without the need for me to architect a solution in AWS that would require internal documentation, or ongoing support by the client. Features such as writing and dispatching Laravel Jobs as Queues, advanced metrics in the Vapor dashboard, managing the application’s DNS and Certification records via the Vapor UI or CLI, or advanced team organizational configuration are all things on the to-do list of my side. I’ll circle back here when I have some news to report!

To conclude, Laravel Vapor is the hot new shiny object on the block that really does help streamline your deployments, and quickly turns any Laravel application into a true serverless PHP application — leveraging multiple key features that AWS offers to help increase your client’s site speed and availability, all while keeping the advanced AWS configuration logic away from the scenes and providing a nice CLI component to make it easier on your end. I’d recommend signing up for a test account to see how it works, and you may find it to become another tool in your arsenal as you continue to help evolve Laravel.

Back to Top

comments powered by Disqus