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)
Comments
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.
[0] the logical conclusion of "edge computing"
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.
Hi Martin! It's Robert from Cambridge (you were my DOS :)). Glad to see your name pop up on HN!
Hi there, good to hear from you! :)
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)