Using LiveView for multi-user / collaborative app development?

Hi all,

How do you feel about using LiveView for multi-user collaboration apps? Is it a good idea? Are you doing it? Do you know any good examples of collaborative apps and products that are developed using LiveView?

I ask because we’re developing a database system (https://vaxine.io) that integrates a CRDT database with Ecto and realtime subscriptions. We’re exploring whether building multi-user apps with LiveView would be a good thing to focus on.

Any thoughts or references would be very helpful! Also if you’re interested in this and / or developing a multi-user app with LiveView I’d love to have a chat to talk through some of the design conversations and trade-offs if you have time :slight_smile:

Thanks,

James

5 Likes

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.

2 Likes

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.

5 Likes

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.

1 Like

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.

1 Like

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.

5 Likes

Livebook is a great example, thanks :slight_smile:

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.

4 Likes

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: Elixir library to write Windows, macOS, Linux, Android apps with OTP24 & Phoenix.LiveView) 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.

1 Like

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).

We implemented LV for collaboration tool with multiple users(almost unlimited). It worked and it’s still in production after almost 2 years and more than 1 year without update. The main use case for LV was filling form with multiple types of answers. Whole platform is about creating forms by admins and filling them with other type of users. Users can see who is on same page of editing answers for form and we added features where user see who is editing and which answer for question in form. You can lock answering question when someone started writing answer to not go way where you have to fight with multiple values for same attribute/answer. To clarify this platform, forms are huge, something between 10 and 50 questions with multiple types, some questions require write big text which can take days to write. It’s platform for competitions where companies are asking for investments.

So when you make atomic fields which can be edited at same time you can have nice collaboration tool with minimal effort. If it’s possible. But in case you want to have Google Docs or Notion, please do not use LV, it will make your life harder, everything is possible thanks to great minds ( Chris is one of them) but it’s not good use case for LV. You have to chose tools which help you, that was also reason why I wrote this article Where to (not) use Phoenix LiveView | by Oliver Kriška | Medium

That collaborative form editing use case is a really interesting one, thanks :slight_smile:

1 Like

also we found out nice use case for LV with checkout form. Some people open it multiple times so we can close/change state for all opened instances pretty easy with LV.

Yup! “realtime sync” not so much for other users but to keep your own proliferation of tabs in sync :+1:

I created a small app during COVID-19 that allowed me and my friends to play pen&paper RPG using Savage Worlds system more easily. Game session was in genserver that used Phoenix pubsub to send state changes to all active LiveView instances. Code was thrown together really quickly without any tests. I’m also not an professional Elixir dev. But I can share the code if you want.

I haven’t yet seen any other platform/framework that you could use so easily create an collaborative app as LiveView.

FB just open sourced lexical which is another rich text editor. They interestingly have an option to hook up websockets for collaborative development it looks like. React | Lexical (the example is react, but lexical is vanilla js)