Google Client Libraries for server-server APIs

Hi everyone,

First post, correct me if this is the wrong place.

I'm a big fan of the swift programming language, and would love to use it on the server.
Coming from a lot of node.js/python/java programming, I always liked the client libraries that were provided by google, that made it seem easy to get up and running with any of the APIs.

However, since it's fairly new on the server, these client libraries don't exist for swift.
I think that this is a pretty big turn off for anyone wanting to try out swift on the server, the fact that they'll have to build web requests manually or build a library themselves.

I found that someone from google had started to make a basic implementation of auto-generating these APIs, so I decided to work on it further to make it more fit for purpose.
Have a look here: GitHub - Mark-McCracken/google-api-swift-client: A client generator for APIs described by Google's API Discovery Format.

I've gotten it to a state where it will successfully compile any discovery document that google currently provides (currently 169 APIs).

I was wondering what further steps I'd need to take to make these libraries what you might call 'production-ready', and how I could make it as easy as possible for someone to install one of these libraries into their project for use?

Regards,
Mark

2 Likes

Thanks for working on this, it is great to see efforts to make Swift usable more places.

I will have a closer look later and will try to give feedback, but I just wanted to say it's a great idea to use backticks for names. I have a couple places I do swift code generation, and would solve a lot of problems.

I don't work much with Google APIs, but AFAIK they are all defined using GRPC (using the definitions found here). We also have a Swift GRPC generator.

I guess that would probably work better than using the discovery API. Apparently the bindings for other platforms are also generated from GRPC:

  1. Google Cloud Client Libraries: You can use these libraries to access Google Cloud APIs. They are based on gRPC for better performance and provide idiomatic client surface for better developer experience.

Did you try generating from GRPC?

EDIT: There is an example which shows you how to work with Google's APIs.

1 Like

Thanks!
I've used backticks quite extensively for keynames, which solve most issues of difficult names, however it didn't work for a few names, where an API response contained an object key called "self", or had a hyphen, or prefixed with a $ or @ symbol.
Another pain was Resources called Error or Type.
But mostly, this was straightforward enough to resolve each of these.

Thanks for this, no I haven't tried generating from gRPC.
I don't know very much about it, what I think I know is that

  1. It's a binary serialization, which makes requests and responses smaller, therefore faster
  2. The interfaces are defined by service files, that can be used to generate a server stub, and a client library

Are those right? If this is the case, will this gRPC generated library look pretty much the same as my REST generated library? In that it will generate swift native structs/class for parameter types and response types, and a service that will communicate to/from the API?

I'll find some time this week to play with gRPC and see if I can generate something similar from those Google definitions, thanks so much!

I'm not an expert on gRPC, but the following snippets from the official FAQ might help you:

Why is gRPC better than any binary blob over HTTP/2?

This is largely what gRPC is on the wire. However gRPC is also a set of libraries that will provide higher-level features consistently across platforms that common HTTP libraries typically do not. Examples of such features include:

  • interaction with flow-control at the application layer
  • cascading call-cancellation
  • load balancing & failover

Can I use gRPC with my favorite data format (JSON, Protobuf, Thrift, XML) ?

Yes. gRPC is designed to be extensible to support multiple content types. The initial release contains support for Protobuf and with external support for other content types such as FlatBuffers and Thrift, at varying levels of maturity.

So it appears that gRPC is not really tied to the particular binary format or whatever; it's more like a framework/standard for writing remote APIs.

And yes, there is a generator which creates stubs from your service definitions. There is a plugin architecture so any kind of language/platform should be able to add support.