Как выглядит коммуникация между 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 архив, в который наполняется данными в реальном времени.

Answer 1

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

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

Comments

[John Bourne]

Через HTTP Streaming?

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

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

[John Bourne]

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

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

Answer 2

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

В вашем случае - взаимодействия нет, если конечно 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, если что...