Много маленьких запросов против нескольких больших запросов - Angular to Django REST API - БД не задействована

Question

Я знаю, что есть вопросы, связанные с SO, но я не уверен, что условия, над которыми мне приходится работать, вызывают какие-либо изменения в ответе, поэтому я задаю его здесь.

Я создаю простое веб-приложение на Angular, которое импортирует данные электронной таблицы от пользователя и отправляет данные в бэкэнд Django, который выполняет анализ данных на нем. Результаты данных возвращаются во внешний интерфейс, а Angular создает панель результатов. Существует диаграмма, отображаемая для каждого столбца электронной таблицы. Я сталкиваюсь с двумя вариантами:

a) Сохранение электронной таблицы в памяти браузера и отправка каждого столбца данных отдельно на сервер Django, который выполняет анализ данных и возвращает результаты.

Плюсы: простая архитектура. Кэширование не требуется.

Минусы: если на листе 150 столбцов, это приведет к 150 вызовам API для этого пользователя.

b) Отправка всего листаданные и пусть Python обрабатывает все. Он вернет большой кусок данных взамен, который должен быть распакован Angular.

Плюсы: только один запрос на файл.

Минусы: для последующих вызовов для того жефайл, мне может понадобиться кэширование? Если файл изменился, это может привести к устареванию данных. Мне также может понадобиться поддерживать сеансы для каждого пользователя.

Ограничения, с которыми я работаю: Я не могу сохранить документ ни на сервере Django, ни в БД. Несмотря на то, что это только внутреннее приложение, документы могут быть чувствительными, и пользователи не будут удобны для хранения любого вида.

Кроме того, существует высокая вероятность того, что файлы могут иметь размер более 100 МБ,так что это также становится фактором.

В таком случае, имеет ли смысл реализовать «Много маленьких запросов»? Заранее извиняюсь, если вопрос повторяется.

Answer 1

Еще одним фактором, который вы не учитываете, является то, что браузеры (скажем, Chrome) выделяют только 6 TCP-портов на хост . Это означает, что если вы используете подход «Много маленьких запросов», вы можете столкнуться с некоторыми серьезными проблемами с производительностью в зависимости от того, сколько времени потребуется для обработки этого запроса на бэкэнде.

Другой фактор, который следует учитывать, -вы собираетесь обрабатывать откат данных? Если вы получаете 50% (75) запросов и пользователь хочет отменить его или браузер зависает и т. Д., Что происходит с другими 50%?

Если это внутреннее приложение, работающее в быстрой сети, ялично я бы просто пошел с одним запросом на файл. 100 МБ в сети 100 ГБ - не такая большая проблема.

Если это не во внутренней сети, то мне пришлось бы выбирать микротранзакции, потому что пользовательский опыт получения до 99% загрузкии неудача через 10 минут - это то, что, я уверен, мы все испытали (ужасно). По крайней мере, благодаря микротранзакционному подходу вы можете контролировать откат данных и даже открывать сокеты на внешнем интерфейсе для обновления. Например, если во время обработки произошел сбой определенного столбца, angular может попытаться отправить его и т. Д.

Здесь не подходит ни один размер, и это просто мое мнение.