Since then something is changed, but not these points:
Low Hanging Fruit - Integrating Push to Keep Client Data in Sync
All complex applications allow data manipulation outside of user interaction. I mean not all data changes are done by users sitting on there devices. The server may be syncing something in the background which brings in new data. How is the client going to know about it? Is it periodically polling the server? That’s crazy. It’s easy to write code that pushes all changes. It should be equally easy to push that data into data store regardless of what push service you’re using. Ember-data stores should define a simple interface to accept messages over push. Perhaps, the store itself is a web socket client which can be connected to your push stream. There are many different ways to do this. Everyone will solve this uncomplicated problem in the same way. This is exactly why the framework should do it. Ideally, there should be no problems if you switch from Websockets/Pusher/Faye/PubNub/Boxcar/etc. The messages always arrive.
Low Hanging Fruit - Local Storage Support in Ember Data
Loading screens blow. I downloaded the data. I shouldn’t have to keep going to the server to get it again. You are probably using HTTP caching, but that still creates network requests. Getting good performance means cutting down on network requests. It’s not very complicated to do in Backbone. Ember data should support local storage by default. For example, you create your store and you can set storedLocally: false if you don’t want it stored. I think that adding local storage to support to the framework and enabling it by default would be a major win. Our app is dealing with a lot of data. Loading in data takes time and reduces performance. We only want to download that data once.
Ambitious Addition - Handling Bad Connections and Crashes: Gateway to Offline Support
Network connections go down. Browsers crash. These things happen. We have the tools to make applications failure resistant. Let’s take your basic todo list application. The user adds a todo and for some reason the server is down. What happens? Do we just say “opps, sorry. Please try again.” I don’t think so. The framework itself can handle these cases. Here is a proposed solution. Use a messaging queue backed by local storage to buffer requests to the backend API. Requests that match a set of failure conditions (503, 504, or timeouts) are enqueued again and will be tried again later. This is a step towards offline support at the data layer. There has been some discussion about this. There are few things in the way. A request/operation object needs to introduced. This object is persisted in the queue. The adapter takes the request objects then does whatever logic is needed and sends them to the server. These objects would need to be tied to records as well. Since operations to individual records are being tracked, this means you can cancel operations to specific records. There are also race conditions. Hell, there are lot of complicated things to worry about, but solving this problem is massive. Imagine if applications simply got support for this by using Ember. Boom, your application has some level of fault tolerance and it may even save you a few customers. I’d say this is hardest problem to work on but the pay off is fantastic.
Maybe I’m wrong, but is there a way today to handle these problems?
@broerse that addon in specifically designed for pouchDb. I suppose that @johnunclesam and the orignal author of the post was thinking in simething more similar to ember-sync great project that is unmaintained from 2015 as far as I can see …
The topic may also grow obsolete with the spread of SW background syncing, however that is not going to work everywhere for now…
@johnunclesam@nandosan ember-data is just a cache for a database. So you need something like PouchDB to make that database local. If your data can be offline you can have hasMany relations that don’t have belongsTo relations yet. ember-data can handle this if your adapter handles Eventually Consistency. We use ember-pouch in progressive web apps as an ember-data offline solution. ember-sync works just like ember-pouch but uses IndexDB and has no Eventually Consistency code so there will be problems with relational data. Ember-pouch uses IndexDB or WebSQL if there is no IndexDB available. See how it is used for hospitals that have sometimes no internet connections, GitHub - HospitalRun/hospitalrun-frontend: Frontend for HospitalRun
You could argue the ember-data needs Eventually Consistency code to support offline databases so you don’t have to handle this in the adapter. I don’t think ember-data should support IndexDB, WebSQL, Service Workers, and all node.js databases for fastboot. That is why we need adapters. After reading your questions again I still think ember-pouch almost solves all the problems but you don’t have to use it
And if I need server (Go, Ruby, C#) checking when migrating from offline to online? With PouchDB I can only have a “dummy” sync with an exact reply in CouchDB (or similar server). I need something like “ember-sync” for repeat - when I’m online again - all the operations but with server-side check.
Is it clear now?
PocuhDB (and ember-pouch of course) is amazing for the exact replication of my ember-data situation. What I need more is a server consult for all my operations (before offline, now online). The eventually conflicts are handled by the server, this is my problem and I can handle it server side.
Maybe I can use ember-pouch for “simply” “dummy” replication and then I can do operations other ways? What do you suggest, @broerse?
It is clear the whole time I think it is sometime faster to sync data from CouchDB to some Go, Ruby, C# service on the server and let CouchDB/PouchDB do the syncing. You can also take a look at:
Thanks @broerse, I know the amazing “Ember localStorage” but what I/we need is a sync. Ember localStorage is the same as “ember-pouch” (without sync logic) or just for something fast. What we need is an offline first scenario = syncing offline/online with backend.
I can sync data from CouchDB and my server backend, but what I need is to handle conflict immediately when the user is back online. And syncing the server with CouchDB I need a way to enter the client of the user when the server, after the CouchDB syncing, has to tell something to the client.
It’s a mess.
“ember-sync” is the real way. “Ember localStorage” is not an alternative to “ember-pouch” or to what we need.
CouchDB/PouchDB is the best sync around. So telling something to the user and back can be done by just listening to the message-in and message-out models or just one message model. PouchDB sync will handle the updates on both sides. NPM is a CouchDB database so if you need one database per user to transport messages to specific clients you don’t have to worry about scaling CouchDB to millions of users. See also IBM Developer
It is just how ember-data works. If you have an ember-pouch application adapter and a JSONAPI catogorie adapter (without the s) your categories model will not be synced by ember-pouch. The only problem with this is that belongsTo/hashMany relations from categories to some other model can’t be used.
The problem is that cross adapter relations don’t work well in ember-data for any adapter. So than ember-data is not the solution for you. A problem is always solved by a bigger problem
