Firebase Realtime Database offers powerful synchronisation across clients... But it does seem to have rather high bandwidth charges.
I was hence wondering if it is possible to perform an "initial sync" on clients, so to speak, where we load a reasonably recent version of the database from elsewhere (with lower bandwidth charges), and then have the Firebase SDK (flutter, web) sync from there instead of downloading all the required parts of the database. Maybe a "load from JSON" sort of function or similar.
Seeing as to how the Firebase SDKs do seem to store some state locally on clients (for offline operation) and sync up with Firebase once online again, I was wondering if it might be possible to:
set the local state to our "recent version" downloaded from another source, along with that version's timestamp
trick the client SDK into thinking that we are recovering from an "offline" state
then let the SDK communicate with the Firebase server to get changes since our last timestamp
Are there any approaches to achieve the effect of saving bandwidth through performing an initial sync from a cheaper source? Thanks in advance!
Unfortunately every get() and every realtime listener will load all data it needs from the database. I had the same idea when started working with the Firebase RTDB but unfortunately at this moment it's not possible.
The only way to reduce the bandwith is to read data in smaller chunkgs as possible.
You might want to take a look at AceBase, which is an open source alternative for the Firebase RTDB. It offers the same functionality, has powerful indexing and querying options, offline support, synchronization etc. Easy to setup and you can host it anywhere you want. You can even use it as a standalone realtime database in the browser, so you could also use it in combination with Firebase to perform custom synchronization between your front and backend db's. AceBase is free and its full source code is public.
Related
I have a requirement in a react project to use firebase real-time db and sometimes this may be during low or no connectivity.
I know that Firestore has a native offline capability but just wondering how could I make firebase db work offline.
The requirements have quite a heavy R/W workload, so I'm trying to avoid Firestore in this instance.
Should I use something like indexeddb? Has anyone had anything similar? And regarding client side rest data encryption would you recommend something?
Many thanks
There is no built-in support for persisting data between reloads in the Firebase Realtime Database SDK for JavaScript/web. It does handle intermittent loss of connectivity, as long as the user doesn't reload the page.
If you want to persist data between page reloads, you will indeed have to implement that yourself - for example by storing the snapshot values in indexeddb.
Also see:
Does Firebase JavaScript API catch-up with server when re-connected
Offline persistence in Firestore enables the browser to store records that were not uploaded to the server (offline) even after the session was closed (Browser exit)
Please see: https://firebase.google.com/docs/firestore/manage-data/enable-offline
However, firestore does not offer any officially supported way to clear the Chace when a user logs out from his session. Please refer to: https://youtu.be/qGAIimfrBB4?t=257
Recently they released the function clearPersistence, but they clearly state that is not meant for security reasons and recommend to disable Persistence if security is an important factor for you. Please see: https://firebase.google.com/docs/reference/android/com/google/firebase/firestore/FirebaseFirestore#clearPersistence()
Note: clearPersistence() is primarily intended to help write reliable
tests that use Cloud Firestore. It uses an efficient mechanism for
dropping existing data but does not attempt to securely overwrite or
otherwise make cached data unrecoverable. For applications that are
sensitive to the disclosure of cached data in between user sessions,
we strongly recommend not enabling persistence at all.
I want to understand better what's the security hole with using "ClearPersistence" on logout of the user.
Anyone experienced with that? Any other working solution that enables you to remove all the Firestore cache after a logout?
There is no guarantee that your code will run in the browser (or any other client). For example: a malicious user can take the configuration data from your application, and call the API to get access to the same data in your project, but then store it wherever they want.
Another malicious user might prevent the app from clearing the local cache, or quickly copy the local cache file to another location to have a copy before it is cleared.
And these are just two if the simplest examples. The simple fact is that you should assume that any data that exists/persists on the client can be seen by any user who has access to that client.
I need to design an offline-first application with sync capabilities so I decided to go with CouchDB. Since I will deploy this application on user's workstation he/she has the capability to tamper with data (in his/her local database e.g. PouchDB). AFAIK, CouchDB only offers validation functions (which only has access to incoming document, its previous version and userCtx) to avoid this, but most of the times this validation depends on the business logic. Is there any way to manage this scenario?
Anyway, if the user tampers the "local" db, its modifications will be deleted when the sync occurs (if the remote db is the master).
Or if you choose 2 ways sync, the master db is modified by the user...
Im coding a static page app using Angular, which shows various Instagram and Twitter posts of the company, and shows the details of the members. I have few questions regarding this, and would like any help.
Firstly, I have about 100+ contacts to display on the first page. Should I create a Json by myself and retrieve it from the service, or should I create a backend and save it there ? I do not have any backend as of now.
Other thing, I was able to retrieve Instagram Json with media content using their API, the doubt im facing is, once I have the call done, will the Json change automatically when the user adds/edits their posts? Or will the Json be the same as I first called it with? Any help is appreciated. Thanks.
For your case, as you have fewer data using Firebase is the best approach. If you write a backend and maintaining it would cost you more. You can use Firebase service URL to retire those records. In future, if you want to add more data it would be easy.My suggestion is Firebase.
Should I create a Json by myself and retrieve it from the service, or should I create a backend and save it there ?
Are you revealing credentials or other sensitive information in the client? That would be one reason to have a backend apart from Instagram or Twitter. Do you envision exhausting API rate limits of Instagram or Twitter APIs? That would be another reason; you could cache results in your backend to reduce external API traffic. Do you need to process (reduce? translate?) the data before it gets to the client, or are you satisfied with performing any processing on the client (e.g. is it fast enough)?
TL;DR: It depends a lot on your particular requirements.
If you do want a backend, the recommendation in the answer from #praneeth-reddy to use Firebase is excellent. If you only need processing/transformation but no caching or separate storage, then AWS Lambda may also be worth considering. If you need more control (build vs. buy), you could write your own backend.
...will the Json change automatically when the user adds/edits their posts? Or will the Json be the same as I first called it with?
Angular can help you update content automatically if the client side data (think browser JavaScript memory) changes via its automatic change detection functionality, but you would have to provide your own logic (e.g. in Angular services perhaps leveraging RxJS) to update the client side data based on data from the APIs. You could poll to update periodically, or for better performance listen for changes using an asynchronous event/push mechanism such as websockets or streams.
I have an ionic app and a Parse.com backend. My users can perform CRUD functions on exercise programmes, changing every aspect of the programme including adding, deleting, editing the exercises within it.
I am confused about when to save, when to call the server and how much data can be held in services / $rootScope?
Typical user flow is as below:
Create Programme and Client (Create both on server and store data in $localStorage).
User goes to edit screen where they can perform CRUD functions on all exercises within the programme. Currently I perform a server call on each function so it is synced to the backed.
The user may go back and select a different programme - downloading the data and storing it localStorage again.
My question is how can I ensure that my users data is always saved to the server and offer them a responsive fast user experience.
Would it be normal to have a timeout function that triggers a save periodically? On a mobile the amount of calls to the server is quite painful over a poor connection.
Any ideas on full local / remote sync with Ionic and Parse.com would be welcome.
From my experience, the best way to think of this is as follows:
localStorage is essentially a cache layer, which if up to date is great because it can reduce network calls. However it is limited to the current session, and should be treated as volatile storage.
Your server is your source of truth, and as such, should always be updated.
What this means is, for reads, localstorage is great, you don't need to fetch your data a million times if it hasn't changed. For writes, always trust your server for long term storage.
The pattern I suggest is, on load, fetch any relevant data and save it to local storage. Any further reads should come from local storage. Edits, should go directly to the server, and on success, you can write those changes to localstorage. This way, if you have an error on save, the user can be informed, and/or you can use localstorage as a queue to continue trying to post the data to the server until a full success.
This is called "offline sync" or sometimes "4 ways data binding". The point is to cache data locally and sync it with a remote backend. This is a very common need, but the solutions are unfornately not that common... The ideal flow would follows this philosophy:
save data locally
try to sync it with server (performing auto merges)
And
Periodically sync, along with a timer and maybe some "connection resumed" event
This is very hard to achieve manually. If been searching modules for a long time, and the only ones that come to my mind don't realy fit your needs (become they often are backend providers that give you frontend connectors; and you already have an opiniated backend), but here they are anyway:
Strongloop's Loopback.io
Meteor
PouchDB