(Изменить: как отмечалось в комментариях, словоблудие AWS, которое я вызвал в 2018 году, было удалено. Тем не менее, мои мысли относительно прокси-сервера Lambda и настраиваемой интеграции все еще сохраняются.)

Похоже, AWS рекомендует выбирать Интеграция Lambda Proxy для разработки нового API.

Примечание

Пользовательская интеграция Lambda, ранее известная как интеграция Lambda, является устаревшей технологией. Мы рекомендуем вам использовать интеграцию Lambda-прокси для любого нового API. Дополнительные сведения см. В разделе Создание API шлюза API с интеграцией прокси-сервера Lambda.

Я понимаю, что намного быстрее (в краткосрочной перспективе) развернуть конечную точку API и интеграцию лямбда с использованием интеграции прокси, а не пользовательской интеграции, но я удивлен, что это рекомендация для всех API / Дальнейшая разработка Lambda:

• Я представил API-шлюз как ответственный за обработку деталей HTTP. Использование прокси-интеграции заставляет (по крайней мере, часть) эту ответственность выполнять лямбда-функцию. (т.е. зная, как интерпретировать заголовки HTTP, параметры запроса, коды состояния и т. д.)
• Поступая таким образом, я чувствую, что это запутывает ответственность поддерживающей лямбда-функции - теперь Lambda необходимо как обрабатывать любую бизнес-логику, для выполнения которой она вызывается, так и обрабатывать интерпретацию входящих значений HTTP и принимать решения. на значениях исходящего ответа HTTP.
• Конечно, вы могли бы реализовать дополнительный уровень функции Lambda, чтобы абстрагироваться от деталей HTTP, но разве это не то, что должен делать шлюз API?
• Это снижает возможность повторного использования любой заданной лямбда-функции в контексте другого, чем обслуживание HTTP-запросов, если только клиенты, отличные от HTTP, не форматируют запрос, как если бы это был HTTP-запрос.

Нет прокси.

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

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

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

Мы также начали с Proxy, так как было очень быстро запустить и запустить множество функций. Вскоре нас осенило, что мы создали довольно тесную связь с тем, как прокси заставляет нас читать ввод и писать вывод, и что наша функция не должна знать об этом и должна иметь более понятные и простые интерфейсы. А затем мы хотели начать оркестровку некоторых из этих функций с помощью AWS Step Функции, и именно тогда мы поняли, что создали функции, которые действительно работают только с интеграцией прокси. Не с пошаговыми функциями, и их, конечно, нелегко перенести.

Больше нет прокси.

Из-за шаблона body mapping - лучше прокси.

Мне не нравится шаблон отображения тела, потому что в экспортированном Swagger он экранирован, например:

        uri: "arn:aws:apigateway:us-east-1:dynamodb:action/UpdateItem"
        responses:
          default:
            statusCode: "200"
        requestTemplates:
          application/json: "{\n    \"TableName\": \"happy-marketer\",\n    \"Key\"\
            : {\n        \"pk\": {\n            \"S\": \"project\"\n        },\n \
            \       \"sk\": {\n            \"S\": \"$context.authorizer.claims.email\
            \ $util.urlDecode($input.params('name'))\"\n        }\n    },\n    \"\
            UpdateExpression\": \"SET projectStatus = :c\",\n    \"ExpressionAttributeValues\"\
            : {\n        \":c\": {\n            \"S\": \"Completed\"\n\n        }\n\
            \    }\n}"
        passthroughBehavior: "never"
        httpMethod: "POST"
        type: "aws"
  /projects/{name}/status/restore:
    options:
      consumes:
      - "application/json"
      produces:
      - "application/json"
      parameters:
      - name: "name"
        in: "path"

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

{
  "email": "$context.authorizer.claims.email",
  "nameOld": "$util.urlDecode($input.params('name'))",

  #if ($input.path('$.nameNew') != "")
  "nameNew": "$util.urlDecode($input.path('$.nameNew'))",
  #end

  #if ($input.path('$.ownerNew') != "")
  "ownerNew": "$input.path('$.ownerNew')",
  #end
  
  #if ($input.path('$.shared') != "")
  "shared": $input.json('$.shared')
  #end
  
  #if ($input.path('$.StartDate') != "")
  , "startDate": "$input.path('$.StartDate')"
  #end
  
  #if ($input.path('$.DueDate') != "")
  , "dueDate": "$input.path('$.DueDate')"
  #end
}

Ошибка - неправильно , перед startDate. В моем бэкэнд-коде Go таких ошибок нет. Я не хочу писать тесты для Apache Velocity.

Кроме того, возможно, интеграция прокси выполняется быстрее - из-за отсутствия промежуточной службы.

Я лично выбрал бы интеграцию с прокси из лучших практик. Вот почему:

• VTL - это еще одна вещь, которую вам нужно усвоить, если вы не используете интеграцию прокси. Кроме того, как вы проверяете свою логику VTL? Я бы сказал, что эта логика скорее бизнес, чем нет. Кроме того, по моему опыту, отладка VTL ужасна.
• Интеграция с прокси позволяет вам развивать свой api, не нарушая потребителей. Вы можете вносить радикальные архитектурные изменения в свой код, и вам никогда не придется повторно развертывать шлюз API.
• Наличие логики сопоставления HTTP-ответов в коде делает его легко тестируемым. Кроме того, вы можете легко отделить логику сопоставления HTTP-ответов от бизнес-логики ваших конечных точек.