Cc @joesavona

The real account is @josephsavona isn't it ?

Tycho, thanks for the hint.

Real-time and persistence are indeed two very hard challenges and Swarm focuses exactly on those two things. This ice-and-fire trade-off (real-time + offline-ready) is mostly motivated by collaborative/social apps and mobile devices. More on objectives: http://swarmjs.github.io/articles/1of5/

It takes a novel architecture to sort those things out. Swarm employs op-based CRDTs, automatic merge of changes, continuous sync, all-async interfaces, etc.

Technically, it syncs over WebSocket and caches data in WebStorage or IndexedDB. It has its own data sync protocol (Lamport timestamps and all that stuff).

Hence, Swarm is not something you can easily slap on an existing system.

Still, I see the obvious Swarm/Relay overlap. That is a centralized data store, unified data fetching/syncing, event flow.

Compared to Relay, Swarm is hardcore on real-time and offline/caching. But, it lacks in object graph management, GraphQL and related things. Which is definitely nice to have (and often requested).

In case Relay would allow for pluggable backends in a non-trivial way, then probably it is possible to carve something out.

So far, React integration was a breeze because basic abstractions match really well.