Live data from Hacker News

A simple way to build collaborative web apps

zjy.cloud

51–60 of 73 posts

Re: A simple way to build collaborative web apps

#51

A 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

The release build is 100k brotli I believe. It’s possible this site is using the dev binary.

It uses the production binary, originally 604.59 KB and after brotli (Vercel uses brotli by default) 213.90 KB.

Re: A simple way to build collaborative web apps

#52

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

Re: A simple way to build collaborative web apps

#53

This stack reminds me of Meteor, which came out nearly a decade ago(!). https://meteor.com It never really took off in the mainstream - I think because it was before many developers really trusted JS on the server, and a "full stack" framework is quite a big commitment for a team to shift to. Also most CRUD apps don't need real time collab. I remember being amazed when changes were instantly propagated between my pho…

Author here. Thanks for mentioning Meteor, which also impressed me a lot when it first came out. I think it didn't take off because it tries to do too much (frontend + backend + db). And one smart move by Replicache is that it tries to integrate nicely with the rest of your stack.

Re: A simple way to build collaborative web apps

#54

I'm interested how this stacks against Phoenix Channels + Presence.

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's Presence is built with CRDT but it's just a single feature, not a general CRDT toolkit.

The thread: https://twitter.com/aboodman/status/1410441402366922762

Re: A simple way to build collaborative web apps

#55

This stack reminds me of Meteor, which came out nearly a decade ago(!). https://meteor.com It never really took off in the mainstream - I think because it was before many developers really trusted JS on the server, and a "full stack" framework is quite a big commitment for a team to shift to. Also most CRUD apps don't need real time collab. I remember being amazed when changes were instantly propagated between my pho…

I built my first big software project in Meteor! It was great, really a shame that it didn't take off. As you said I think it tries to do too much. Hell, at some point they even introduced their own package manager. It might be good for solo developers but as soon as you have a bit more bandwith I think you give up too much control.

Re: A simple way to build collaborative web apps

#56

Really interesting...you can build a similar (websocket/db backed) app with LiveView out of the box, no? Any idea how well that'd hold up against this solution?

The big difference is that with CRDTs you can make edits offline and they will get merged with other changes when you come back online. Websocket/db really only works when you always online.

That being said you can totally implement collab without CRDTs and if you don't particularly need offline it should be easier.

Re: A simple way to build collaborative web apps

#57

I'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…

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! :)

Re: A simple way to build collaborative web apps

#58
At FastComments we store every change as an event, which can either be pushed or polled. Clients subscribe, and poll on reconnect.

Also, integrations use polling: https://github.com/FastComments/fastcomments-integrations/tr...

The integrations work kind of like DB slave replication. They do an initial sync and then maintain state via the event stream.

Re: A simple way to build collaborative web apps

#59
post #23

Very nice writeup! However, the example did not fully work for me. I could perform CRUD on a single tab, but opening the list in multiple tabs did not replicate the list or actions. Seeing this in the console: [Error] Could not connect to the server. [Error] Fetch API cannot load https://damp-fire-554.fly.dev/replicache-pull?list_id=kx1I-gXPWwOxU9teRUJ_c due to access control checks. [Error] Failed to load resource:…

Seems like a CORS related bug on Safari. I tested on Safari 15 and couldn't reproduce it.

https://stackoverflow.com/questions/63141448/safari-fetch-ap...

Re: A simple way to build collaborative web apps

#60
post #57

I'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…

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?

Post reply on HN