How do we make it work with Laravel Vapor?

[TheBigK]

Vapor is make Laravel go serverless; and I'm wondering how do we go about having laravel-websockets work in the serverless environment; especially Vapor.

Do we need to spin up a new server just for websockets? Or is there a better way?

[francislavoie]

I don't see any way that it would work out of the box with Vapor/AWS Lambda. With that model, each incoming request spins up a new instance of Laravel from the deployed code. I'm pretty sure you'll just need to run your websockets server in EC2 or ECS. If you go the ECS route you can probably scale up based on active connections once https://github.com/beyondcode/laravel-websockets/pull/140 is merged, pointing your websocket instances/ECS containers/broadcasting to the managed Redis instance (does Vapor set up ElastiCache Redis? Not sure if that's known yet)

Note I'm kinda talking out of my ass right now, I haven't actually used AWS in a few years and I'm just working off third-party knowledge... but I was at Laracon US for the Vapor announcement and that's what it feels like makes sense.

[TheBigK]

How about setting up a pusher like service using this package and just pointing to it?

[francislavoie]

I'm not sure what you mean by "pusher like service", laravel-websockets is actually an implementation of the Pusher API.

I'll just say, if you're running Vapor, it would likely mean that you can afford paying for service costs, so you could just pay for Pusher instead of using this lib.

[TheBigK]

I'll just say, if you're running Vapor, it would likely mean that you can afford paying for service costs, so you could just pay for Pusher instead of using this lib.

Not really. Pusher's pricing is way out of reach. My app has ~5K - 10K concurrent users and that'd mean I'll have to shell out several hundred dollars. This package solves that problem for me and I think most of the developers who need to have sockets in their app.

I believe that serverless would cost less when the web app has spikes of traffic every week. I currently run basic AWS infra but scaling is an issue when traffic goes up. I'd rather have it on 'serverless' provided I can run everything with it.

Of course, the solution is to spin up a new server in our AWS infrastructure and use it exclusively for AWS.

I'm however wondering if there's any way this package can be tweaked to run with Vapor.

[francislavoie]

Fair point regarding pricing.

But like I said above, no, this package can't run directly on AWS Lambda (which is what Vapor uses), because it's a long-running process. Like I said, I recommend ECS to run containerized instances of websockets, using load-balancing to proxy to any of the instances, using my fork in (i.e. code in #140) to scale horizontally, using Redis as a storage backend.

[TheBigK]

I did read your post; but it's going to take me a while to understand what problem is solves. I'm still pretty new to WS; learning things as I use it.

[francislavoie]

Currently (with the code in the master branch), you can only run a single instance of laravel-websockets. This means that you're entirely limited by network/hardware limits of a single machine, like IO, connection, and file handle limits.

My PR aims to make it possible to run multiple instances of laravel-websockets side-by-side such that you can get around those limits by running more instances each on their own server. This is called horizontal scaling (whereas vertical scaling would be just upgrading the server to higher CPU, RAM, etc, but still only running a single server).

[andrejguran]

This could solve the problem: https://aws.amazon.com/blogs/compute/announcing-websocket-apis-in-amazon-api-gateway/

[vesper8]

Seems like anyone who is budget-minded should steer clear of serverless in most cases. And this package runs best on a dedicated server, even in a serverless architecture not everything needs to be serverless, or should be

[booni3]

@vesper8 - Im not sure that is strictly true. The actual Lambda part of is extremely cheap. Your RDS, Vapor, NAT gateway (for private DB) are the bits that add up. The minimum for all of that would be around $100/month. Not a $5 droplet for sure and maybe out of reach for a hobby, but for anything commercial this should not be a barrier.

Back to the issue of web-sockets. Did anyone get any further with this? Can someone explain why this would not work on serverless while pusher does. (has anyone actually tested pusher?)

[bernisnukic]

@booni3 Pusher is a third party service/server that you connect to while laravel websockets is your own server that you have to run, aws lambda has a 15 minute max execution time so its not feasible.

I have used pusher in production and it works fine but its expensive.

[Humni]

From my understanding, it is "possible" isn't it? https://serverless.com/blog/api-gateway-websockets-support/

[francislavoie]

That doesn't imply that laravel-websockets would work with Lambda. All that does is have AWS keep the connection alive, and incoming messages are run as a lambda function, and outgoing messages are triggered by an HTTP request to AWS with the connection ID in the payload from the backend (i.e. from a queue job). Completely incompatible with this project. But you could use it yourself instead of laravel-websockets.

[lstables]

Has anyone found this to work on Vapor? I'm interested in switching to it from Pusher, but need to know it works on Vapor and what if any configuration needs doing....

[booni3]

This is from a laravel serverless group I am part of (quite complicated though, I would just go with pusher!!)

Here is a quick list to make laravel-websockets work with Vapor through the Pusher SDK:

EC2 Instance/ DO Droplet

1. Setup Server: Nginx, PHP
2. Setup Security: Firewall + allow Port 6001
3. Setup SSL Certificate (Certbot) for domain
4. Require Laravel, laravel-websockets, pusher-js + Echo
5. Configure Nginx based on SSL Documentation (proxy server)
6. Customize .env file to match Pusher Credentials of Vapor + add SSL Certificates paths
7. (I additionally had to set verify_peer => false, in websockets.php config for it to work on Chrome)

On vapor side:

1. .env (same pusher credentials/secrets as EC2/DO)
2. broadcasting.php: Point Host to EC2/DO domain, Port to 6001
3. bootstrap.js: Point Echo to wsHost: EC2/DO domain Then test a connection by running artisan websockets:serve in your application directory (EC2/ DO -> (var/www/html)), and if it works setup Supervisor to run this process for you as user=root.

[lstables]

Great write up, might give it shot. Pusher could become quite expensive as people have pointed out and I would like everything under one roof so to speak.

[georgeboot]

For anyone wondering, I am creating a package to use Laravel Echo with API Gateway Websockets as a driver.

You currently have to deploy it using Bref, but I am working on support for Vapor too. First release in days.

https://github.com/georgeboot/laravel-echo-api-gateway

[tntsoft]

@georgeboot any updates on this? Tried it and it doesn't seem to be working now.

[georgeboot]

I don't really have to time to maintain it anymore.

My recommendation is to use Soketi serverless instead: https://renoki-25232877.hubspotpagebuilder.eu/soketi-serverless

Basically free to use and very well build.