Connecting to the emulator w/o project ID

[SeanFeldman]

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]

Describe the solution you'd like

If you don't specify the ProjectId in the FirestoreDbBuilder, the library will (currently) try to determine it by contacting the GCP metadata server - that's probably not what you want in this case. We could potentially have a different defaulting approach when connecting to the emulator, but that's not something that's going to happen imminently.

When working with GCP locally, the team is using a Dockerized emulator (https://firebase.google.com/docs/emulator-suite). I'm forced to specify the project ID. I want to be able to use the emulator w/o tying to a specific Project ID because I have different solutions that require the use of the emulator (different collections, the database could be the same).

Describe alternatives you've considered
Building emulator image per solution and passing the ProjectId. Unfortunately, that means I cannot run more than one .NET solution simultaneously, as ports required by containers will conflict. And it means we can't have an image that any project can use. Instead, each project needs to build its own image.

Additional context
It shouldn't matter what ProjectId is when working with an emulator. Ideally, omitting ProjectId from FirestoreDbBuilder (null, empty string, or a special value such as emulator) should imply using a local emulator.

The thread started in StackOverflow with @jskeet.

[jskeet]

I'll try to look at this in January, but I can see two potential issues:

• We'll need some way of getting "the emulator project" from the emulator. (I don't know if that's feasible.)
• We'll need to handle the case where the other emulator (via gcloud) is being used; that may well not have the concept of a project ID at all

One workaround you could consider is using an environment variable in the Docker container (which can then be passed in when starting it). I assume the Docker image uses (or could use) the --project flag. If you take that from an environment variable, you could pass that in when starting the container, so you only need a single image which can work with any project. You'd still need to specify the same project ID in the .NET code, but at least you wouldn't need multiple images.

[SeanFeldman]

Looks like the workaround we've discussed is going to be materialized as an official Docker image, released with every update to the NPM package (firebase/firebase-tools#1644). Which is a welcomed change to simplify working with the emulator.

[jskeet]

@SeanFeldman: So where are we in terms of .NET library support? If there's an environment variable that we should use to automatically detect the project ID when connecting to the emulator, I'd be happy to support that (even if it's only used in one of the two emulators).

[SeanFeldman]

The entry point in the image must run the following command.

firebase emulators:start --project PROJECT_ID

To avoid hardcoding PROJECT_ID it would need to be passed to the container via an environment variable. What that environment variable name will be, I can't answer. I suppose this could be answered by @joehan who is working on the official firebase-tools image (PR in progress).

[SeanFeldman]

It would be great to know what's the status of firebase/firebase-tools#1644 and the associated PR firebase/firebase-tools#6255 before this issue can be closed or anything is done.