Выгрузка / загрузка LARGE файлов в / из функции Lambda с использованием API Gateway без использования S3 Bucket

Question

Я реализую API без сервера , используя:

1. Шлюз API
2. Лямбда
3. S3 Bucket "При необходимости"

Мой поток:

1. Вызов метода POST или PUT с двоичным файлом "zip ", загрузите его в Lambda.
2. В Lambda: разархивируйте файл.
3. В Lambda: запустите определенный скрипт над извлеченными файлами.
4. В Lambda: создайтеnew zip.
5. Верните его на мой рабочий стол.

Этот поток уже реализован, и он хорошо работает с небольшими файлами, 10 МБ для загрузки и 6 МБ для загрузки.Но у меня возникают проблемы при работе с большими файлами, так как это будет иметь место во многих случаях.Чтобы решить эту проблему, я думаю о следующем потоке:

1. Целевой файл загружается в S3 Bucket.
2. Создается новое событие и запускается Lambda.

3. Lambda Внутренние задачи:

   3.1 Lambda Загрузить файл из корзины S3.

   3.2 Lambda Сгенерировать соответствующий пакет WPK.

   3.3 Lambda Загрузить сгенерированный пакет WPKв S3.

   3.4. Lambda возвращает подписанный URL-адрес, связанный с загруженным файлом, в качестве ответа.

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

Мои компоненты и блок-схема будет:

Компонент и блок-схема

Answer 1

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

1. Используйте Node.js для потоковая передача zip-файла, разархивирование файла в канале, помещение содержимого в канале потока записи обратно на S3.
2. Развертывание вашего кода в задании по склеиванию AWS.
3. Загрузкафайл для S3, запускается AWS Lambda, передают имя файла как ключ к работе склеивания, и все остальное будет выполнено.Таким образом, у вас есть подход без сервера и код, который не вызывает проблем с памятью при распаковке больших файлов