#Websocket interface for schema model changing

1 messages · Page 1 of 1 (latest)

solar solstice
#

Hi,

I'm interested in exposing a websocket interface to a client, which updates its clients in real time every time a certain model in Postgres changes, but I'm not sure how to architect it. I've established a connection to my websocket via app.webSocket("path") { ... } as in the docs, but I'm not sure the mechanism how to tell the websocket to send a message on model update. I could use webSocket.eventLoop.scheduleRepeatedTask to check for an update every X seconds, but I'm curious if I'm thinking about this wrong or if there are better/less manual ways.

rapid oriole
#

Ill try and find but there ins an example on websockets, maybe on hacking wth siwft, where they make a class to represent connected websocket clients. You could do something like that and expose the class that holds the connection info to the class that knows about the changes

#

that should eliminate polling I think.

last ridge
#

And then in terms of managing the Webhook calls, @rapid oriole is right - you’ll likely want some kind of manager to route messages to active connections, though may also want to consider a way to track particular subscriptions by clients and limit updates to the clients who actually want them. I’ll leave a few files here from an implementation I built a few years back if that helps

rapid oriole
#

the timer and timeouts is a nice touch

last ridge
#

I’ve stripped a few project specific bits out but left enough for you to imagine how a set of connected clients (customer service agents in this case) could receive updates and modify their notification subscriptions 👍

solar solstice
#

This is super helpful, ModelMiddleware looks like exactly the protocol for me to implement, and I knew I'd have questions about routing to clients but the gist is a great starting point. Thank you both!

rapid oriole
#

no problem. and yeah that gist is pretty tight and simple yet complete imo. I plan on using it soon in my personal prjects new and old, when i get back to them.

light cypress
#

But just a reminder,

Using ModelMiddlware isn't scalable when using multiple machines.

I had one case where fly.io scaled my application into 2 machines, and I started getting irrelevant behavior

rapid oriole
#

interesting observation

#

I wonder what aspect is scaling wrong

light cypress
#

Because the changes are published on the machine wise

And you can't guarantee that the socket is only connected to this machine

lucid flint
#

@light cypress you're right, but you should set up a Redis (or other) pub-sub system for scaling websockets anyways

#

So I think a ModelMiddleware is fair then

#

If you use a database hook, you'll need to observe all traffic on all nodes, and then decide what's relevant. So while it certainly works, I'm reluctant to say "efficient"