Aws-serverless-express - это платформа API на основе NodeJS, используемая для имитации возможностей маршрутизации инфраструктуры ExpressJS внутри функций Lambda. Эта статья призвана объяснить плюсы и минусы использования этой библиотеки.
Начиная!
Вы, вероятно, здесь потому, что:
- Вы разработчик NodeJS
- Вы использовали Express в качестве платформы API.
- Вы планируете перенос рабочих нагрузок API на бессерверную архитектуру.
- Вы хотите быстро приступить к работе с AWS Lambda, но каким-то образом перегружены новыми концепциями и хотели бы использовать эту структуру.
Что ж, если мне удастся идентифицировать вашу возможную личность, вы попали в нужное место, поскольку эта статья предназначена для демонстрации положительных и отрицательных сторон фреймворка AWS serverless express с точки зрения архитектора.
Различия между Serverless Express и Classic ExpressJS
Чтобы дать справедливую оценку достоинствам и недостаткам aws-serverless-express, мы должны понимать критические различия между классическими и основанными на лямбда экспресс-фреймворками.
Критические различия
Среды хостинга
aws-serverless-express предназначен для работы внутри лямбда-функций, тогда как классический ExpressJS должен работать внутри виртуальных машин или контейнеров Docker. Это означает, что бессерверный экспресс не способен сохранять состояние сеанса в какой-либо форме из-за случайного расположения выполнения лямбда-функций между зонами доступности региона.
Это также означает, что фреймворк на основе лямбда может быть дешевле, более масштабируемым и предлагает вам большую эффективность по сравнению с традиционным.
Государственное управление
aws-serverless-express не управляет состоянием, потому что он предназначен для работы с различными базовыми лямбда-функциями. Это означает, что любая попытка сохранить состояние, связанное с сеансом, внутри экземпляра API приведет к сбоям в лямбда-функции. Это связано с тем, что лямбда-функции удаляются после 15 минут простоя вычислений.
Давайте начнем сравнение!
Теперь, когда мы знаем о критических различиях между двумя фреймворками Express, мы можем начать разбираться в хороших и плохих вещах, связанных с использованием serverless-express.
Преимущество №1 Serverless Express ускоряет миграцию
Использование бессерверной экспресс-версии для миграции существующих рабочих нагрузок API в бессерверную архитектуру снижает усилия, необходимые со стороны разработчиков, потому что:
- Реализация маршрутизации между двумя фреймворками аналогична, что приводит к более низкому когнитивному барьеру между мышлением, необходимым для построения поверх двух фреймворков.
- Разработчикам не нужно изменять маршруты HTTP, существующие в переносимом приложении.
- Разработчикам внешнего интерфейса не нужно обновлять ВСЕ свой клиентский код, чтобы указать модули графического интерфейса для новых маршрутов. Я выделил слово «Все» полужирным шрифтом, потому что хотел подчеркнуть, что вам все равно нужно обновить некоторый код, связанный с HTTP. В частности, методы HTTP (PUT, POST, GET, DELETE).
- Разработчики могут с уверенностью копировать и вставлять код уровня контроллера из существующих API-интерфейсов на основе выражений в выражения на основе лямбда-выражений.
Преимущество №2: сокращение SAM и кода формирования облака
Поскольку serverless express требует, чтобы у нас была только одна лямбда-функция, определение кода SAM и Cloud Formation становится проще, поскольку вам не нужно беспокоиться о приобретении инфраструктуры в качестве навыков кода для автоматизации и предоставления бессерверных рабочих нагрузок.
Это также упрощает обслуживание и чтение шаблона SAM с точки зрения нового участника (в принципе, любой краткий и умещающийся на одном экране код легко поддерживать).
Преимущество №3 более быстрого развертывания
Поскольку serverless express не требует наличия более одной лямбда-функции для запуска всех ваших API-интерфейсов, это позволяет нам добиться более быстрого развертывания, потому что:
- У вас есть только один набор узловых модулей
- SAM требуется только для минимальной упаковки / архивации / большей части одной лямбда-функции
- SAM будет загружать только два артефакта (шаблон + код API) по сравнению с традиционным масштабом развертывания (`артефакт` x` Количество API`) + 1
Преимущество №4 стандартной версии зависимостей
Поскольку serverless express требует, чтобы у вас был только один набор узловых модулей для запуска и работы, вы можете быть уверены, что у вас есть стандартная и идентичная версия каждой библиотеки, которую вы используете в своей кодовой базе API.
Это приносит пользу вашей организации, гарантируя, что любая форма использования библиотеки внутри базы кода API стандартизирована и не возникает неожиданного поведения из разных версий фреймворков, которые часто находятся в типичных API на основе лямбда, где каждая конечная точка имеет свой собственный набор узловых модулей.
Преимущество № 5: будьте уверены, что разработчики не могут создавать API с отслеживанием состояния
aws-serverless-express отметили в своей документации Github, что его можно запускать только в режиме без сохранения состояния. Это хорошая новость для вас, как для архитектора, поскольку вам не нужно искать какие-либо средства защиты от масштабирования от разработчиков, которые любят хранить большие объекты в памяти сервера.
Обобщение преимуществ
- Ускоряет перенос существующих рабочих нагрузок API на бессерверные
- Это уменьшает количество SAM и Cloud Formation, которые вам нужно определить.
- Он предлагает более быстрое развертывание, поскольку у вас есть единый набор библиотек.
- Это позволяет вашей команде иметь стандартную версию зависимостей
- Вы можете быть уверены, что разработчики не собираются создавать API с отслеживанием состояния.
Недостаток №1. Глагол успокоения - горячая тема
Вы когда-нибудь извлекали массив объектов из API, к которому можно получить доступ с помощью команды POST HTTP? Звучит неловко? Черт возьми! Я хотел бы познакомить вас с наиболее частыми жалобами, которые вы собираетесь получить от сторон-потребителей (разработчиков Frontend).
Недостаток 2: дополнительные 372 КБ модулей узлов
Я только что загрузил самую последнюю версию aws-serverless-express через NPM, и на момент написания (август 2020 г.) она предлагает вам дополнительные 372 КБ зависимостей. Вы могли бы легко избежать этих дополнительных модулей, просто выбрав чистую архитектуру Lambda. Это цена компромисса маршрутизации из раздела преимуществ.
Недостаток №3: более низкая скорость обучения в чистом бессерверном стеке
Это довольно очевидно, так как вы не собираетесь сильно запачкаться с SAM или Cloud Formation. Вы с большей вероятностью прочитаете эту статью, потому что компания хочет, чтобы вы как можно скорее предоставили преобразованный экспресс-API.
Недостаток №4: у вас начнется ужасный холодок
aws-serverless-express вынуждает вас поглотить все конечные точки в одном пакете Lambda, что означает, что внутренним компонентам Lambda приходится извлекать весь исходный код для выполнения одного конкретного пути выполнения из исходного кода.
Загрузка кода для конкретной конечной точки - одно из замечательных преимуществ, которые предлагают вам бессерверные API-интерфейсы, которые вы потеряете при использовании внутренних маршрутизаторов внутри лямбда-функций.
Недостаток 5: повторное развертывание рабочего кода
Поскольку aws-serverless-express поощряет объединение нескольких конечных точек в один пакет Lambda, он также заставляет вас повторно развертывать всю кодовую базу, включая код, в котором не было изменений до выпуска.
Это не должно беспокоить, если вы не вносите каких-либо существенных изменений или каких-либо обновлений в свои зависимости. Обновления библиотек и зависимостей являются наиболее распространенным источником риска при обновлении API на основе NodeJS.
Недостаток № 6 Вынужденное обновление всего существующего кода вместе с библиотеками
Как упоминалось в предыдущем пункте, обновление ваших зависимостей слишком болезненно и дорого с точки зрения поиска во всех областях, представляющих интерес. Я хотел бы сравнить обновления зависимостей с попаданием под грузовик. Он просто заставляет вас провести тщательный поиск по всей кодовой базе API.
Вы можете просто смягчить это, используя инструменты анализа кода, такие как Quod AI. Этот потрясающий инструмент интеллектуального анализа кода на базе искусственного интеллекта настолько нелеп, что упрощает бессерверный поиск кода. Я очень рекомендую это проверить!
Недостаток №7: риск нарушения рабочего кодекса
Вы когда-нибудь регистрировали код, который использовался для работы, который внезапно начинал давать сбои без какого-либо взаимодействия с вашей стороны? После некоторого расследования вы поняли, что это ваш непослушный коллега сломал все это к черту? Звучит знакомо? Да, это часто случается, когда вы просите разработчиков вместе писать код даже без участия aws-serverless-express!
Недостаток №8: конфликты кода происходят все чаще
Исходя из той же причины, что и в предыдущем пункте, конфликты кода будут возникать чаще, когда разработчики вместе работают над одной базой кода. Разделение, которое предлагает чисто бессерверная среда, теряется при использовании этой структуры.
Обобщение недостатков
- Неудобное использование HTTP-глаголов - частый случай при использовании AWS serverless express.
- Вы получаете дополнительные 372 КБ узловых модулей + потребление памяти, связанное с загрузкой внутренних компонентов serverless-express.
- Ваши разработчики получат более медленное внедрение и скорость обучения по сравнению с использованием чистого стека Lambda.
- Вы вынуждены держать свои инстансы в тепле из-за холодного запуска
- Вы повторно развертываете рабочий код каждый раз, когда выпускаются обновления, что приводит к увеличению риска. Радиус взрыва также увеличивается при обновлении зависимостей 2-го уровня.
- Если вам нужна новая версия библиотеки, весь зависимый код внутри лямбда требует внимания и работы, связанной с обновлениями.
- Вы рискуете нарушить существующий код при внесении изменений, подобных тому, как поддерживались старые монолитные приложения.
- Наличие более одного разработчика, работающего над вашим проектом, повышает риск конфликтов кода при работе с этим фреймворком.
Означает ли это, что мы должны избегать использования экспресс-без сервера?
Недостатки, представленные в этой статье, значительно превосходят представленные преимущества (почти в два раза). Однако это не должно означать, что мы должны отказаться от использования aws-serverless-express!
Когда ваша команда проводит оценку фреймворка (да, пожалуйста или нет), имейте в виду, что оценка фреймворка на основе данных - ваш самый мощный инструмент!
Всегда предпочитайте полагаться на точные цифры, связанные с критическими факторами, которые обеспечивают стратегическую ценность для вашей организации (время выполнения, уверенность разработчиков, производительность приложений и т. Д.).
Я бы порекомендовал провести вашу собственную оценку веса и влияния каждого из перечисленных мною плюсов и минусов для ваших собственных сценариев использования.
Эта статья никоим образом не должна оказывать какое-либо предубеждение при принятии решения, поскольку каждое приложение имеет свой собственный интригующий набор требований, настроек и переменных.
Привет! Я пишу книгу о бессерверных!
Если вы нашли эту статью полезной, я пишу тонны примеров кода и статей на Github в свободное время и буду признателен за помощь сообщества в виде примеров кода Golang и Python.
Идеи, безусловно, приветствуются, и я хотел бы иметь в книге лист Excel, в котором перечислены его участники!
