[deleted]
A simple way to build collaborative web apps
61–70 of 73 posts
Re: A simple way to build collaborative web apps
#62I'm really glad to see an article like this. I've worked in the space for a while (Fluid Framework) and there's a growing number of libraries addressing realtime collab. One of the key things that many folks miss is that building a collaborative app with real time coauthoring is tricky. Setting up a websocket and hoping for the best won't work. The libraries are also not functionally equivalent. Some use OT, some use…
There's algo GUN [1], but I tried it and it's too opinionated for my taste. For those who like it, it seems to be quite good.
Re: A simple way to build collaborative web apps
#63> Dealing with a global database brings in much complexity that is not essential to the subject matter of this article, which will wait for another piece. Excellent write. It would be great to know why CockroachDB failed your needs.
Thanks! Wait for my next article. Hope it won't be long.
Thanks for the solid article.
Definitely interested in understanding end user benefit of the distributed database given one of purposes of library is to hide write latency and there needs to be coordination for every write.
Re: A simple way to build collaborative web apps
#64Great article! Is there something similar to Replicache that is targeted towards simple multiplayer games? Im building a multiplayer version of a clicker game like Universal Paperclips[0] and dealing with similar the problems that Replicache tries to solve.
Re: A simple way to build collaborative web apps
#65Earlier quoted context omitted.
DerbyJS and ShareDB/Racer are meant to go together. I know of one big company using it extensively, hundreds of millions of messages a day! :)
Could you share more info about the use case? Like a Google Docs kind of thing or w?
In this case, the entire product uses it. Every button, field, list, is "live" with derby+sharedb and scaled by horizontally scaling redis and the DB.
Re: A simple way to build collaborative web apps
#66I remember listening to an episode of the Exponent podcast, in which Ben Thompson said something like (paraphrasing from memory): > People who love "native apps" can complain about Electron all they want—but there's simply no replacement for the real-time collaboration offered by web-based apps like Figma! As someone who's not exactly thrilled with Electron and its memory usage—is there a reason the two go together?…
>in Cocoa and GTK?
This is reason enough. Already you now have to build the UI twice because there is no GUI framework that actually looks good on all OSs. You see this all the time where apps made on linux but technically work on macos just work terrible or look super ugly on macos.
You also have to remember windows, ios and android. When you build something targeting web browsers you only have to worry about screen sizes rather than OSs.
Re: A simple way to build collaborative web apps
#67A 225K gzipped .wasm file download for a client-side state management and persisistence layer is not great. It is competitive with some similar solutions, but still a lot for any web app's performance budget
0.2MB seems fine for a fully featured web app. Loading up the average website today typically loads tens of MB for an index page.
Re: A simple way to build collaborative web apps
#68Earlier quoted context omitted.
Yes, it would be great if someone with this experience can chime in, especially since Phoenix has CRDTs built-in.
Replicache's creator Aaron has a pretty good Twitter thread explaining the difference among Replicache, WebSocket and (classic) CRDTs. I will summarize briefly here: - WebSocket (and Phoenix Channel) is just a communication method. To maintain consistency and resolve conflict, you need something like Replicache. - CRDTs are more suitable for p2p scenario while Replicache works better for client-server apps. - Phoenix…
Also, a bit of the underlying plumbing here: https://twitter.com/aboodman/status/1323352541887754240
Re: A simple way to build collaborative web apps
#69Earlier quoted context omitted.
It appears Replicache doesn't use CRDTs since it has a central source of truth: https://news.ycombinator.com/item?id=22175530 See also the commentary here: https://doc.replicache.dev/guide/local-mutations This sounds a lot like Operational Transform but without the transform part - it assumes that locally applied mutations can be undone and rebased without user interaction. But I feel like the Google Wave team would…
Indeed, there can never be one universal solution to this, because the problem is one of specification rather than (only) implementation. For example, suppose we have an edit/delete conflict, where two clients concurrently interact with the same entity in your data model. In a simple case, we can decide to “resurrect” the affected entity and apply the edit, which is the option that never results in significant data l…
> How should we reconcile these changes, if simply allowing either one to take precedence means discarding data from the other?
Exactly. This is why Replicache expresses change as high-level operations, like createPost or deletePerson that are application-defined.
Replicache doesn't try to automatically merge the effects of concurrent mutations, it just replays the mutations in the same order on each client. It's up to the implementation of the mutation to decide what the correct result is, and that answer can and often does change when the mutation is replayed on top of different states.
Because Replicache mutations are atomic, applications can also enforce invariants such as uniqueness or even more complex app-level invariants.
Imagine, for example, a calendaring application. An application built with Replicache can enforce the invariant that a room is only booked by one event in one time slice even under concurrent edits, just using normal programmatic validation. It's hard to do this kind of thing with CRDTs or other approaches to automatic merging because the data model knows nothing about the application's constraints.
It's a pretty simple-minded system, actually, but our experience is that it is a nice way to think about these problems and provides good results for many types of data, in particular structured data.
Re: A simple way to build collaborative web apps
#70Earlier quoted context omitted.
I’m not sure if you are understanding that when Replicache rebases operations locally it actually re-executes code which can have arbitrary effects. This design yields a lot of flexibility to preserve intent: the function can look at current state of world and decide to do something different. Now, it is true that OT is considered the gold standard for certain kinds of collaborative editing, in particular unstructure…
I don’t know enough to comment on replicache, but you can also do OT on top of an operation based CRDT. For diamond types we’re making it support both - so if you want to, applications can do OT (which is simple, small, and fast) to talk to a server (or local proxy process), and then that process can do p2p server to server replication using CRDTs. The result is we need way less complexity in the browser, or in appli…
Cool, I need to look into this more.
I think for many customers the authoritative server is an advantage. It's useful in SaaS apps for the server to be able to override the clients, for all kinds of reasons -- antiabuse, authorization, extra validation rules, or just fixing bugs.