This works for both SPA (highly recommended) and MPA (vintage apps)
What our team implemented until now is:
1) plain appcache - the application files, that can be used offline, are cached
on the browser. When you need to update application files just modify appcache
manifest file. There is a part that needs to be always on-line: authentication,
external services, reporting etc. The application is web 2.0.
2) PouchDB to store the application files, usually in _design/app as
attachments. Each time when data is replicated the application files are also
checked. This application may be web or hybrid (Cordova/Phonegap)
3) CouchBase Lite to store everything. In fact the whole application is just a
wrapper around CBLite. So when one needs an application it will point to the
sync url (e.g. http://myapplication.cloudant.com/database), choose the
application, replicate the application and data, operate offline, sync with
server. The updates, other modules and other applications are deployed in the
same way. This is a boilerplate, a bootstrap, an application loader and we use
CouchDB like an application deployment repository and document store - somehow
similar with Cordova plugin repository. The only issue you may have is with
Apple - they do not agree with this method for application deployment.
Make your choice - as you like it!For human operator press # :-) Dragos
STOICA0735220023
În Luni, 28 Martie 2016 4:22:15, Giovanni P <[email protected]> a scris:
using this second approach you can also use PouchDB for better flow.
1. users go the hosted SPA in your URL;
2. the first time they load the page, due to the presence of an appcache,
files will be stored in the browser and remain accessible when offline;
3. they can start inputting data or doing whatever your app does using
PouchDB, which will be automatically loaded and will store data in the
browser;
4. whenever they want, they can input a CouchDB URL somewhere in the app;
5. from that point on, the data from PouchDB will be synced to the CouchDB
and vice-versa.
On Sun, Mar 27, 2016 at 10:18 PM, Giovanni P <[email protected]> wrote:
> 2 is probably your best option. Just use attachments. /db/doc/index.html
>
> better yet, if possible: host the static files for the SPA yourself, use
> the HTML appcache so the files will be avaliable for the users even when
> offline, then let the users input their own CouchDB URL/passwords in the
> app. store all this relevant data client-side, on localStorage, and let
> this hosted SPA connect to their local CouchDBs.
>
> On Sun, Mar 27, 2016 at 9:17 PM, Kyle Snavely <[email protected]> wrote:
>
>> Hi Darryl,
>>
>> I've had really good luck using Python Flask web services supported by a
>> CouchDB (Cloudant) backend. That will expand your target support from
>> Windows to most platforms, and might be less overhead if you're talking
>> about a fairly simple application. I've been down the couch-app route
>> (successfully) but unless you are talking a very basic application (just
>> HTML/client-side JS) I've found using an external tool for the web service
>> to be advantageous. Node would likely provide similar advantages --
>> allowing you to break down the problem into a client/server space.
>>
>> Cheers,
>> Kyle
>>
>> On Sun, Mar 27, 2016 at 8:10 PM, Darryl Wagoner <[email protected]>
>> wrote:
>>
>> > I have been tinkering with CouchDB for about a year and I really like
>> it.
>> >
>> > What I have been able to find out the best way to do is deploying a
>> CouchDB
>> > to an end users computer. I expect the end users to be fairly dumb.
>> > During the key times they application will be used, Internet may or may
>> not
>> > be available or I would host it on a web hosting service.
>> >
>> > The options I have thought about are:
>> >
>> > 1. Tell them to install CouchDB and writing a C# web server that runs
>> the
>> > SPA. Downside is I limit my customer to windows
>> > 2. Use CouchDb to server the JavaScript/HTML files. Not a bad
>> solution,
>> > but I can find any docs on how to do that. It would be great to
>> repackage
>> > CouchDb to have my files.
>> > 3. Have them install Apache or such to server the files
>> > 4. Have them install another web service ie: nodejs, etc
>> >
>> > Suggestions?
>> >
>> > thanks
>> > -darryl
>> >
>>
>
>
