Closed mcrumm closed 5 years ago
Would the solutions discussed for SQS also be valid here?
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. :)
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
Yes, let's go with this contract and we can mirror it on SQS! :+1: /c @msaraiva
Would it more make sense to deprecate the :scope
option, or always pass it as the first argument to the generator MFA?
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.
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!
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.