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 !)

[leob]

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 : 24h_60m_30d = 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 !)

@Adesin-fr Thanks, wow the pricing calculation is brilliant, I was not fully aware of the costs of keeping the connections open!

To the costs that you're mentioning we should also add that we're keeping a DynamoDB database around to keep track of the connections, I want to look into that to see if we properly clean up the connection records so that the DyanamoDB database doesn't keep growing ...

Yes you're right about CloudWatch, I also came across an article somewhere which mentions that the costs incurred by that can become substantial if you're not careful about it - the best solution (apart from not logging "too much" i.e. only logging what's useful) is probably to configure the log retention to be pretty short? Keeping those logs around for a long time is probably not useful at all ...

I also came across a situation where we had a bit higher S3 costs than we expected - turned out that with defailt Serverless/CloudFormation deployment settings it's keeping around a LOT of "old" deployment buckets - which then causes those S3 costs ... something to be aware of.

I'll remove the Soketi reference from the README - I agree it doesn't make much sense anymore to mention it.

Will also try to research a bit more about the costs (based on what you explained) and add that to the README as well.

But yes this is brilliant, thanks - let's keep this repo alive, the last contribution (PR) was super useful, it allowed us to switch from PHP 7 to PHP 8 and it solved a few other issues as well ... great stuff !

P.S. I've updated the README (no longer mentioning Soketi)

[Adesin-fr]

I'll do the math for DDB, but I think It'll be even less than anything else ! DDB is awfully cheap when you don't use it so much...

I'll give a shot at #2 also, since I plan to use this on machine that have to be connected 24/24h... I might make a PR quickly ;)

PS : also perhaps mention in the README that using it in Laravel is just a matter of setting the broadcast driver to the correct value. Event if it's written in the HowTo, it could be a bit more clear ;)
And the package is probably compatible with Laravel 9+ ? I'll test it soon !

[leob]

I'll do the math for DDB, but I think It'll be even less than anything else ! DDB is awfully cheap when you don't use it so much...

I'll give a shot at #2 also, since I plan to use this on machine that have to be connected 24/24h... I might make a PR quickly ;)

PS : also perhaps mention in the README that using it in Laravel is just a matter of setting the broadcast driver to the correct value. Event if it's written in the HowTo, it could be a bit more clear ;) And the package is probably compatible with Laravel 9+ ? I'll test it soon !

@Adesin-fr Yes I agree, I also think that the DynamoDB costs will be marginal - the only thing I'd want to check is whether the "old" connection records get cleaned up when a connection is closed ...

#2 - you mean this one I suppose?

#2

Yes, that might be useful - I wasn't even aware of this limitation!

I'm also seeing this one - #9 - I might want to take on this one myself:

#9

This one is about the infamous "410 Gone" error, and I've seen that one quite a few times ... this ticket (#9) also seems to have a suggested fix/PR already, so I might want to give it a shot - assuming that it's still an error after the last PR that we deployed ...

As far as I can see these two (#2 and #9) are the most important/useful open issues that we have ... maybe also this one - #14 - but I'm not really sure what it's about and whether it's still and issue, I don't think I've run into this myself:

#14