serverless next.js
v3.7.0
Un componente sin servidor de configuración cero Next.js para AWS Lambda@Edge apuntando a la paridad de funciones completa.
Revise las funciones para obtener una lista de funciones compatibles actualmente.
️ Este readMe refleja los últimos cambios en la ramamaster. Puede o no ser publicado para lalatestversión (estable) oalphaen NPM. Vaya a lanzamientos, busque la versión correcta@sls-next/serverless-componentque está utilizando y abra el ReadMe para esa versión para obtener información más precisa. Si se enumera una función en este ReadMe pero no funciona, primero intente actualizar a la versiónalphamás reciente en NPM.
Actualmente, esto está utilizando Componentes Beta sin servidor (no versión de GA) ya que el proyecto se inició antes de GA. Actualmente estamos reelaborando cómo funcionarán las implementaciones en el futuro y explorando mejores soluciones IAC como CDK, CDK para Terraform, etc. y hará un anuncio antes de fin de año en cualquier actualización.
Desde su siguiente.js 8.0, se introdujo el modo sin servidor que proporciona una nueva API de bajo nivel que proyectos como este puede usar para implementar en diferentes proveedores de nubes. Sin embargo, Next.js no proporciona la lógica de enrutamiento completa sin servidor, de ahí que este proyecto sea necesario para llenar el vacío. La visión a largo plazo es permitirle a sí mismo con varias nubes, comenzando con AWS.
Este proyecto es una mejor versión del complemento sin servidor que se centra en abordar problemas centrales como el soporte de los próximos 9, una mejor experiencia de desarrollo, el límite de recursos de 200 CloudFormation y el rendimiento.
Se necesita poco o ninguna configuración. Puede extender los valores predeterminados según las necesidades de su aplicación.
Los usuarios de este componente deberían poder usar las herramientas de desarrollo Next.js, también conocido next dev . Es el trabajo del componente implementar su aplicación para garantizar la paridad con todas las características de Next que conocemos y amamos. Intentamos emular todo o la mayoría de la lógica de enrutamiento y del lado del servidor desde Next.js y optimizarla para un entorno sin servidor. A continuación puede encontrar una lista de las características que se admiten actualmente.
Con una arquitectura simplificada y ningún uso de CloudFormation, no hay límites para cuántas páginas puede tener en su aplicación, ¡además de los tiempos de implementación son muy rápidos! con la excepción de los tiempos de propagación de Cloudfront, por supuesto.
Dado que emulamos la lógica de enrutamiento Next.js, desafortunadamente no siempre estamos a plena paridad. Lo siguiente muestra todas las características compatibles o características planificadas. Si la casilla de verificación está marcada, significa que la función es compatible. De lo contrario, es probable que aún no sea compatible o actualmente en la etapa de planificación o implementación. Consulte la descripción de un elemento para obtener detalles específicos.
Tenga en cuenta que algunas características solo pueden estar en la última versión alfa. Si una función se enumera como compatible pero no funciona en la latest etiqueta, lo más probable es que esté en la etiqueta alpha . Si puede, ayúdenos a probar los últimos cambios alfa y envíe un informe de error si encuentra algún problema. ¡Gracias!
¿Hay una característica que desee pero que aún no se admite? ¡Abra un nuevo problema para informarnos!
/_next/* Servido desde CloudFront. getStaticProps . getServerSideProps . getStaticPaths . _next/static/* y static/* , ya que esos comportamientos de caché no tienen manejadores Lambda unidos a ellos. Tenga en cuenta que el nuevo has formato de coincidencia (https://nextjs.org/docs/api-reference/next.config.js/redirects#header-cookie-and-Query-matching) aún no es compatible. _next/static/* y static/* , ya que esos comportamientos de caché no tienen controladores Lambda unidos a ellos. Tenga en cuenta que el nuevo has formato de coincidencia (https://nextjs.org/docs/api-reference/next.config.js/redirects#header-cookie-and-Query-matching) aún no es compatible. _next/static/* y static/* , ya que esos comportamientos de caché no tienen manejadores Lambda unidos a ellos. Tenga en cuenta que el nuevo has formato de coincidencia (https://nextjs.org/docs/api-reference/next.config.js/redirects#header-cookie-and-Query-matching) aún no es compatible. next-i18next . Primero, asegúrese de tener Node.js 12+ instalado en la máquina de implementación, ya que todo el código ahora se transpila a ES2019. Agregue su próxima aplicación a 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 Si especifica @sls-next/serverless-component en su archivo serverless.yml , no agrega @sls-next/serverless-component a su archivo paquete.json, no se usa y solo se usa la versión en el archivo serverless.yml , que se usa sin servidor de NPM por sí mismo. Si no especifica la versión, usará la latest etiqueta, que se refiere a la última versión estable aquí (es decir, no versiones alfa).
También puede señalarlo a una instalación local, por ejemplo, si desea una versión usando package.json .
En este caso, configure lo siguiente:
# serverless.yml
myNextApplication :
component : " ./node_modules/@sls-next/serverless-component "Luego establezca sus credenciales de AWS como variables de entorno:
AWS_ACCESS_KEY_ID=accesskey
AWS_SECRET_ACCESS_KEY=sshhhY simplemente implementa:
$ serverlessSi tiene problemas de implementación debido a una nueva versión sin servidor, intente fijar a una versión específica, por ejemplo, 2.72.2. Ver #2320 (comentario)
[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) Maneja silencio a continuación. JS construye fallas.
También se recomienda agregar una bandera --debug para obtener registros más útiles de lo que está sucediendo detrás de escena.
No intente implementar ejecutando serverless deploy , use solo serverless
En la mayoría de los casos, no querría usar el dominio de distribución de CloudFront para acceder a su aplicación. En su lugar, puede especificar un nombre de dominio personalizado.
Puede usar cualquier nombre de dominio, pero debe usar AWS Route53 para su alojamiento DNS. Para migrar registros DNS de un dominio existente, siga las instrucciones aquí. Los requisitos para usar un nombre de dominio personalizado:
mydomain.com ) con un conjunto de servidores de nombres.El componente Servidor Sext.JS generará automáticamente un certificado SSL y creará un nuevo registro para apuntar a su distribución de 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" También puede configurar un subdomain :
# serverless.yml
myNextApplication :
component : " @sls-next/serverless-component@{version_here} "
inputs :
domain : ["sub", "example.com"] # [ sub-domain, domain ] Para especificar sus propias entradas Cloudfront, simplemente agregue cualquier entrada AWS-Cloudfront en 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 : val2Esto es particularmente útil para almacenar en caché de cualquiera de sus próximas páginas. Consulte esto para una aplicación de ejemplo con configuración de caché personalizado. También puede actualizar una distribución existente de CloudFront utilizando entradas CloudFront personalizadas.
Las páginas renderizadas estáticamente (es decir, las páginas HTML que se cargan a S3) tienen el siguiente conjunto de control de caché:
cache-control: public, max-age=0, s-maxage=2678400, must-revalidate
s-maxage permite a Cloudfront en caché de las páginas en las ubicaciones de borde durante 31 días. max-age=0 En combinación con must-revalidate asegure que los navegadores nunca almacenen en caché las páginas estáticas. Esto permite que CloudFront tenga el control total de los TTL en caché. En cada implementación se crea una invalidación /* para garantizar que los usuarios obtengan contenido nuevo.
Por defecto, los formatos de imagen comunes ( gif|jpe?g|jp2|tiff|png|webp|bmp|svg|ico ) En /public o /static Golders tienen una política Cache-Control de un año aplicada ( public, max-age=31536000, must-revalidate ). Puede personalizar el value del encabezado de Cache-Control y el regex de qué archivos test , con 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 debe ser una política Cache-Control válida y test debe ser una regex válida de los tipos de archivos que desea probar. Si no desea que los navegadores almacenen en caché los activos del directorio público, puede deshabilitar esto:
myNextApplication :
component : " @sls-next/serverless-component@{version_here} "
inputs :
publicDirectoryCache : falseDe manera predeterminada, las funciones Lambda@Edge se ejecutan usando AWSLAMBDABASICEXECUTIONROLO, que solo permite cargar registros en CloudWatch. Si necesita permisos más allá de esto, como, por ejemplo, acceso a Dynamodb o cualquier otro recurso de AWS, necesitará su propia política personalizada o rol de 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 "Asegúrese de agregar permisos de registro de CloudWatch a su política o rol personalizados. Ejemplo de JSON de 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 " ]
}
]
} El rol debe incluir una relación de confianza con lambda.amazonaws.com y edgelambda.amazonaws.com .
Nota : Especifique bucketName y brinde permisos para acceder a ese cubo a través policy o roleArn para que los Lambdas predeterminados y API puedan acceder a los recursos estáticos.
La exhaustiva lista de acciones de AWS requeridas para una implementación:
"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 los Lambdas de borde predeterminados , API e Image (para NEXT.JS Optimization) se asignarán a 512 MB de memoria de forma predeterminada. Este valor se puede alterar asignando un número a la entrada memory
# serverless.yml
myNextApplication :
component : " @sls-next/serverless-component@{version_here} "
inputs :
memory : 1024 Los valores para los lambdas predeterminados , API y de imagen se pueden definir por separado asignando memory a un objeto como así:
# serverless.yml
myNextApplication :
component : " @sls-next/serverless-component@{version_here} "
inputs :
memory :
defaultLambda : 1024
apiLambda : 2048
imageLambda : 2048Se puede seguir el mismo patrón para especificar el tiempo de ejecución Node.js (nodeJS14.x por defecto):
# 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 runtimesDel mismo modo, el tiempo de espera por defecto es de 10 segundos. Para personalizar, puede:
# serverless.yml
myNextApplication :
component : " @sls-next/serverless-component@{version_here} "
inputs :
timeout :
defaultLambda : 20
apiLambda : 15
imageLambda : 15Tenga en cuenta que el tiempo de espera máximo permitido para Lambda@Edge es de 30 segundos. Ver https://docs.aws.amazon.com/amazoncloudfront/latest/developeguide/lambda-Requirements-limits.html
También puede establecer un nombre personalizado para LambDas predeterminados , API e Image , si no el componente AWS -Lambda Servidor se establece en la ID de recursos:
# serverless.yml
myNextApplication :
component : " @sls-next/serverless-component@{version_here} "
inputs :
name :
defaultLambda : fooDefaultLambda
apiLambda : fooApiLambda
imageLambda : fooImageLambdaHay una cuarta regeneración Lambda, que se puede configurar de manera similar y se usa para una regeneración estática incremental. Sin embargo, no usa Lamda@Edge y puede, por ejemplo, tener una configuración de tiempo de espera más larga.
Se crean cuatro comportamientos de caché en CloudFront.
Los dos primeros _next/* y static/* reenvían las solicitudes a S3.
El tercero está asociado a una función Lambda que es responsable de manejar tres tipos de solicitudes.
Página del lado del lado del servidor. Cualquier página que define el método getInitialProps se representará en este nivel y la respuesta se devuelve inmediatamente al usuario.
Página optimizada estáticamente. Las solicitudes a las páginas que fueron compiladas al lado de HTML se envían a S3.
Recursos públicos. Solicitudes para recursos de nivel raíz como /robots.txt , /favicon.ico , /manifest.json , etc. Estos se envían a S3.
La razón por la cual 2. Y 3. Tienen que pasar por Lambda@Edge primero es porque las rutas no se ajustan a un patrón como _next/* o static/* . Además, un comportamiento de caché por ruta es una mala idea porque Cloudfront solo permite 25 por distribución.
El cuarto comportamiento de caché maneja las siguientes solicitudes de API api/* .
| Nombre | Tipo | Valor predeterminado | Descripción |
|---|---|---|---|
| desplegar | boolean | true | Cuando se establece en False, no implementará la aplicación en el proveedor (por ejemplo, AWS). |
| dominio | Array | null | Por ejemplo ['admin', 'portal.com'] |
| dominio del dominio | object | {} | Agrega redireccionamientos a nivel de dominio en el borde usando una redirección 308. Especifique un objeto de nombre de dominio -> Destino de redirección con el protocolo. Por ejemplo, www.example.com: https://example.com . Vea aquí para obtener más información. |
| nombre | string | null | Nombre del cubo personalizado donde se almacenan los activos estáticos. Por defecto se está autogenerados. |
| región de cubo | string | null | Región donde desea alojar su cubo S3. Asegúrese de que esto esté geográficamente más cerca de la mayoría de sus usuarios finales para reducir la latencia cuando CloudFront proxies una solicitud a S3. |
| buckettags | object | undefined | Etiquetas de cubo personalizadas para configurar su cubo. Si no se define, el componente no actualizará ninguna etiqueta. Si se establece en un objeto vacío, eliminará todas las etiquetas. |
| NextConfigdir | string | ./ | Directorio donde está su aplicación next.config.js File. Esta entrada es útil cuando serverless.yml no está en el mismo directorio que la siguiente aplicación.Nota: nextConfigDir debe establecerse si se usa next.config.js distDir |
| nextstaticdir | string | ./ | Si su directorio static o public no es un hijo directo de nextConfigDir , esto es necesario |
| descripción | string | *lambda-type*@Edge for Next CloudFront distribution | La descripción que se utilizará para ambos lambdas. Tenga en cuenta que "(API)" se agregará a la descripción API Lambda. |
| política | string|object | arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole | La Política ARN o en línea que se asignará a ambos Lambdas. |
| rolearn | string|object | nulo | El ARN de papel que se asignará a ambos lambdas. |
| tiempo de ejecución | string|object | nodejs14.x | Cuando se le asigna un valor, tanto el valor predeterminado como el API Lambdas se le asignarán el tiempo de ejecución definido en el valor. Cuando se asigna a un objeto, los valores para los lambdas predeterminados y API se pueden definir por separado |
| memoria | number|object | 512 | Cuando se le asigna un número, tanto los Lambdas predeterminados como API se asignarán la memoria de ese valor. Cuando se asigna a un objeto, los valores para los lambdas predeterminados y API se pueden definir por separado |
| etiquetas | object | undefined | Etiquetas para asignar a una lambda. Si no se define, el componente no actualizará ninguna etiqueta. Si se establece en un objeto vacío, eliminará todas las etiquetas. |
| se acabó el tiempo | number|object | 10 | Igual que arriba |
| entrenador de animales | string | index.handler | Cuando se le asigne un valor, anula el controlador de función predeterminado para permitir la configuración. Copias handler.js en ruta hacia las carpetas Lambda. Su controlador aún debe llamar al default-handler después o su función no funcionará con Next.js |
| nombre | object | / | Los nombres de todas las lambdas se pueden definir explícitamente |
| construir | boolean|object | true | Cuando True construye e implementa la aplicación, cuando False supone que la aplicación se ha construido y usa los directorios .next .serverless_nextjs en nextConfigDir para implementar. Si se pasa un objeto, build permite anular cómo se llama el script y con qué argumentos. |
| build.cmd | string | node_modules/.bin/next | Comando de compilación, puede pasar un comando no-op (por ejemplo, true o : en sistemas basados en UNIX) que luego omitirá el siguiente.js construye |
| Build.args | Array|string | ['build'] | Argumentos para pasar a la construcción |
| build.cwd | string | ./ | Anular el directorio de trabajo actual |
| build. habilitado | boolean | true | Igual que pasar build:false pero desde la configuración |
| construir.env | object | {} | Agregue variables de entorno adicionales al script |
| build.postBuildCommands | Array | [] | Cualquier comando para ejecutar post-construcción y pre-deploy. Por ejemplo, puede ejecutar cualquier código personalizado en el directorio .serverless_nextjs , por ejemplo, puede copiar archivos adicionales en la lambda: consulte #767 (comentario) para obtener un ejemplo para next-18n . Solo se aplica durante la ejecución del comando serverless . |
| build.cleanupdotNext | boolean | true | Si limpiar el directorio .next antes de ejecutar el paso de compilación |
| Build.AssetignArepaterns | string[] | [] | Patrones de globas para ignorar al descubrir archivos para copiar desde _next/estáticos, públicos, directorios estáticos. |
| build.usev2Handler | boolean | false | Experimental Establezca esto en verdadero para usar los controladores V2 que comienzan a usar manejadores generados. NOTA: Esto tiene la funcionalidad de separateApiLambda y disableOriginResponseHandler por lo que no debe usarse juntos. Además, aún no está completamente optimizado en términos de tamaño del código, pero aún debe ser un rendimiento. En el futuro, es probable que usemos este modo por defecto. |
| frente a la nube | object | {} | Las entradas que se pasarán a AWS-Cloudfront |
| certificación | string | `` `` | Certificado específico ARN para usar para la distribución de CloudFront. Útil si tiene un certificado SSL comodín que desea usar. Esto actualmente funciona solo en conjunto con la entrada domain . Verifique la configuración personalizada de CloudFront sobre cómo especificar certificate sin necesidad de usar la entrada domain (tenga en cuenta que hacerlo anulará cualquier certificado debido a la entrada de dominio). |
| tipo de dominio | string | "both" | Puede ser uno de: "apex" - Apex Dominio solamente, no cree un subdominio www. "www" - dominio www solamente, no cree un subdominio APEX. "both" : cree dominios WWW y APEX cuando se proporcione cualquiera de los cuales se proporciona. |
| aprotocolversión de dominio | string | "TLSv1.2_2018" | Puede ser uno de: "SSLv3", "TLSv1", "TLSv1.1_2016", "TLSv1.2_2018", "TLSv1.2_2019", "TLSv1.2_2021" or "TLSv1_2016" . Ver referencia. |
| PublicDirectoryCache | boolean|object | true | Personalice la política de almacenamiento en caché de activos de la carpeta public / static . Asignar un objeto con value y/o test le permite personalizar la política de almacenamiento en caché y los tipos de archivos que se almacenan en caché. Asignación de falsos deshabilitar el almacenamiento en caché |
| useerverlesstracetarget | boolean | false | Use el objetivo experimental de Trace Insey-TRACE para construir su próxima aplicación. Este es el mismo objetivo de construcción que Vercel ahora usa. Vea este RFC para más detalles. Nota: Al usar esto, es posible que deba establecer la variable NODE_ENV en production . |
| Manificadores de hombres | boolean | false | Use manejadores minificados preconstruidos para reducir el tamaño del código. No minifica los manejadores personalizados. |
| enablehttpcompression | boolean | false | Cuando se establece en true las funciones Lambda@Edge para SSR y las solicitudes de API utilizarán GZIP para comprimir la respuesta. Tenga en cuenta que no debe necesitar habilitar esto porque CloudFront comprimirá respuestas para usted fuera de la caja. |
| autenticación | object | undefined | Objeto de autenticación para usar con autenticación básica (disponible desde 1.19.0-alfa.3). Solo admite una sola combinación de nombre de usuario/contraseña por ahora y se incluye en texto sin formato en el controlador Lambda. También debe reenviar el encabezado Authorization para los comportamientos de CloudFront, por ejemplo, defaults , api/* , y _next/data/_ . Nota: Esto se entiende como un medio simple para proteger un entorno como un sitio de desarrollo/prueba, no se recomienda para el uso de producción. |
| autenticación. Nombre de usuario | string | undefined | Nombre de usuario para la autenticación básica. |
| habils3Aceleration | boolean | true | Si habilita la aceleración de transferencia S3. Esto puede ser útil para deshabilitar ya que algunas regiones de AWS no lo admiten. Ver referencia. |
| RetRoundlambdaversions | boolean | false | Soporte básico para eliminar las viejas versiones de Lambda después de implementarse para garantizar. Si se establece en True, cada vez que lo implementa, eliminará automáticamente hasta ~ 50 versiones antiguas (comenzando desde el más antiguo) de todas las lambdas que no están implementadas/replicadas. Si necesita estrategias más complejas, se recomienda escribir su propio script para eliminar versiones antiguas. |
Las entradas personalizadas se pueden configurar así:
myNextApp :
component : " @sls-next/serverless-component@{version_here} "
inputs :
bucketName : my-bucket(Experimental): se requiere más trabajo para poner a al día esta construcción y también para reutilizar parte de la lógica sin servidor. Como resultado, es probable que la construcción se adapte/cambie en consecuencia.
La documentación se puede encontrar aquí.
Como emulamos a continuación. Sin embargo, creemos que hemos cubierto la mayoría de las características y hemos agregado una buena unidad y cobertura de prueba de extremo a extremo para garantizar la estabilidad (por ejemplo, más de más de 10 suites de prueba de extremo a extremo). Varias personas están utilizando esto para alimentar su inicio, sitios web personales, etc.
Las limitaciones del proveedor de la nube también se aplican, por ejemplo, en AWS Lambda@Edge, hay arranque en frío, límites de tamaño de código, límite de tamaño de respuesta de 1 MB, etc., por nombrar algunos. Por supuesto, también está vinculado a una sola plataforma por ahora (AWS Lambda@Edge; ¡más pronto!).
También continuamos mejorando el proceso de implementación al considerar mejores soluciones de infraestructura como código en el futuro cercano (CDK, CDK Terraform, Pulumi, etc.).
Asegúrese de que su serverless.yml use el formato serverless-components (beta). Los componentes sin servidor difieren del marco original sin servidor, a pesar de que ambos son accesibles a través de la misma CLI.
✅ hacer
# serverless.yml
myNextApp :
component : " @sls-next/serverless-component@{version_here} "
myTable :
component : serverless/aws-dynamodb
inputs :
name : Customers
# other componentsNo
# serverless.yml
provider :
name : aws
runtime : nodejs10.x
region : eu-west-1
myNextApp :
component : " @sls-next/serverless-component@{version_here} "
Resources : ... Tenga en cuenta cómo el YAML correcto no declara un provider , Resources , etc.
Para la implementación, no ejecute serverless deploy . Simplemente ejecute serverless y eso implementa sus componentes declarados en el archivo serverless.yml .
Para obtener más información sobre los componentes sin servidor, visite aquí.
El controlador API y los paquetes de controlador predeterminado se implementan por separado, pero cada uno tiene un límite de 50 MB con cremallera o 250 MB sin comprimir por AWS; vea aquí y aquí. Por diseño, actualmente solo hay un Lambda@Edge para todas las rutas de página y un Lambda@Edge para todas las rutas API. Esto podría conducir a problemas de tamaño del código, especialmente si tiene muchas rutas API, páginas SSR, etc.
Si se encuentra con problemas de tamaño del código, intente lo siguiente:
Optimice el tamaño de su código: reduzca las dependencias # en sus páginas SSR y rutas API, tenga menos páginas SSR (es decir, no use getInitialProps() o getServerSideProps() ).
Minifique el código del controlador en sí utilizando la entrada minifyHandlers . Esto reducirá el tamaño del controlador de ~ 500 kb a ~ 200 kb.
Minifique/minimice su código del lado del servidor usando Terser agregando la siguiente configuración de Webpack a su next.config.js . Utiliza la variable de entorno NEXT_MINIMIZE para indicarle que minimice el código SSR. Tenga en cuenta que esto aumentará los tiempos de construcción y minificará el código para que pueda ser más difícil depurar errores de CloudWatch.
Primero, agregue terser-webpack-plugin a sus dependencias. Luego actualice 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 ;
} ;Tenga en cuenta que si no usa ninguna ruta API, todos los archivos JS utilizados solo para las páginas estáticas previas al paquete se eliminan automáticamente del paquete. Sin embargo, si usa rutas API, no las eliminamos, ya que pueden usarse para el modo de vista previa. No hay una forma oficial/no ruidosa de identificar y eliminar estos archivos JS no utilizados en el modo de vista previa, incluso cuando se utilizan rutas API. Pero podemos agregar una nueva entrada para excluirlos manualmente, si es necesario.
useServerlessTraceTarget en serverless.yml . Esto hará que Next.js no se dependa de las dependencias en cada página (en su lugar, cree páginas livianas) y luego serverless-next.js hará referencia a un solo conjunto de dependencias en node_modules . Es probable que esto sea debido a un problema del tamaño del código Lambda@Edge (ver arriba para obtener soluciones potenciales. Problema de GitHub relacionado) o si tiene una velocidad de carga de red lenta y/o está tratando de implementar un gran paquete Lambda.
En el segundo caso, el paquete aws-sdk NPM utilizado tiene un tiempo de espera predeterminado de 120 segundos. En este momento, esto no es configurable, pero podemos admitir tiempos horarios más largos en el futuro cercano (similar a Serverless/Serverless#937, que solo se aplica al marco sin servidor, no a los componentes sin servidor).
Por defecto, CloudFront establece el encabezado Host al nombre de host S3 Origin. Debe reenviar el encabezado Host al origen. Vea el ejemplo a continuación para reenviarlo para su comportamiento api/* Cache:
myNextApplication :
component : " @sls-next/serverless-component@{version_here} "
inputs :
cloudfront :
api/* :
forward :
headers : [Host] Se alienta a los usuarios a usar este componente en lugar del serverless-plugin . Este componente fue construido y diseñado utilizando lecciones aprendidas del complemento sin servidor.
Consulte examples/dynamodb-crud para una aplicación TODO de ejemplo que interactúe con DynamodB. Puede encontrar una lista completa de ejemplos aquí
Desafortunadamente, debido a la forma en que funciona los componentes sin servidor (al menos la versión beta), el estado de implementación debe sincronizarse fuera del comando principal serverless . Entonces puede probar las siguientes soluciones:
.serverless . Aunque esto no se recomienda, ya que no funciona bien para múltiples etapas..serverless , ver un ejemplo aquí, aquí (utiliza múltiples archivos serverless.yml ), o aquí (basado en GitHub Actions, usa múltiples archivos serverless.yml ).distributionId CloudFront para especificar una distribución de CloudFront existente para implementar.En el futuro, buscaremos mejorar esto integrando la gestión de la etapa adecuada en el componente mismo.
Este proyecto fue iniciado por el autor original cuando los componentes sin servidor estaban en beta, y desafortunadamente GA Components se lanzó poco después. Pero esto se hizo cada vez más grande, con varios subcomponentes importados a este monoreso, ya que no los mantuvieron sin servidor. Y luego se hizo difícil actualizar.
Había un plan para actualizar a los componentes de GA, pero se suspendió por algunas razones:
Actualmente estamos buscando soluciones IAC adecuadas (como CDK para Terraform, CDK, Pulumi, etc.) para abordar esto y aliviar la carga de mantener la lógica de despliegue compleja, para que podamos centrarnos en la experiencia del desarrollador y la paridad con Next.js.
¡Sí! El bloqueador principal fue que la lógica de enrutamiento Next.js solía estar altamente junto con Lambda@Edge/CloudFront Logic. Sin embargo, hemos generado la mayor parte de la lógica central (en el paquete @sls-next/core ) para que pueda reutilizarse en otras plataformas, simplemente creando un controlador de envoltura, implementando algún cliente específico de plataforma (por ejemplo, para recuperar páginas, activar la regeneración estática, etc.) y creando un implementador. Si era observador, habrá notado un nuevo paquete actualmente en las implementaciones de Lambda a través de API Gateway: https://github.com/serverless-nextjs/serverless-next.js/tree/master/packages/libs/lambda. Con suerte, otras plataformas como Azure y Google Cloud deberían seguir pronto.
us-east-1 . ¿Cómo puedo implementarlo en otra región? Serverless Next.js es sin región . Por diseño, las aplicaciones serverless-next.js se implementarán en todo el mundo en cada ubicación de Cloudfront Edge. La lambda podría parecer que solo se implementa en us-east-1 pero detrás de escena, se replica en cualquier otra región.
Consulte la muestra a continuación para obtener una configuración build avanzada que incluye pasar argumentos adicionales y variables de entorno a la compilación.
# 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} Si intenta concatenar una variable de entorno con otra cadena, como ${env.VARIABLE}-blah , el marco sin servidor parece resolverlo solo ${env.VARIABLE} .
Parece ser un error en los componentes sin servidor: puede deberse a no usar la última versión de GA, donde podría haberse solucionado (esto todavía está en componentes beta, desafortunadamente). Por ahora, la solución es:
serverless.yml primero, luego concatene: stage : ${env.STAGE}
my-app :
component : " @sls-next/[email protected] "
inputs :
domain :
- " ${stage}-front-end "
- mydomain.com Puede usar la nueva entrada domainRedirects , junto con el reenvío de encabezado Host y domainType: both , para redirigir las solicitudes al dominio correcto. Consulte la configuración de ejemplo a continuación que redirige www.example.com solicitudes a 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 Todo esto sucede dentro de los manejadores de solicitud de origen Lambda@Edge. Tenga en cuenta que esto no le permitirá redirigir las solicitudes en _next/static/* o /static/* , ya que esos comportamientos de caché no tienen un controlador Lambda@Edge conectado a ellos.
De lo contrario, también puede usar la solución manual utilizando un cubo S3 descrito aquí. En resumen, deberá crear un nuevo cubo S3 y configurarlo con el alojamiento de sitios web estático para redirigir las solicitudes a su tipo de subdominio compatible (por ejemplo, "www.example.com" o "Ejemplo.com"). Para poder admitir redireccionamientos HTTPS, deberá configurar una distribución de Cloudfront con el cubo de redirección S3 como origen. Finalmente, deberá crear un registro "A" en la Ruta 53 con su distribución CloudFront recientemente creada como el objetivo de alias.
build.env no aparezcan en mi aplicación Para permitir que su aplicación acceda a las variables de entorno definidas, debe exponerlas a través del next.config.js como se describe aquí.
Dado un serverless.yml como este
myApp :
inputs :
build :
env :
API_HOST : " http://example.com "Tu próximo.config.js debería verse así:
module . exports = {
env : {
API_HOST : process . env . API_HOST
}
} ; Puede ver un error como a continuación:
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)
Comúnmente ocurre cuando el tamaño de la respuesta es demasiado grande. Lambda@Edge actualmente tiene una limitación de 1 MB devuelto por el controlador de solicitud de origen. Ver: https://docs.aws.amazon.com/amazoncloudfront/latest/developeguide/lambda-generating-http-respondes-in-requests.html#lambda-generating-http-responses-errores. Desafortunadamente, puede que no haya una solución que no sea tratar de garantizar que sus respuestas sean más pequeñas.
Asegúrese de reenviar el encabezado Accept-Language a través de la configuración de CloudFront, en caso de que no pueda determinar qué lenguajes entiende y/o prefiere. Por defecto, se reenvía, pero si anula con su propia configuración, debe agregarla hacia atrás.
Si está utilizando bibliotecas de terceros (solo next-i18next por ahora) y usa rutas predeterminadas, es posible que algunos archivos deban copiarse en los directorios Lambda. Este componente intentará detectar archivos predeterminados y copiarlos para usted. Sin embargo, si tiene una configuración personalizada, es posible que deba escribir sus propios postBuildCommands para copiar archivos, etc.
Consulte el ReadMe para obtener más información y advertencias.
Puede abrir un nuevo problema aquí. Si publica un problema, siga primero la wiki de depuración para obtener algunos consejos útiles e intente incluir tanta información para reproducir el problema.
Si informa una vulnerabilidad de seguridad, siga la política de seguridad.
Tenga en cuenta que solo hay un mantenedor central en este momento (@dphang) y un puñado de contribuyentes comunitarios, todos contribuyen a esta biblioteca en su tiempo libre. 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]
