Realtime support for Workers KV (onChange)

#1

So, we are planning to move our realtime simple app to workers. Example of a to-do list. So when the page gets loaded first it shows data from KV, And when any users add a new list, it gets updated in KV. Now there are going to multiple people accessing the todolist page, How can we trigger an update to everyone when there a change in the data? So if person x has added from New York, it would show up in realtime to other users in different parts of the world at the same time and without delay… Is there a js api that keep the connection open like websocket or SSE or onChange() event?

I also tried this article, but it doesn’t sync data in different tabs/browsers after I add a new list, unless the page is manually reloaded

#2

Websockets are still not supported on Workers (looks like it’s a big technical and financial challenge).

The only way I can see some real-time update working is like how Discourse does it - by having the browser poll every x seconds to see updates on its message bus. An issue is that I don’t know of a good message bus solution that would work within Workers, other than running some redis cluster or other external datastore (which can add scaling issues and kind of defeats the purpose of workers). Another problem with this is that your Workers would cost significantly more, depending on how many clients are polling and how often the poll rate is.

1 Like
#3

So looks like, the best option is to use KV data to use on first load, and then setTimeout function to call external json every x seconds?

#4

Yes, that’s the only option I see that would work with the current iteration of Workers.

1 Like
#5

I’d argue that workers are not suitable for any real-time collaboration due to the distributed nature of KV, it can take up to a minute before a KV change is active worldwide. Add to that the amount of requests due to polling all the time will rack up considerable costs.

1 Like
#6

At present, there isn’t really a way to do realtime collaboration purely on Workers. You could write your code in Workers, but you’ll need to connect to some third-party database API that supports realtime. Workers KV is not a suitable storage system for this since it is eventually-consistent; collaborators not connected to the same colo would likely see many seconds of delay, and there’s no way to do transactions to avoid clobbering each other’s writes.

This is something we’re exteremly interested in supporting in the future, since it would be a natural fit for Workers to be able to coordinate collaboration at a colo close to all the collaborators. But, I don’t have any timeline I can give you right now for when this will be possible.

5 Likes
#7

Hi Naveed

Well one easy solution is to use a realtime cloud service, and trigger updates from the workers over a pub/sub channel to subscribers. We’ve created some examples in fact at https://www.ably.io/tutorials#tut-reactor, and we’re just adding native Cloudflare Workers support into the Ably realtime platform (within the next few weeks).

If you think this is of interest, I would be more than happy to get one of our devs to knock up a quick demo.

Matt

2 Likes
#8

Hey Matt,

Thanks. We did try fanout, pubnub and pusher in the past with our html + js. And right now I was considering of using firestore, however looking at your latency example and the technology offering, I wonder why I did not try ably yet :slight_smile:

So, yes, I would love to share our use case and see how CF Workers and Ably can work together. Let me know the best way to reach you.

#9

Matt’s on Twitter and other places, plus their website has some Contact links:
https://www.ably.io/about/team

1 Like
#10

Isn’t ably very different from firestore since ably doesn’t have a persistent DB?

#11

Hey Naveed

Drop the team a line at [email protected] and I’ll respond to the email that way. Or feel free to reach out on our live chat at www.ably.io, and I hope we can help you get this working.

Matt

#12

Yup, we don’t have a persistent DB. Our model is very much we do one thing well, which is provide a cloud messaging layer built on the concept pub/sub channels. Our customers therefore typically distributed updates over channels, either as deltas, CRDTs, complete objects, or other solutions.

#13

Yeah, I’ve been checking your examples during the day, it’s really fast!

Can it be used as a message-queue?

#14

I run a startup called https://tallyfy.com and we actually use PubNub, but without CF workers - so none of the “compute at the edge” benefits are possible at present, even though we’re rather excited about the possibilities, just like you are!

I think if someone built a service that laid over something like Google Cloud Spanner, you might at least have a decent persistence layer underneath that’s more reliable to many writes/reads. It seems you only need to think about post-write fan-out.

In other words, to update multiple listening clients on PubNub in real-time (to me) - the simplest architecture is just a matter of knowing that sockets/channels exist and then pushing a post-write update to all those listening clients to tell them to “fetch this object ID and update yourself”. That would avoid polling.

From what I understand of your use case, it’s only writes that really need updates to all listening clients.

We’re playing with more ideas on how we might use Workers in other ways too, but some of the essential primitives are missing. We intend to post our updates on architecture on our tech page, btw, in case we ever implement something awesome via CF workers:

Right now - long-lived caching seems the most obvious use case. In an app like ours, not many objects are long-lived and/or don’t change very often. Even if they were, it’s easier to just make a static version of them and cache via standard CDN or push via Cloudfront, etc.

One more use case you might really like - we started using Moesif to log all API calls at the edge. They have a Cloudflare add-on, and that might add value straight away if your app is API-first. Think of that as real-time logging of API calls, at the edge.