Bottom line is, if your app's content is behind a login screen, just use client side rendering. It is way lower complexity and a way better user experience.
How's Linear so fast? A technical breakdown
21–30 of 250 posts
Re: How's Linear so fast? A technical breakdown
#22Whole blog post is basically: Make a mutation in the clientside, assume it worked, and save in the background.
Re: How's Linear so fast? A technical breakdown
#23https://github.com/wzhudev/reverse-linear-sync-engine/blob/m...
Re: How's Linear so fast? A technical breakdown
#24Whole blog post is basically: Make a mutation in the clientside, assume it worked, and save in the background.
Re: How's Linear so fast? A technical breakdown
#25I worry that optimistic updates is going to become trendy and applied to more software, but without any plan for the "sad path" - failed to sync, sync conflict, etc. Get ready for a whole new era of race conditions and frustration!
Re: How's Linear so fast? A technical breakdown
#26I’ve actually found Linear to be quite slow? There was a week where it would also spin at 100% CPU if I left a tab with it open for a while :(
Re: How's Linear so fast? A technical breakdown
#27Re: How's Linear so fast? A technical breakdown
#28One thing I would like to point out though is that building a performant sync engine that behaves the way you would like in most cases is a non-trivial thing.
If two users are offline and add, edit, remove issues and come online again, you need to reason about what happens. Sometimes you can get away with Last Writer Wins but what happens if an issue is deleted and then edited. What happens if an item in a list gets re-ordered differently on different clients, what's the final ordering? In which cases can you merge what state and in which do you need to discard something. Do you show a conflict resolution UI? How do you deal with rollbacks. How do you deal with schema drift and updates on items that would be affected by schema drift? Business logic might change between being reconnects. FK constraints can shift. Can you set up your data and the sync engine so that it only syncs the minimum amount of changes and batches them correctly during longer offline sessions so you don't fire 5000 change requests after reconnecting?
I recently had to implement local first + remote sync on some fairly complex dynamic forms and where luckily there is usually only one writer and I can get away with last writer wins and reject if things are too old or if there is schema drift and can just display an error message and roll back. But what I am trying to say is: Whatever can go wrong in an online-first world, can also go wrong in an offline first world but you might get informed of that all at once at a later time - or not at all and your data is not what you think it should be. Some sync engines like zero from rocicorp has opted out of supporting offline writes entirely because of all these problems.
And just to be clear: I love offline first approaches. I yearn for fast performance. And in a lot of cases slapping a sync engine on your app can really be helpful for that if your use case allows it. But it's absolutely crucial to be aware of the pitfalls that come with it.
Re: How's Linear so fast? A technical breakdown
#29This is basically a thick client, and comes with according trade-offs. It's interesting and there are some best practices, but I can't help but feeling that either the author is a huge fan or the post is an ad (or "sponsored").
Re: How's Linear so fast? A technical breakdown
#30He chose the path to a better product rather than the path to a quick buck. That is definitely odd for a silicon valley startup