I have a react app that use apollo as a grapql client.
The app now need offline support for a subset/subapp.
There is a service worker (thanks to workbox and webpack) that do the pre-caching of the assets of the app and works good.
Now there is a need to add support for the data.
The app need to works in offline mode like is online. That means, the user should be able to see al the data and perform a few mutations, that will need to sync back when the app gets online again.
I have the following approaches as possible solutions:
* Use a service worker:
Add a button that trigger a set of queries to retrieve all the required data for the offline work.
Use the service worker (workbox runtimeCaching) to cache all the responses for these queries.
When the app goes offline, the service worker will "serve" the response of the queries so the app will work "as if its online", performing the queries as normal with the service worker acting as a "proxy".
Set an "optimistic ui" approach for the mutations and use workbox backgroundSync to sync the changes (basically send the mutation action back to the endpoint when the browser get's online again).
* Use some apollo native approach (like apollo-cache-persist) to store the queries cache in localStorage. Trigger all the required queries for the app, persist that cache, rehydrate the app from the cache in further loads if the app is not online.
What would be a better and simple approach for an offline web app=
Service-Worker is your best bet.
I am currently thinking about this decision, and I have decided to stick with Service-Worker.
Related
I'm building a desktop client app (win/linux/mac) with a backend hosted in GCP (I'm considering other cloud platforms too). The desktop app should be minimalistic and provide access to local machine resources to the backend. And I'm looking for a way to invoke my app from the server (when some event occurs) and then the app would do some work on a local machine. Here's what I've tried so far.
Google Cloud Pub/Sub. Seems like it does what I need, but to make it work I have to create a service account, generate JSON key and store it locally, which is not good. I can restrict the service account access permissions, of course, but still it doesn't look good to me. Maybe there are other ways to auth my app running at the end user machine? I want to keep my desktop app minimal (ideally without UI, just an "agent" console process / Windows service). Maybe I could consider a login screen to connect the app with the backend, if that solves the problem, but I don't want to overcomplicate.
Google Cloud Run + SignalR / WebSockets. This solution also looks good, but it has one significant disadvantage. As long as there's at least one open WebSocket the Cloud Run instance is considered active and therefore billed. There are other difficulties related to scalability and container instances synchronization too.
What do you think about the options above, and what are the other possibilities? Am I left with REST API and polling for updates? I'm quite new to the cloud stuff so any help is appreciated. Thanks!
If you want to be able to invoke your local app from Google Cloud, you need 2 things
The first one, to register your app on Google Cloud, with, preferably, a auth mecanism (can be an API key for example). Like this, the GCP backend know where to call you app (which IP/port) and how (the auth mechanism)
The second is to have your app up and running and listen external communication. HTTP is the easiest way. Wait a HTTP call on the IP/port defined during the registration, check the auth and perform the process.
You can store the data (location and the auth) in firestore for example, and use Cloud Run to perform the HTTP call.
You can also inverse the solution and to poll (long polling or regular poll) the backend from the local app when it is running.
The 2 approach are possible, the second one slightly easier but can be challenging to manage the security.
I am developing an application which is used by multiple clients and the main goal of the app is to be used online. But a specific requirement is, it should be able to work offline too (only for a single client(s) in an emergency situation and for short time - 24 hours maximum). now I am using Django REST framework for backend and Jquery/AJAX frontend for GET and PUT etc. requests which update PostgreSQL DB on the backend. Now little research on the internet suggests the I should use PouchDB on the frontend and/or CouchDB on the backend. But my questions are:
Is it really possible?
If yes, then which DB should be used for the backend database?
When the offline client become available online, how we can synchronize the data generated online?
Can we cache some data on clients machine for offline availability purpose?
Is it still possible to use PostgreSQL for the backend? (I really want to use it !)
I am planning to use Firebase database and want to know how it fits in to the following scenario.
lets say I have a browser app, android app / iOS which uses Web Services to get / insert data, web services talks to the Data Base and returns data to the client.
This way I have to write code once in my web services and all the clients use that to retrieve and insert data to the database.
If I want to use Firebase, will I be following the same approach of having webservices between the client's and the Firebase DB.
I have done some sample Firebase examples where it it gets data from database directly without web services and in this approach we have to write our logic on each client (Web browser/ android app/ iOs app).
I have looked into this article
https://firebase.googleblog.com/2013/03/where-does-firebase-fit-in-your-app.html?showComment=1480073224245#c464815735109872173
The Pattern 2 has the server concept but that does not look appropriate in my scenario.
Can I have my web service and Firebase database and get data Synchronization capabilities.
Correct me if I am wrong and please suggest the approach I need to take.
Thank you for your valuable suggestions in advance.
Thanks & regards,
Rao Burugula
The article you link gives you the most common options for integrating Firebase into your app. Pattern 2 is the easiest way to use the Firebase Database and run your own server-side code:
In this model the Firebase Database sits between the app on the user's device and your back-end code. By using this model, you can still get all the benefits of the realtime synchronization, security rules and scalability, but also have back-end code that runs in a trusted environment.
Of course you can also go for a more traditional three-tier model, where your app server sites between the devices and the database. But in that case the Firebase database won't have direct interaction with your app anymore, so you'll have to take care of the realtime aspects of the synchronization (if you want those) in your own code.
I also recommend reading the Google Cloud documentation on using the Firebase Database and App Engine's Flexible Environments. The architecture described there is the same, but a bit more up-to-date:
We have Salesforce in house and need a proxy server to send API calls to an external Web Service interface (Box). Since Salesforce only allows 10 callouts per apex invocation, we need an external cloud server to send these callouts. Not having the money for CastIron or even Pervasive, I was wondering if we could implement this on Heroku?
Of course, Heroku needs to be able to receive Soap messages and send them.
If it can, this would be all we need for our Box integration. (I think)
Does Heroku have addons that receive Soap Messages?
Yes, Heroku is designed for, among others, use cases like this.
Run and scale any type of app.
Run any web or background process with any web framework or worker
type. Get direct, granular control over your app's workloads. Scale
distributed processes effortlessly with a single command. Easily scale
to millions of users.
Heroku Home Page
I'm thinking of using firebase to write a mobile app using PhoneGap and the HTML5 Application Cache.
Lets suppose each user has a list of TODO items. If the app is started when the phone is offline, will it be able to load data from the previous session and sync when a connection is established? If so I'm wondering how this is implemented because I couldn't find a reference to localStorage in firebase.js.
The short answer is: not yet.
Once an app has connected to Firebase, the client will cache data locally and be able to access data where there is an outstanding "on" callback even after a network connection is lost. However, this data is not persisted to disk, the "offline mode" will only work while the app is still running.
Full offline support will be coming in the future.
edit 2016 : full offline support is now possible for native iOS and Android apps: https://www.firebase.com/blog/2015-05-29-announcing-mobile-offline-support.html
An alternative to Firebase that solves this problem for JS apps is CouchDb (server) <=> PouchDb (JS client). If you've implemented a nice clean client side service layer then porting to PouchDb should be fairly straight forward since both are NoSQL/JSON databases. CouchDb also supports indexed map/reduce views.
PouchDb is a Javascript API that implements a fully offline CouchDb client. It can auto detect and use either local storage, IndexDb or WebSQL to permanently persist local data while online or offline. The PouchDb API can be used to access either your local or remote databases (just change the URL) and wire up full syncing or filtered syncing between the two. There are many useful PouchDb plugins, code samples and a small wrapper library to support AngularJS's Q promises API.
Using PouchDb, you can safely start up your app while offline and then days later restart your app and sync all your CUD data changes to the server. This can result in update collisions so CouchDb supports record versioning that is designed to detect and track this. Consequently, you'll likely need server side logic to resolve these collisions. This is unavoidable for distributed systems with offline synchronization and a key feature of CouchDb. I'm not sure that Firebase supports this MVCC feature.
PouchDb is basically a reimplementation of Apache CouchDb including it's synchronization protocol. Both CouchDb and PouchDb are well tested, free and open source. Being open source means that a CouchDb server can also be deployed as an Intranet service - optionally syncing to an external cloud service. There are a number of CouchDb hosting providers.
IBM's Cloudant hosting team recently added their BigCouch clustering features to Apache CouchDb 2.0 project so now you can scale from Micro Db (PouchDb) => Single Server => Multi-Master (Replicated) => Big Couch Clustered / Geo Clustered. Unlike MongoDb, CouchDb safely supports single server deployment.
NOTE: PouchDb can also sync to CouchBase using the same protocol but Couchbase !== CouchDb. It's a commercial product.
Another cool trick is that PouchDb can be run inside a NodeJS server as a replacement for CouchDb. I think it's not (yet) ready for production use but very handy for unit testing. See express-pouchdb.
Links:
Apache CouchDb Project
Couch Db - The Definitive Guide - Free book.
Pouch Db
AngularJS wrapper for PouchDB
Couchbase
CouchDb Hosters (Updated July 2020)
Compare CouchDb Hosters
Cloudant
Hyve
DIY
How To Install CouchDB and Futon on Ubuntu 12.04 - Digital Ocean
Secure CouchDB by using SSL/HTTPS
Docker + CouchDb:
Dockerizing a CouchDB Service
GitHub: Yet Another Dockerized CouchDB
Dockerized CouchDB 1.6.0 with stud SSL terminator
Security Model
One issue you'll need to consider when migrating to CouchDb is that it has a more limited access control model. This is partly due to it's replication algorithm. This blog post covers this in detail (better than the real definitive guide).
Matt Woodward's Definitive Guide to CouchDB Authentication and Security
CouchDB Security Overview
superlogin is an excellent NodeJS Passport/Authentication API that wrappers CouchDb allowing PouchDb offline apps to support social OAuth logins or username/password accounts. Includes a fully working demo and client side ng-superlogin Angular API.
Adapters
In practice you'll probably want to use WebSQL for your PouchDB storage as it performs much better. - Here's the full details on the storage adapters
PouchDb Extras
There's a staggering array of new cool "Christmas Tree" goodies always poping out the open source door from the prolific PouchDb community.
One the best features of PouchDb is all the open source plugins (37) and UI framework adapters (12).
Very old question, yet problem still persists.
I have been using firebase only for a few days and I couldn't find a satisfactory solution to this problem myself, so I thought I would share what I ended up doing.
On app start I check if I am online navigator.onLine. If not, I read from local storage and restore the firebase ref from it.
export const firebaseFromLocalStorage = (local, storeRef) => {
// assuming data is array
const localData = JSON.parse(localStorage.getItem(local)) || []
localData.map(obj => {
const key = obj['.key']
delete obj['.key']
storeRef
.child(key)
.set(obj)
})
}
Then proceed as normal. When the app goes online it will sync its local state with the server just like when it starts online and loses connection momentarily.
Off course this implies that localStorage needs to be kept in sync with your firebase ref. I do this at each get operation.
Hope this helps