BASTIEN LEGRAS: Hi, I guess you can hear me.
So my name is Bastien Legras.
I am a cloud solution engineer based in Google Paris office.
I work with Christoph that you just saw before me.
And we cover together Southern Europe, so France, Italy, and
Spain, and Portugal.
And in this session--
it's a 20-minute session--
we're going to cover mobile from a more technical
perspective.
So we're going to cover Cloud Endpoints.
Maybe you heard about it.
It's a feature of App Engine.
And we're going to cover, as well, Cloud Mobile Backends.
That has been announced at Google I/O. And I will show an
extract of the video of Google I/O.
So first, Cloud Endpoints.
For those who don't know already, the idea with Cloud
Endpoints is to accelerate the time to market for your mobile
applications, or web applications as well, in
HTML5, by autocoding the layer that connects your mobile app
to our backend.
So you just have to focus on the UI, on the user
experience, and the features of your game, and don't worry
about the [INAUDIBLE]
that will access the backend services.
And we do that for Android and iOS.
The other topic, the Mobile Backend Starter, and we're
going to go deep dive into these features, is a set of
APIs, of services in the App Engine, that will also help
you do stuff like authentication, messaging--
so push from the cloud--
continuous queries-- we'll have a short video on that--
and, again, help you be more productive and focus more on
your app rather than on the technical underground.
So first this one minute interview with Fred Sauer and
Mandy Waite who are in developer relations, also at
Google, based in the US, and she's in London, I guess.
Telling what is the strategy with cloud backend.
So for that, because we don't have an output, I will try to
use the mic, hoping we won't have feedback.
FRED SAUER: So how viable or recommended would it be to
build a backend service for mobile apps around Google
Cloud Endpoints?
MANDY WAITE: All right, I think, really, that's probably
the biggest use case for Cloud Endpoints,
building mobile backends.
And we say backends, again, we're talking about the
general sense of it, rather than the App
Engine sense of backends.
If you want to build an application that will provide
resources and services that are consumed by mobile
devices, then Cloud Endpoints will do that for
you out of the box.
I think, pretty much, we covered most
of that in the slides.
But the documentation is pretty extensive, both for
Java and for Python.
So you can learn more about how to use Cloud Endpoints.
You can check that out.
There was also Google I/O.
FRED SAUER: There was, yes.
MANDY WAITE: You can actually get a lot of information from
Google I/O sessions from previous years.
FRED SAUER: Very good.
All right, your turn.
MANDY WAITE: My turn.
BASTIEN LEGRAS: I'm not sure you have heard very well, but
you have the captions.
So as you understand, the idea is to really help startups
being more productive and so to try more applications, more
games, on Android and iOS.
So let's talk about--
sorry--
so where Christoph left you last, which
is the Cloud Endpoints.
So as I said, the idea is that all the essential components
that all mobile applications need are, basically,
autocoded--
when I say autocoded, it's like a wrapper is coded.
So you just have to--
if you are building your own APIs, in the App Engine
backend, then you will manage with the cloud backend to
expose these APIs, and also have the client side that will
be written by the App Engine toolkit, so you can directly
start from that.
And the development process is quite simple.
So you write your API backend first.
That's where you need to start, at the data design, and
of course, the methods you want to expose.
And then, what you can do is either annotate your API
backend code, because this is the annotation that will help
the toolkit to generate the wrapper, or you can use the
plug-in for Eclipse, if you are an Eclipse developer.
And by the way, who is an Eclipse developer here?
Quite a number of you.
So the two options are here.
Then what you want to do is to generate the client library,
of course, from which you will then write your mobile app.
And again, two solutions.
You can use the SH tool, endpoints.sh, or use the
plug-in directly within Eclipse.
And then, for the last step, you can start working on your
client app and, as I said, focus on your UI, on the
business logic on the client side of your application.
So now, some extract of the Google I/O slides as well.
So they were building an application live in the demo.
And I encourage you to go have a look at this video.
It's a 30-minute long video.
And I'll show you after the link, where geeks want to
finally choose us for using maps, et cetera.
And the idea here, as you can see, that application on the
left is using the Mobile Backend Starter Client,
directly connected, and the Android Client ID.
So the ID that will also help identify your application with
the backend to connect to each other.
What you can do as well-- so now I'm more focusing on the
backend itself-- is that you can directly store your
application data in two kinds of storage.
I don't know if you can read, but there is the App Engine
data store, which we have now renamed by the way, as Cloud
Datastore, from which you can connect from anywhere.
And the idea is that we now have even four storage
mechanisms with Google Cloud platform.
You have this Cloud Datastore, which is a NoSQL, [INAUDIBLE]
datastore.
You can store terabytes of objects if you want.
Here we have, also, the Google Cloud storage, which is object
storage, more like a file system.
And we will have a session on that this
afternoon at 3:00, I think.
That will be me again.
I'll do a quick demo.
For those who don't know, there is also CloudSQL, which
is MySQL 5.5 managed in our cloud data centers.
And you can directly access using SQL queries at the port
3306 from Compute Engine today.
And at the end, because I wanted to focus more on
storage, there is also another storage mechanism which is
more in the Compute Engine world.
And we will discuss about Compute Engine a lot.
This afternoon, I will do a demo of that as well.
It's called the Persistent Disk.
So Persistent Disk is a five-system mounted network
share that you can share across apps to 16 machines.
And you can format yourself.
And you can use that to boot your machines--
very convenient and scalable.
Then other features that you may need from the cloud
backend for your application is asynchronous processing.
So you can use Task Queues.
Task Queues is one of the top components in App Engine.
So you can directly create your tasks, store them, and
they will executive so you can run your batches.
I don't know why I am using my keyboard.
So then the push notification, that's
something also really key.
This is something we've been using a lot at Google since
day one because for Android, with Google Play--
so former Android market--
when we want to push application updates so your
phone is going to download them automatically, the idea
that we've been using that type of technology.
So cloud messaging--
so the phone stays quite connected, if you
want, with the cloud.
So you can push from your app's backend to the users a
notification.
That's very useful.
Let's say in a gaming environment, or if people want
to chat-- we use it as well for Google Hangout--
renamed, it was Google Talk before.
We cannot predict when the notification will come.
And cloud messaging is the right toolkit for that.
So you can really push messages, technical messages,
to the app instances you get.
And we have also worked on the iOS world.
So as you can see here, Apple push notification service,
which is similar to VPN, similar to push also with
messages from the backend to iOS instances.
Another example-- so I hope, in the next video, I will show
and you can hear, so you understand
how it works as well.
But you see, still, on the right side, the Mobile Backend
Starter and the Client Library on the left, showing how you
can do that kind of registration and
push messages directly.
And then serving and processing images.
If you are developing, I don't know, a camera for the phone,
or a game that needs image processing, like social
network, that's also a service we provide
on the cloud platform.
So something you directly use from cloud storage to store
the static images.
And then you can process them in the image service to
convert them from a format to another, to do, I don't know,
color modifications, stuff like this, or push lighter
images to your phone, if, when you're want to have a mosaics,
family pictures.
So that's the type, usually, of usage we see
on the image services.
Another one is the search.
So of course, we do a lot of things in search.
And now App Engine--
so I think this was an App Engine in the March version--
we now provide full text search.
And that's also something very useful in the mobile use case.
So we can do full text search on the backend directly from
the phone as well.
And geo proximity again, if you wanted to search in a
geolocalization context.
The tasks we were talking about, the Task Queues, now
there's also the schedule task.
If you need to have schedule task for your application,
like, I don't know, recurrent updates, or if there is a
message that you need to pass at the certain time of the day
to your users.
That's also a component of App Engine you may want to use in
a mobile scenario.
Now I heard a question this morning of someone asking
what's the integration between the App Engine
and the Compute Engine?
So we have been working on that.
And the idea is that if you have a heavy task that you
don't want to run using App Engine backend, but you need
really a sever to do that, or rack of servers, you can do
that from Compute Engine and
orchestrate it from App Engine.
So the idea here-- that's what we call VM Engine--
is that you can imagine you create a task.
And this task is going to be sent to a cluster of GC
machines that you can start from App Engine, execute the
task, send back the result, and then
shut down the mission.
Maybe you've heard at I/O that we now do [INAUDIBLE], so that
is very useful.
If you have really heavy video processing task for which you
need a heavy CPU server.
You can really imagine that the task is generated by App
Engine, executed by Compute Engine, result is sent back,
and App Engine [INAUDIBLE].
Very convenient, and all that is
integrated using Task Queues.
Continuous Query also is quite interesting.
So I would like to show an extract of the I/O session on
that, so you can better understand what was the use
case, and how it works because it's a five-step scenario.
And that's, I think, very interesting also for gaming or
mobile apps in general.
So we're going to try with this one.
But worse case is there are captions, OK?
So a two- or three-minute video, there are captions .
And I think I already--
no, let's try that way.
DAVID CHANDLER: Well, I'll tell you about the Continuous
Query capability that we're going to use to do that.
So this is a feature of the Mobile Backend Starter project
that uses several App Engine features as well.
There's a API and preview called Prospective Search.
And what that does is, anytime data comes in that matches the
parameters of your query, then App Engine will notify your
app on the server side that some matching
data has been found.
So we're going to use that to our advantage here.
Any time a new location update gets posted, then our app will
get notified on the server side.
And the Mobile Backend Starter project takes that further and
will send a GCM message to our app running on
the phone as well.
So the flow looks like this.
In step one, a new location update comes from the phone,
gets put in the server.
In step two, the App Engine Prospective Search API
notifies the server side part of our Mobile
Backend Starter app.
That sends a GCM message, Google Cloud Messaging, to the
client in step three.
Then, in step four we re-query to get the latest data from
the server.
And then, finally, step five, we draw the markers on the map
with that most recent data.
So I'm going to go now write the code that actually does
this in our app.
So we'll again take a look into our map activity.
And the first thing we want to do is write a query--
I'm just going to scroll down a little bit here--
that will go out and get the geek locations.
So we paste in some code here, query geeks, and show you what
that looks like.
All the capability that I just described on that slide is
called Continuous Queries is what we're calling it right
now in this project.
And so the first part of our query is to write a handler
that will receive the results, so we have
a OnComplete handler.
And we're just going to draw markers, simple enough.
Then, to actually register the query, we call
getCloudBackend. clearAllSubscription.
Now the notion of a Continuous Query, you can subscribe to
queries on the server.
So we want to clear any existing subscriptions and
then set up a new one.
So we say a new Cloud Query for kind geek.
We're just going to get the top 50 geeks sorted in order
of the most recent location updates.
And we're going to make the scope future and past.
So again, this is a feature of the Mobile Backend Starter
that lets you say, I want to be notified of future matches
to this query, as well as present.
And if you think about the amount of code that you would
have to write to do all manually, setting up GCM,
keeping track of this data, is actually a very nice
convenience.
BASTIEN LEGRAS: It stops there.
So it was to better illustrate this concept.
So this is the slide Christoph was showing before.
But now, you maybe more understand how all the pieces
of the puzzle come together.
So it's a recap of all these features, as you can see.
So we really believe with that kind of architectures, App
Engine is a great orchestrater.
So it's like the chef or puppet if you use that kind of
technology to talk to all the services.
We think that with doing a lot of
integration between the services--
the team in Google, it's hundreds of engineers we have
in US and in Europe.
But the idea is to have a common set of APIs.
And you will see in the demo this afternoon on the Compute
Engine, I will show what is a project, how the console looks
like, and how you can activate your services, and how you can
connect each together when it comes to
design and video projects.
So in this capacity, App Engine is talking to your
devices, whether they are Android or iOS.
It can talk directly from here and push to Android devices
using Google Cloud Messaging technology or using Apple push
notification technology.
So that's the two ways you can communicate from the cloud to
the devices.
That was the monetization piece AdMob that Christoph
mentioned earlier.
You have all these App Engine features--
we've been covering these in the App Engine session-- that
are, of course, useful in a mobile development scenario.
The Task Queries as I mentioned earlier, and that
you can use to do some batch processing on Compute Engine
for heavy loads, schedule tasks, search APIs, and log
the APIs as usual on App Engine that you can also
imagine, because now we are plugging together BigQuery,
which is our big data engine, and some other parts of
Google, like Google Analytics, Google AdSense, the logs here
from App Engine.
So you can also analyze the way all your users are playing
or are using your application to better understand what
works, what doesn't work, in an application.
So you can optimize it, whether it's difficult
[? seniority ?]--
and again, to make sure that people are not stuck in level
four because there's a challenge that was maybe too
much difficult for the user.
Or if it's a feature that no one uses.
So that's a great way, using the logs and BigQuery to
detect that kind of optimization you should do on
your application.
And if you are very hungry--
[APPLAUSE]
BASTIEN LEGRAS: Thank you very much.