Большинство ваших точек верны, и это действительно можно назвать антипаттерном для запуска Express внутри ваших функций Lambda за шлюзом API.
Следует отметить, что время инициализации не , что представляет большую проблему. Хотя время выполнения одного вызова ограничено 15 минутами, один экземпляр Lambda будет обслуживать несколько запросов после его запуска. Часто вызываемый одиночный экземпляр Lambda обычно имеет срок службы или от 6 до 9 часов и удаляется в течение примерно 30 минут бездействия. (обратите внимание, что AWS публично не раскрывает эти параметры, и эти цифры следует использовать только в качестве ориентировочного). Кто бы ни был неудачлив, чтобы получить холодный старт и съесть задержку инициализации, он может получить дополнительную задержку в тысячи миллисекунд.
Основное преимущество этого подхода, как вы сказали, заключается в предоставлении пути миграции для существующих разработчиков Node с существующими знаниями и приложениями Express. Как правило, вы не должны учитывать этот подход при разработке приложения с нуля и внедрении идиоматических шаблонов без сервера (например, с использованием маршрутизации API Gateway).
Просто повторюсь, основные недостатки этого подхода:
- Более высокая общая ненужная сложность кода благодаря отказу от функциональности API Gateway (маршрутизация и т. Д.)
- Большее время инициализации, приводящее к более длительным холодным запускам
- Большая площадь кода из-за большего числа зависимостей
- Большая площадь кода из-за потери тряски дерева / индивидуальной упаковки из-за внутренней маршрутизации
P.S. Основным претендентом в эти дни, вероятно, был бы не отдельный экземпляр EC2, а скорее контейнеры Fargate, работающие с Express в Node.js. Этот шаблон обладает многими теми же преимуществами, что и безсерверный, сохраняя при этом существующие шаблоны и инструменты разработки в основном без изменений.