Video: Google I/O 2012 – Building Mobile App Engine Backends for Android, iOS and the Web
CHRISTINA ILVENTO: Hi. Good morning, everyone. I'm Christina Ilvento. I'm one of the product managers for Google App Engine. DAN HOLEVOET: And I'm Dan Holevoet. I'm an engineer on the Developer Relations team, also focusing on App Engine. CHRISTINA ILVENTO: And today we're here to talk to you about building mobile App Engine back ends for Android, iOS, and the web. So a little bit about why we're here. We're really here to talk to you about using Google App Engine as a back end for applications with multiple clients– clients on your phone, clients in the browser– and also to introduce to you Google Cloud Endpoints, which we announced yesterday in our App Engine overview session, which is a feature that makes it even easier to develop client applications for your App Engine back ends.
So we talked about what about why we're here, but why are you all here? As a show of hands, how many of you have built an App Engine app before? Wow! OK. We've got quite an App Engine crowd here. And how many of you have built a mobile app before? All right. Excellent. Anyone who's built a mobile app backed on App Engine? AUDIENCE: Tried. FEMALE SPEAKER: Tried. OK, great. So chances are you're here to learn a little bit more about App Engine, to learn about building applications with multiple clients in general. But regardless of the specifics, you're probably here because you're thinking about building an application. And you're thinking about building an app because you've got a great idea. You've got the kind of idea that gets you onto the front page of your favorite news source on the web, something that people talk about around the water cooler. Or maybe if it's not something really aspirational like that, at least it's an idea that you think is going to make you a million bucks.
So you're here to build an app, and you know that this thing needs to be everywhere your users are going to be. This thing needs to be on multiple platforms. We're not talking about a 90s-style website here, we're talking about an app that goes everywhere that your users go. And beyond that, we're talking about an app that needs to scale. Chances are you're not going to make a million bucks on your mom's book club. So you want this thing to be able to scale up so that when all of your users start using all those multiple platforms, your app scales with them. So keeping this in mind, we have an app that needs to work on multiple platforms, it needs to scale. We come up with an idea for what our architecture is going to look like.
It probably looks something like this, where you have a single back end that has your application logic that's actually talking to some sort of shared state, some storage, and maybe some other fancy services. But on top of that application logic– really the core of your application– you're probably standing up an API. And that API is going to be called by all of your client applications running on iOS, Android, and in web browsers. And this seems like a pretty reasonable design. So let's go ahead and start to actually build this thing, make it work. So the first thing that we're going to do is probably pick an open source stack and stand this up maybe on a server that we have lying around in our basement. So the first thing we're gonna do, we'll stand up Apache, we'll stand up MySQL, get those two playing nicely together. And we're essentially ready now to actually start building the core of the application now that we have our open source stack set up. So we start to actually implement the application logic. So once we get the core of the app written, we have to actually figure out what this API is going to look like. And you figure out your API methods, write all the service class code that you need to have that API actually stand up.
But now we get to a point where we've got to figure out some of the specifics of the API. It's not just figuring out what methods you're going to use. We have to figure out, How are we gonna authorize our clients? How do we know who's calling our API? And are they allowed to be calling our API? How are you gonna authenticate your users? How are you going to authenticate users on a device and have that actually be communicated to your back end in a way you can securely handle user data? I'm not sure if any of you have ever tried to do this in the past, but it turns out that it's not exactly trivial to make that work. What are you going to do for compression? How are you going to decide what wire format to use? There are a lot of things that come along with building an API that you have to manage before you can even get in to building those client applications.
But you've got this great idea. So we're going to assume you're a smart guy. And you've figured this out. You've actually stood up the API. You're ready to go. And we're ready to start building our client applications. So as you start to build these, maybe you build them all at the same time, maybe you build one at a time. But as you start to build the client application, you probably don't want a lot of that API-specific code sitting around in the logic of your client apps. So what you're probably going to do is factor that out into some sort of API wrapper code. So at this point we have our three clients. They all have some wrapper code. And every time we make a change to our API– and chances are we're going to make a few as we're developing this great app– we have to make that change now in three places in three different languages– for our Android app, for our iPhone app, and for the web.
But again, we're smart developers here. We've got this working. So at this point, our app is ready to launch. We've got it. We've got the client apps talking to this back end, and everything works. So we launch. And before we launch we probably do some fancy math to figure out what our load is going to look like and figure out how we're going to provision and all of that. But it turns out that being good at math is not the same thing as being able to predict the future. And chances are you're either going to over provision and end up provisioning a lot more than you really need, or you're going to end up having some really fun downtime and getting to send out your first post-mortem to your beta users. So we get into a situation where essentially what you're doing is you're actually going through your development process. And then every time you're ready to actually add more users, or whether you're ready or not you're adding more users, you need to go through the cycle of estimating your load, provisioning, actually setting up all the hardware, if you're buying hardware, or provisioning VMs, and then actually being able to launch– in addition to all the overhead and maintenance of just keeping your API up to date with all of your new versions.
So at some point after we've been working on this app for a while, we realize that what we're really doing is playing sysadmin. And really spending a lot of time working on the API-specific aspects of this. And spending a lot of time figuring out load balancing and all of that, rather than doing what we really set out to do, which was to build this great million-dollar app and do things like actually figure out a monetization strategy, add features, improve our clients, all of that. But let's pause for a minute. I promise that this talk is not completely depressing. App Engine can really help with this. So with App Engine, it's really, really easy to get a scalable back end up and running quickly. So if you're not familiar with App Engine– I know we had a lot of folks raise their hand, but many of you didn't. App Engine is our scalable web hosting platform that lets you take advantage of the robustness and scale of Google's core infrastructure in your applications in a fully managed environment.
And it's really easy to get started. All you have to do is download the SDK, write your code in Java, Python, or Go. And then you can test it locally using our local development server. And then upload it to Google and run your application on Google's infrastructure. So scaling is a really important part of writing an app like this. And it turns out that scaling is actually really easy on App Engine. And it's rare that important things are easy, so this is great. So with App Engine, as the traffic for your app increases, we automatically provision more instances and actually spin up more instances to handle that traffic as your traffic increases. And the great thing is that you only pay for what you use. So you get both the benefit of reliable scaling when you need it, but you also get efficiency when you don't. And beyond just the scaling, because you're running in a fully managed environment, you don't need to worry about your full stack.
What version your kernel is running, no longer your problem. All you need to be worrying about is the actual application logic that you're deploying. So this is great. But App Engine is more than just sort of scaling and the fully managed environment. With App Engine you get a great set of core features that help you to build a real feature-rich application quickly. So with App Engine, there are several storage options that are already baked in. You can use the App Engine Datastore, which is a NoSQL data store without any configuration or setup already baked into your app. And you can also use Google Cloud SQL with our integration with Google Cloud SQL. And they started taking open sign ups, I think, yesterday. So you have storage that's already built in. You also have some great compute options. So things like task queues and cron jobs, you don't have to manage all of that yourself. It's all just built into App Engine.
And beyond that, App Engine has some great APIs and services included. So things like the user's API, so you can authenticate Google users in your application, that's all included in App Engine, as well as things like MapReduce, Search, and Mail. So you don't need to go out and find an open-source solution and worry about integrating that into your app. It's all there for you in App Engine. All right. So we've taken the lightning tour of App Engine. Let's use that for our back end. So now using App Engine as our back end, what we'll do is we'll have that shared state be stored in Datastore. We'll write all of our application logic in an App Engine app. And then we can use any of those APIs and services as well. And so now at this point, we're both taking advantage of the scaling of App Engine, so we don't have to worry about managing all that ourselves.
But we're also sort of getting this thing done more quickly because we didn't have to do all that setup and configuration hassle at the beginning. And so this is great. And so now we don't really need to worry as much about the back end. But what about with the rest of this architecture diagram that we have up here? We're still having to manage that API ourselves. We're still having to deal with all of the wrapper code and the things in our clients. I know I promised you at the beginning we'd talk about Endpoints, our shiny new feature of this talk. And so let's get right to it. And let's skip slides while we're doing it. Sorry, guys. So with Endpoints, you can extend your App Engine back end using Google's API infrastructure. So basically, the way it works is that you can annotate your App Engine back-end code to stand up in API, and all of the configuration and service classes are generated for you. You don't have to handle any of that on your own. And then you've got an API up and running for all of your clients to call in to. And another great feature of Endpoints is that you get custom client libraries.
At this point you've done all you need to do to actually stand up this API. But now let's get on to the clients. So we've got our API, and we're going to write our clients. And this is just a little snippet of what you'd see in the command line if you were generating an Objective C client library. So we provide tools to generate those client libraries, either in the command line or through an integration with the Google plug-in for Eclipse. So at this point, we now have our strongly typed Objective C client library. We can pop that into our client app. And then we're ready to go. And it's that simple to actually get the API up and running and into your application. So I've walked you through the basics of how endpoints work. And I'm going to hand it over now to Dan, who's going to give a more detailed walk-through and show you some of the code.
DAN HOLEVOET: Great. Thanks, Christina. [APPLAUSE] DAN HOLEVOET: So a lot of you are probably wondering what our million-dollar app idea is. And so to kill the suspense, it's a tic-tac-toe game, which I'm sure is going to make us tons of money. So let me just load up a sample of what this type of app looks like on an Android device here. So I have it running in the emulator. This is working on Froyo. It works on Froyo and above. And so I've got the simple board layout here. I can click on these squares. And every time I click on one of these squares, what it's doing is it's sending requests to our App Engine back end with the– ugh, wow. Awesome. I checked right before the demo, I swear. It's sending off a request to our back-end server with the current board state.
And then the computer is going to make a move, send the request back to the Android app. We're going to update the UI with the computer's move. And then we can keep playing. So let's do that here. All right. So we got this nice little option here for multiple moves. All right. Looks like I won. Awesome. Great. So this is going to send it off to another API that we have running on App Engine, which is keeping track of our previous games. It's recorded my victory for posterity. And then it shows it up at the bottom of the screen. So let's look at the code for what this app looks like. So we'll start with the App Engine back end. And as I said, I have two APIs running. The first one of those APIs is keeping track of the state of the board. And the second one is a really simple resource that keeps track of the high score. So what we're looking at here is a simple model for the Datastore. We're using JDO.
This is exactly the same code that you would write today if you were writing an App Engine app that wanted to keep track of something like a high score, right? So this is exactly the same model and everything that you're used to writing. So we have a couple properties here, things like the outcome of the game, when we played it, some getters and setters, and things like that. So that's all very straightforward. And then as a companion to this, we've written an Endpoint class, which we'll use to interact with the model in the data store. So we have some simple methods here for getting one of the scores from the data store, or listing all of the scores from the data store, or inserting a score into the data store. And again this is all code that you're probably very familiar writing if you've written App Engine apps in Java in the past. So now what we're going to do is we're going to turn this into an API. And we'll do that by adding a series of annotations into the code.
So the first one of these is the @API annotation. And actually, as soon as I've added this, this is actually enough to give me an API that I can use inside of my Android app. But there's some small improvements and tweaks that I can make to it if I want to make it a little more customized. So the first one I'll do is I'll give this API a name. This is part of tic-tac-toe. So we'll give it the name of tictactoe. And then the next annotation we can add– and again, this is completely optional at this point– is the API method annotation. And we can use that to give each of our methods a name. So we'll call this scores.get. And we'll do this for the other methods, as well. So this one is scores.list. And this is all very straightforward. So there we go. We've got three nicely named API methods. And then there's some other things that we can also use the API method annotation for. So one of those, for example, if I wanted to do user authentication inside of my application, I could add some customization options for OAuth2 inside of the API method annotation.
So I could do things like provide a list of client IDs that would be acceptable as consumers of my API. I could add an audience field if I only wanted to accept requests that were coming from a certain audience, things like that. And then once those are in there, I can add a user parameter into my API method, which will give me a user object that I can then use inside of my back-end code. And this is exactly the same user object it you would use if you were using the built-in users API that's part of App Engine. So it's exactly the same behavior. It's the API that you're used to using. We're not adding anything custom or special here. So if you have other pieces of your project that use the user's API there, this is completely compatible with that as well. So for the purposes of the demo, we'll leave that out just because it makes things run a little bit smoother as far as my demo flow.
But again, it's very simple to add authentication to your back end. So this class is basically finished at this point. And just quickly, I'll show you the board Endpoint class that I've made, as well. Again, we have only one method here, which is just allowing us to get the move from the computer. And it's part of the same API. We're using the API method annotation here as well. All right. So now that we've got all this code written, we can run this application locally. So I'll just hit the Play button here in Eclipse, and it'll spin up a local server. Great. Looks like it's running on this port. And then we'll go into some curl commands that we can try out the API locally. So the first one of these that we're going to show you here is a command to test the board API. And so what we're doing here is we're passing in JSON Blob, which has the current state of the board.
So we're representing the board here as a one-dimensional array of squares. I've set the middle square to be an X. And I'm sending that to the API that's running on my local machine. And if I hit Return here, we get a response back. The computer has played one of the adjacent squares with an O. And then we can use that in whatever applications we would like. So that's really convenient. It makes it really simple to test these APIs as you're developing them. So that's cool. So let's actually try deploying this to App Engine. So we'll use the Google plug-in for Eclipse here. We'll hit the Deploy to App Engine button inside of Google Plugin for Eclipse. We'll hit the Deploy, and then we'll let this go in the background. Hopefully the network will cooperate with us, and it won't take too long for this to go through. All right, just checking to make sure that the API is running and the back end is running on App Engine. All right.
Great. And so now we can flip over to one of the tabs where I have the application running. So one of the things that Christina mentioned before was that all of these APIs are built on the same API infrastructure that powers lots of Google's other APIs, so things like the Google Calendar API or the Google+ APIs that many of you are probably familiar with. And one of the things that binds all of those APIs and makes them very easy to use is this common discovery format that we have provided for all of the APIs. And basically what this is is a JSON description of each of the APIs that's being hosted by Google's infrastructure. And the same way that we have those for Google APIs, we have those for APIs built with Google Cloud Endpoints. So you can see here, this is the discovery document for the API that I just deployed.
And if we scroll through this, we have descriptions of all of the methods and the objects that I'm returning from any of these API calls, what the expected inputs are, things like that, which we can then use inside of Google's other tools. And so one of those tools that we can use is the Google APIs Explorer, which many of have probably tried for, again, things like the Google+ API, when you're learning about a new API and you just want to try it out before having to write too much client code. So I've loaded up the API Explorer here with my tic-tac-toe APIs. And if I click on one of these APIs here– so let's look at the getmove method– I can fill in a sample request to the API. And again, we'll use that same board that I was showing you before where I've played in the middle square. We can hit Execute, and then this is going to send off a request to our API.
And using the Google Plugin for Eclipse, we're going to use this new feature we just added which says, Generate Cloud Endpoint Client Library. And if I select this, what this is going to do is it's going to read all of the annotations that I've added to my back-end classes, send them off to Google. Google is going to generate some API configuration for me and return a client library that I can then use in any Java application. So it's done that now. It's loaded this file here. And if we go and look at it inside of the Finder, we can see all of the things that it's generated for me. So we only have one API. It's v1, right? So we only have one directory here. And if we expand this, we can see all of the things that it's created for me.
So the two things that are most interesting to you here, probably are the Libs directory, which has all of the libraries that I would need to run this in basically any Java environment. So this isn't just the jars that we need to run on Android, it also includes jars for running it on another App Engine app, or other Java environments. And so I have an Android app that I've created here as well. And I've already loaded in a smaller set of those libraries into this directory already. And one thing I should add is that the Java client library also works with Proguard. So you might be looking at this and saying, oh, well that's a lot of stuff. But it actually compiles down to a very, very reasonable size when you're using Proguard. And then the second thing that we've got in here is a set of source files, which we can use to interact with the API. So I will copy these into my App Engine project here. And then if we go back into Eclipse, refresh this directory here, it's loaded those files in.
And now we can update this sample activity that I've created here, which will allow me to interact with the API. So to show you a sample of what these API calls might look like, I've constructed a service class above here in this activity. Very straightforward, right? And so once I have done that, I can then use it inside of the rest of the activity class to generate calls to the API. So what we're interested in here, inside of this asynchronous task, is the computer's next move. So I will make a call to the board API. So we'll call service.board. And then I'm interested in the getmove method, which is great. And then we've been passed in the board state here in this object. And then we'll send it off to the server. So it's really simple to call these API calls using the generated libraries. We basically have a one liner here to make a call to my back end. So now that that's added we can then compile this app in the background and hopefully load it up on my Android emulator again. So we'll just give that a second, switch over to this here.
My poor little computer has lots of things running, so this may take a second longer than normal. All right. So this is the app that I just built. It's also already loading in the previous games that I've played. And if I click on one of these squares, then it's sending a request off the server. And again, we're playing tic-tac-toe. Pretty neat. So there's another mobile development platform, which some of you guys might have heard of, and maybe you're interested in developing for that as well. So let's look at what this might look like in the iOS development case. So in the same way that we have a generator for the Java client library, we have a generator for Objective C as well. So I'm going to call that here using one of the discovery files that was generated from my API. So what this is doing is it's, again, reading that discovery format that I talked about before and generating a set of header and implementation classes that I can then use inside of an application in Xcode.
So these are all the files I need here. And we can just copy these into an application that I have set up. I've got a little directory for them already. We'll just drop those in there. And then in the same way that I showed you in the Java case, we can paste in an example API call to get the next move from the computer. So we'll start writing here. So we're interested in querying the tic-tac-toe API. And we want to query for the board and pass in an object. Autocomplete's super helpful here. All right, great. So we have that written as well. And then if we hit Run, again, this will compile in the background and then fire up the simulator. All right. We've got all my previous games, again, loading at the bottom. I'm on a roll today. And I can play again.
So with that, I'll hand it back to Christina. [APPLAUSE] CHRISTINA ILVENTO: Great. Thanks, Dan. I'll give everybody a minute to scan those QR codes and see if you can beat Dan's really awesome record for this run through of our talk. All right. Looks like still a few people trying to get it. So this is really, really powerful, what Dan just walked us through. We were able to get, in the space of this talk and with admittedly a little bit of copy-and-paste magic, a real application up and running with multiple clients. And so for tic-tac-toe, really what we did here was we actually wrote the back-end code the same way we do normally in our normal App Engine development environment. We were storing our previous games in the Datastore. The game logic for the computer to make its next move was just a regular App Engine app. And then Dan showed you how you might use the Users API to actually add that OAuth support in, as well. And then we just annotated the board and score classes to actually generate the API configuration that Dan showed you, and the service classes, and actually created our board and score APIs. And then we were able to generate the client libraries.
And then the other cool thing that you get as a benefit of being built on top of Google's API infrastructure is you get some of the tooling that's available around Google APIs, like the APIs Explorer, which is a really great way to, as you're designing your API and starting to test it out, play around with the API during your development process. So Endpoints is really great for actually building an application with multiple clients. You get the scalability of Google's infrastructure. You get the same scalability that you're used to with App Engine, as well as the scalability of Google's API infrastructure. If you're familiar with some of the Google APIs, like Google+, YouTube, they're handling billions of API calls per day. And your API for your client applications is getting the benefit of that scale. You also get the flexibility of multiple clients and the flexibility of choosing the Endpoints that are meaningful to your application.
So you're not restricted to things like crowd operations, or any particular sort of data type, or having to fit your application's logic into some sort of mold of an API. You really create the API that makes sense for your application. And then finally you get the simplicity, which I think Dan showed pretty well, of just needing to annotate and then you're done. You've got your API. And you get to continue to use your normal App Engine development process. There's no need to go out and find some other way to do an API, find some other way to do auth. It's all very seamlessly integrated into your normal App Engine development process. And so maybe you're thinking, all right, it's scalable, whatever. I mean you guys wrote tic-tac-toe, very cute. But it turns out that on your Android phones, if you all are using the I/O app, that the I/O Android app is also written using Endpoints. So when you actually installed that app, and chose which account you wanted to use, and got your session scheduled, all of that is running using Endpoints.
And so we've had some really good success using this internally to Google, to actually create some of our applications. And so we're really excited today to open this up to trusted testers. So if you all are interested in getting early access to Endpoints– excellent, people are reaching for their phones to scan the QR code. Please do scan the QR code and sign up at endpoints-truste d-tester.appspot.com. We're really pleased to be making this available to you today as trusted testers and let you all try it out and build your million-dollar app ideas. Because it turns out maybe ours isn't going to make a million bucks, Dan. I'm not sure. So I'll give everybody a minute to scan that QR code. And if you want to get even earlier access, Dan is going to be running a Codelab tomorrow at 11 AM, I think in Codelab room one.
And he's going to walk you through the finer points of building the tic-tac-toe app and help you get this up and running for yourselves so you can see what that's like. And there are a couple of talks later this afternoon that are also going to touch on Endpoints. So, Brad and Ido are going to be talking about HTML5 in App Engine at about 1:30. And then Yaniv and Sriram are going to be talking a bit more about the Android side, as well as some of the authentication stuff that we didn't get to go through today, at 5:15, and then the Codelab that Dan is going to be running tomorrow. All right. So that about sums it up for what we had for you all. So thank you very much for coming. I think we definitely have some time to take questions. And then, again, here are the QR codes for the web version, the Android version, and the trusted-tester sign up. But if you'd like to ask a question, please do come up to the microphones on either side. Thank you. [APPLAUSE] AUDIENCE: Hi.
CHRISTINA ILVENTO: Go ahead. Yeah. AUDIENCE: So when you develop an app that runs– a product runs on multiple clients, you have a data structure, and objects, and stuff like that. So for example, there's Java on App Engine, Java on Android. And sometimes I see the objects get generated from the API and not the other way around. So how do we tackle this? Like, I have the same structure in other places, but I need to build it again. Because this approach goes from the API point of view and not the object's point of view. CHRISTINA ILVENTO: Sure, so Dan do you want to? DAN HOLEVOET: Yeah. So in this case, the objects that are passed by the API are described by the code that you're writing. So the score class that I showed on the App Engine side, if you already had an object and you wanted to use that as the basis for your API, you could do that. So the discovery format that's powering all of these things behind the scenes is interpreting your object and then writing client libraries that will read and write to your object format in the correct way. AUDIENCE: So I have an object class in Objective C, an object class– DAN HOLEVOET: Right.
So we generate a class in Objective C for you that's matching the object that you've created on your server. AUDIENCE: OK. So perhaps it's for the Codelab, but I need to fill in the actual actions. So is it generated that I can fill in without overriding my code every time the API is generated? DAN HOLEVOET: Yeah. So the Endpoint class that I showed you, you're in control of all of the code that's in that class. AUDIENCE: But that's generated. DAN HOLEVOET: No, that wasn't generated. AUDIENCE: OK. DAN HOLEVOET: So that was a class that I had. We actually do offer the ability to generate, automatically, an Endpoint class for you based off of an object. So I could've automatically created a class to interact with the score object. I didn't show that here. But you could do that. The way I was showing it though, you're in control of all of that code, and you're just annotating it to describe the way that your API should be built around it.
AUDIENCE: OK. Thank you. CHRISTINA ILVENTO: Maybe take one from the other side? AUDIENCE: Hi. So I was wondering, you guys have support for the annotations on Java and Python. But what is your plans for supporting Go in this? CHRISTINA ILVENTO: So right now we're only making this available to trusted testers in Python and Java. So we don't have any specific Go support yet. And I don't think we have any, in particular, planned. But stay tuned. We'll definitely update you as we make support for more languages available. AUDIENCE: And I just had one more question about supporting multiple languages in the same app. I know for right now there's a work-around where you can push a Java version to one version name and Go or Python to another one. But do you have any plans for supporting multiple languages in the same app? CHRISTINA ILVENTO: So– DAN HOLEVOET: You mean just in App Engine in general, or? AUDIENCE: Yes.
Yes. CHRISTINA ILVENTO: For App Engine in general, maybe find us in the sandbox afterwards and we can talk in a little more detail about your particular app. AUDIENCE: Sure. Thank you. CHRISTINA ILVENTO: Thanks. AUDIENCE: Cool demo. My question, I noticed after you generated the client-side library it was in a folder with a version, like v1, or something like that. So I was just curious if you could talk a little bit about how the versioning is handled. So you were going to add the user parameter, for example, when you created the next version of the client library, how is that managed? DAN HOLEVOET: Right. So the @API annotation also allows you to control things like the versioning. So if I wanted to say this is v2 that I'm deploying now, I could add a version parameter into the API annotation there and give it a different version. And I could have both deployed simultaneously.
So if I had a client that was still calling v1, that would still go back to my old v1 code. And if I had a v2 client, I could have that point to a different set of code. AUDIENCE: I see. Cool. And then the second question is– let a few more people leave the room– any plans for a Windows Phone client generator? [LAUGHTER] AUDIENCE: I know. It sucks. But I have to do it. I don't choose to do it. CHRISTINA ILVENTO: No concrete plans at this particular moment. AUDIENCE: OK. Thank you. CHRISTINA ILVENTO: But you could– if you wanted to just call it as a rest API, there's no reason you couldn't call it from Windows Phone. But no particular plans to support that yet. Other side? AUDIENCE: Two questions. Mine is sort of part of his. So for Windows clients on tablets and things like that that are coming out, it sounds like there's no plans for C Sharp or any .Net client generation. CHRISTINA ILVENTO: So we don't have support for that at the moment. But we are thinking about the additional languages that we're going to provide support for. So if you sign up for our Trusted Tester program– AUDIENCE: Already did it.
CHRISTINA ILVENTO: –and give that feedback, that will be really helpful to us as we continue to develop it. AUDIENCE: The other question I had is with the Google Compute Engine mentioned this morning. Do you see scenarios where I can deploy that plus this using Endpoints together? Or is those seen as I'd have to expose a rest endpoint from there to be able to deploy with this. So I'd have a worker role doing something there combined with a front end that's provided by this. CHRISTINA ILVENTO: Oh, so you'd stand up an API on top of App Engine using Endpoints and then have your compute engine– AUDIENCE: Yeah. CHRISTINA ILVENTO: –instances call into that? AUDIENCE: Yeah. CHRISTINA ILVENTO: That's not something that we've particularly been targeting.
And I think that there's probably going to be additional development around there. But that's certainly something that you could do, because you can just stand up a basic rest API. And if you were writing some Java code, you could just use the Java client library. So there's nothing that would prevent you from doing that. AUDIENCE: OK. Thanks. CHRISTINA ILVENTO: Thank you. AUDIENCE: So I have a question about authentication. So it's obviously using OAuth. And probably on Android side you can use the account manager, and use the user account, et cetera, et cetera. But sometimes you don't want to authenticate the user. You just want to make sure that only your app can talk to this Endpoint. You don't care about the actual user. So just making sure that nobody's calling your API and racking up you bill and whatever. So do you have any support for this? For example, App Engine has the service accounts.
So anything similar for mobile clients like an application account on the user account? DAN HOLEVOET: So the client IDs and audience field that I was talking about as possible things you could add in to the API method annotation. If you have your client represented by one of those client IDs, you can then say in your API method annotation, I only want requests from this client ID to be accepted when they're calling the back end. So then any other person who's using a different client ID, their request would be denied when the API is called. AUDIENCE: Right. So but the client IDs is actually authenticated? It's like not just anyone can reverse your app and copy the idea and do the same thing? DAN HOLEVOET: Right. So the client IDs are set up through the Google APIs console. AUDIENCE: Oh, OK. DAN HOLEVOET: And then there's some improvements to the account manager that are going to make that process work end to end on Android devices, as well. AUDIENCE: OK. So is there any documentation about this yet, or? CHRISTINA ILVENTO: So definitely check out Yaniv and Sriram's talk later today.
I think that one was at 5:15. AUDIENCE: OK. CHRISTINA ILVENTO: And they'll be talking a bit more about the auth there. AUDIENCE: All right. Thanks. CHRISTINA ILVENTO: Thank you. AUDIENCE: So if I have server-side resources with child object collections, the generated libraries have a sort of helper facility to do lazy loading of those larger collections that are attached to the resources that I'm accessing? DAN HOLEVOET: That's a good question. I haven't checked into that specifically. Maybe if you find us afterward, we can investigate a little more into that particular use case. AUDIENCE: OK. All right. Appreciate it. CHRISTINA ILVENTO: Thank you. AUDIENCE: Great. I do a ton of development around the Calendar and Documents API. And typically when I'm interacting with that service, from Python for example, I have to implement exponential back-off and retries.
I haven't looked into that much. AUDIENCE: OK. AUDIENCE: [INAUDIBLE] AUDIENCE: OK. CHRISTINA ILVENTO: So stay tuned. AUDIENCE: Hi. I missed the first part of the talk, so maybe you answered this. So does it have any support for caching or throttling of clients? Like for overuse of one client, it starts calling too much often to the API. DAN HOLEVOET: So caching on the client side, or? AUDIENCE: Caching, no, no. Those, sorry, were two questions. Does it have caching support and also throttling in case of overuse? DAN HOLEVOET: So right now I don't think we have any throttling support. But as far as the caching goes– so one of the demos that I showed, when I was calling the APIs Explorer, there's an e-tag that's passed with each request.
And you can use that on the client side to basically not refresh the content every single time that changes. So if you just say, give me the e-tag, then you don't have to request everything again. AUDIENCE: OK. And caching on the server side with memcache or something like that? DAN HOLEVOET: So then it's just an App Engine API, or an App Engine app. So you can do whatever type of caching you want on the back end. So App Engine supports memcache, so you can use memcache. If you want to create some sort of more complicated caching hierarchy, you can do that, too. AUDIENCE: OK. Thank you. AUDIENCE: Oh, very exciting demo. Thank you. So our company works on a client-server application that handles tons of vehicle network data. And I spend a lot of time sending out database queries and all that, tons of them. I was wondering, since I spent so much time profiling the database performance, if we happen to port our existing server into the Google App Engine, do you guys provide some sort of executables that you can run to monitor the performance and all that? DAN HOLEVOET: I mean, there's Appstats. AUDIENCE: OK. DAN HOLEVOET: Which does, basically, I think, what you're looking for.
AUDIENCE: OK. What was that called again? DAN HOLEVOET: Appstats. CHRISTINA ILVENTO: Appstats. AUDIENCE: Oh, OK. Thank you. CHRISTINA ILVENTO: So it looks like we've exhausted the questions from the mic. Anyone else brave enough? All right. Well thank you, again, very much for coming. And please feel free to find us in the sandbox later. We will be around. And enjoy the rest of the conference. Thanks, guys. DAN HOLEVOET: Thank you. [APPLAUSE].