Support local emulator development

[jkomoros]

Some work was done recently (which issue?)

But there currently isn't a way to use it in all local testing with realistic data, because the prod backups have to be imported into the local emulator.

Looks like there's a way to run emulators:start --import=<blob of backup>: firebase/firebase-tools#1968

This would allow potentially getting rid of the dev instance! (Or maybe not, presumably there are still some differences in emulator vs hosted that you'd want to verify before a real deploy)

[jkomoros]

Some of the work on getting the emulator to work was done in #314

[jkomoros]

https://stackoverflow.com/questions/57838764/how-do-import-data-from-cloud-firestore-to-the-local-emulator

[jkomoros]

firebase/firebase-tools#1167 (comment)

[jkomoros]

firebase/firebase-tools#2175

[jkomoros]

Add a .gitignore for a snapshots directory.

Add a gulp command to fetch the most recent backup. It runs gsutil ls | tail and sees if it matches the existing snapshot or not. If it doesn't, it fetches it. It then the make-faux-firestore-export-file, which starts an empty emualtor, has it export to snapshots/CHANGE_ME, then renames the contents of that file and its name where it says CHANGE_ME to point to the most recent snapshot directory.

Then have a start-emulators which does emulators:start with --import pointing to the snapshot.

For extra credit, fetch-backup should also run a backup of prod if no backup is done. (and it should fail if backup name isn't defined)

And every tim ea new snapshot is downloaded, the other ones should be removed.

Also, consider having a hard-linked directory in snapshots to the most recent snapshot, which MIGHT allow the firestore export file to be made once and never again (but doesn't the name of the index file wihtin the directory also include the name of the export?)

emulators:start --import=./snapshots/ is sufficient, it will look for firebase-export-metadata within it

[jkomoros]

Auth can now be done in the emulator: https://firebase.googleblog.com/2020/10/whats-new-at-Firebase-Summit-2020.html?utm_source=firebase&utm_medium=email&utm_campaign=newsletter

[jkomoros]

Emulators have gotten pretty powerful: https://firebase.google.com/docs/emulator-suite/connect_firestore

[jkomoros]

https://firebase.google.com/docs/emulator-suite

[jkomoros]

https://stackoverflow.com/questions/57838764/how-to-import-data-from-cloud-firestore-to-the-local-emulator

[jkomoros]

Some of the limitations in the firestore emulator seem dangerous: https://firebase.google.com/docs/emulator-suite/connect_firestore

How the Cloud Firestore emulator differs from production
The Cloud Firestore Emulator attempts to faithfully replicate the behavior of the production service with some notable limitations.

Transactions
The emulator does not currently implement all transaction behavior seen in production. When you're testing features that involve multiple concurrent writes to one document, the emulator may be slow to complete write requests. In some cases, locks may take up to 30 seconds to be released. Consider adjusting test timeouts accordingly, if needed.

Indexes
The emulator does not track compound indexes and instead will execute any valid query. Make sure to test your app against a real Cloud Firestore instance to determine which indexes you will need.

Limits
The emulator does not enforce all limits enforced in production. For example, the emulator may allow transactions that would be rejected as too large by the production service. Make sure you are familiar with the documented limits and that you design your app to proactively avoid them.