Aws-lambda-dotnet: Amazon.Lambda.AspNetCoreServer com Application Load Balancer

Eu estava apenas dando uma olhada na nova integração do ALB. A solicitação JSON que é enviada para a função do Lambda é diferente do API Gateway. Não deve ser muito difícil detectar no APIGatewayProxyFunction o formato JSON e fazer uma lógica de análise diferente com base na fonte.

Isso seria bom. Provavelmente usaríamos o ALB como nosso método preferido de integração, pois já fazemos uso pesado do ALB.

No momento, estamos usando APIGatewayProxyFunction, mas o API Gateway permite apenas 30 segundos para concluir a transação. Um ELB seria uma boa solução para nossos dados maiores que precisam de processamento. (Até o limite das funções lambda 15min)

Seria incrível se pudéssemos usar o LambdaEntryPoint : Amazon.Lambda.AspNetCoreServer.APIGatewayProxyFunction e não se importar se é APIGateway ou um ELB.

Eu tenho trabalhado no suporte ALB no ramo alb-support . O próximo passo nesse ramo é trabalhar em Amazon.Lambda.AspNetCoreServer

Nossa isso foi rápido! =) Obrigado!
Mal posso esperar!

Isso é ótimo, obrigado. Ansioso para usar isso para nosso aplicativo da web dotnet core. Obrigado!

Concordo, mal posso esperar por esse recurso!

Atualização de status Eu empurrei o branch alb-support-aspnetcore que contém as atualizações para Amazon.Lambda.AspNetCoreServer .

As mudanças acabaram desencadeando uma refatoração maior do que eu havia saltado. Definitivamente, quando escrevi originalmente essa biblioteca, eu não tinha previsto que haveria vários front-ends HTTP para funções do Lambda.

Se alguém estiver disposto a clonar o repositório e tentar enquanto eu termino a validação, seria ótimo. Você deve apenas clonar o repositório, entrar em Amazon.Lambda.ApplicationLoadBalancerEvents e Amazon.Lambda.AspNetCoreServer e fazer um dotnet pack . Em seguida, adicione o pacote NuGet criado a um feed local.

Para a maioria dos aplicativos, a única alteração que você deve fazer em LambdaEntryPoint ou o que você nomeou é alterar a classe base de APIGatewayProxyFunction para ApplicationLoadBalancerFunction .

O engraçado é que eu re-implantei para um nome LAMBDA usando master e consegui usar o ELB com LambdaEntryPoint : Amazon.Lambda.AspNetCoreServer.APIGatewayProxyFunction antes de sua ramificação e tudo funcionou. (Só precisa definir as regras no ELB Trigger para usar o caminho "api/*")

(De alguma forma, configurar um gatilho ELB na nova função lambda funciona no portão sem suas ramificações, talvez porque os cabeçalhos/respostas sejam quase os mesmos.)

Se eu tiver tempo, vou testar seu branch ainda hoje.

Há uma boa quantidade de semelhança entre o API Gateway e o evento ALB, o que pode permitir que você tenha sorte. Se você habilitasse cabeçalhos de vários valores ou tivesse dados binários do corpo da solicitação, isso falharia.

Ramo parece bom.

Isso parece ótimo! Estou ansioso para ver como essa funcionalidade funciona em ação. Temos algum ETA estimado sobre quando isso pode ser mesclado e empacotado?

Realmente ansioso para ver isso no pacote oficial.
Eu acho que esta é a melhor oferta serverless que você tem. Nós migraríamos a maioria de nossas APIs e até mesmo sites para isso se não fossem as duas principais desvantagens; API Gateway e os atrasos de inicialização a frio (lambda). Isso corrige um deles, e as verificações de integridade do ALB devem ajudar a manter os lambdas vivos :-)

@normj , apenas curioso se há algum ETA sobre quando podemos esperar que isso esteja disponível no Nuget?

Estou esperando ansiosamente que esse recurso seja incluído no Nuget também.

Eu testei isso no meu aplicativo já existente e parece funcionar sem problemas.

A versão 3.0.0 do Amazon.Lambda.AspNetCoreServer foi lançada hoje com suporte ALB. Confira a postagem do blog para mais informações. https://aws.amazon.com/blogs/developer/updates-for-serverless-asp-net-core/

@normj Ótimo post e excelente trabalho! Obrigado por tudo o que você faz para integrar o .NET ao ecossistema da AWS.

@ryanpagel Seja bem vindo 😄

Fechando conforme o recurso é lançado.