In the 1st generation standard environment GAE (python 2.7) services you should continue to use the Task Queue API, there is no deprecation note for it.
Task Queue API is not available in the other environments, so for those services you have to use the newer Cloud Tasks API (which at least initially was based on a 1st gen standard environment service under the hood, but now it supports multiple HTTP endpoints).
You shouldn't worry too much about the Cloud Tasks page - it just make sense to manage both through a common GUI due to their similarities, but the 2 products continue to operate independently. Depending on which API you use you could, I suppose, use both features in the same time (for different tasks, of course) and manage both through the common GUI.
You can't exactly talk about which service handles a queue as tasks in the same queue could be handled by different services. For example in GAE push queues there are 3 ways for targeting a task:
- Declare the target when you construct the task. You can set the target explicitly using the
target parameter in the
taskqueue.add() function. See the example above.
- Include a
target directive when you define a queue in the queue.yaml, as in the definition of queue-blue. All tasks
added to a queue with a target will use that target, even if a
different target was assigned to the task at construction time.
- If no target is specified according to either of the previous two methods, then the task's target is the version of the service that
enqueues it. Note that if you enqueue a task from the default service
and version in this manner, and the default version changes before the
task executes, it will run in the new default version.
In Cloud Tasks targeting is even wider - a task target isn't even necessarily a GAE service. From Cloud Tasks queues with HTTP targets:
In the case of generic HTTP Targets, the Cloud Tasks service forwards
the task request to the worker, located at any generic HTTP endpoint,
such as Cloud Functions, Cloud Run, GKE, Compute
Engine, or even an on-prem web server, and based on how the task
is configured.
The deferred queues is similarly misleading, you should be referring to deferred tasks. In general there are 2 main reasons for using them:
In some cases where you might need a series of diverse small tasks
handled asynchronously but you don't want to go through the work of
setting up individual distinct handlers, the App Engine SDK allows you
to use runtime specific libraries to create simple functions to manage
these tasks. This feature is not available in Cloud Tasks. Note,
though, that normal tasks can be scheduled in the future using Cloud
Tasks.
