relation to google-apis-rs org?

[mwilliammyers]

Hello! This looks like a cool project!

Just opening up this issue to discuss how the google-apis-rs org and this repo can best collaborate (if that is something everyone wants). We currently have a complete (still kind of WIP) automatically generated HTTP based API for every Google API, but I would love to work on a gRPC async-await API...

What does everyone think?

@ggriffiniii @Byron @Hirevo

[Hirevo]

Hello,

I definitely would not be opposed to collaborate with the google-apis-rs org.
Due to the fact that this library is hand-written and aims for idiomatic APIs, it is slower to develop and is nowhere near as complete as what the google-apis-rs org has done.
Development also slowed down for other reasons like my personal knowledge of Google's APIs (I haven't really used most of the services their platform offers) and my studies.

But if there is interest, since google-apis-rs and this project share the same goal of enabling access to Google's APIs for Rust developers, maybe this library can be moved under the umbrella of google-apis-rs, to offer both HTTP-based and gRPC-based options ?
I don't actually know what is the intended scope of the organisation and/or if they have other plans for it.

[mwilliammyers]

Awesome! Thanks for starting such a useful project!

I would be happy to move this repo to the google-apis-rs org (if @ggriffiniii @Byron and you of course are ok with it).

In the next few weeks I will have time to write some code (it won't need to be much) to generate gRPC bindings for all the APIs and I will probably be able to spend some time hand-coding more idiomatic bindings. I have used a lot of the GCP APIs, and I am familiar enough with the ones I have not used to be of some help.

Like you said, I envision having two main repos/projects:

• regular REST based APIs that are more complete/automatically generated but less idiomatic
• gRPC base, with two levels of APIs:
  • A higher level, more idiomatic, hand-written (most likely) API for the commonly used Google APIs
  • A lower level, automatically generated "raw" gRPC bindings for all* Google APIs. These APIs would likely just make authenticating easier and then follow the pattern in this example from Tonic.

The only question would be how to release them to crates.io when the time comes... I am not super fond of having two crates (REST and gRPC) for each Google API, but we can worry about that later 🙃

And who knows, maybe Google will one day take over the repos in the org and Rust will get an official client!

*Some APIs do not have gRPC bindings yet (I think most are related to Firebase?) like Google Cloud Identity Platform. Maybe we can wrap the auto generated REST code with a more idiomatic API or just build it from scratch?

[Byron]

Hi @mwilliammyers ,

thanks for involving me into this conversation. I believe it would be great if shared interests could be bundled into a team to increase the amount of work done, and maybe even the amount of fun had in the process :).

@ggriffiniii is now an owner of the organization and should be able to perform the admin work necessary to move things forward if there is agreement about it.

All the best!

[Hirevo]

@mwilliammyers I very much like that vision, it would give an option for everyone: people looking for a higher-level abstraction (very much like me) and people looking for more control who wouldn't mind going at a lower level.

I don't know if I can help in any way on the automatically generated parts, but if I can still be one of the maintainers for the higher-level parts, I would be perfectly happy.
Most notably, one of the things I would want to greatly improve is the documentation, the code is somewhat documented but I think there is still room for improvement and there is nothing substantial in the READMEs currently.

About releasing on crates.io, I actually have the google-cloud and google-cloud-derive crates already reserved but without any code released there, so we can still explore what to do with those names and transfer them to the organization as well (if we want to use them).

[mwilliammyers]

@ggriffiniii, when you get a chance, can you add @Hirevo to the org so they can move this repo over?

(I think everyone said they were ok with that plan of action?)

[Byron]

@mwilliammyers You are now an owner of the organization and can go ahead on your own account.

[Hirevo]

@mwilliammyers Thank you for the invitation, I have been able to successfully transfer this repository over.
Thanks a lot for the proposition, and I hope this will be a good addition for Rust's story with GCP.

[mwilliammyers]

@Hirevo thanks! I know it will!