Как выглядит коммуникация между frontend и backend при использовании ZipOutputStream?

Question

[John Bourne]

Как выглядит коммуникация между frontend и backend (java), когда пользователь отправляет запрос на скачивание zip архива? Backend будет использовать ZipOutputStream (бибилиотека), чтобы собирать zip архив на ходу (то есть добавлять в него файлы).

Фронт отправляет http API GET запрос, в ответ мы отдаём что? Могли бы, вы пожалуйста, рассказать мне про полный цикл коммуникации frontend и backend, с примерами запросов.

Comments

[Dmitry Roo]

Для фронта это обычный файл? Такой же как и любой другой?

[John Bourne]

Dmitry Roo, да, это ZIP архив, в который наполняется данными в реальном времени.

[Dmitry Roo]

https://stackoverflow.com/questions/65146044/sprin...
оно?

[John Bourne]

Dmitry Roo, кажется, да. Спасибо!

Answer 1

[Алексей Черемисин]

В вашем случае - взаимодействия нет, если конечно frontend на является нативным приложением.
Поясню:
1) backend подготавливает zip-архив и шлет его в бинарном виде через GET/POST/PUT, выставляя заголовок
Content-Type: application/zip
и возможно

Content-Disposition: attachment; filename="myarchive.zip"

2) frontend, принимая данный ответ на свой запрос:
- если это браузер, то просто скачает файл (если не использовали Blob или что-то подобное),
- если это приложение, то получит бинарный поток, который кладет самостоятельно на диск и распаковывает
- если же frontend в виде JS в браузере примет этот поток, то средств его распаковать у браузера нет! можно только показать прогрессию загрузки.

Comments

[John Bourne]

Да, когда файл храниться в ОЗУ или на дске в виде zip, такой сценарий я понимаю.

Но не понимаю сценарий, когда, бэкенд будет получать со стороннего сервиса файлы в течении 1 минуты, по мере их получения упаковывать их в один zip. Но скачивание на фронте должно начаться не дожидаясь полной упаковки. То есть нужен стим. Вот в таком сценарии я не понимаю, что к чему.

[Алексей Черемисин]

John Bourne,

Вот в таком сценарии я не понимаю, что к чему.

По правде говоря, я тоже в этом сценарии мало прослеживаю логику.
Если на беке у нас что-тот происходит относительно медленно, то на фронте нужен какой-то другой сценарий работы.
Например: на беке мы запустили "задачу" и с фронта ее постоянно мониторим ее выполнение (websockets/sse/long pooling/poolng), как только "задача" завершена, то даем ссылку на скачивание результатов.
Как пример подобного поведения можно привести всякие мегааплоад и прочие сервисы.
Со стороны фронта все это реализуется достаточно просто, как и со стороны бека.

[John Bourne]

Например: на беке мы запустили "задачу" и с фронта ее постоянно мониторим ее выполнение (websockets/sse/long pooling/poolng), как только "задача" завершена, то даем ссылку на скачивание результатов.

Для подобного необходимо либо локально или в оперативе хранить 100 файлов. А я так не хочу. Я хочу чтобы в оперативе было не больше 1 файла. Получил файл, сложил в ZIP, пошёл за другим.

Пример, как я это вижу:

[Алексей Черемисин]

John Bourne, ну, можно и так.
вопрос в том, что:
- где-то Ваш поток может порваться, на роутере, на прокси, да еще фиг знает где...
- режете себе ситуацию с докачкой файла и многопоточной закачкой...
- непонятно, как будете обрабатывать ошибки...

В конечном итоге придете к созданию временных файлов и их периодической чистке...

Или у Вас вопрос, как работать с ZipOutputStream? Там есть еще ZipEntry, если что...

[John Bourne]

Алексей Черемисин, верно, вопрос мой про ZipOutputStream, как с ним работать в контексте потоковой подачи данных через http.

[Алексей Черемисин]

John Bourne, Ох, но все же просто, нужно из Response взять OutputStream (getOutputStream если не путаю). И этот OutputStream подсунуть в ZipOutputStream - все!
Как-то так...

// ....
OutputStream out  = response.getOutputStream();
ZipOutputStream zos  = new ZipOutputStream(out); // tadam!
// .... may be in while ....
ZipEntry zint = new ZipEntry("myfile.doc");
zos.putNextEntry(zint);
zos.write(mybuffer);
zos.closeEntry();
//....
zos.flush();
zos.close();

Весь вопрос, что у Вас, сервлет или еще что? Ну тут уж читать доку на фреймворк.

[John Bourne]

Алексей Черемисин, благодарю!

Answer 2

[Сергей Соловьев]

Бэк отправляет HTTP ответ, в котором выставляет Content-Encoding: gzip (или другой формат). Фронт находит и пытается распаковать

Comments

[John Bourne]

Через HTTP Streaming?

[Сергей Соловьев]

John Bourne, нет, также как и обычный ответ. Разница только в том, что есть доп. этап распаковки ответа

[John Bourne]

Сергей Соловьев, вы говорите про ситуацию, когда бэкенд на в оперативной памяти или в локальном хранилище имеет готовый zip архив?

У меня ситуация такая, бэкенд будет получать в течении 1 минуты файлы, и их упаковывать в zip. Но скачивание на фронте должно начаться не дожидаясь полной упаковки. То есть нужен стим.

[Сергей Соловьев]

John Bourne, я в тему алгоритмов сжатия давно не копал, но судя по всему тут необходим алгоритм потокового сжатия, а все текущие (на сколько мне известно) должны знать все содержимое заранее, чтобы составить словарь.
В таком варианте стриминг невозможен из-за самого алгоритма сжатия

[Odissey Nemo]

John Bourne, HTTP-заголовки для поддержки докачки (Content-Type: application/zip, Transfer-Encoding: chunked).
Т.е. клиент получает кусками, а server поддаёт как может. Закончится всё только когда сервер закончит и клиент это узнает. И тогда он сможет открыть полученный ZIP целиком, наконец.
Деталей не помню, давно занимался. Но так делал и оно работало. Такое нужно, когда не знаешь пределы длины ZIP файла, формируемого на ходу из результатов запроса по произвольной выборке отчётов, скажем, или каких-от квитанций в XML или любом другом виде.
Спроси deepseek - он такие короткие но сочные вопросы щёлкает на раз.