Чтобы на конкретный запрос вернуть данные, запрос от клиента, там и request_uuid генерится. У одного юзера во время одной сессии может быть сгенерировано много таких запросов с разным request_uuid.
Еще user_id используется в имени канала.
Это можно реализовать, например, с помощью Tornado или asyncio + Redis pub/sub + sockjs (https://github.com/leporo/tornado-redis#pubsub).
На фронте генерируем случайный uuid, подписываемся и отправляем в запросе на бэкенд. В Celery результат таска пишем в Redis канал с тем uuid в имени. Результат отправляется подписанному клиенту.
Django будет обрабатывать эти запросы синхронно. А их может быть сильно больше чем к основному приложению. Tornado или другой асинхронный фреймворк лучше справляются с этой задачей.
Наверно три основные библиотеки, которые использую вместе с Django, это Celery для асинхронных тасков, Django Rest Framework для REST API и Python Social Auth для интеграции с соцсетями.
Еще user_id используется в имени канала.
На фронте генерируем случайный uuid, подписываемся и отправляем в запросе на бэкенд. В Celery результат таска пишем в Redis канал с тем uuid в имени. Результат отправляется подписанному клиенту.
В статье заменил uWSGI на WSGI, так корректней будет.
Наверно три основные библиотеки, которые использую вместе с Django, это Celery для асинхронных тасков, Django Rest Framework для REST API и Python Social Auth для интеграции с соцсетями.
Еще есть такие списки:
https://github.com/wsvincent/awesome-django
https://github.com/vinta/awesome-python