Just curious what do you guys do as far as sending...
# help
g
Just curious what do you guys do as far as sending out a websocket message to multiple users? Unless I am blind it doesnt seem AWS has a way to batch to multiple connection ids so we have to send out a single message for every single connected user which I feel could cause issues with latency especially when we get into the multiple thousands of users connected to specific events.
s
One way is to store websocket connections in a DynamoDB table and use that to determine who gets a message
a
You could use Amplify library’s PubSub client and connect it with AWS IOT or use MQTT over WebSockets. Check this out - https://docs.amplify.aws/lib/pubsub/getting-started/q/platform/js/ All relevant users will then be subscribed to the topic that you publish to and so the processing wouldn’t be serial.
s
SST does this internally to enable the live lambda development environment
Although, I admit the DDB route feels surprisingly manual . Seems like there should be a better/managed way to do this.
a
Seth’s approach is the next one I’d suggest because it involves connection management which you don’t have to deal with in case of Pub/Sub.
g
Does IoT allow custom authorizers? Want to make sure I can send different data to unauthenticated vs authenticated users. And the issue I mainly am concerned about is latency not the ability to do so with tradition sockets. Like how long will it take to send 30k messages using a normal api gateway since theres no batching
t
I think garret's question is more around looping through potentially 1000 conns and calling postToConnection on each of them
g
Yeah exactly, we currently use pusher and we are in the process of moving off of that onto our own managed sockets. And we do manage to hit pretty high concurrent connections to a single channel at times.
s
My company builds a CRM and uses Pusher (SaaS product for this particular use case) for this functionality
Oh, haha, I've had the same thought re: moving off of Pusher. Interested that you all are going down the same path
t
it does suck for broadcast purposes, @Ashishkumar Pandey solution probably the most managed one I know of
but I also hate amplify 😬
a
@Garret Harp I don’t think so, it needs IAM permissions. You could though add some logic to give IAM access to relevant users. I understand what you’re doing but I believe, using pub/sub is the more mature and automated way to deal with such use case.
@thdxr I mean to only use the lib not the platform. I love sst too much to switch to something novice such as amplify.
g
I wonder if maybe just using appsync might be the best bet, anyone know of the latency for appsync subs?
s
Curious about that pattern. My investigation stopped at learing that AppSync had a sub functionality, but I never dug any deeper
a
I don’t know how AppSync internally processes its subscriptions, if it’s serial then it’d be similar to what you’re already doing.
g
I hadnt ever used appsync subscriptions in the past because they are pretty useless for monitoring any mutations made but if I just manually send it my own data I think it could be useful compared to trying to fan out myself
t
@Ashishkumar Pandey I'm irrationally afraid of the lib too haha
AppSync sub has a HUGE limitation which is triggering server side events
you have to do some crazy workarounds
a
@thdxr lol, fork it. 😂
j
@Garret Harp I've built a chat application that uses AWS IoT to handle message distribution. I have some credentials whose only permission is iot:subscribe and my app subs them to certain topics. To send messages users post to an api endpoint and a lambda decides what mqtt topic to publish to
t
how fast is that?
is it faster than apig websockets?
a
If you want to use the IoT Core pub/sub without going down the Amplify rabbit hole trap, there really isn't much to it. This shows how I did it a few years ago: https://github.com/onicagroup/cargoplane
t
I got a prototype of this whole workflow working 🙂 we'll roll it up into a nice construct + browser library