Local file geodatabase access using ArcGIS API for Javascript

[maglourenco]

Greetings everyone,

I would like to ask if it is already possible to access the local file system using the JS API when developing for mobile.

I would like to have a sort-of offline app where a sync-enabled file geodatabase would store data locally and periodically sync with a Feature Service.

Is this possible?

Thanks

[ReneRubalcava]

There's nothing in the API to do this natively. There is an FGDB API you can try some stuff with.

https://github.com/Esri/file-geodatabase-api

Years ago, I wrote a node extension to play with it.

https://github.com/odoe/node_fgdb

It might be possible compile this to web assembly and use it with the a web app, but I haven't tried that and I'm not sure if anyone else has. You would still need to write a thin API layer to expose some fgdb methods, but could be a fun project.

[maglourenco]

Thanks for the answer and for sharing your extension.

So essentially there is no native way, or workaround, to get it to work offline with the JS API correct? I saw that if we developed as a PWA we could have access to limited offline capabilities but I haven't dug into that yet.

[ReneRubalcava]

PWA will only get you so far. It will cache static assets, like JS, CSS, images, stuff like that. But map data not so much. Plus there is licensing of offline that plays into it as well. You could do some light disconnected style work, like for field apps. Say you have spotty connection in the field, you can start DIY edit session with a local FeatureLayer, then do a batch edit when you have a better connection. I wrote about that here.

https://odoe.net/blog/edit-sessions

[maglourenco]

Thank you for your insight and your page.

Basically, my decision is between continuing the development with the Runtime SDK for Android or moving on to the JS API. With the Runtime SDK, I get the offline workflow, with the JS API I get the stream layer. 

So the issue here is deciding whether to DIY the offline workflow on the JS API, or DIY the stream layer on the Runtime SDK. Do you have any idea what might be less time-consuming and more feasible?

Thanks