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. So rather than dealing with
all of that wrapper code yourself, instead you get to
generate client libraries. So you can get strongly typed
Objective C or Java client libraries for your API that
you can use in your mobile clients, as well as dynamically
typed libraries for JavaScript that you can
use for your browser apps. And the final great thing about
this is that we have OAuth2 support. So figuring out the client
authentication and all that is all handled for you
with Endpoints. So if this slide was not dense
enough for you, let’s walk through how this actually
works in your App Engine development process. So the first thing that we’re
going to do is actually write our back-end code. And we write this the same
way that we would today. So what we have up here is just
a basic Java sample with a game and one method to update
the game, same way you would write a Java App
Engine app today. And the next thing we do to get
our API is we annotate it. And all we have to do is add
this @API annotation to actually turn this
into an API. So from here, the configuration
for the API and the actual service classes
are generated for you. You don’t have to do any
additional work. 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. You can see what that request
might look like if you were inspecting the packets in
something like Wireshark. And then you get the response
from the API, as well. And this looks very similar to
what we saw when we were just testing it locally, except the
computer’s decided to play in a different square. So that’s really cool. And one of the pieces that the
API Explorer is built on is the JavaScript client
library, which we provide for Google APIs. And using that same technology,
we can then go and build a web front end for
the tic-tac-toe game. Again, using this
exact same API. So I’ve written an application
like that here, which you can see, it’s got a very simple
board interface. And if I click on one of these
squares, it’ll send a request off to the computer. The computer plays, and so on. But one thing that’s interesting
about this is then you can go and inspect these
requests as they’re going on in the background. And you can look at the contents
of the requests that I’m sending, as well as the
responses from each of those requests here, too, which,
again, makes it really easy to develop these applications if
you were writing them in, say, Chrome, for instance. So we’ll play again here. Looks like I am a winner
again, awesome. So this is going to send off
a request, again, recording another victory. And hopefully the– back her up– yeah,
there we go– has loaded both the previous
game that I played on the Android device, as well as my
most recent victory in the JavaScript app. So I bet a lot of you are here
not because of your desire to build web applications but your
desire to build Android applications. So let’s take a look at what
this might look like if we were to add this behavior to
an Android application. So the first thing that we’re
going to do is we’re going to return to our App
Engine project. 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. Running– oops. Yes, all right. Presenter’s luck,
what can I say? All right. So now we’ve gotten clients
written in three different languages, running on three
different platforms. And to just show you what this
looks like as far as the development experience on the
admin side, we can then look at the requests coming in from
each of these platforms. And you can see here, at the top
we have requests coming in from the Objective C client. Below that, we have some
requests coming in from the Java client library, which is
the one running on Android. And looks like we’ve got some
people in the audience who are also playing. That’s awesome. And then if we go back to the
previous page, we can see some requests coming from my laptop
here running the JavaScript client library. So there you have it, a simple
App Engine back end powering a mobile application running on
the web, iOS, and Android. So if anyone in the audience
is interested in trying out and doesn’t want to copy the
URLs themselves, we also have some handy QR codes here you
can load up and play. 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 Dan showed you both how to
do the Objective C on the command line, as well as using
the Google Plugin for Eclipse to generate the Java
client libraries. And then we used those to write
our client apps So in the space of the few minutes
Dan was up here, our tic-tac-toe app is off
the ground, and we’re ready to launch. So with Endpoints, you get some
really great features. So you can write your back
end in Python or Java. And then you can use the
annotation-based configuration to actually set up
your API and then get the OAuth2 support. And then on the client side, you
can get generated client libraries in Objective C, Java,
or JavaScript for iOS, Android, or your browser. And then you get the great
tools, and Dan walked you through quite a few of those. So you both get the App Engine
Dev AppServer, so you can test your API locally as part of your
normal App Engine testing process, as well as the
integration with the Google Plugin for Eclipse for
generating client libraries and your natural Android,
Java flow, as well. 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. The API just hiccups for
one reason or another. If I’m writing my own Endpoint,
should I implement similar back-off and retries– should I just expect it to fail
just for the heck of it? CHRISTINA ILVENTO: That sounds
like a reasonable coding practice, just in general. Expect that the worst will
happen every once in awhile. But in terms of a specific– is there retry already
included, or anything like that? Maybe we should chat in more
detail afterwards. AUDIENCE: OK. CHRISTINA ILVENTO: So there’s
some bit in the client libraries there, but I think it
probably warrants a longer discussion. AUDIENCE: OK. Thank you. CHRISTINA ILVENTO: Thank you. AUDIENCE: Are there any plans
or problems with integrating the JavaScript libraries
with GWT, or gwit? CHRISTINA ILVENTO: Are there
any problems with it? AUDIENCE: Like having a wrapper
around it so that gwit services or widgets can easily
call these same services? DAN HOLEVOET: I haven’t
tried that. CHRISTINA ILVENTO: Yeah. 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]