[throwaway_bad]

Having client state just be a replica of server state solves so many problems I don't understand why the concept never caught on. Pouchdb/couchdb are still the only ones doing it afaik.

Instead we have a bajillion layers of CRUD all in slightly different protocols just to do the same read or write to the database.

[koolba]

When your data is public and immutable, this approach is very pleasant. The client becomes just another caching layer and worst case it's presenting a historical version of the truth. You can even extend this across tabs with things like local storage.

This breaks down quickly once you have data that could become private or mutate rather than append.

[tehbeard]

This what stopped me exploring couchdb further.

The "one db per user" model for private data made using other features like views etc more difficult when you have to upgrade,edit,remove them.

Mutability wasn't really a problem, either present the conflicts to user and pick one or write code to merge if possible.

[rockwotj]

I think the Firebase Realtime Database and Firestore have a good model for offline and being able to have private and mutable data. It does get complex but the Firebase SDKs do the heavy lifting for you here.

[megous]

In reality data can't become private again, after being available. You may try to contact all users to delete their copy, but they may not respect that.

[liuliu]

In short, server data is more normalized than the data client needs. As you get closer to view layer, your data gets denormalized further and further. Client-server interaction sits somewhere in the middle to both minimize the bytes-over-wire as well as the round-trips to the backend to get up-to-date.

Take a look at GraphQL, its central promise is to let client choose what's the optimal data it needs (that often denormalized through nested GraphQL queries), and send it in one batch.

It is not to say there shouldn't be a simple replica. It is just if we want it to be a simple replica, we should have a server-side mirrored some-what-denormalized representation rather than just the raw server-data models.

[dustingetz]

Data security is a huge issue, Facebook.com has very specific whitelisted access patterns encoded as CRUD endpoints. 1) Users want to make sure their data is used in non-creepy or non-stalky ways; 2) Facebook's business needs to control the access point so they can serve you adds or otherwise monetize. So the API exposes only limited access patterns, the API TOS disallows caching, and they go to great lengths to prevent scrapers.

If immutable fact/datom streams with idealized cache infrastructure becomes a thing (and architecturally i hope it does) it's going to need DRM to be accepted by both users and businesses.

[gwbas1c]

> Having client state just be a replica of server state solves so many problems I don't understand why the concept never caught on.

As soon as your server state is larger than whatever your client can handle, the whole metaphor breaks down.

[ralusek]

I'm assuming that the client state would be a lazy representation of the back end state, that only pulls data as needed. The result being that local and server state must both be treated only as asynchronously accessible.

[gnur]

Firestore is doing something very similar and it is very easy to use.

[dsun180]

There is a limit on what data can be replicated with the client. For a simple chat-app you can replicate all messages of a user. But you would never replicate the whole state of wikipedia to make it searchable.

[sergiotapia]

MeteorJS tried it and failed miserably. It doesn't scale.

[vlasky]

Wrong. This is popular anti-Meteor FUD spread by people who don't know how to use its features properly or have the engineering/computer science background to design a system to be able to manage computational complexity or scalability.

In 2015, my business implemented a Meteor-based real-time vehicle tracking app utilising Blaze, Iron Router, DDP, Pub/Sub

Our Meteor app runs 24hrs/day and handles hundreds of drivers tracking in every few seconds whilst publishing real-time updates and reports to many connected clients. Yes, this means Pub/Sub and DDP.

This is easily being handled by a single Node.js process on a commodity Linux server consuming a fraction of a single core’s available CPU power during peak periods, using only several hundred megabytes of RAM.

How was this achieved?

We chose to use Meteor with MySQL instead of MongoDB. When using the Meteor MySQL package, reactivity is triggered by the MySQL binary log instead of the MongoDB oplog. The MySQL package provides finer-grained control over reactivity by allowing you to provide your own custom trigger functions.

Accordingly, we put a lot of thought into our MySQL schema design and coded our custom trigger functions to be selective as possible to prevent SQL queries from being needlessly executed and wasting CPU, IO and network bandwidth by publishing redundant updates to the client.

In terms of scalability in general, are we limited to a single Node.js process? Absolutely not - we use Nginx to terminate the connection from the client and spread the load across multiple Node.js processes. Similarly, MySQL master-slave replication allows us to spread the load across a cluster of servers.

For those using MongoDB, a Meteor package named RedisOplog provides improved scalability with the assistance of Redis's pub/sub functionality.

[mch82]

> RxDB can do a realtime replication with any CouchDB compliant endpoint and also with GraphQL endpoints.

PouchDB is mentioned a couple of times, including one “PouchDB compatible” mention. Wondering what unique use cases RxDB supports?

[dtech]

That's exactly the model that Apollo Client library uses (GraphQL-based data store for react), and teams I spoke that tried it are quite enthusiastic for this reason.

[skrebbel]

How would that work, with, say Twitter? Copy all tweets ever to each browser?

I mean, that's why it didn't catch on right :-) It's hard :-)

[throwaway_bad]

Same way you scale replication for any server, by sharding and only replicating the shards you care about.

The "shard" could just be that users own feed in this case. Then you get offline for free where user adds a tweet and it appears immediately, replicating back to server when he goes back online. The server replica side will need to be a lot more complicated to deal with broadcasting but I don't see why it won't work.

[bayesian_horse]

I've heard somewhere that Twitter maintains a copy of all tweets in a user's timeline for that user.

If I had to make a Twitter clone with CouchDB, I would probably have one timeline document per user, and maybe one per day to limit the syncing bandwidth.

[azr79]

Security is a huge deal