React Helsinki February 2020

…ecture I'm aware of (please do let me know if anyone is aware of others!). But the architecture itself has been used successfully in a bunch of apps, most notable of which is probably Linear ( link , I remember watching an early video of their founder explaining the architecture in more detail but I can't seem to find it anymore (edit: found it! link to this video )). Basically the way authorization works is you define specific mutations that are supported (no arbitrary writes to client state, so write semantics are constrained for ease of authorization and conflict handling), with a client-side and server-side implementation for each mutation. The client side gets applied optimistically and then syn…

Linear's write ups / talks on real-time sync are also very good, if a bit old now. 1. link to this video 2. link Also see this overview of related tech here: 3. link And c.f. automerge from ink & switch: 4. link

I mostly agree, but having used Linear.app which has a crazy good and fast UI based on a local database synced with their cloud database, I'm not sure anymore: link to this video . I think it's important to define early in a project if the app is "cloud-based" or "local-based". If it's cloud-based, then only the server mutates state and sends views to the clients, as you wrote. Everything is simple. If it's local-based, then all data are available locally and mutated locally. The cloud is only used as mirror/backup and can support for some advanced features like full-text search. That's also a very clear architecture. That's how Linear works. Things become hairy and unnecessarily complex when no clear…

(Cofounder here) The app is fullstack typescript react application with custom realtime sync engine for instant updates and offline readiness. Our cofounder did a talk about our sync few years back: link to this video The app works both in the browser and we also distribute it with Electron wrapper for macOS and Windows, but it's essentially the same experience.

We created Linear1 as local-first product. Back in to 2019 there wasn't much anything available so we created our sync engine. Today we have several thousands companies, from early stage to public companies as paying customers (companies such as Vercel, Replit, Substack, Square..) Our co-founder did talk about sync engine back in 2020 and recently did updated talk about scaling it 3. The scaling has definitely taken lot of work and optimizing as datasets for company wide workspace with potentially thousands of users ands object they created can become quite large. 1: link 2: link to this video 3: link

I was just tinkering on an offline/local-first app a few weeks ago. This biggest issue with using LiveView as the rendering layer was that I had to do a lot of client-side caching in order to make the offline portion work because markups were generated on the server-side. Then I had to use a client-side framework (React in my case) to patch the DOMs with data updates. All in all, I don't think it's worth the effort to use LiveView for a local-first app. BUT, LiveState (aka LiveView for JSON) is very suitable for building a sync engine. https://github.com/launchscout/live\_state Sync Engine references: [video [video