Abstract storage implementation?

[rexxars]

Hi,

This project looks like exactly the thing I need for a bunch of things I've been wanting to do. I tried including it in a project, but it seems Realm has a known issue where debugging JS remotely in react native fails on Android (see for instance realm/realm-js#562).

I was wondering how closely this project is tied to Realm, and whether or not you could achieve the same functionality with AsyncStorage, for instance? I understand you wouldn't get quite the same performance characteristics, but in many cases that isn't really an issue - rather you are looking for the queue semantics.

[billmalarky]

Realm was chosen for persistence because the queue requires transaction support for several reasons. Due to this requirement AsyncStorage cannot be used (I put a fair amount of thought into trying to come up with a workaround but in order to touch the queue asynchronously in parallel - such as via the UI thread and a worker thread or throwing jobs on the queue asynchronously - transactions must be used). I'm on mobile for a few days, but I've discussed the issue with realm debugging (and why I chose realm) on Reddit more thoroughly here (read the full comment chain): https://www.reddit.com/r/reactnative/comments/7oyw7z/react_native_queue_advanced_jobtask_management/dse0nvf I'm certainly open to alternative storage solutions so long as they support transactions if you have a solution you can suggest. For what it's worth I was not able to find a good cross platform react native sqllite library because that would be ideal to use.

…

On Tue, Jan 23, 2018, 6:33 AM Espen Hovlandsdal ***@***.***> wrote: Hi, This project looks like exactly the thing I need for a bunch of things I've been wanting to do. I tried including it in a project, but it seems Realm has a known issue where debugging JS remotely in react native fails on Android (see for instance realm/realm-js#562 <realm/realm-js#562>). I was wondering how closely this project is tied to Realm, and whether or not you could achieve the same functionality with AsyncStorage, for instance? I understand you wouldn't get quite the same performance characteristics, but in many cases that isn't really an issue - rather you are looking for the queue semantics. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#3>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABxTUwvjVR7UtI0heMBMtOR4X4Bwkw1_ks5tNe2egaJpZM4RpvJp> .

[rexxars]

Thanks for the background and thorough explanation.
It's unfortunately pretty much impossible to use it as it is, since we really do need to debug the apps. I had a quick look for realm alternatives, but there's nothing that comes close to how easy it is to set up :/

[billmalarky]

@rexxars do you mind doing a rapid install of react-native-queue into your project and quickly throwing up a test worker and some example jobs then trying remote debugging?

I used chrome remote debugging for console logging etc when I was building this and performance was never a problem.

I also just fired up the workspace app I used to build react-native-queue and set up a bunch of debugging breakpoints, pause on exception etc, and walked through the code line-by-line and performance was never an issue.

I have a feeling that react-native-queue's realm footprint is just so small, that the known debugging performance problem is really a non-issue for react-native-queue.

For others, I'll paste the relevant part of the reddit thread here:

Typically realm native code communicates directly with your JS code via a private React Native api (ie, realm native code makes calls directly to JS code and vice versa), so it has great performance. This is possible when the JS thread and native code threads are running on the same device/simulator. However when using chrome debugging, your JS code is NOT run on your device/simulator, it is run inside of the chrome browser, while all the native code is running on your device/simulator. As a result, instead of realm native code making direct calls into your JS and vice versa, realm has to communicate using blocking ajax requests to chrome. You can imagine how awful performance is in that situation (well you don't have to imagine I guess).

The good news is this. These performance hits occur each and every time you touch realm. If you minimize exposure to realm, you minimize the debugging performance issues. React Native Queue is backed by realm, but the footprint is quite small (we only hit realm when a job is created, and when we pull jobs off the queue, and on job completion, that's pretty much it), such that I'd be surprised if the problem was anywhere near as bad as debugging a large app where realm was used for all persistence logic.

TL;DR react-native-queue doesn't seem to be hitting realm hard enough to actually cause the debugging performance issues that have people concerned about realm.

[rexxars]

I'm afraid it's even worse than that - even without actually using the queue for anything, the app simply hangs on startup. Something like a minute before it actually kicks off and continues. Realm does do a bunch of weird things, like attempting to contact the remote debugging server over the 4G (public) IP, so it might just be that it's trying to connect to an incorrect IP and eventually times out and tries the next in line, for all I know.

I'm confident this doesn't have anything to do with your library, I was just hoping there was an alternative that is as easy to get up and running, but I have been unable to find one.

[billmalarky]

That's so weird, I've run this queue on simulated iOS/Android as well as on an actual android device and have never run into this problem. What version of react-native are you on if you don't mind me asking? That problem seems so glaring that I'd imagine just about everyone would report it, but I've only heard about it from some people, and I know that a fair amount of projects are already using react-native-queue (in addition to myself of course).

[rexxars]

I'm on 0.52.1

[juliancorrea]

@rexxars I posted in another issue in this repo (#9) a workaround for it. The correction was done in realms(master), but there is no release yet.
Many devs are discussing this issue in: realm/realm-js#1711

[giautm]

I want to use this project with another storage layer (ie Expo’s SQLite). So please abstract the data storage layer