Here’s a link that was featured in the Syntax newsletter today:
Most apps should use a sync engine instead of doing RPC.
It’s more clear to me now than ever before: This will become the new default for future app development.
Gets rid of massive amounts of complexity and empowers frontend developers
The OP defines sync engines like this later in the thread:
An end-to-end system that syncs data directly into clients (often into a client-side database) instead of the client having to manually fetch/post data.
Correct me if I’m wrong, but doesn’t that sound like Meteor live data? If so, maybe we should add some posts to this thread.
You are partly correct. However, Meteor live data doesn’t cache or sync things yet. There needs to be more work so it could be considered a true sync engine. Right now, we only fetch the data (initial add) and then react to changes from the server.
Given that Meteor caches data in client-side MongoDB, what are one or two of the differences between Meteor live subscriptions, and a true sync engine?
Yup, never used Meteor without adding persistence either.
I’d say with few packages/lines of codes, Meteor is exactly what they’re advocating for.
The only thing I’d really loved improved is subscription performance and decoupling of update queue, it was always pretty standard part of many boilerplate codebases to introduce offline-first/ssr/webpack to Meteor.
