Я не думаю, что ваши варианты верны.Существует два варианта построения API с поддержкой Lambda:
1 - Сборка лямбд и их независимое развертывание на AWS в одном или нескольких проектах.Затем вручную создайте конечные точки шлюза API, которые указывают на одну или несколько лямбд.
2 - Используйте проект без сервера, чтобы объединить лямбды в одном проекте.Определите свои конечные точки в этом проекте, и Cloudformation создаст конечные точки шлюза API и подключит их к своим лямбдам при развертывании.
Что касается плюсов и минусов,
Опция1:
Плюсы: обладает возможностью гибкого развертывания лямбда-выражений независимо друг от друга, также вы можете настраивать конечные точки шлюза API так, как вам нужно, без необходимости понимать синтаксис определения Cloudformation, которыйВ моем опыте потребовалось некоторое время.
Минусы: Если у вас много лямбд, это станет кошмаром для менеджмента.Также ваше определение конечной точки отсутствует в исходном коде, и изменения в конфигурации конечной точки не будут отслеживаться.
Опция 2:
Плюсы: Если вы выясните Cloudformation или хотите использовать конфигурацию по умолчанию, развернуть лямбду и подключить ее к конечной точке шлюза API очень просто.AWS создаст для вас конечную точку и создаст этапы разработки и разработки, политики, роли IAM и т. Д. В результате развертывания Cloudformation непосредственно из Visual Studio все развертывание и все связанные объекты попадают в один и тот же «стек» в AWS Cloudformation.которые можно легко изменить, изменить или удалить.Кроме того, ваша инфраструктура теперь является кодом, и его изменения можно проверить в вашем git-репо.
Минусы: Самым большим минусом, на мой взгляд, является тот факт, что стек не охватывает VS Solutionа скорее просто проект, поэтому все ваши лямбды должны жить в одном и том же проекте, а это значит, что если у вас их много, все они окажутся в одном монолитном двоичном коде лямбдыСгенерированный большой двоичный файл проекта будет стоить вам времени работы с памятью в AWS и проблем с эффективностью.Другой недостаток заключается в том, что если вы хотите иметь определенный или не совсем обычный API-шлюз, вам нужно понять синтаксис Cloudformation, чтобы изменить файл serverless.template.
Вывод: Мое предпочтительное решение состояло в том, чтобы разделить мое настоящее приложение на более мелкие порции связанных лямбд на основе объекта API и поместить эти лямбды в несколько проектов приложений без сервера.Например, у меня есть проект заказа, который содержит все лямбды, связанные с API заказа, и проект продукта, который содержит лямбды, связанные с API продукта и т. Д. Оба они будут работать в одном решении и будут развернуты отдельно.В настоящее время я работаю над способом развертывания всего решения за один раз.