In ServiceApi classes, consider how to expose the underlying gRPC layer for advanced use cases.

[garrettjonesgoogle]

We may want to expose the channel and 1 or more gRPC stubs for advanced use cases not met by the generated methods in the wrapper.

[aozarov]

I wonder, if we decide to do that, if returning the ServiceApiSettings wouldn't be preferred.

As a side not (related to the suggestion), I wonder if in ApiUtils.settingsWithChannels we should not configure the newly created channel (if setting didn't include channel) with settings.getCredentials if it
is not null?

Also, if we decide to return the ServiceApiSettings reference that was created by ApiUtils.ServiceApiSettings then I think we need also to populate the other fields (such as Credentials,
ServicePath and Port).

[garrettjonesgoogle]

The code has changed a bit since Arie's comment - ApiUtils is now gone, and ServiceApiSettings now handles the population of the default channel itself. I think Arie's concerns are addressed now.

I'm unsure if we currently have a demonstrated need to expose the gRPC layer through the Api classes - it is already accessible from its own package, which is a dependency.

@aozarov , what are your thoughts?

[garrettjonesgoogle]

The Service Api classes now expose the corresponding Settings classes. Resolving this issue.