Using LiveView for multi-user / collaborative app development?

Isn’t every LiveView application a multi-user collaboration application in a sense? There is a huge, global state held in the database, and every online user is presented with a evolving projection of the shared state, and every online user can mutate the shared state, and the mutation is sent out to every participant in real time. A chatroom is one such example.

Collaborative usually means parallel edits of the same document by multiple people. More google docs, less chat room. I don’t think LV is well suited for that usecase. Usually it needs some kind of CRDT shared between clients, which is a good usecase for channels. LV however can supply the things around a CRDT based collaborative editing experience.

Yup, and in fact Vaxine is a CRDT system (based on https://www.antidotedb.eu).

I totally agree that every LiveView application can be a multi-user collaboration application in a sense, where we can use something like PubSub to push changes to the state and the view will naturally sync. I guess I’m really keen to explore:

a) any practical examples of this in the wild? i.e.: collaborative apps built with LiveView
b) any thoughts on the online / offline trade-off with LiveView and how this impacts its suitability for multi-user UX

On the online UX point, it strikes me that multi-player environments / components in a sense need online to make collaborative progress and so perhaps requiring online can be OK in practice. However, a lot of the multi-user / multiplayer systems I see in the wild tend to be developed using client stores, optimistic writes and background sync.

If the scale of the application is small enough, you might not need CRDT. One GenServer per document can do the job of serializing concurrent editing. You can keep the client side dumb and rely on the full loop of client → LiveView → GenServer for the doc → LiveView → client for every mutation.

SPAs are an obvious choice for things like Google Docs, so drawing the line is tricky, but I want to point out that Livebook is a fully collaborative LiveView application, with rich text editor, visualizations, presence, etc. So LV could be a great choice for a collaborative app. It really depends on what you are building and the tradeoffs you are comfortable with.

Livebook is a great example, thanks

Out of interest, do you have any insight into use-cases where the trade-off of having the network on the interaction path is more acceptable? I’m particularly trying to wrap my head around the intersection of multi-user-collaboration and online-is-acceptable.

Conceptually I can see that some multiplayer experiences only make sense when you’re online – no great point stacking up a lot of offline changes in a fast moving multiplayer game, for example. Whereas some tools (like maybe a Notion or a Google Docs) require both multi-user collaboration and offline support, so you can carry on working when your connection drops.

Do you have any insight in particular from visibility into LiveView adoption / thinking through the network-on-the-interaction-path constraint?

Obviously offline support is a clear dealbreaker. The interesting thing about that in context of this convo is that Google Docs also doesn’t work offline. It swaps over to read-only mode as soon as the connection dies.
I can’t think of many web applications I use day to day that are offline capable. I also maintain that for the vast majority, just because SPAs are capable of offline mode, doesn’t mean folks actually implement it. You opt-in to a massive amount of complexity in doing so. That said, if you need it, you need it, but I find most folks don’t bother implementing it just because they can. So vast majority of web apps today are already on the network-on-the-interaction path.

Carrying on working while offline, optimistic updates that require pre-rendering the full UI element before hitting the server, and particularly large HTML documents are all things that would point towards client code rather than LV, bu there’s some gray area.

I have idly wondered if it would be possible to make offline-capable phoenix apps using a bundled runtime (something like GitHub - elixir-desktop/desktop: Building Local-First apps for Windows, MacOS, Linux, iOS and Android using Phoenix LiveView & Elixir! · GitHub) along with a CRDT or on-client replication (eg using https://litestream.io/ or even postgres with a wireguard tunnel to fly.io). “Idly” here meaning a lot of hand-waving as it’s all a bit out of my competence range.

What brings this to mind is that I’m increasingly of the view that political and physical (climate) instabilities are going to make connectivity less reliable over the coming decades. Admittedly my personal experience of climate change (flooding and bush fires) is influencing me. My nearest town has been wiped out twice already this year, and I’ve been entirely cut off from all communications (including physical, with roads and bridges destroyed) for weeks at a time. Electricity and internet are now essentially intermittent utilities here, and I’ve had to abandon some online-only software I hitherto considered essential. And this is in a rich and very politically stable nation, so I think it bodes poorly for permanently-connected software in much of the world.

I have maybe a slightly different use case. What if your project is either part of a larger ecosystem, or the foundation of an ecosystem, or is the ecosystem itself. In this situation you may have many different and independent parties involved that collectively have an interest to evolve a common technology or open standard even. Each of the ecosystem participants has their own project concerns where they likely build project-specific extensions, and then find a need to make some or all of these new capabilities part of the shared technnology base. Before contributing to the ecosystem-wide Liveview their ‘living documentation’ would not necessarily be offline, but disconnected at project-specific location.

Right now I have 2 examples where this use case would apply. One is the Fediverse, a decentralized and open standards-based social networking environment. Many projects are part of it and interoperating. Some of these are implemented in Elixir, like Bonfire, Pleroma and Mobilizon, but there are apps in many different languages. The ActivityPub protocol on which they are based is extensible for any application type / business domain but requires consensus of message formats and heuristics of extensions. A whole range of Liveview-integrated tools might support the collaboration here (which is a serious challenge right now).

Another example are projects having a plugin architecture to allow anyone to extend the application. For instance aforementioned Bonfire is such a project, where the Fediverse server platform should allow any developer to build and launch their own apps in as easy ways as possible. But the plugin architecture will evolve as a result of this, and various plugin projects will have to collaborate to forge seamless integrations.

Other things I’d like to mention re:collaborative app development. LiveView is perfect for developing docs along with the code. A ‘living documentation’ concept, or kind of Readme Driven Development. I would like to see that extended to having a good focus on the kind of documentation artifacts that are created. So architecture documents with diagrams, requirements tracking, UX storyboards, etc. and other perspectives as needed. The documentation process would be more multi-disciplinary. All the while the objective should be to keep things minimal and, importantly, Living. So no dead architecture document that no dev looks at anymore, or a fancy dream UX design that isn’t implemented.

Yup, the Google Docs example is such an interesting reference. The canonical online collaboration tool with a clear reason to allow people to keep writing when their train goes in a tunnel but it doesn’t support offline (at least by default / without plugins).