Ably Blog

Looks like Ably has their own page on long-polling and why sometimes you can't use that or web-sockets. A few cherry-picked sentences (though it actually was a good read, do recommend the whole article if you have the time).

https://www.ably.io/concepts/long-polling

> Reliable message ordering can be an issue with long polling because it is possible for multiple HTTP requests from the same client to be in flight simultaneously.

> Another issue is that a server may send a response, but network or browser issues may prevent the message from being successfully received. Unless some sort of message receipt confirmation process is implemented, a subsequent call to the server may result in missed messages.

> Depending on the server implementation, confirmation of message receipt by one client instance may also cause another client instance to never receive an expected message at all, as the server could mistakenly believe that the client has already received the data it is expecting.

> Unfortunately, such complexity is difficult to scale effectively. To maintain the session state for a given client, that state must either be sharable among all servers behind a load balancer – a task with significant architectural complexity – or subsequent client requests within the same session must be routed to the same server to which their original request was processed.

> This can also become a potential denial-of-service attack vector – a problem which then requires further layers of…

Ably - London UK & Boston, US (Hybrid/Remote) https://ably.com/

Our everyday digital experiences are in the midst of a realtime revolution. Whether attending an event in a virtual venue, receiving realtime financial information, or monitoring live car performance data – consumers simply expect realtime digital experiences as standard. As such, synchronized data in realtime is now business critical for many organisations. Yet, at the same time, organizations don’t have the in-house capabilities nor the time to do this efficiently at scale. That’s where Ably comes in.

We provide a suite of APIs to build, extend, and deliver powerful digital experiences in realtime for more than 265 million devices across 80 countries each month. Organizations like Toyota, Bloomberg, HubSpot, and Hopin depend on Ably’s platform to offload the growing complexity of business-critical realtime data synchronization at global scale.

We have several really exciting roles we think you may be interest in:

R&D Engineer: https://boards.eu.greenhouse.io/ably30/jobs/4019101101

Distributed Systems Engineer: https://boards.eu.greenhouse.io/ably30/jobs/4018675101

Engineering Manager, Infrastructure: https://boards.eu.greenhouse.io/ably30/jobs/4029497101

Head of Solution Engineering: https://boards.eu.greenhouse.io/ably30/jobs/4024634101

Solution Engineer: https://boards.eu.greenhouse.io/ably30/jobs/4019118101

We also have many more amazing opportunities here at Ably as we continue to grow, and you…

The ElectricSQL concept of 'shapes' is interesting. Right now, a shape is just a single table with some column filters and a where clause. The shape is defined on the fly in the query string. Electric does single table sync of those 'shapes' a lot like Supabase realtime.

I work as part of the team building Ably LiveSync, a competitor in this space. Our postgres connector[0] works in the opposite way by taking rows from an 'outbox' table and fanning them out to subscribed clients over websockets in realtime.

Here's the thing; for any meaningfully complicated data in a relational database the data is likely to be normalised across tables with relations, and there are going to be joins. So I'm really curious how people are making single-table-sync work. (Maybe this is where Electric imagine the future of shapes, solving for joins).

In LiveSync we do it the other way around, instead of having a live-query style subscription to a table (like ElectricSQL), we listen for someone writing a row to the 'outbox' table and that row is automatically sent to subscribers. This means that you're writing your denormlised data directly to the outbox and it's being sent on to clients, rather than writing your normalised data to tables but being limited by single table sync. Or worse, your clients having to subscribe to multiple sync streams and trying and stitch the data back together. We opted to have the write-side insert the denormalised data, rather than having the read side have to…

Initially I thought I would be able to do it with webRTC but it turns out you still need some kind of specific server to connect clients.
Instead I cheated a little bit and used a messaging service https://ably.com/.
It was easy to setup and use, and their free plan is generous.
Another thing I didn't achieve is to find a RNG I could configure with a seed, so amongst my client I have a special one, the "host" who is drawing the cards, etc.
Overall it's been working really well. There is one thing that is particularly difficult without a server, that is debugging. Especially if using a mobile phone, you're in the dark when a bug happens. And with Ably and the free tier, you have to be connect in debug mode beforehand to see the logs, very unpractical.
Good luck with your game!

I've done this before myself for a pretty simple game and had to build the system alongside it. It's quite fiddly to get right.

I've been working on a new game on and off which is a bit less working with websockets directly and I looked at ably[0] to be that firebase like system, I've found it works reasonably well if you squint, though it's definitely not the same thing.

You can hack together a pretty nice implementation which gets you started using for example using presence[1] to store a minimal dataset associated with synced state. Then derive gamestate off that.

Which you can then expand on.

Though maybe you were wanting a more complete solution =)...

- [0]: https://www.ably.io

- [1]: https://www.ably.io/documentation/realtime/presence

the biggest drawback with SSE, even when unidirectional comm is sufficient is

> SSE is subject to limitation with regards to the maximum number of open connections. This can be especially painful when opening various tabs as the limit is per browser and set to a very low number (6).

https://ably.com/blog/websockets-vs-sse

SharedWorker could be one way to solve this, but lack of Safari support is a blocker, as usual. https://developer.mozilla.org/en-US/docs/Web/API/SharedWorker

also, for websockets, there are various libs that handle auto-reconnnects

https://github.com/github/stable-socket

https://github.com/joewalnes/reconnecting-websocket

https://dev.to/jeroendk/how-to-implement-a-random-exponential-backoff-algorithm-in-javascript-18n6