Firebase-tools: Emulator support for database commands

[prescottprue]

It would be great to be able to use the database commands, such as database:get, database:set, and firestore:delete to interact with the emulator suite.

Since the emulator mentions setting the environment variable FIREBASE_DATABASE_EMULATOR_HOST=localhost:9000, then maybe it could work by detecting that variable.

To load the projects path from the emulator instead of the hosted instance, it would be great do the following:
FIREBASE_DATABASE_EMULATOR_HOST=localhost:9000 firebase database:get /projects

It would also be great to have this for Firestore delete:
FIRESTORE_EMULATOR_HOST=localhost:8080 firebase firestore:delete /projects/ABC123

NOTE: This has already been submitted as a feature request through the support page. The response was that the feature would be created on my behalf - creating this since one doesn't appear to have been created.

[samtstern]

@prescottprue thanks for filing this, I think this is a very good idea and there are a few ways we could implement it.

1. We use some environment variable or flag to point existing firebase whatever commands at the emulator. This is likely simple but the downside is that it would be really easy to mix up emulator and prod.

2. We create some sort of "emulator REPL" which you can run and then run commands against the emulator interactively. We could even drop you right into this REPL after emulators:start sets things up. The downside is that this would not be as scriptable.

What do you think? Any other major options I am missing?

[prescottprue]

For us, just passing the environment variable would be easiest since we are planning on scripting things. I also like the idea of the REPL, but it seems like it would mostly be useful for local dev which could also just make use of the environment variable method

Not sure how easy it would be, but it might also work nicely if there was a --emulator flag that could be passed to database commands and then it would pick up an emulator running through tools (so that the port number doesn't have to be passed in an environment variable)

[samtstern]

I like the idea of --emulator as a consistent flag and it wouldn't be too
hard to implement. I'd rather not have people have to export the host and
port every time like you said.

On Wed, Feb 5, 2020, 9:43 AM Scott Prue [e-mail] wrote:

For us, just passing the environment variable would be easiest since we
are planning on scripting things. I also like the idea of the REPL, but it
seems like it would mostly be useful for local dev which could also just
make use of the environment variable method

Not sure how easy it would be, but it might also work nicely if there was
a --emulator flag that could be passed to database commands and then it
would pick up an emulator running through tools (so that the port number
doesn't have to be passed in an environment variable)

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/firebase/firebase-tools/issues/1957?email_source=notifications&email_token=ACATB2UC7YWYW4TS3AUIIQTRBL3CZA5CNFSM4KQAEGU2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEK4KNHY#issuecomment-582526623,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ACATB2V3CH3UTHWVIHQFIEDRBL3CZANCNFSM4KQAEGUQ
.

[samtstern]

@prescottprue I recently realized you can do this using the envOverride system that the CLI has. This system was initially meant for our team to test the CLI against staging servers but it can be used to do what you want.

https://github.com/firebase/firebase-tools/blob/18802d0a4d9f851d8573ec949a66444092710726/src/api.js#L85

So for example, you can do this to delete from the Firestore emulator:

FIRESTORE_URL="http://localhost:8080" firebase firestore:delete

We're gonna need to do some more work to make this ergonomic and useful in more situations, so leaving this open.

[samtstern]

@bkendall @yuchenshi do you think we should just make the CLI respect the same environment variables that the Admin SDKs support? So have the CLI look for FIRESTORE_EMULATOR_HOST and FIREBASE_DATABASE_EMULATOR_HOST?

[yuchenshi]

My vote would be yes since essentially we're doing admin work. This should apply to both CLI when invoked over the command-line or imported as a library.

My only concern is that people may be already doing things like firebase emulators:exec ./my-test-script.sh where my-test-script.sh dumps the production database using CLI first and then imports data into emulators using SDKs. Those workflows will be broken by the env var change.

In an ideal world, dumping data should be done before starting the emulators, and ideally imported through emulators:exec --import my-dump though.

[samtstern]

@yuchenshi we recently started setting FIRESTORE_URL in emulators:foo so this won't be a more breaking change (although we didn't consider that one breaking the time I can see how it is).

The good news is if anyone gets broken it will be: you accidentally didnt write to prod. Which is way better than the reverse.

[samtstern]

In #2109 this was fixed for almost all commands where emulator support is reasonable. All you have to do is export FIREBASE_DATABASE_EMULATOR_HOST=... or export FIRESTORE_EMULATOR_HOST=.... in your environment and the commands will target the emulators.

For example:

# Assume the database emulator is running on port 9000
FIREBASE_DATABASE_EMULATOR_HOST=localhost:9000 firebase database:get /foo/bar

or:

# Assume the direstore emulator is running on port 8080
FIRESTORE_EMULATOR_HOST=localhost:8080 firebase firestore:delete --recursive /foo

The big exception is database:remove because that command is implemented in a pretty complex way and I didn't feel comfortable modifying it. For those who need database:remove in the emulator please file a new issue and we will discuss it there, I think this broad umbrella issue should be closed.

All database:* and firestore:* commands which do NOT support the emulators will now warn you if you try to execute them with the environment variables set to make sure you don't accidentally affect production.