[java-firestore] Ability to set emulator host/port from .setHost rather than env var

Environment details

OSX, Java

Steps to reproduce

To use Testcontainer + Firestore emulator is extremely difficult.

Code example

Firestore client library can only connect to a firestore emulator by using an env var. This is not idiomatic for Java unit tests.

it's impossible to set the emulator host/port simply from .setHost(..)

FirestoreOptions firestoreOptions =
   FirestoreOptions.newBuilder().setHost(...).

The real code is this:

// duplicate the FakeCredentials class because it's package protected and not publicly accessible.
static class FakeCredentials extends Credentials {
 private final Map<String, List<String>> HEADERS =
     ImmutableMap.of("Authorization", Arrays.asList("Bearer owner"));
...
}

// then, duplicate the code that otherwise executes from an env var:
FirestoreOptions firestoreOptions =
   FirestoreOptions.newBuilder()
       .setProjectId(FIRESTORE_PROJECT_ID)
       .setChannelProvider(
           InstantiatingGrpcChannelProvider.newBuilder()
               .setEndpoint(
                   String.format(
                       "%s:%d",
                       FIRESTORE_CONTAINER.getContainerIpAddress(),
                       FIRESTORE_CONTAINER.getMappedPort(8080)))
               .setChannelConfigurator(
                   (managedChannelBuilder -> managedChannelBuilder.usePlaintext()))
               .build())
       .setCredentialsProvider(FixedCredentialsProvider.create(new FakeCredentials()))
       .build();

Any additional information below

It'd be MUCH easier if emulator host/port can simply be set via .setHost(...), OR, a convenience method, such as .useEmulator(host, port)

@eddumelendez

/cc @eddumelendez who's also working with TestContainer integration for GCP. https://github.com/eddumelendez/testcontainers-java/tree/gcloud

In the same vein of googleapis/java-firestore#190.

Something I'm hoping to have time for soon, but no specific estimate.

looks like the same issue. shared an internal friction log. thnx!

@BenWhitehead

@BenWhitehead I am not opposed to this, but there seems to be a much more generic problem here: It is very difficult (even for me) to figure out which of the sheer endless options I have to enable to get change even simple settings.

If we add a setHost here (and not in the main settings provider), how should we deal with conflicting settings?

I don't think that'll be any worse than now? Which is exposing all of these surfaces anyways. I feel that's a different set of problems - we need to minimize the surface, identify what's really necessary, and expose them via proper API surface. But setHost should just work. It's already there.

What you really need is a setHost(String hostname, boolean ssl, boolean useFakeCredentials). A single setHost does not help, since it still leaves a bunch of settings unset. If we need a short term fix, we could add a setEmulatorHost that does most of this for you.

I don't think a short term setEmulatorHost would necessarily be better for us maintenance wise. There is also the question about how difficult it is to bootstrap the emulator for use in java code. In datastore there is an emulator runner which allows the emulator to be started from java code, I think there is a desire to have the same thing for Firestore. With that in mind I think it'd be better for us to figure out how those will work together and then provide a good api for all emulator functionality rather than having two related but disconnected things our users have to figure out how to connect.

If we're wanting to push out a fix to help out the fact that env variables can't be modified in process, we could add a fallback java property firestore.emulator.host and try reading that. This would allow in-process configuration of that flag for users.

    String envVar = System.getenv("FIRESTORE_EMULATOR_HOST");
    String sysProp = System.getProperty("firestore.emulator.host");
    String emulatorHost = envVar != null ? envVar : sysProp;
    
    if (emulatorHost != null) {
      // use fake creds
      // no ssl
    }

why do we expose setHost if it's not to be used to set it to any arbitrary hosts?

does setHost take in a protocol? it actually does respect the dns:// protocol. tbh; ideally the api should've accepted a full url prefix, e.g. https://.... or http://.... emulators would only be using http

the system property would work, but no one would find that in the api or .setHost javadoc popup. we should add it to the java doc.

feat: add method to set emulator host programmatically (#319) (#336)

chore: release 2.1.0 (#345)

Navigation Menu

Repository navigation

[java-firestore] Ability to set emulator host/port from .setHost rather than env var #13143

Environment details

Steps to reproduce

Code example

Any additional information below

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[java-firestore] Ability to set emulator host/port from .setHost rather than env var #13143

Description

Environment details

Steps to reproduce

Code example

Any additional information below

Activity

saturnism commented on May 8, 2020

BenWhitehead commented on May 11, 2020

saturnism commented on May 12, 2020

schmidt-sebastian commented on May 12, 2020

saturnism commented on May 12, 2020

schmidt-sebastian commented on May 13, 2020

BenWhitehead commented on May 13, 2020

saturnism commented on May 13, 2020

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions