Is using Google Cloud Tasks to invoke an internal Django endpoint effectively asynchronous (even under WSGI)?
I'm running a Django application on Google Cloud Run using the default WSGI-based setup (e.g., Gunicorn/ runserver for local dev).
To avoid blocking during long-running operations like third-party API calls, I'm planning to use Google Cloud Tasks.
Current design:
A request comes in to a Django endpoint (e.g., a webhook or ping from an external service)
Instead of processing the request inline, I enqueue a Cloud Task
That task posts to another Django endpoint within the same service, which performs the third-party API call using data passed in the task payload
This means:
I'm not offloading the work to a separate Cloud Run service
The fetch logic is still part of the same Django service/container, just decoupled by the task
My question:
Does this setup allow the third-party call to be effectively asynchronous (i.e., non-blocking to the original request), despite using WSGI and not ASGI or Celery?
When searching around, I mostly see articles and examples where Cloud Tasks are used to call a separate Cloud Run service, not another internal route in the same app.
Is this internal invocation pattern valid and scalable under WSGI, or are there caveats I should be aware of?
To ensure if that setup is valid or possible, it would be best to consult a Google Cloud sales specialist. They can offer personalized advice and technical recommendations tailored to your application’s needs. From identifying suitable use cases to helping you manage future workload costs effectively, their insights can be invaluable.
It depends a little on what you are trying not to block here. The task will take the same amount of time regardless of the way it is initiated, so the client will not be able to make use of the result until it is complete in any case.
What I think you might want is a way for a client to get a response to its request quickly rather than waiting for the task to complete because the client does not care about the result and just wants to initiate the process. So you really want the long running process to not block the response to the initial request. If so the pattern you describe should work fine.
This pattern worked well for us in App Engine, where long running tasks would be triggered from the original client request. The original request would receive a response as soon as the task was created with a task identifier. Cloud tasks then makes a request to the long running endpoint within the same application, and records progress in data store. Cloud tasks is agnostic to what it calls, whether that is part of the original application or not, so there is no need for an additional application or service. The client could optionally then poll an endpoint for status updates.
In terms of the server scaling, running ASGI may allow for an instance to handle more requests concurrently (particularly if they are blocked on a third party API), which can reduce costs. But even with WSGI cloud run will just create more instances to handle more requests. To put it another way, if you were using an ASGI server, and returning the result of the long running operation in the first request the client would still have to wait a long time for the first response, you just might be able to handle more clients per instance.