Существуют разные способы передачи данных между представлениями. На самом деле это не сильно отличается от того, что возникает проблема передачи данных между двумя разными сценариями и, конечно, некоторые концепции межпроцессного взаимодействия. Некоторые вещи, которые приходят на ум, -
- GET request - Первый запрос достигает view1-> отправить данные в браузер -> браузер перенаправляет в view2
- POST-запрос - (как вы предложили) Тот же поток, что и выше, но он подходит, когда требуется больше данных
- Переменные сессии Django - Это самый простой способ реализации
- Файлы cookie на стороне клиента - Можно использовать, но существуют ограничения на объем хранимых данных.
- Общая память на уровне веб-сервера - Сложно, но можно сделать.
- API REST - Если у вас может быть автономный сервер, то этот сервер может использовать API REST для вызова представлений.
- Очереди сообщений - Опять же, если автономный сервер возможен, возможно, даже очереди сообщений будут работать. то есть первое представление (API) принимает запросы и помещает их в очередь, и некоторые другие процессы могут извлекать сообщения и переходить во второе представление (другое API). Это позволит отделить API первого и второго вида и, возможно, лучше управлять загрузкой.
- Кэш - Может быть, кеш, подобный memcached , может выступать в качестве посредника. Но тогда, если вы идете по этому пути, лучше использовать сеансы Django, так как он скрывает множество деталей реализации, но если масштабирование является проблемой, memcached или redis являются хорошими вариантами.
- Постоянное хранилище - хранить данные в каком-либо механизме постоянного хранения, таком как mysql. Это отделяет ваш запрос, принимающий участие (возможно, с клиентским API) от обрабатывающей части, имея БД в середине.
- NoSql хранилища - если скорость записи находится в другом порядке сотен тысяч в секунду, тогда производительность MySql станет узким местом (есть способы обойти настройку mysql, но это не легко). Тогда рассмотрение NoSql DB может быть альтернативой. например: DynamoDB, Redis, HBase и т. д.
- Потоковая обработка - например, Storm или AWS Kinesis может быть вариантом, если ваш сценарий использования - вычисления в реальном времени. Фактически вы могли бы использовать AWS Lambda посередине в качестве безсерверного вычислительного модуля, который считывал бы и вызывал бы ваш API второго представления.
- Записать данные в файл - тогда следующий вид может прочитать из этого файла (очень уродливо). Этого, вероятно, никогда не следует делать, но ставить эту точку здесь как нечто, чего не следует делать.
Не могу думать больше. Будет ли обновление, если я получу. Надеюсь, это поможет каким-то образом.