Как передать параметры на сервер без сервера

Я работаю над безсервисным проектом aws и должен проверять функции лямбда локально.
Я использую serverless invoke local -f {function_name} для проверки вызовов API, которые не запрашивают никаких параметров пути или запроса.
Мой вопрос в том, как я могу использовать эту команду для передачи любого параметра пути или запроса функции?

Пример безсерверного описания

getFoodDetails:
    handler: handler.getFoodDetails
    events:
      - http:
          method: get
          path: /foods/{food_id}
          cors: true
          request:
            parameters:
              paths:
                food_id: true

ОТВЕТЫ

Ответ 1

Строка данных

Как уже говорилось, вы можете использовать --data для передачи строковых данных как события в вашу функцию.

serverless invoke local -f {function_name} --data '{ "queryStringParameters": {"id":"P50WXIl6PUlonrSH"}}'

Файл данных

Вы также можете передать --path в файл json с данными в качестве event и в "файле события" определить --path данные.

serverless invoke --function {function_name} --path event_mock.json

Вы можете как-то вернуть событие из звонка и сохранить его в файле JSON или получить его из Amazon. Они предоставляют некоторые примеры: https://docs.aws.amazon.com/lambda/latest/dg/eventsources.html

Помните, что если вы передадите и --path и --data, данные, включенные в файл --path, перезапишут данные, которые вы передали с флагом --data.

Документация: https://serverless.com/framework/docs/providers/aws/cli-reference/invoke#invoke-local

Ответ 2

Используйте --data и передайте любой формат данных, который вы хотите отправить в локальную лямбду.

Пример строковых данных:

serverless invoke --function functionName --stage dev --region us-east-1 --data "hello world"

Пример данных JSON:

serverless invoke --function functionName --stage dev --region us-east-1 --data '{ "property1": "value"}'

Данные JSON из файла:

serverless invoke --function functionName --stage dev --region us-east-1 --path lib/data.json

Полная документация доступна здесь здесь

Надеюсь, это поможет.

Ответ 3

Я пробовал ответы с атрибутом --data но ни один не работает.
На самом деле проблема в том, что --data будет передавать строковое значение в платформу. Так что если вы пишете в своем файле JavaScript: console.log(typeof(event)); , вы получите String вместо Object. Это означает, что безсерверный фреймворк не преобразует входные данные в объект JSON правильно. Вот почему вы получили хх неопределенной ошибки.

Мое решение - использовать -p (или --path). В вашем примере выполните следующие действия:

  1. создайте файл .json в текущем месте вашей консоли. Например: test.json
  2. в файле json напишите: {"pathParameters":{"food_id":"100"}}
  3. в файле js, чтобы получить food_id, используйте event.pathParameters.food_id
  4. команда запуска: sls invoke local -f yourFunction -p test.json

Ответ 4

Для дальнейшего использования. Ваш случай был бы разрешен так. Просто вычислил это благодаря примеру Kannaiyans JSON.

sls invoke local -f getFoodDetails --data '{ "queryStringParameters": {"food_id":"123"}}'

Ответ 5

Можно ли передавать файл CSV или XML в лямбда-функцию через директиву --path или это всегда должен быть JSON?

Ответ 6

Одна из проблем с локальным вызовом, с которой вы, похоже, столкнулись, - это отладка времени выполнения лямбды против ресурса динамодаба. В идеале вы хотите вызывать как лямбда-динамику, так и живую таблицу динамодб. Сегодня локальный локальный вызов без сервера и интерфейс командной строки AWS SAM вызывают лямбда-среду выполнения, но не облачный стэк.

Пока у вас есть Lambda ARN, вы можете вызывать как лямбда-среду выполнения, так и облачный стек с помощью Stackery CLI. (это бесплатно) Вот пример отладки лямбда-сервера без фреймворка.

Ответ 7

Здесь также есть альтернатива всем остальным вариантам. Я написал статью об этом в блоге и сошлюсь на нее после прохождения некоторых деталей.

Есть два основных аспекта, с которыми вам нужно разобраться:

  1. Выполните код в вашем обработчике и бизнес-логике, передав объекты событий в ваш обработчик
  2. Обработка запросов к сервисам AWS таким образом, чтобы упростить тестирование

Для первого я просто добавил Mocha в проект и использовал среду модульного тестирования, чтобы иметь возможность нажать кнопку в моей IDE и выполнить мой код с тестовыми данными. Я также могу выполнять локальную отладку, пошаговое выполнение кода и т.д. Без проблем. Дополнительным преимуществом является то, что если вы просто настроите это, как и я, просто для выполнения своего кода, у вас все еще есть начало набора модульных тестов, которые вы можете узнать позже, если хотите

Во-вторых, это еще проще. Существует модуль npm под названием aws-sdk-mock, который позволяет зарегистрировать прослушиватель для конкретной службы и метода AWS (например, DynamoDB.query или S3.putItem) и отвечать на этот запрос с любым желанием, даже если возникают ошибки Вы хотите проверить, как ваш код обрабатывает немыслимое; сервис AWS не работает.

С настройкой этих двух элементов я могу локально протестировать любой обработчик, который я разработал. В конечном итоге вам всегда нужно будет проводить некоторые интеграционные тесты в облаке, поскольку нет никакой локальной замены, какой бы сложной или удивительной она ни была, для реальных облачных сервисов, которые вы будете использовать, но это может сделать вас довольно далеко.

https://serverless.com/blog/serverless-local-development