Lambda - отличный набор для всех преимуществ, перечисленных на странице продукта AWS, а Serverless - очень полезный фреймворк для разработки функций Lambda. Однако локальная разработка бессерверных приложений - это настоящая боль, если то, что вы решаете, не совсем тривиально.
Когда все усложняется и ваши функции Lambda начинают интегрироваться с другими сервисами AWS, все действительно начинает ломаться. Есть несколько вещей, которые выглядят как серебряные пули, я поделюсь ими здесь и объясню, почему они не сработали для меня, а затем дам вам рабочий пример, который я сам изо всех сил пытался найти (поэтому я пишу это).
Локальный стек
Localstack - определенно самая крупная попытка найти здесь серебряную пулю. По сути, он эмулирует огромный кусок AWS локально, и вы подключаете к нему свои бессерверные функции. Почему я его не использовал:
- Биты работали, но если у вас есть какая-то полусложная настройка (например, регион за пределами us-east-1 или eu-west-1), она выйдет из строя. Загрузка всего шаблона облачной информации была катастрофой из-за разорванных связей между сервисами. Я дошел до редактирования кода локального стека, чтобы попытаться исправить проблему за проблемой, с которой я сталкивался, и сдался. Продукт был бы крутым, если бы не пытался сделать что-то настолько сверхсложное.
- Это также огромная утечка ресурсов на машине разработчика.
- По сути, вам не нужно эмулировать половину AWS для тестирования вашего кода.
Бессерверный автономный режим
Бессерверный автономный режим довольно прост. Это должно позволить вам запускать ваши функции локально и вызывать их по мере необходимости. На мой взгляд, это потребовало наличия конечных точек HTTP для ваших лямбда-функций, все наши лямбда-функции управлялись либо событиями SQS, либо Cron. Мы также создаем экземпляры наших тем SNS в нашем коде, поэтому он будет постоянно пытаться создавать темы SNS, а AWS выдает ошибки.
Я также пробовал использовать serverless-offline-sqs, но не смог заставить его управлять событиями в наших функциях Lamdba.
Я потратил много времени на настройку среды разработки и понял, что это в корне неправильный подход. Мне нужно было начать писать правильные модульные тесты и использовать имитацию для эмуляции инфраструктуры (я имею в виду, что в идеале они должны быть должным образом изолированы, а инфраструктура / функции будут полностью игнорировать друг друга, но это на другой день).
Пример
Допустим, мы разрабатываем приложение, в котором используются:
- Лямбда
- MongoDB
- SQS
- SNS
Ваша лямбда-функция подключается к вашей MongoDB, выполняет определенные действия и периодически отправляет уведомления SNS / сообщения SQS другим службам.
Лямбда
Что касается самого выполняемого кода, я собирался использовать шутку, чтобы начать писать тесты. Jest хорошо работает и прекрасно интегрируется в бессерверную версию.
MongoDB
Чтобы подражать MongoDB, я собираюсь использовать версию MongoDB в памяти, которая хорошо сочетается с нашими моделями Mongoose.
SQS / SNS
Для любой инфраструктуры Amazon мы будем использовать aws-sdk-mock. Это отличная оболочка для sinon для имитации инфраструктуры AWS, которая, как вы увидите позже, очень полезна для модульных тестов.
Связывая все вместе
Итак, во-первых, давайте установим наши зависимости.
npm install aws-sdk-mock mongodb-memory-server sinon jest --save-dev
Давайте также создадим папку tests, в которой будет храниться весь этот тестовый код.
mkdir tests
Настройка MongoDB
Теперь, чтобы наш код мог интегрироваться с нашим сервером Mongo-DB в памяти, нам нужно будет добавить несколько функций установки / удаления и среду Mongo. Клонируем это репо и ставим:
setup.js
teardown.js
mongo-environment.js
в вашу новую тестовую папку.
В корневой каталог добавьте jest.config.js
с этим содержимым.
module.exports = { globalSetup: './tests/setup.js', globalTeardown: './tests/teardown.js', testEnvironment: './tests/mongo-environment.js', roots: ['./tests/'], };
Этого должно быть достаточно для запуска и запуска MongoDB. Теперь о наших реальных сценариях тестирования.
Настройка наших тестов
Теперь, наконец, вы можете связать все это вместе с помощью этого фрагмента:
Добавьте шутку в свой package.json
"scripts":{ "test": "jest" },
И запустить с npm test
.
Следует отметить один важный момент: для aws-mock-sdk требуется очень специфический способ создания экземпляров ресурсов AWS (в рамках функциональных тестов), поэтому, если вы видите какие-либо ошибки в регионах aws, дважды проверьте вы соблюдаете правила ».