Lambda Integration против Lambda Proxy: за и против

Как вы относитесь к плюсам и минусам использования интеграции Lambda с функцией прокси и без нее в AWS API Gateway (а точнее, при использовании безсерверной системы)? Вот что я думаю до сих пор:

Интеграция лямбда с прокси

Pro. Можно быстро прототипировать и кодировать, не беспокоясь о всех необходимых конфигурационных деталях (и повторно изобретая несколько колес, например, общие шаблонные сопоставления и т.д.).
Pro: действительно легко вернуть любой код состояния и настраиваемые заголовки, в то же время есть общий способ чтения тела, заголовков, параметров запроса.
Con: все сделано в коде, поэтому автогенерирующая документация немного сложнее. Зависимости (заголовки, модели, возвращенные коды состояния) "скрыты" в коде.

Интеграция лямбда без прокси

Con: включает в себя гораздо больше работы по настройке, и эта конфигурация может дублироваться в разных ресурсах.
Pro: он позволяет отделить то, что получает и возвращает лямбда, и как он сопоставляется с разными кодами, заголовками и полезными нагрузками HTTP-кода.
Pro: очень полезно, потому что он предопределяет то, что он возвращает, и что он требует в терминах заголовков и полезных нагрузок.
Pro: тяжелая работа при настройке всего полезна в конечном счете, потому что можно экспортировать все в Swagger, чтобы другие могли использовать это для генерации для него различных SDK.

Каковы ваши мысли? Обычно ли вы используете Lambda Proxy или простые интеграторы лямбда? Что вы предпочитаете и почему?

EDIT. До сих пор я склонен всегда не использовать функции прокси-сервера из-за упомянутых причин (развязка и определение зависимостей - заголовки, коды состояния и т.д.).

Ответ 1

Нет прокси.

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

Что касается плюсов прокси-сервера, я бы назвал их минусами, так как он чувствует, что у вас тоже есть и как профессионал. Я видел все это до того, как "давайте двигаться очень быстро". Да, мы должны быть гибкими и двигаться быстро, но не ценой мышления. Я получаю это со своими инженерами все время, одна вещь, чтобы быть низкими на документацию/дизайн еще один, чтобы сказать "орехи для планирования позволяет просто код". Thats, как вы углу себя, независимо от того, как быстро вы выходите на рынок. Без прокси (и некоторое раннее планирование вашей структуры проекта и, возможно, некоторое хорошее мышление DDD) довольно легко мигрировать от AWS, если мир будет гореть.

В дополнение к этому, мне очень сложно получить новые боты до скорости с использованием AWS. Как только вы это знаете, все его соус, но разработчики - это разработчики, а не инженеры инфраструктуры (те из нас, кто делают оба, на удивление редки). Отсев помогает людям быть продуктивными, когда они начинают свое устрашающее путешествие вниз по рабитолу. Id скорее мой код кода, чем нужно беспокоить меня о CFN каждые 20 минут.