AWS Lambda - создание бессерверного API с использованием .NET Core

Я не думаю, что твои варианты верны. Есть два варианта создания API с поддержкой Lambda:

1- Создайте лямбда-выражения и разверните их независимо в AWS в одном или нескольких проектах. Затем вручную создайте конечные точки шлюза API, которые указывают на одну или несколько лямбда-выражений.

2- Используйте бессерверный проект, чтобы объединить ваши лямбды в один проект. Определите свои конечные точки в этом проекте и попросите Cloudformation создать конечные точки API Gateway и подключить их к вашим лямбдам при развертывании.

Что касается плюсов и минусов,

Опция 1:

Плюсы: обладает гибкостью независимого развертывания лямбда-выражений, также вы можете настроить конечные точки шлюза API любым удобным для вас способом, без необходимости понимать синтаксис определения Cloudformation, который, по моему опыту, потребовал некоторого времени нарастания.

Минусы: Если у вас много лямбда-выражений, это становится кошмаром для менеджмента. Также ваше определение конечной точки отсутствует в исходном коде, и изменения в конфигурации конечной точки не будут отслеживаться.

Вариант 2:

Плюсы: Если вы разбираетесь в Cloudformation или хотите использовать конфигурацию по умолчанию, развернуть лямбда-выражение и подключить ее к конечной точке шлюза API очень просто. AWS создаст для вас конечную точку и создаст этапы разработки и производства, политики, роли IAM и т. д. Это развертывание Cloudformation непосредственно из Visual Studio приводит к тому, что все развертывание и все связанные объекты попадают в один и тот же «стек» в AWS Cloudformation. которые можно очень легко изменить, переназначить или удалить. Кроме того, ваша инфраструктура теперь представляет собой код, и изменения в нем можно проверить в вашем репозитории git.

Минусы: На мой взгляд, самый большой недостаток заключается в том, что стек не охватывает решение VS, а только проект, поэтому все ваши лямбда-выражения должны жить в одном проекте, что означает, что если у вас их много, они все закончатся. в одном монолитном бинарном лямбда-выражении. Сгенерированный большой двоичный файл проекта будет стоить вам времени выполнения памяти на AWS и проблем с эффективностью. Другой недостаток заключается в том, что если вы хотите иметь конкретный или нестандартный API-шлюз, вам необходимо понимать синтаксис Cloudformation, чтобы изменить файл serverless.template.

Заключение: Я предпочел разделить настоящее приложение на более мелкие части связанных лямбда-выражений на основе объекта API и поместить эти лямбда-выражения в несколько проектов бессерверных приложений. Например, у меня есть проект заказа, который содержит все лямбды, связанные с API заказа, и проект продукта, содержащий лямбды, связанные с API продукта и т. д. Оба они будут жить в одном решении и будут развертываться отдельно. В настоящее время я работаю над тем, чтобы развернуть все решение сразу.