serverless next.js
v3.7.0
Uma configuração zero a seguir.
Revise os recursos para obter uma lista dos recursos atualmente suportados.
️ Este ReadMe reflete as últimas alterações no ramomaster. Pode ou ainda não ser publicado na versãolatest(estável) oualphano NPM. Por favor, vá para lançamentos, encontre a versão correta@sls-next/serverless-componentvocê está usando e abra o ReadMe para obter informações para obter informações mais precisas. Se um recurso estiver listado neste Readme, mas não está funcionando, tente primeiro atualizar para o lançamentoalphamais recente no NPM.
Atualmente, isso está usando os componentes sem servidores beta (não a versão GA), pois o projeto foi iniciado antes do GA. Atualmente, estamos reformulando como as implantações funcionarão no futuro e explorando melhores soluções IAC, como CDK, CDK para Terraform, etc., e faremos um anúncio antes do final do ano em quaisquer atualizações.
Desde o próximo.js 8.0, foi introduzido o modo sem servidor, que fornece uma nova API de baixo nível, que projetos como esse podem usar para implantar em diferentes fornecedores de nuvem. No entanto, o Next.js não fornece a lógica de roteamento sem servidor completa, portanto, por que esse projeto é necessário para preencher a lacuna. A visão de longo prazo é permitir que você se sinta com várias nuvens, começando pela AWS.
Este projeto é uma versão melhor do plug -in sem servidor, que se concentra em abordar questões principais, como o próximo suporte 9, melhor experiência de desenvolvimento, o limite e o desempenho do Recurso de 200formamento em CloudFormation.
Há pouca ou nenhuma configuração necessária. Você pode estender os padrões com base nas necessidades de seu aplicativo.
Os usuários deste componente devem poder usar o Next.js Development Tooling, também conhecido como next dev . O trabalho do componente é implantar seu aplicativo, garantindo a paridade com todos os recursos do próximo que conhecemos e amamos. Tentamos imitar toda ou a maioria da lógica de roteamento e servidor do Next.js e otimizá-la para um ambiente sem servidor. Abaixo, você pode encontrar uma lista dos recursos atualmente suportados.
Com uma arquitetura simplificada e sem uso da CloudFormation, não há limites para quantas páginas você pode ter em seu aplicativo, além de que os tempos de implantação sejam muito rápidos! Com exceção dos tempos de propagação do CloudFront, é claro.
Como imitamos a lógica de roteamento do Next.js, infelizmente nem sempre nem sempre estamos em plena paridade. A seguir, todos os recursos suportados ou recursos planejados. Se a caixa de seleção estiver marcada, isso significa que o recurso será suportado. Caso contrário, provavelmente ainda não é suportado ou atualmente em estágio de planejamento ou implementação. Consulte a descrição de um item para obter detalhes específicos.
Observe que alguns recursos podem estar apenas na versão alfa mais recente. Se um recurso for listado como suportado, mas não está trabalhando na tag latest , provavelmente está na tag alpha . Se puder, ajude -nos a testar as alterações alfa mais recentes e enviar um relatório de bug se encontrar algum problema. Obrigado!
Existe um recurso que você deseja, mas ainda não é suportado? Por favor, abra um novo problema para nos informar!
/_next/* servido no CloudFront. getStaticProps . getServerSideProps . getStaticPaths . _next/static/* e static/* , pois esses comportamentos de cache não têm manipuladores de lambda anexados a eles. Observe que o novo has formato correspondente (https://nextjs.org/docs/api-reference/next.config.js/redirects#header-cookie-and-query-matching) ainda não está suportado. _next/static/* e static/* , pois esses comportamentos de cache não têm manipuladores de lambda anexados a eles. Observe que o novo has formato correspondente (https://nextjs.org/docs/api-reference/next.config.js/redirects#header-cookie-and-query-matching) ainda não está suportado. _next/static/* e static/* , pois esses comportamentos de cache não têm manipuladores de lambda anexados a eles. Observe que o novo has formato correspondente (https://nextjs.org/docs/api-reference/next.config.js/redirects#header-cookie-and-query-matching) ainda não está suportado. next-i18next . Primeiro, verifique se você possui o Node.js 12+ instalado na máquina de implantação, pois todo o código agora está transpilado para o ES2019. Adicione seu próximo aplicativo ao serverless.yml:
# serverless.yml
myNextApplication :
component : " @sls-next/serverless-component@{version_here} " # it is recommended you pin the latest stable version of serverless-next.js Se você especificar @sls-next/serverless-component no seu arquivo serverless.yml , não adicione @sls-next/serverless-component ao seu arquivo package.json, ele não é usado e apenas a versão no arquivo serverless.yml é usada, quais puxões sem servidor do NPM por si só. Se você não especificar a versão, ela usará a tag latest , que se refere à versão estável mais recente aqui (ou seja, versões alfa).
Você também pode apontá -lo para uma instalação local, por exemplo, se você deseja ver versão usando package.json .
Nesse caso, configure o seguinte:
# serverless.yml
myNextApplication :
component : " ./node_modules/@sls-next/serverless-component "Em seguida, defina suas credenciais da AWS como variáveis de ambiente:
AWS_ACCESS_KEY_ID=accesskey
AWS_SECRET_ACCESS_KEY=sshhhE simplesmente implantar:
$ serverlessSe você tiver problemas de implantação devido à nova versão sem servidor, tente fixar na versão específica, por exemplo, 2.72.2. Veja #2320 (comentário)
[ALPHA - may be buggy] You may also deploy using npx @sls-next/serverless-patched (or serverless-patched if you installed it locally), which is a patched version of serverless that fixes a couple of issues by patching the underlying @serverless/cli : (1) Continuous "Deploying" messages being printed in non-interactive terminals (eg CI output) that make it hard to debug, and (2) Handles Silent Next.js construa falhas.
Também é recomendável adicionar -bandeira --debug para obter logs mais úteis do que está acontecendo nos bastidores.
Não tente implantar executando serverless deploy , use apenas serverless
Na maioria dos casos, você não gostaria de usar o domínio de distribuição da CloudFront para acessar seu aplicativo. Em vez disso, você pode especificar um nome de domínio personalizado.
Você pode usar qualquer nome de domínio, mas deve estar usando a AWS Route53 para sua hospedagem DNS. Para migrar os registros do DNS de um domínio existente, siga as instruções aqui. Os requisitos para usar um nome de domínio personalizado:
mydomain.com ) com um conjunto de servidores de nomes.O componente Next.js sem servidor gerará automaticamente um certificado SSL e criará um novo registro para apontar para a sua distribuição CloudFront.
# serverless.yml
myNextApplication :
component : " @sls-next/serverless-component@{version_here} "
inputs :
domain : " example.com " # sub-domain defaults to www
domainMinimumProtocolVersion : " TLSv1.2_2018 " # can be omitted, defaults to "TLSv1.2_2018" Você também pode configurar um subdomain :
# serverless.yml
myNextApplication :
component : " @sls-next/serverless-component@{version_here} "
inputs :
domain : ["sub", "example.com"] # [ sub-domain, domain ] Para especificar suas próprias entradas CloudFront, basta adicionar quaisquer entradas AWS-cloudfront no cloudfront :
# serverless.yml
myNextApplication :
component : " @sls-next/serverless-component@{version_here} "
inputs :
cloudfront :
# if you want to use an existing cloudfront distribution, provide it here
distributionId : XYZEXAMPLE # optional
# this is the default cache behaviour of the cloudfront distribution
# the origin-request edge lambda associated to this cache behaviour does the pages server side rendering
defaults :
forward :
headers :
[
CloudFront-Is-Desktop-Viewer,
CloudFront-Is-Mobile-Viewer,
CloudFront-Is-Tablet-Viewer
]
# this is the cache behaviour for next.js api pages
api :
minTTL : 10
maxTTL : 10
defaultTTL : 10
# you can set other cache behaviours like "defaults" above that can handle server side rendering
# but more specific for a subset of your next.js pages
/blog/* :
minTTL : 1000
maxTTL : 1000
defaultTTL : 1000
forward :
cookies : " all "
queryString : false
/about :
minTTL : 3000
maxTTL : 3000
defaultTTL : 3000
# you can add custom origins to the cloudfront distribution
origins :
- url : /static
pathPatterns :
/wp-content/* :
minTTL : 10
maxTTL : 10
defaultTTL : 10
- url : https://old-static.com
pathPatterns :
/old-static/* :
minTTL : 10
maxTTL : 10
defaultTTL : 10
- url : http://old-api.com
protocolPolicy : http-only
pathPatterns :
/old-api/* :
minTTL : 10
maxTTL : 10
defaultTTL : 10
aliases : ["foo.example.com", "bar.example.com"]
priceClass : " PriceClass_100 "
# You can add custom error responses
errorPages :
- code : 503
path : " /503.html "
minTTL : 5 # optional, minimum ttl the error is cached (default 10)
responseCode : 500 # optional, alters the response code
comment : " a comment " # optional, describes your distribution
webACLId : " arn:aws:wafv2:us-east-1:123456789012:global/webacl/ExampleWebACL/473e64fd-f30b-4765-81a0-62ad96dd167a " # ARN of WAF
restrictions :
geoRestriction :
restrictionType : " blacklist " # valid values are whitelist/blacklist/none. Set to "none" and omit items to disable restrictions
items : ["AA"] # ISO 3166 alpha-2 country codes
certificate :
cloudFrontDefaultCertificate : false # specify false and one of IAM/ACM certificates, or specify true and omit IAM/ACM inputs for default certificate
acmCertificateArn : " arn:aws:acm:us-east-1:123456789012:certificate/12345678-1234-1234-1234-123456789012 "
iamCertificateId : " iam-certificate-id " # specify either ACM or IAM certificate, not both
sslSupportMethod : " sni-only " # can be omitted, defaults to "sni-only"
minimumProtocolVersion : " TLSv1.2_2019 " # can be omitted, defaults to "TLSv1.2_2019"
originAccessIdentityId : XYZEXAMPLE # optional
paths : ["/*"] # which paths should be invalidated on deploy, default matches everything, empty array skips invalidation completely
waitBeforeInvalidate : true # by default true, it waits for the CloudFront distribution to have completed before invalidating, to avoid possibly caching old page
tags : # Add any tags you want
tag1 : val1
tag2 : val2Isso é particularmente útil para armazenar em cache em qualquer uma das suas próximas páginas. Veja isso para um exemplo de aplicativo com configuração de cache personalizada. Você também pode atualizar uma distribuição CloudFront existente usando as entradas CloudFront personalizadas.
Páginas renderizadas estaticamente (por exemplo, páginas HTML que são carregadas para S3) têm o seguinte conjunto de controle de cache:
cache-control: public, max-age=0, s-maxage=2678400, must-revalidate
s-maxage permite que o CloudFront cache as páginas nos locais da borda por 31 dias. max-age=0 em combinação com must-revalidate Certifique-se de que os navegadores nunca cache as páginas estáticas. Isso permite que o CloudFront esteja no controle total dos TTLs de cache. Em cada implantação, uma invalidação /* é criada para garantir que os usuários obtenham novo conteúdo.
Por padrão, formatos de imagem comuns ( gif|jpe?g|jp2|tiff|png|webp|bmp|svg|ico ) sob /public ou /static têm uma política Cache-Control de um ano aplicada ( public, max-age=31536000, must-revalidate ). Você pode personalizar o value do cabeçalho Cache-Control e o regex de quais arquivos test , com publicDirectoryCache :
myNextApplication :
component : " @sls-next/serverless-component@{version_here} "
inputs :
publicDirectoryCache :
value : public, max-age=604800
test : /.(gif|jpe?g|png|txt|xml)$/i value deve ser uma política Cache-Control válida e test deve ser um regex válido dos tipos de arquivos que você deseja testar. Se você não deseja que os navegadores contem ativos do diretório público, você pode desativar isso:
myNextApplication :
component : " @sls-next/serverless-component@{version_here} "
inputs :
publicDirectoryCache : falsePor padrão, as funções Lambda@Edge são executadas usando awslambdabasicexecutionRole, que apenas permite o upload de logs para o CloudWatch. Se você precisar de permissões além disso, como por exemplo, acesso ao DynamoDB ou qualquer outro recurso da AWS, você precisará de sua própria política ou função personalizada: ARN:
# serverless.yml
myNextApplication :
component : " @sls-next/serverless-component@{version_here} "
inputs :
policy : " arn:aws:iam::123456789012:policy/MyCustomPolicy " # serverless.yml
myNextApplication :
component : " @sls-next/serverless-component@{version_here} "
inputs :
roleArn : " arn:aws:iam::123456789012:role/MyCustomLambdaRole "Certifique -se de adicionar permissões de log CloudWatch à sua política ou função personalizada. Exemplo de JSON Política Mínima:
{
"Version" : " 2012-10-17 " ,
"Statement" : [
{
"Effect" : " Allow " ,
"Resource" : " * " ,
"Action" : [
" logs:CreateLogGroup " ,
" logs:CreateLogStream " ,
" logs:PutLogEvents "
]
},
{
"Effect" : " Allow " ,
"Resource" : " arn:aws:s3:::s3-deployment-bucket-name/* " ,
"Action" : [ " s3:GetObject " , " s3:PutObject " ]
}
]
} A função deve incluir o relacionamento de confiança com lambda.amazonaws.com e edgelambda.amazonaws.com .
Nota : Especifique bucketName e forneça permissões para acessar esse bucket por meio policy ou roleArn para que o padrão e a API Lambdas possam acessar recursos estáticos.
A lista exaustiva de ações da AWS necessárias para uma implantação:
"acm:DescribeCertificate", // only for custom domains
"acm:ListCertificates", // only for custom domains
"acm:RequestCertificate", // only for custom domains
"cloudfront:CreateCloudFrontOriginAccessIdentity",
"cloudfront:CreateDistribution",
"cloudfront:CreateInvalidation",
"cloudfront:GetDistribution",
"cloudfront:GetDistributionConfig",
"cloudfront:ListCloudFrontOriginAccessIdentities",
"cloudfront:ListDistributions",
"cloudfront:ListDistributionsByLambdaFunction",
"cloudfront:ListDistributionsByWebACLId",
"cloudfront:ListFieldLevelEncryptionConfigs",
"cloudfront:ListFieldLevelEncryptionProfiles",
"cloudfront:ListInvalidations",
"cloudfront:ListPublicKeys",
"cloudfront:ListStreamingDistributions",
"cloudfront:UpdateDistribution",
"cloudfront:TagResource", // for adding tags
"cloudfront:UntagResource", // for adding tags
"cloudfront:ListTagsForResource", // for adding tags
"iam:AttachRolePolicy",
"iam:CreateRole",
"iam:CreateServiceLinkedRole",
"iam:GetRole",
"iam:PutRolePolicy",
"iam:PassRole",
"lambda:CreateFunction",
"lambda:EnableReplication",
"lambda:DeleteFunction", // only for custom domains
"lambda:GetFunction",
"lambda:GetFunctionConfiguration",
"lambda:PublishVersion",
"lambda:UpdateFunctionCode",
"lambda:UpdateFunctionConfiguration",
"lambda:ListTags", // for tagging lambdas
"lambda:TagResource", // for tagging lambdas
"lambda:UntagResource", // for tagging lambdas
"route53:ChangeResourceRecordSets", // only for custom domains
"route53:ListHostedZonesByName",
"route53:ListResourceRecordSets", // only for custom domains
"s3:CreateBucket",
"s3:GetAccelerateConfiguration",
"s3:GetObject", // only if persisting state to S3 for CI/CD
"s3:ListBucket",
"s3:PutAccelerateConfiguration",
"s3:PutBucketPolicy",
"s3:PutObject",
"s3:PutBucketTagging", // for tagging buckets
"s3:GetBucketTagging", // for tagging buckets
"lambda:ListEventSourceMappings",
"lambda:CreateEventSourceMapping",
"iam:UpdateAssumeRolePolicy",
"iam:DeleteRolePolicy",
"sqs:CreateQueue", // SQS permissions only needed if you use Incremental Static Regeneration. Corresponding SQS.SendMessage permission needed in the Lambda role
"sqs:DeleteQueue",
"sqs:GetQueueAttributes",
"sqs:SetQueueAttributes"
A API e a imagem padrão (para otimização de imagem Next.js), lambdas de borda, receberão 512 MB de memória por padrão. Este valor pode ser alterado atribuindo um número à entrada memory
# serverless.yml
myNextApplication :
component : " @sls-next/serverless-component@{version_here} "
inputs :
memory : 1024 Os valores para o padrão , a API e a imagem lambdas podem ser definidos separadamente atribuindo memory a um objeto como assim:
# serverless.yml
myNextApplication :
component : " @sls-next/serverless-component@{version_here} "
inputs :
memory :
defaultLambda : 1024
apiLambda : 2048
imageLambda : 2048O mesmo padrão pode ser seguido para especificar o Node.js Runtime (nodejs14.x por padrão):
# serverless.yml
myNextApplication :
component : " @sls-next/serverless-component@{version_here} "
inputs :
runtime :
defaultLambda : " nodejs14.x "
apiLambda : " nodejs14.x "
imageLambda : " nodejs14.x " # Note that the sharp image library is built for Lambda Node.js 14.x, although it will likely work fine on other runtimesDa mesma forma, o tempo limite por padrão é de 10 segundos. Para personalizar você pode:
# serverless.yml
myNextApplication :
component : " @sls-next/serverless-component@{version_here} "
inputs :
timeout :
defaultLambda : 20
apiLambda : 15
imageLambda : 15Nota O tempo limite máximo permitido para Lambda@Edge é de 30 segundos. Consulte https://docs.aws.amazon.com/amazonCloudfront/latest/develdguide/lambda-requiements-limits.html
Você também pode definir um nome personalizado para o padrão , API e Image Lambdas - se não o padrão é definido pelo componente AWS -Lambda sem servidor para o ID do recurso:
# serverless.yml
myNextApplication :
component : " @sls-next/serverless-component@{version_here} "
inputs :
name :
defaultLambda : fooDefaultLambda
apiLambda : fooApiLambda
imageLambda : fooImageLambdaHá uma quarta regeneração lambda, que pode ser configurada de maneira semelhante e é usada para regeneração estática incremental. No entanto, ele não usa Lamda@Edge e pode, por exemplo, ter uma configuração de tempo limite mais longa.
Quatro comportamentos de cache são criados no CloudFront.
Os dois primeiros _next/* e static/* encaminham as solicitações para S3.
O terceiro está associado a uma função Lambda, responsável por lidar com três tipos de solicitações.
Página renderizada do lado do servidor. Qualquer página que definir o método getInitialProps será renderizada nesse nível e a resposta será retornada imediatamente ao usuário.
Página otimizada estaticamente. Os pedidos de páginas pré-compilados por HTML são encaminhados para S3.
Recursos públicos. Solicitações para recursos de nível raiz como /robots.txt , /favicon.ico , /manifest.json , etc. Eles são encaminhados para S3.
A razão pela qual 2. E 3. Devo passar pelo Lambda@Edge primeiro é porque as rotas não estão em conformidade com um padrão como _next/* ou static/* . Além disso, um comportamento de cache por rota é uma má idéia, porque o CloudFront permite apenas 25 por distribuição.
O quarto comportamento do cache lida com a próxima API solicita api/* .
| Nome | Tipo | Valor padrão | Descrição |
|---|---|---|---|
| implantar | boolean | true | Quando definido como false, ele não implantará o aplicativo para o provedor (por exemplo, AWS). |
| domínio | Array | null | Por exemplo ['admin', 'portal.com'] |
| domainRredirects | object | {} | Adiciona redirecionamentos no nível do domínio na borda usando um redirecionamento 308. Especifique um objeto de nome de domínio -> Redirecionar destino com protocolo. Por exemplo, www.example.com: https://example.com . Veja aqui para obter mais informações. |
| BucketName | string | null | Nome do balde personalizado onde os ativos estáticos são armazenados. Por padrão, é autogenerado. |
| Bucketregion | string | null | Região onde você deseja hospedar seu balde S3. Verifique se isso está geograficamente mais próximo da maioria dos usuários finais para reduzir a latência quando o CloudFront proxies uma solicitação para o S3. |
| buckettags | object | undefined | Tags de balde personalizadas para definir para o seu balde. Se indefinido, o componente não atualizará nenhuma tags. Se definido como um objeto vazio, ele removerá todas as tags. |
| NextConfigdir | string | ./ | Diretório em que está o seu arquivo APLICATION next.config.js . Essa entrada é útil quando o serverless.yml não está no mesmo diretório que o próximo aplicativo.NOTA: nextConfigDir deve ser definido se next.config.js distDir for usado |
| NextstaticDir | string | ./ | Se o seu diretório static ou public não for um filho direto do nextConfigDir , isso é necessário |
| descrição | string | *lambda-type*@Edge for Next CloudFront distribution | A descrição que será usada para ambos os lambdas. Observe que "(API)" será anexado à descrição da API Lambda. |
| política | string|object | arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole | A política ARN ou embutida que será atribuída a ambos os lambdas. |
| Rolearn | string|object | nulo | O arn de função que será atribuído a ambos os lambdas. |
| Tempo de execução | string|object | nodejs14.x | Quando atribuído um valor, o padrão e o API Lambdas receberão o tempo de execução definido no valor. Quando atribuído a um objeto, os valores para o padrão e a API lambdas podem ser definidos separadamente |
| memória | number|object | 512 | Quando atribuído um número, o padrão e o API Lambdas receberão memória desse valor. Quando atribuído a um objeto, os valores para o padrão e a API lambdas podem ser definidos separadamente |
| tags | object | undefined | Tags a serem atribuídas a um lambda. Se indefinido, o componente não atualizará nenhuma tags. Se definido como um objeto vazio, ele removerá todas as tags. |
| tempo esgotado | number|object | 10 | O mesmo que acima |
| manipulador | string | index.handler | Quando atribuído um valor, substitui o manipulador de função padrão para permitir a configuração. Copia handler.js na rota para as pastas Lambda. Seu manipulador ainda deve ligar para o default-handler depois ou sua função não funcionará com o próximo.js |
| nome | object | / | Nomes para todos os lambdas podem ser explicitamente definidos |
| construir | boolean|object | true | Quando o True construta e implanta aplicativo, quando false assumem que o aplicativo foi construído e usa os diretórios .next .serverless_nextjs no nextConfigDir para implantar. Se um objeto for aprovado, build permite substituir o script é chamado e com quais argumentos. |
| build.cmd | string | node_modules/.bin/next | Comando Build, você pode passar um comando não-op (por exemplo, true ou : em sistemas baseados em UNIX), que irá pular o próximo.js Build |
| build.args | Array|string | ['build'] | Argumentos para passar para a construção |
| build.cwd | string | ./ | Substituir o diretório de trabalho atual |
| build.enabled | boolean | true | O mesmo que build:false , mas de dentro da configuração |
| build.env | object | {} | Adicione variáveis de ambiente adicionais ao script |
| Build.PostbuildCommands | Array | [] | Quaisquer comandos para executar pós-construção e pré-implantação. Por exemplo, você pode executar qualquer código personalizado no diretório .serverless_nextjs , por exemplo, você pode copiar arquivos adicionais no Lambda: consulte #767 (comentar) para um exemplo para next-18n . Aplica -se apenas durante a execução do comando serverless . |
| Build.cleanUpDotNext | boolean | true | Se deve limpar o diretório .next antes de executar a etapa de construção |
| build.assetignorePatterns | string[] | [] | Padrões globais a serem ignorados ao descobrir arquivos para copiar de _next/estático, público e estático. |
| build.usev2Handler | boolean | false | Defina o conjunto experimental para usar os manipuladores V2, que começam a usar manipuladores genicizados. Nota: Isso possui a funcionalidade de separateApiLambda e disableOriginResponseHandler , para que não deve ser usada em conjunto. Além disso, ainda não está completamente otimizado em termos de tamanho de código, mas ainda deve ser executado. No futuro, provavelmente usaremos esse modo por padrão. |
| CloudFront | object | {} | Entradas a serem passadas para a AWS-cloudfront |
| certatearn | string | `` | Certificado específico ARN para usar na distribuição do CloudFront. É útil se você tiver um certificado SSL curinga que deseja usar. Atualmente, isso funciona apenas em conjunto com a entrada domain . Verifique a configuração do CloudFront Custom para como especificar certificate sem precisar usar a entrada domain (observe que isso substituirá qualquer certificado devido à entrada do domínio). |
| DomainType | string | "both" | Pode ser um dos: "apex" - apenas o domínio Apex, não crie um subdomínio de www. "www" - apenas o domínio www, não crie um subdomínio Apex. "both" - crie domínios www e apex quando um é fornecido. |
| DomainMinimumProtocolversão | string | "TLSv1.2_2018" | Pode ser um dos: "SSLv3", "TLSv1", "TLSv1.1_2016", "TLSv1.2_2018", "TLSv1.2_2019", "TLSv1.2_2021" or "TLSv1_2016" . Veja referência. |
| publicDirectoryCache | boolean|object | true | Personalize a política de cache de ativos public / static . A atribuição de um objeto com value e/ou test permite personalizar a política de armazenamento em cache e os tipos de arquivos em cache. Atribuir falsas desativa o cache |
| usaRerverlesstraceTarget | boolean | false | Use o destino Experimental-Serverless Trace para criar seu próximo aplicativo. Este é o mesmo alvo de construção que o Vercel agora usa. Veja este RFC para obter detalhes. NOTA: Ao usar isso, pode ser necessário definir a variável NODE_ENV para production . |
| MinifyHandlers | boolean | false | Use manipuladores minificados pré-construídos para reduzir o tamanho do código. Não minifica os manipuladores personalizados. |
| Ativarhttpcompression | boolean | false | Quando definido como true as funções Lambda@Edge para solicitações SSR e API usarão o GZIP para comprimir a resposta. Observe que você não precisa ativar isso, porque o CloudFront compactará as respostas para você fora da caixa. |
| autenticação | object | undefined | Objeto de autenticação para uso com autenticação básica (disponível em 1.19.0-alfa.3). Ele suporta apenas uma única combinação de nome de usuário/senha por enquanto e está inlinada em texto simples no manipulador Lambda. Você também deve encaminhar o cabeçalho Authorization para comportamentos do CloudFront, por exemplo, defaults , api/* e _next/data/_ . Nota: isso é um meio simples de proteger um ambiente como um local de desenvolvimento/teste, não é recomendado para o uso da produção. |
| Authentication.username | string | undefined | Nome de usuário para autenticação básica. |
| Ativa 3Celation | boolean | true | Se deve habilitar a aceleração da transferência S3. Isso pode ser útil para desativar, pois algumas regiões da AWS não o apoiam. Veja referência. |
| Removerloldlambdaversions | boolean | false | Suporte básico para remover as versões antigas do Lambda após a implantação para garantir. Se definido como true, toda vez que você implantar, removerá automaticamente até ~ 50 versões antigas (começando por mais antigas) de todos os lambdas que não são implantados/replicados. Se você precisar de estratégias mais complexas, é recomendável escrever seu próprio script para remover versões antigas. |
Entradas personalizadas podem ser configuradas assim:
myNextApp :
component : " @sls-next/serverless-component@{version_here} "
inputs :
bucketName : my-bucket(Experimental) - Mais trabalho necessário para recuperar esse construto e também para reutilizar parte da lógica sem servidor. Como resultado, é provável que o construto se adapte/altere de acordo.
A documentação pode ser encontrada aqui.
Como estamos emulando a lógica de roteamento do Next.js quase do zero para otimizá -la para um ambiente sem servidor, pode haver alguns recursos incompletos ou ausentes (como mencionado anteriormente). No entanto, sentimos que cobrimos a maioria dos recursos e adicionamos uma boa unidade e cobertura de teste de ponta a ponta para garantir a estabilidade (por exemplo, em mais de 10 suítes de teste de ponta a ponta). Várias pessoas estão usando isso para alimentar sua startup, sites pessoais etc.
As limitações do provedor de nuvem também se aplicam - por exemplo, no AWS Lambda@Edge, há partidas frias, limites de tamanho de código, limite de tamanho de resposta de 1 MB, etc., para citar alguns. É claro que você também está vinculado a uma única plataforma por enquanto (aws lambda@edge; mais em breve!).
Também continuamos a melhorar o processo de implantação, considerando melhores soluções de infraestrutura como código em um futuro próximo (CDK, CDK Terraform, Pulumi, etc.).
Verifique se o seu serverless.yml usa o formato serverless-components (beta). Os componentes sem servidores diferem da estrutura original sem servidor, mesmo que ambos sejam acessíveis pela mesma CLI.
✅ Do
# serverless.yml
myNextApp :
component : " @sls-next/serverless-component@{version_here} "
myTable :
component : serverless/aws-dynamodb
inputs :
name : Customers
# other componentsNão
# serverless.yml
provider :
name : aws
runtime : nodejs10.x
region : eu-west-1
myNextApp :
component : " @sls-next/serverless-component@{version_here} "
Resources : ... Observe como a YAML correta não declara um provider , Resources etc.
Para implantar, não execute serverless deploy . Simplesmente execute serverless e isso implanta seus componentes declarados no arquivo serverless.yml .
Para mais informações sobre os componentes sem servidor, vá aqui.
Os pacotes manipuladores de API e manipuladores padrão são implantados separadamente, mas cada um tem um limite de 50 MB com zíper ou 250 MB não compactados por AWS - veja aqui e aqui. Por design, atualmente existe apenas um lambda@edge para todas as rotas de página e um lambda@edge para todas as rotas de API. Isso pode levar a problemas de tamanho de código, especialmente se você tiver muitas rotas de API, páginas SSR, etc.
Se você estiver encontrando problemas de tamanho de código, tente o seguinte:
Otimize o tamanho do seu código: reduza as dependências # em suas páginas SSR e rotas de API, tenha menos páginas SSR (ou seja, não use getInitialProps() ou getServerSideProps() ).
Minify o código do manipulador em si usando a entrada minifyHandlers . Isso reduzirá o tamanho do manipulador de ~ 500 kb para ~ 200 kb.
Minificar/minimizar o código do lado do servidor usando o TERSER adicionando a seguinte configuração WebPack ao seu next.config.js . Ele usa a variável de ambiente NEXT_MINIMIZE para indicá -la para minimizar o código SSR. Observe que isso aumentará os tempos de construção e minimizará o código para que possa ser mais difícil depurar erros em nuvem.
Primeiro, adicione terser-webpack-plugin às suas dependências. Em seguida, atualize next.config.js :
const TerserPlugin = require ( "terser-webpack-plugin" ) ; webpack: ( config , { buildId , dev , isServer , defaultLoaders , webpack } ) => {
if ( isServer && ! dev && process . env . NEXT_MINIMIZE === "true" ) {
config . optimization = {
minimize : true ,
minimizer : [
new TerserPlugin ( {
parallel : true ,
cache : true ,
terserOptions : {
output : { comments : false } ,
mangle : true ,
compress : true
} ,
extractComments : false
} )
]
} ;
}
return config ;
} ;Observe que, se você não usar nenhuma rotas de API, todos os arquivos JS usados apenas para páginas estáticas de pré -renda serão removidas automaticamente do pacote. No entanto, se você usar rotas de API, não as removemos, pois elas podem ser usadas para o modo de visualização. Não existe uma maneira oficial/não hacky de identificar e remover esses arquivos JS não usados no modo de visualização, mesmo quando as rotas de API são usadas. Mas podemos adicionar uma nova entrada para excluí -los manualmente, se necessário.
useServerlessTraceTarget no serverless.yml . Isso fará com que o Next.js não agrupe dependências em cada página (em vez de criar páginas leves) e, em seguida, serverless-next.js node_modules Provavelmente, isso ocorre devido a um problema de tamanho do código Lambda@Edge (veja acima para obter soluções em potencial. Problema relacionado ao github) ou se você tiver uma velocidade de upload de rede lenta e/ou está tentando implantar um grande pacote Lambda.
No segundo caso, o pacote aws-sdk NPM usado tem um tempo limite padrão de 120 segundos. No momento, isso não é configurável, mas podemos oferecer suporte a tempo limite mais longos em um futuro próximo (semelhante ao#937 sem servidor/sem servidor, que se aplica apenas à estrutura sem servidor, e não aos componentes sem servidor).
Por padrão, o CloudFront define o cabeçalho Host para o nome do host de origem S3. Você precisa encaminhar o cabeçalho Host para a origem. Veja o exemplo abaixo para encaminhá -lo para o seu comportamento de api/* Cache:
myNextApplication :
component : " @sls-next/serverless-component@{version_here} "
inputs :
cloudfront :
api/* :
forward :
headers : [Host] Os usuários são incentivados a usar esse componente em vez da serverless-plugin . Esse componente foi construído e projetado usando lições aprendidas com o plug -in sem servidor.
Consulte examples/dynamodb-crud Para um exemplo de aplicativo TODO que interage com o DynamoDB. Você pode encontrar uma lista completa de exemplos aqui
Infelizmente, devido à maneira como os componentes sem servidor funcionam (pelo menos a versão beta), o estado de implantação precisa ser sincronizado fora do comando principal serverless . Então você pode tentar as seguintes soluções:
.serverless . Embora isso não seja recomendado, pois não funciona bem para vários estágios..serverless , veja um exemplo aqui, aqui (usa vários arquivos serverless.yml ) ou aqui (baseado em ações do GitHub, usa vários arquivos serverless.yml ).distributionId CloudFront para especificar uma distribuição CloudFront existente para implantar.No futuro, procuraremos melhorar isso, integrando o gerenciamento adequado do estágio no próprio componente.
Este projeto foi iniciado pelo autor original quando os componentes sem servidor estavam na versão beta e, infelizmente, os componentes do GA foi lançado logo depois. Mas isso ficou maior e maior, com vários subcomponentes importados para esse monorepo, pois não foram mantidos por sem servidor. E então ficou difícil atualizar.
Havia um plano para atualizar os componentes do GA, mas foi suspenso por alguns motivos:
Atualmente, estamos investigando soluções IAC adequadas (como CDK para Terraform, CDK, Pulumi etc.) para abordar isso e aliviar o ônus de manter a lógica de implantação complexa, para que possamos focar na experiência do desenvolvedor e apresentar paridade com o próximo.js.
Sim! O bloqueador principal era que a lógica de roteamento do próximo.js costumava ser altamente acoplada à lógica Lambda@Edge/Cloudfront. No entanto, genricizamos a maior parte da lógica principal (no pacote @sls-next/core ) para que ela possa ser reutilizada em outras plataformas, simplesmente criando um manipulador de embrulho, implementando algum cliente específico da plataforma (por exemplo, para recuperar páginas, desencadear regeneração estática etc.) e criar um implantador. Se você foi observador, terá notado um novo pacote atualmente em andamento para as implantações Lambda via API Gateway: https://github.com/serverless-nextjs/serverless-next.js/tree/master/packages/libs/lambda. Outras plataformas como o Azure e o Google Cloud devem seguir em breve.
us-east-1 . Como posso implantá -lo em outra região? Sem servidor Next.js não tem região . Por design, os aplicativos serverless-next.js serão implantados em todo o mundo em cada localização do CloudFront Edge. O Lambda pode parecer que só é implantado para us-east-1 mas nos bastidores, é replicado para todas as outras regiões.
Consulte a amostra abaixo para obter uma configuração build avançada que inclua a passagem de argumentos adicionais e variáveis de ambiente para a compilação.
# serverless.yml
myDatabase :
component : MY_DATABASE_COMPONENT
myNextApp :
component : " @sls-next/serverless-component@{version_here} "
inputs :
build :
args : ["build", "custom/path/to/pages"]
env :
DATABASE_URL : ${myDatabase.databaseUrl} Se você tentar concatenar uma variável de ambiente com outra string, como ${env.VARIABLE}-blah , a estrutura sem servidor parece resolvê-la apenas para ${env.VARIABLE} .
Parece ser um bug nos componentes sem servidor - pode ser devido a não usar a versão mais recente do GA, onde pode ter sido corrigida (isso ainda está no componente beta, infelizmente). Por enquanto, a solução alternativa é:
serverless.yml primeiro, depois concatenar: stage : ${env.STAGE}
my-app :
component : " @sls-next/[email protected] "
inputs :
domain :
- " ${stage}-front-end "
- mydomain.com Você pode usar a nova entrada domainRedirects , juntamente com o cabeçalho Host e domainType: both , para redirecionar solicitações para o domínio correto. Consulte Exemplo de configuração abaixo que redireciona www.example.com solicitações para https://example.com .
next-app :
component : " ../../serverless-components/nextjs-component "
inputs :
cloudfront :
defaults :
forward :
headers : [Host]
domain : ["example.com"]
domainType : " both "
domainRedirects :
www.example.com : https://example.com Tudo isso acontece dentro dos manipuladores de solicitação de origem Lambda@Edge. Observe que isso não permitirá redirecionar solicitações em _next/static/* ou /static/* , pois esses comportamentos de cache não possuem um manipulador de lambda@Edge anexado a eles.
Caso contrário, você também pode usar a solução alternativa manual usando um balde S3 descrito aqui. Em resumo, você precisará criar um novo balde S3 e configurá -lo com a hospedagem estática para redirecionar solicitações para o seu tipo de subdomínio suportado (ex. "Www.example.com" ou "Explet.com"). Para poder suportar redirecionamentos de HTTPs, você precisará configurar uma distribuição em nuvem com o balde de redirecionamento S3 como origem. Por fim, você precisará criar um registro "A" na Rota 53 com sua distribuição do CloudFront recém -criada como alvo de alias.
build.env não aparecem no meu aplicativo Para permitir que seu aplicativo acesse as variáveis de ambiente definidas, você precisa expô -las através do next.config.js conforme descrito aqui.
Dado um serverless.yml como este
myApp :
inputs :
build :
env :
API_HOST : " http://example.com "seu next.config.js deve ficar assim:
module . exports = {
env : {
API_HOST : process . env . API_HOST
}
} ; Você pode ver um erro como abaixo:
502 ERROR
The request could not be satisfied.
The Lambda function returned invalid JSON: The JSON output is not parsable. We can't connect to the server for this app or website at this time. There might be too much traffic or a configuration error. Try again later, or contact the app or website owner.
If you provide content to customers through CloudFront, you can find steps to troubleshoot and help prevent this error by reviewing the CloudFront documentation.
Generated by cloudfront (CloudFront)
Geralmente ocorre quando o tamanho da resposta é muito grande. Lambda@Edge atualmente tem uma limitação de 1 MB retornada pelo manipulador de solicitação de origem. Veja: https://docs.aws.amazon.com/amazonCloudfront/latest/develderguide/lambda-generating-http-rosponsses-in-requests.html#lambda-generating-httt-sponses-errrors. Infelizmente, pode não haver uma solução alternativa além de tentar garantir que suas respostas sejam menores.
Certifique-se de que você encaminhe o cabeçalho do Accept-Language via configuração do CloudFront; Otherewise, não é capaz de determinar quais idiomas o usuário entende e/ou prefere. Por padrão, ele será encaminhado, mas se você substituir sua própria configuração, adicione -a novamente.
Se você estiver usando bibliotecas de terceiros (apenas next-i18next por enquanto) e usar caminhos padrão, alguns arquivos podem precisar ser copiados para os diretórios da Lambda. Este componente tentará detectar arquivos padrão e copiá -los para você. No entanto, se você tiver uma configuração personalizada, pode ser necessário escrever seus próprios postBuildCommands com copiar arquivos, etc.
Consulte o ReadMe para obter mais informações e advertências.
Você pode abrir um novo problema aqui. Se postar um problema, siga o Wiki de depuração primeiro para obter algumas dicas úteis e tente incluir o máximo de informações para reproduzir o problema.
Se você estiver relatando uma vulnerabilidade de segurança, siga a política de segurança.
Observe que existe apenas um mantenedor principal agora (@dphang) e um punhado de colaboradores da comunidade, que contribuem para esta biblioteca em seu tempo livre. So we hope you understand that our response is best-effort and may take several days, or more. So we hope you could at least help debug the issue or provide as much context. In case an issue hasn't been looked at for a long time (> a few weeks) or it seems like a major issue, feel free to mention a maintainer and we will try to prioritize it.
We would love if you can help contribute, whether it's coding, triaging or debugging issues, helping with documentation, or financial support! Please see the contributing guide.
This project exists thanks to all the people who contribute. [Contribuir].
Made with contributors-img.
Become a financial contributor and help us sustain our community. [Contribuir]
Support this project with your organization. Your logo will show up here with a link to your website. [Contribuir]
