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"
* 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)
I have a short list that I'm testing but none of them have the features we need: 1) Live video 2) # channels and 3) adoption
Even moving off Twitter has been a challenge but I am optimistic about bsky
"Join our Discord community and attend the next meetup"
Hmm. :-)
We are actively looking for a solution, drop a line in the thread
There's probably a social aspect in which the name itself functions as a sort of shibboleth.
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.
Martin has had a material impact on my career. I don't think I would have gotten my job at LinkedIn if it wasn't for his book, Designing Data-Intensive book: https://www.oreilly.com/library/view/designing-data-intensiv...
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.
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.
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!
If your new to all this, the term "Local-first software" originated from this Ink and Switch paper by Martin Kleppmann https://www.inkandswitch.com/local-first/
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.
