Batching calls to Google APIs (Javascript)

One of the benefits of having a standardised API layer across all the (recent) Google APIs is that a bunch of features come for free. One of these handy items is batching, which is generally pretty easy to do.

For example, an awful lot of Google+ Sign-In implementations retrieve both the signed-in user's profile information and the collection of friends the user shared with the app when the user connects. This generally necessitates two calls, two connections, and two lots of overhead, but can be easily combined into a single request.

If you take a look at the Google+ Javascript QuickStart you'll see there is a profile function and a people function, each making a call to gapi.client.plus.people.something, and then request.execute. We can replace that with a single function that combines both, and looks a little like this:

All we've done here is created each request, and a new RPC batch with gapi.client.newRpcBatch(). It's called RPC batch as we're actually using the JSON RPC endpoint here - every API exposes both RPC and REST-style URL structured endpoints automatically, but the RPC one is a little easier to work with for batching.

We then add each of our requests (even though they're to different parts of the API) to the RPCBatch, and associate the callback with them. The other parameter we could pass in there is 'id', which would allow us to write a single callback function and pull out the requests we wanted if that was easier. One thing worth noting is that the callbacks are slightly different - in the batch version, the response we receive is a object containing the request ID and a 'result' object, which is equivalent to what we would have received when calling directly. This means there's an extra line of code to unwrap that, but otherwise the functions are the same as in the quickstart.

Finally, we just call rpcBatch.execute() and our callbacks are fired. For an idea of the savings, in a completely unscientific test I tried the standard quickstart and found the average time to fetch profile was around 180ms, and friends 500ms. With the batching operation, I found that the total was around 500ms - the friends was completely covering the time of the profile retrieval.

Where this type of thing really helps is in situations like on mobile, where establishing a TCP connection can really be painful. You can read more about the RPCBatch options in the Google APIs Javascript Client Library documentation.

Popular posts from this blog

Client-Server Authentication with ID tokens

Image
These days there are few purely client-side applications - even traditionally unconnected software like casual games make use of servers and services to provide a better, richer experience - and importantly one that can follow the user across devices. We are in a world where we need to authenticate a user of many clients to a set of back-end services. There are a few ways of doing that when using a identity provider, like Google, but in this post I want to talk about a specific method that makes use of ID tokens. This approach has been well covered by Tim Bray for Android, but with the release a couple of months ago of the iOS 1.4.0 SDK for Google+, it is now available across Android, iOS and the Web. This makes it a particularly powerful way of signing in a user, and asserting the identity of that user securely to your application servers. Why ID TokensThis whole architecture relies on a point of view which I suspect is still not particularly common amongst developers implementing au…
Read more

Common problems with Google+ Sign-In on Android

Image
It has been fantastic to see so many people trying out Google+ Sign-In, and through the bootcamps and other events I've had a chance to talk to some people who are actually implementing it in their apps. The Android integration is pretty straightforward, thanks to Google Play Services, but there are still some issues I've seem come up a couple of times.

tl;dr: make sure your app is set up in the API console, and make sure you can handle multiple onStart events coming in during sign-in.

1. Consent screen appears more than once. 

The basic life cycle of the PlusClient looks a bit like this:


When we call the onStart, we immediately call mPlusClient.connect(). Google Play Services checks whether the user is already signed in to the application, and, if so the onConnected method is instantly called and the user seamlessly signed in.

If the connect() call fails, then onConnectionFailed() is called with a ConnectionResult object, which represents the error. The error is probably RESOLU…
Read more

TLS and ZeroMQ

It's pretty straightforward to use synchronous encryption over ZeroMQ - just a case of encrypting and decrypting at each end with some previously shared key. Asynchronous encryption is a bit more interesting, as it allows signing for message integrity and authenticity, as well as data hiding. There have been some good examples of crypto over Pub/Sub (notably Salt), but not a lot of examples of direct messaging.

The de-facto library for this sort of work is OpenSSL, but this has a couple of problems. The first is that usually openssl manages the TCP connection itself, which could be an option for some ZeroMQ cases, but doesn't fit if the user wanted to use a different transport, or an unusual topology. TLS or SSL also require a handshake at the start of the communication, which means we may have to send messages back and forth without there being any application data.

For the first part, OpenSSL includes support for usage as a filter thanks to it's BIO IO abstraction layer.…
Read more