Lambda - отличный набор для всех преимуществ, перечисленных на странице продукта AWS, а Serverless - очень полезный фреймворк для разработки функций Lambda. Однако локальная разработка бессерверных приложений - это настоящая боль, если то, что вы решаете, не совсем тривиально.

Когда все усложняется и ваши функции Lambda начинают интегрироваться с другими сервисами AWS, все действительно начинает ломаться. Есть несколько вещей, которые выглядят как серебряные пули, я поделюсь ими здесь и объясню, почему они не сработали для меня, а затем дам вам рабочий пример, который я сам изо всех сил пытался найти (поэтому я пишу это).

Локальный стек

Localstack - определенно самая крупная попытка найти здесь серебряную пулю. По сути, он эмулирует огромный кусок AWS локально, и вы подключаете к нему свои бессерверные функции. Почему я его не использовал:

  1. Биты работали, но если у вас есть какая-то полусложная настройка (например, регион за пределами us-east-1 или eu-west-1), она выйдет из строя. Загрузка всего шаблона облачной информации была катастрофой из-за разорванных связей между сервисами. Я дошел до редактирования кода локального стека, чтобы попытаться исправить проблему за проблемой, с которой я сталкивался, и сдался. Продукт был бы крутым, если бы не пытался сделать что-то настолько сверхсложное.
  2. Это также огромная утечка ресурсов на машине разработчика.
  3. По сути, вам не нужно эмулировать половину 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, дважды проверьте вы соблюдаете правила ».