This package is really useful, shame it's no longer maintained - could I volunteer? :)

[leob]

Hi @georgeboot,

You say "this package is no longer maintained", and I think that's a shame, it works really well for us.

I'd consider "volunteering" to take over maintenance for this package, what do you think?

Have a nice day,
Leo

P.S. you recommend "Soketi", all great and well, I looked at it, however we're running on AWS Lambda and we've based our whole architecture on it - something like Soketi doesn't play with that, it would make our AWS Lambda based architecture somewhat pointless ... laravel-echo-api-gateway really fits like a glove for us :)

[georgeboot]

Sure why not! Sounds awesome!

I'll give you triage permissions. Please just ask pr reviews from me when it's ready so I can merge and tag. If that works good, full access in the future.

[leob]

Okay cool, let's do it!

[michaelaguiar]

@leob I am also maintaining a fork of this at: https://github.com/aliasproject/laravel-echo-api-gateway and plan to continue to improve it if you want to join!

Let me know if it's better to work directly on this repo without @georgeboot , or on a fork. I use this on many projects and it works pretty great for me, and super easy to deploy new Websockets servers via API Gateway.

[leob]

@leob I am also maintaining a fork of this at: aliasproject/laravel-echo-api-gateway and plan to continue to improve it if you want to join!

Let me know if it's better to work directly on this repo without @georgeboot , or on a fork. I use this on many projects and it works pretty great for me, and super easy to deploy new Websockets servers via API Gateway.

@michaelaguiar Thanks, great to hear!

Yes I like it too - easy to install and use, works like a charm, I'm using it on a project of mine ...

Okay, let me look at your fork, and if that works for me then I'm inclined to add a note here in this repo, directing people to the fork, and make that the new 'official' one ... I'll get back to you.

[georgeboot]

Not sure how many active instals there are, but it would probably be easier for people if you can bring your changes into this repo, so people get the benefits without having to switch packages. But do what you think is best.

[leob]

Not sure how many active instals there are, but it would probably be easier for people if you can bring your changes into this repo, so people get the benefits without having to switch packages. But do what you think is best.

@georgeboot Yes you may be right, it might be less confusing ... let me take a look at what's in @michaelaguiar's fork and we'll figure it out.

[michaelaguiar]

Either way works for me! FYI @leob - my fork has very minimal changes from the current version here. I did fix an issue I had with deploying to Laravel Vapor and the token issue that @georgeboot mentioned in both the aws sdk repo and Laravel. I'm happy to team up on making improvements either here or in my fork.

[leob]

Either way works for me! FYI @leob - my fork has very minimal changes from the current version here. I did fix an issue I had with deploying to Laravel Vapor and the token issue that @georgeboot mentioned in both the aws sdk repo and Laravel. I'm happy to team up on making improvements either here or in my fork.

@michaelaguiar I'll take a look at the changes in your repo - and then maybe we can create a pull request to integrate your changes into the main repo (this one), and add you as a committer, and we can all work on it here ... that might be the nicest and least confusing way to do it :)

[michaelaguiar]

Works for me. I can create a PR for review.

[rdrc]

Any updates here? I am also interested in this approach for Laravel Vapor since it seems like the Soketi serverless option mentioned in the docs is no longer available https://renoki-25232877.hubspotpagebuilder.eu/soketi-serverless.

It looks like @leob and @michaelaguiar are maintaining separate forks, is there one that would be recommended?

[leob]

Any updates here? I am also interested in this approach for Laravel Vapor since it seems like the Soketi serverless option mentioned in the docs is no longer available renoki-25232877.hubspotpagebuilder.eu/soketi-serverless.

It looks like @leob and @michaelaguiar are maintaining separate forks, is there one that would be recommended?

@rdrc This repo here is the original repo, and is the one we should be maintaining - I offered to @michaelaguiar to integrate his changes/improvements into this repo ...

Yes, "Soketi" is also not an option for me - we're developing an app which is fully AWS (Lambda) based for the backend, so I also want websockets to run on AWS, not somewhere else, it wouldn't make sense ... I really like this repo, it's the best and most mature implementation that I came across for PHP/AWS/Lambda, and it's very important to us, so I'm interested and motivated in helping maintain it.

I just need to start reserving some time to dive into the source code and fully understand it, and then look at @michaelaguiar's changes ... but yes, this repo should be the one going forward !

[michaelaguiar]

Sorry I haven't submitted my PR yet! I am preparing it now and will submit it in the next few minutes.

[michaelaguiar]

First PR #29 is in. I am extracting another update from my fork, but this some of the main changes. Take a look and let me know what you think.

[leob]

First PR #29 is in. I am extracting another update from my fork, but this some of the main changes. Take a look and let me know what you think.

@michaelaguiar Great! will check tomorrow and merge if it looks good ...

[Adesin-fr]

Nice that we've got new contributors ;)
I was searching for this to ditch Pusher, have tried Soketi, but it has some nasty bugs, the project seems to be dead and last but not least, it does not run on Lambda ;)

IMHO : the Readme.md should not mention soketi, since the project seems abandonned, that's not fair for users ;)
IMHO2: It could be great to add some figures about the cost in the readme. I can handle this if needed.
I've made some calculations : a full time connection costs : 24h60m30d = 43200 minutes per month (a bit more for months with 31 days...), and this is billed 0,297 USD PER MILLION minutes, so : 0.0128 USD / month per user (if connected 24h/days !)
And the messages by themself are billed 1,19 USD for the first billion, then 0.99 per billion over this...
That's silly cheap ;)
PS : some costs that has to be added: a bit of lambda compute, and a bit of cloudwatch logs (README could also encourage users to lower the number of days cloudwatch logs are kept, those are adding pretty fast to the bill !)