Provide a dummy token module for tests/emulation

[mcrumm]

It would be nice to ship a token module that doesn't actually need to communicate with Google. This would be really helpful in a test environment, but also when interfacing with the emulator, since it doesn't validate tokens.

[josevalim]

Would the solutions discussed for SQS also be valid here?

[josevalim]

Btw, we preferred to go with a MFArgs tuple instead of a module because the contract is simple, so there is no reason to force the overhead of defining a module. The token generator option is also easier to handler during testing. :)

[mcrumm]

Would the solutions discussed for SQS also be valid here?

Yes, this is totally valid here, too.

Btw, we preferred to go with a MFArgs tuple instead of a module because the contract is simple, so there is no reason to force the overhead of defining a module. The token generator option is also easier to handler during testing. :)

Agreed. Would you expect the call to the :token_generator would return just the token, or a named tuple?

For Goth, the default MFArgs tuple would look like this:

{Goth.Token, :for_scope, ["https://www.googleapis.com/auth/pubsub"]}

and it's going to return

{:ok, "some_token"} | :error

[josevalim]

Yes, let's go with this contract and we can mirror it on SQS! :+1: /c @msaraiva

[mcrumm]

Would it more make sense to deprecate the :scope option, or always pass it as the first argument to the generator MFA?

[josevalim]

Good question. It depends if most people will use the Goth one out of the box. If so, I would say the :scope is exclusive to when you pass no token generator. If they pass their own token generator, then they need to pass the scope or whatever else by themselves.

[mcrumm]

Thanks! I think Goth will be the de facto token provider, but I refused to make it a hard dependency because there are other options out there, and the Google libs don't require it.

I appreciate the input!