Kleppmann is one of very few people who not only understands technical topics deeply, but is a great speaker & a writer. Very much looking forward to it.
As for local first, I see it as a combination of a few things
- moving databases as close to users as possible [0]
- writing data without coordination with other nodes
- background sync
What this buys you is extremely high availability (as you can write without having to coordinate over a network), lower latency in general, because the database is right there (ideally within visual range), and more reliability, because network outages only effect background sync.
I'll also add that while local first is often seen in the context of b2c users, i.e someone using their smart phone while travelling on an urban train system that has network dead spots - I think the real use-case is industrial. A lot of facilities completely grind to a halt when there's a network outage, which is not that infrequent. To say nothing of in field and IoT applications in industries like agriculture and mining.
Thank you! To your point about industrial use, yes – this is interesting. For example, Actyx makes a software system for coordination within a factory floor, and Ditto performs sync between devices of cabin crew on an aircraft. These are nice examples of industrial local-first systems.
Well said. After linear.app showed the jump in UX for local data ('moving databases as close to users as possible') it became really easy to answer the questions below by saying checkout linear.app
* Why do we need local-first?
* We don't need offline support
* Google already has all my data, don't care about data ownership (a little orthogonal)
A big shout out to local-first community and Martin in particular.
I'm a big believer in local-first and just to share that next month we will be presenting in the IEEE rapid standardization workshop Bangalore for a new robust wireless PHY standard proposal for rural community utilizing local-first learning management system (LMS) as a potential case-study.
I'm really looking forward to this month Local First Web Meetup, Yonz has done a tremendous job organising them. It feels like being part of something new and growing, and to be honest I believe it is.
This is the 1 year anniversary addition, and what a year of talk it's been. Lots of exciting stuff is happing in the world of local-first software this year, and this talk from Martin is the perfect way to kick it off!
TBH Discord as the de facto place for communities to organize online is getting kinda annoying. The Discord apps really don't handle being in lots of such organizations at once, or really make them easy to deal with at all. I wish there was something halfway between Discord and Reddit for things like this.
I saw a rant from someone in the FSF about project names that give you no idea what the software is for or does. This adds another layer to the complaint.
There's probably a social aspect in which the name itself functions as a sort of shibboleth.
This event is the 1 year anniversary of the https://lofi.software meet-ups. It's great Discord community to join if you're interested in local-first software development.
P2P Matrix (https://arewep2pyet.com) is our answer to peer-first community software, but it's currently on hiatus thanks to funding issues. The best I can propose is normal Matrix - and then when P2P comes along, it'll replicate onto clients as easily as it replicates onto servers today.
Meanwhile, bsky is perfect for twitter replacement, imo,
Local-first has a lot of passionate folks around it! It doesn't feel super popular in orgs, but it feels like the right thing to do, like it's better for users.
It also implies tackling some very complex & difficult data syncing challenges. Which can be appealing! So many systems out there end up querying the same data again and again, end up sending large entity trees out. There's so many interesting promising improvements/rearchitectings we could be making that would improve client-server systems broadly, and local-first brings into focus many of these un-optimal data-architecture concerns while also layering in delay-tolerant challenges.
That's really it: local first is (can be, there are some good tools at hand too) a hard-mode, and getting good at it will improve computing architectures greatly from the client side out. If you want the best client side tech, if client side optimizations matter to you, local-first is a good place to be.
Also, Martin Kleppmann is speaking & is a revered elder guru of data systems (his book Designing Data Intensive Systems is the modern text on data systems, among many other notables). Where local first came from & where it's going sounds like a wonderful place to prognosticate from, and I'm so excited for a little shared view into Martin's crystal ball.
For those wondering what this is about (like I was). This is from their website [1]:
So, you want to build an app that has its data co-located with its UI? That works offline? That synchronizes between clients? And that lets its users own their data?
Welcome to the world of local-first web development.
I briefly worked with Martin at my first internship (Rapportive) and he immediately stuck out as someone who goes way above and beyond the typical when thinking through hard technical problems. Haven't heard his name in a while, but I'll definitely check out this talk.
I learned how to build a web application with FE, BE, DB, and distributed workers for my first job. But it wasn't until I read his book that I understood the enormous gap between building web apps and planet-scale web applications. The book saved me from bombing my interviews.
As for local first, I see it as a combination of a few things
- moving databases as close to users as possible [0]
- writing data without coordination with other nodes
- background sync
What this buys you is extremely high availability (as you can write without having to coordinate over a network), lower latency in general, because the database is right there (ideally within visual range), and more reliability, because network outages only effect background sync.
I'll also add that while local first is often seen in the context of b2c users, i.e someone using their smart phone while travelling on an urban train system that has network dead spots - I think the real use-case is industrial. A lot of facilities completely grind to a halt when there's a network outage, which is not that infrequent. To say nothing of in field and IoT applications in industries like agriculture and mining.
[0] the logical conclusion of "edge computing"