WESLEY: Hi, and welcome to "Serverless Migration Station."
I'm Wesley from Google, joined by Martin
to help you modernize your apps running
on one of our serverless compute platforms.
In this and the next few migration modules,
our little friend Porter will take you
on a journey to migrate from App Engine taskqueues
to Cloud Tasks.
That said, this video won't feature any migrating at all.
MARTIN: Oh really, Wes?
Why not?
I thought this was the "Serverless Migration" video
series.
What's up with that?
WESLEY: Aw.
You caught me, Martin.
Yeah, usually Porter does take users from point A to point B.
But here in module 7, we need to take a detour first
to reacquaint folks with App Engine taskqueues.
We'll add their queues to the module 1 Flask Engine NEB app.
Then we can migrate it to Cloud Tasks ahead in module 8.
MARTIN: OK, I get it.
So we're going to take one of our original Python 2 apps,
add App Engine taskqueues to it, and then learn
how to migrate to Cloud Tasks?
WESLEY: Yep.
You got it, Martin.
In module 1, we migrated from App Engine's webapp2 framework
to Flask, a popular framework in the Python community.
While webapp2 apps run on App Engine,
Flask apps run on App Engine and most other hosting services.
So pause here to review the module 1 video
and do its codelab to reacquaint yourself with that migration,
because this module picks up where that one leaves off.
MARTIN: Ah, yes.
I remember that migration.
So what are we going to use taskqueues
for in our sample app, Wes?
WESLEY: Yeah.
Glad you asked, Martin.
Well, you know our app creates a new entity for each page visit.
Because it only shows the 10 most recent visits,
there's no need to keep all the old ones, right?
Why take up all the extra space, and possibly
exceed our Datastore free tier, and possibly have to pay?
Well, we'll have to add a task that deletes all visits older
than the oldest one shown.
MARTIN: OK.
I have to be honest.
I haven't used App Engine taskqueues in quite a while.
Can I get my hands dirty and do it myself
while you're showing us on screen?
WESLEY: Absolutely.
Go and grab your module 1 code if you did the codelab,
or clone the repo or download the zip file if you didn't.
Pause here if you need to do that.
Module 1 is where we'll start.
If you want to do this by hand with me
now or on your own time, please follow the module 7 codelab.
Ready?
Let's go to the computer now and do this.
Since we're only adding the use of taskqueues to our app,
there are no changes to any of the config files.
Python 2 users should ensure your lib folder is intact.
If not or you're unsure, just delete it
and rerun the pip install command.
Since it's always good to start from a working app,
use gcloud app deploy to redeploy the module 1 app
and ensure it works before we update it.
This is one of the few modules where
the app will look and work slightly differently when
we're done.
To delete the oldest entries, we'll
use some timestamp utilities, like those in the time
and datetime modules.
We're also going to be adding logging to help debug.
Most importantly, we need to add the taskqueue API.
The imports are in the best practice ordering
of standard library packages first,
followed by third-party libraries,
then finally local libraries, and everything
in alphabetical order.
Since we only care about older visits not shown to the user,
it has nothing to do with when visits are created,
so store_visit stays the same.
The actual fetching of most recent visits
hasn't changed, either.
But instead of returning with the data right away,
let's use the timestamp of the oldest visit
and delete everything older than that.
We'll save a human-readable log entry and save it for the user.
That's followed by the most important part, creating
the push task to do the work, passing
in the timestamp and the handler the task should post to.
Once the task is added, return the data
like before, but also include the oldest visit timestamp.
When the task runs, the taskqueue service sends an HTTP
POST to the handler trim(), so let's move to that now.
Flask routes default to HTTP GET,
but tasks are POSTed to their handlers,
so that's why trim()'s decorator is designated that way.
To start, it grabs the oldest entity timestamp we got from
fetch_visits().
Next, it queries for all entities older than that.
We don't need the data, so just ask for keys only
to speed it up.
If old visits exist, log how many we're deleting and do it.
Otherwise, log there aren't any.
And that's it for the task.
The main handler stores and fetches visits as before,
but now we have a timestamp for the oldest displayed visit
to let the user know that visits older
than that will automatically be deleted.
Both the data and oldest visit timestamp
are sent to the template for rendering.
But before we do that, we better update that template.
The majority of the template stays the same,
but check for a timestamp.
If so, show that older visits will be deleted.
Because it checks for the existence of the timestamp,
this template can be used in other modules,
because there are no side effects
if the timestamp isn't there.
And those are all the changes necessary to add
push tasks to our existing app.
If you did everything correctly and redeployed the sample app,
you should now see an additional message down
at the bottom letting users know what visits
were deleted by the push task.
OK, back to the program.
MARTIN: Thanks for the tutorial, Wes.
Where should I go if I want to reacquaint myself
with App Engine taskqueues?
WESLEY: Well, Martin, I'd say start
with the taskqueue overview page in the docs.
While our simple app only uses push tasks,
you'll find docs for both push and pull queues there.
MARTIN: Cool, I'll take a look.
But can you give me a heads-up on what we're doing next?
WESLEY: Sure, Martin.
Now that we have App Engine taskqueues in our app,
we'll migrate it to Cloud Tasks ahead in module 8.
If you want to read ahead, check out the links
to the migration page, as well as the Cloud Tasks
documentation.
You can also do the module 8 codelab
if you want to get started on it right away,
or go back to the repo to either look at the code
or check out the next video.
And we look forward to having all of you join us for module 8
and moving to Cloud Tasks.
This is Wesley.
On behalf of Martin and Porter, we
hope to see you at that next "Migration Station"
or on another "Serverless Expedition" soon.
[MUSIC PLAYING]