These folks are exploring a local-first architecture. Some quotes:
… We’ve effectively created a data-centric scripting API for interacting with the application, without the original application needing to explicitly work to expose an API. We think this points towards fascinating possibilities for interoperability.
Since the introduction of object-oriented programming, most interoperability has been “verb-based”: that is, based on having programs call into each other using APIs. Indeed, new programmers are often taught to hide data behind APIs as much as possible in order to encapsulate state. Unfortunately, verb-based APIs create an unfortunate n-to-n problem : every app needs to know how to call the APIs of every other app. In contrast, data-based interoperability can use the shared data directly: once an app knows how to read a data format, it can read that data regardless of which app produced it.
… Overall, we think shared state is a better abstraction than message passing for many instances of integrations with external services.
This is similar to where I’ve landed in my explorations of IoT architecture. Every instance should have a copy of the data it is interested in and simply read and write that data. Everything else happens automatically in the background.
Yeah, I thought of Meteor too when I read this. I’ve been maintaining a project in Meteor since 2015 – it’s been a pretty good experience. While it’s not the hot new thing, it actually works very well and has given me very little trouble. As a community, Meteor is not on fire, but is making steady progress forward, seems to be actively maintained since it was sold to Tiny, and keeps up with new releases of related technologies such as React. It is interesting that when the original Meteor group veered off in the Graphql direction, they may have taken a step backwards into APIs, instead of focusing on the problem of data synchronization.
The biggest problem I have with meteor is it does not extend outside the browser/JS ecosystem, so it does not easily extend to IoT devices where I also need data synchronization. Also, it tends to be one-way – you subscribe to a data set, and then get updates, but you can’t disconnect, make changes, and then intelligently sync up later.
I completely agree. Meteor is a great framework for web apps, but there are other kinds of data-intensive applications. What we actually need is a software library. I’m also not a fan of a declarative query language; I think that a declarative API is better.
Traditionally, databases are separate processes, potentially on separate servers. I really like the idea of a software library, as it allows you to embed the database logic (frequently a subset of the overall database functionality) right into your app directly.