serverless next.js
v3.7.0
Une configuration zéro NEXT.js 10/11 Composant sans serveur pour AWS Lambda @ Edge viser la parité complète des fonctionnalités.
Veuillez consulter les fonctionnalités pour une liste des fonctionnalités actuellement prises en charge.
️ Cette lecture reflète les derniers changements sur la branchemaster. Il peut ou non être publié dans lalatestversion (stable) oualphadans NPM. Veuillez accéder aux versions, trouver la version correct@sls-next/serverless-componentque vous utilisez et ouvrez la lecture pour cette version pour des informations plus précises. Si une fonctionnalité est répertoriée dans cette lecture mais ne fonctionne pas, veuillez d'abord essayer de passer à la versionalphala plus récente dans NPM.
Ceci utilise actuellement des composants sans serveur Beta (pas GA version) au début du projet avant GA. Nous retravaillons actuellement la façon dont les déploiements fonctionneront à l'avenir et explorant de meilleures solutions IAC telles que CDK, CDK pour Terraform, etc. et ferons une annonce avant la fin de l'année sur toute mise à jour.
Depuis Next.js 8.0, le mode sans serveur a été introduit qui fournit une nouvelle API de bas niveau que des projets comme celui-ci peuvent utiliser pour se déployer sur différents fournisseurs de cloud. Cependant, Next.js ne fournit pas la logique de routage sans serveur complète, d'où la raison pour laquelle ce projet est nécessaire pour combler l'écart. La vision à long terme est de vous permettre d'auto-héberger avec divers nuages, en commençant par AWS.
Ce projet est une meilleure version du plugin sans serveur qui se concentre sur la résolution des problèmes de base comme la prise en charge des 9 prochains, une meilleure expérience de développement, la limite de ressources et les performances de 200 cloudformations.
Il y a peu ou pas de configuration nécessaire. Vous pouvez étendre les valeurs par défaut en fonction de vos besoins d'application.
Les utilisateurs de ce composant devraient pouvoir utiliser Next.js Development Toolling, alias next dev . Il est du travail du composant de déployer votre demande en garantissant la parité avec toutes les fonctionnalités de Next que nous connaissons et aimons. Nous essayons d'imiter tout ou partie de la logique de routage et côté serveur de Next.js et de l'optimiser pour un environnement sans serveur. Vous trouverez ci-dessous une liste des fonctionnalités actuellement prises en charge.
Avec une architecture simplifiée et aucune utilisation de Cloudformation, il n'y a pas de limites au nombre de pages que vous pouvez avoir dans votre application, ainsi que les temps de déploiement sont très rapides! À l'exception des temps de propagation CloudFront bien sûr.
Puisque nous imitons la logique de routage suivante. Ce qui suit affiche toutes les fonctionnalités prises en charge ou les fonctionnalités planifiées. Si la case à cocher est cochée, cela signifie que la fonctionnalité est prise en charge. Sinon, il n'est probablement pas encore pris en charge ou actuellement en phase de planification ou de mise en œuvre. Veuillez vous référer à la description d'un article pour des détails spécifiques.
Notez que certaines fonctionnalités ne peuvent être que sur la dernière version alpha. Si une fonctionnalité est répertoriée comme prise en charge mais ne fonctionne pas sur la latest balise, c'est probablement dans la balise alpha . Si vous le pouvez, veuillez nous aider à tester les dernières modifications alpha et à soumettre un rapport de bogue si vous trouvez des problèmes. Merci!
Y a-t-il une fonctionnalité que vous voulez mais n'est pas encore prise en charge? Veuillez ouvrir un nouveau numéro pour nous le faire savoir!
/_next/* servi à partir de CloudFront. getStaticProps . getServerSideProps . getStaticPaths . _next/static/* et static/* , car ces comportements de cache n'ont pas de gestionnaires de lambda. Remarque que le nouveau format has (https://nextjs.org/docs/api-reference/next.config.js/redirects#header-cookie-and-oiny-matching) n'est pas encore pris en charge. _next/static/* et static/* , car ces comportements de cache n'ont pas de gestionnaires de lambda. Remarque que le nouveau format has (https://nextjs.org/docs/api-reference/next.config.js/redirects#header-cookie-and-oiny-matching) n'est pas encore pris en charge. _next/static/* et static/* , car ces comportements de cache n'ont pas de gestionnaires de lambda. Remarque que le nouveau format has (https://nextjs.org/docs/api-reference/next.config.js/redirects#header-cookie-and-oiny-matching) n'est pas encore pris en charge. next-i18next . Tout d'abord, assurez-vous que Node.js 12+ soit installé sur la machine de déploiement car tout le code est désormais transpiré vers ES2019. Ajoutez votre prochaine application à 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 vous spécifiez @sls-next/serverless-component dans votre fichier serverless.yml , n'ajoutez pas @sls-next/serverless-component dans votre fichier package.json, il n'est pas utilisé et seule la version dans le fichier serverless.yml est utilisée, ce qui s'approche de NPM sans serveur de NPM par lui-même. Si vous ne spécifiez pas la version, il utilisera la latest balise, qui fait référence à la dernière version stable ici (c'est-à-dire pas des versions alpha).
Vous pouvez également le pointer vers une installation locale, par exemple si vous souhaitez la version à l'aide de package.json .
Dans ce cas, configurez ce qui suit:
# serverless.yml
myNextApplication :
component : " ./node_modules/@sls-next/serverless-component "Définissez ensuite vos informations d'identification AWS en tant que variables d'environnement:
AWS_ACCESS_KEY_ID=accesskey
AWS_SECRET_ACCESS_KEY=sshhhEt simplement déploier:
$ serverlessSi vous avez des problèmes de déploiement en raison d'une nouvelle version sans serveur, veuillez essayer d'épingler une version spécifique, par exemple 2.72.2. Voir # 2320 (commentaire)
[Alpha - Peut être buggy] Vous pouvez également déployer à l'aide de NPX @serverless/cli npx @sls-next/serverless-patched (ou serverless-patched si vous l'avez installé localement), qui est une version correcée de serverless qui résout quelques problèmes en correct Gère silencieuse Next.js Build défaillance.
Il est également recommandé d'ajouter un drapeau --debug pour obtenir des journaux plus utiles de ce qui se passe dans les coulisses.
N'essayez pas de déployer en exécutant serverless deploy , utilisez uniquement serverless
Dans la plupart des cas, vous ne voudriez pas utiliser le domaine de distribution de CloudFront pour accéder à votre application. Au lieu de cela, vous pouvez spécifier un nom de domaine personnalisé.
Vous pouvez utiliser n'importe quel nom de domaine, mais vous devez utiliser AWS Route53 pour votre hébergement DNS. Pour migrer les enregistrements DNS à partir d'un domaine existant, suivez les instructions ici. Les exigences pour utiliser un nom de domaine personnalisé:
mydomain.com ) avec un ensemble de serveurs de noms.Le composant NEXT.JS sans serveur générera automatiquement un certificat SSL et créera un nouvel enregistrement pour pointer de votre distribution 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" Vous pouvez également configurer un subdomain :
# serverless.yml
myNextApplication :
component : " @sls-next/serverless-component@{version_here} "
inputs :
domain : ["sub", "example.com"] # [ sub-domain, domain ] Pour spécifier vos propres entrées CloudFront, ajoutez simplement toutes les entrées AWS-CloudFront sous 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 : val2Ceci est particulièrement utile pour mettre en cache l'une de vos pages suivantes. Voir ceci pour un exemple d'application avec une configuration de cache personnalisée. Vous pouvez également mettre à jour une distribution CloudFront existante à l'aide des entrées CloudFront personnalisées.
Les pages rendues statiquement (c.-à-d. Les pages HTML qui sont téléchargées sur S3) ont l'ensemble de contrôle de cache suivant:
cache-control: public, max-age=0, s-maxage=2678400, must-revalidate
s-maxage permet à CloudFront de mettre en cache les pages aux emplacements des bords pendant 31 jours. max-age=0 en combinaison avec must-revalidate Assurez-vous que les navigateurs ne mettent jamais en cache les pages statiques. Cela permet à CloudFront de contrôler le total de la mise en cache TTLS. À chaque déploiement, une invalidation /* est créée pour garantir que les utilisateurs obtiennent un nouveau contenu.
Par défaut, les formats d'image communs ( gif|jpe?g|jp2|tiff|png|webp|bmp|svg|ico ) Under /public Or /static les dossiers ont une politique Cache-Control d'un an appliquée ( public, max-age=31536000, must-revalidate ). Vous pouvez personnaliser la value d'en-tête Cache-Control et le regex des fichiers à test , avec 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 doit être une stratégie Cache-Control valide et test doit être un regex valide des types de fichiers que vous souhaitez tester. Si vous ne voulez pas que les navigateurs mettent en cache les actifs du répertoire public, vous pouvez désactiver ceci:
myNextApplication :
component : " @sls-next/serverless-component@{version_here} "
inputs :
publicDirectoryCache : falsePar défaut, les fonctions Lambda @ Edge s'exécutent à l'aide d'AwslambdabasiceXecutionRole qui permet uniquement de télécharger des journaux vers CloudWatch. Si vous avez besoin d'autorisations au-delà de cela, comme par exemple l'accès à DynamoDB ou à toute autre ressource AWS, vous aurez besoin de votre propre politique ou rôle personnalisé 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 "Assurez-vous d'ajouter des autorisations de journal CloudWatch à votre stratégie ou rôle personnalisé. Exemple de JSON de politique minimale:
{
"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 " ]
}
]
} Le rôle devrait inclure la relation de confiance avec lambda.amazonaws.com et edgelambda.amazonaws.com .
Remarque : Spécifiez bucketName et donnez des autorisations pour accéder à ce seau via policy ou roleArn afin que les lambdas par défaut et API puissent accéder aux ressources statiques.
La liste exhaustive des actions AWS requises pour un déploiement:
"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"
La par défaut , l'API et l'image (pour Next.js Optimization d'image) Lambdas se verront attribuer 512 Mo de mémoire par défaut. Cette valeur peut être modifiée en attribuant un nombre à l'entrée memory
# serverless.yml
myNextApplication :
component : " @sls-next/serverless-component@{version_here} "
inputs :
memory : 1024 Les valeurs pour les lambdas par défaut , API et Image peuvent être définies séparément en attribuant memory à un objet comme tel:
# serverless.yml
myNextApplication :
component : " @sls-next/serverless-component@{version_here} "
inputs :
memory :
defaultLambda : 1024
apiLambda : 2048
imageLambda : 2048Le même motif peut être suivi pour spécifier l'exécution Node.js (Nodejs14.x par défaut):
# 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 runtimesDe même, le délai d'expiration par défaut est de 10 secondes. Pour personnaliser, vous pouvez:
# serverless.yml
myNextApplication :
component : " @sls-next/serverless-component@{version_here} "
inputs :
timeout :
defaultLambda : 20
apiLambda : 15
imageLambda : 15Remarque Le délai maximum autorisé pour Lambda @ Edge est de 30 secondes. Voir https://docs.aws.amazon.com/amazoncloudfront/latest/developerguide/lambda-requiments-limits.html
Vous pouvez également définir un nom personnalisé pour les Lambdas par défaut , API et IMAGE - Si ce n'est que la valeur par défaut est définie par le composant AWS-Lambda Serverless sur l'ID de ressource:
# serverless.yml
myNextApplication :
component : " @sls-next/serverless-component@{version_here} "
inputs :
name :
defaultLambda : fooDefaultLambda
apiLambda : fooApiLambda
imageLambda : fooImageLambdaIl y a une quatrième régénération Lambda, qui peut être configurée de manière similaire et est utilisée pour une régénération statique incrémentielle. Cependant, il n'utilise pas Lamda @ Edge et peut, par exemple, avoir un paramètre de délai d'attente plus long.
Quatre comportements de cache sont créés dans CloudFront.
Les deux premiers _next/* et static/* transmettent les demandes à S3.
Le troisième est associé à une fonction lambda qui est responsable de la gestion de trois types de demandes.
Page côté serveur rendu. Toute page qui définit la méthode getInitialProps sera rendue à ce niveau et la réponse est renvoyée immédiatement à l'utilisateur.
Page statiquement optimisée. Les demandes aux pages qui ont été précompilées par Next to HTML sont transmises à S3.
Ressources publiques. Demandes de ressources de niveau de racine comme /robots.txt , /favicon.ico , /manifest.json , etc. Celles-ci sont transmises à S3.
La raison pour laquelle 2. Et 3. Je dois passer par Lambda @ Edge en premier est parce que les itinéraires ne sont pas conformes à un modèle comme _next/* ou static/* . De plus, un comportement de cache par route est une mauvaise idée car CloudFront ne permet que 25 par distribution.
Le quatrième comportement de cache gère la prochaine API demande api/* .
| Nom | Taper | Valeur par défaut | Description |
|---|---|---|---|
| déployer | boolean | true | Lorsqu'il est défini sur False, il ne déploiera pas l'application au fournisseur (par exemple AWS). |
| domaine | Array | null | Par exemple ['admin', 'portal.com'] |
| domaineRedirects | object | {} | Ajoute des redirectes au niveau du domaine au bord à l'aide d'une redirection 308. Spécifiez un objet de nom de domaine -> Redirection de la destination avec protocole. Par exemple, www.example.com: https://example.com . Voir ici pour plus d'informations. |
| nom de godet | string | null | Nom de godet personnalisé où les actifs statiques sont stockés. Par défaut est autoogénéré. |
| seau | string | null | Région où vous souhaitez héberger votre seau S3. Assurez-vous que cela est géographiquement plus proche de la majorité de vos utilisateurs finaux pour réduire la latence lorsque CloudFront indique une demande à S3. |
| buckettags | object | undefined | Étiquettes de godet personnalisées à définir pour votre seau. Si non défini, le composant ne mettra pas à jour les balises. S'il est défini sur un objet vide, il supprimera toutes les balises. |
| NextConfigdir | string | ./ | Répertoire où est votre application next.config.js le fichier. Cette entrée est utile lorsque le serverless.yml n'est pas dans le même répertoire que l'application suivante.Remarque: nextConfigDir doit être défini si next.config.js distDir est utilisé |
| Nextstaticdir | string | ./ | Si votre annuaire static ou public n'est pas un enfant direct de nextConfigDir , cela est nécessaire |
| description | string | *lambda-type*@Edge for Next CloudFront distribution | La description qui sera utilisée pour les deux lambdas. Notez que "(API)" sera annexé à la description de l'API Lambda. |
| politique | string|object | arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole | La politique ARN ou en ligne qui sera affectée aux deux lambdas. |
| rolearn | string|object | nul | L'ARN du rôle qui sera affecté aux deux lambdas. |
| temps d'exécution | string|object | nodejs14.x | Lorsqu'il est attribué une valeur, les Lambdas par défaut et API se verront attribuer le temps d'exécution défini dans la valeur. Lorsqu'il est affecté à un objet, les valeurs pour les lambdas par défaut et API peuvent être définies séparément |
| mémoire | number|object | 512 | Lorsqu'il est affecté à un nombre, les Lambdas par défaut et API se verront attribuer la mémoire de cette valeur. Lorsqu'il est affecté à un objet, les valeurs pour les lambdas par défaut et API peuvent être définies séparément |
| balises | object | undefined | Tags à affecter à un lambda. Si non défini, le composant ne mettra pas à jour les balises. S'il est défini sur un objet vide, il supprimera toutes les balises. |
| temps mort | number|object | 10 | Identique à ci-dessus |
| maître | string | index.handler | Lorsqu'il est attribué une valeur, remplace le gestionnaire de fonction par défaut pour permettre la configuration. Copies handler.js en route vers les dossiers lambda. Votre gestionnaire doit toujours appeler le default-handler par la suite ou votre fonction ne fonctionnera pas avec Next.js |
| nom | object | / / | Les noms de tous les lambdas peuvent être explicitement définis |
| construire | boolean|object | true | Lorsque True Builds et déploie l'application, lorsque FAUX supposait que l'application a été construite et utilise les répertoires .next .serverless_nextjs dans nextConfigDir à déployer. Si un objet est passé, build permet de remplacer quel script est appelé et avec quels arguments. |
| build.cmd | string | node_modules/.bin/next | Build Command, vous pouvez passer une commande sans opération (par exemple, true ou : dans les systèmes basés sur Unix) qui sauteront ensuite la construction suivante.js |
| build.args | Array|string | ['build'] | Arguments à passer à la construction |
| build.cwd | string | ./ | Remplacer le répertoire de travail actuel |
| build.aged | boolean | true | Identique à build:false mais à l'intérieur de la configuration |
| build.env | object | {} | Ajouter des variables d'environnement supplémentaires au script |
| build.PostBuildCommands | Array | [] | Toutes les commandes pour exécuter après la construction et le pré-déploiement. Par exemple, vous pouvez exécuter n'importe quel code personnalisé sur le répertoire .serverless_nextjs , par exemple, vous pouvez copier des fichiers supplémentaires dans le lambda: voir # 767 (commentaire) pour un exemple pour next-18n . Ne s'applique que lors de l'exécution de la commande serverless . |
| build.cleanupdotnext | boolean | true | Si vous devez nettoyer .next répertoire avant d'exécuter l'étape de construction |
| build.Assentignorepatterns | string[] | [] | Modèles globaux à ignorer lors de la découverte de fichiers à copier à partir des répertoires _Next / statique, publics et statiques. |
| build.usev2handler | boolean | false | Expérimental Définissez ceci sur True pour utiliser des gestionnaires V2 qui commencent à utiliser des gestionnaires génériques. Remarque: Cela a les fonctionnalités de separateApiLambda et disableOriginResponseHandler , il ne doit donc pas être utilisé ensemble. De plus, il n'est pas encore complètement optimisé en termes de taille de code, mais doit toujours être performant. À l'avenir, nous utiliserons probablement ce mode par défaut. |
| nuage | object | {} | Entrées à transmettre à AWS-Cloudfront |
| certificat | string | `` | Certificat spécifique ARN à utiliser pour la distribution CloudFront. Utile si vous avez un certificat SSL générique que vous souhaitez utiliser. Cela ne fonctionne actuellement qu'en tandem avec l'entrée domain . Veuillez vérifier la configuration CloudFront personnalisée pour spécifier certificate sans avoir besoin d'utiliser l'entrée domain (notez que cela remplacera tout certificat en raison de l'entrée de domaine). |
| type de domaine | string | "both" | Peut être l'un des: "apex" - Domaine Apex uniquement, ne créez pas un sous-domaine www. "www" - Domaine www uniquement, ne créez pas un sous-domaine Apex. "both" - créent des domaines www et APEX lorsque l'un ou l'autre est fourni. |
| domainemimumprotocolversion | string | "TLSv1.2_2018" | Peut être l'un des: "SSLv3", "TLSv1", "TLSv1.1_2016", "TLSv1.2_2018", "TLSv1.2_2019", "TLSv1.2_2021" or "TLSv1_2016" . Voir référence. |
| publicDirectoryCache | boolean|object | true | Personnalisez la politique de mise en cache des actifs de dossier public / static . L'attribution d'un objet avec value et / ou test vous permet de personnaliser la stratégie de mise en cache et les types de fichiers mis en cache. Attribuer de fausses désactifs en cache |
| useserverlesstracetarget | boolean | false | Utilisez la cible expérimentale-serveur sans trace pour créer votre prochaine application. Il s'agit de la même cible de construction que Vercel utilise désormais. Voir cette RFC pour plus de détails. Remarque: En utilisant cela, vous devrez peut-être définir la variable NODE_ENV dans production . |
| MinifyHandlers | boolean | false | Utilisez des gestionnaires minifiés prédéfinis pour réduire la taille du code. N'immerifie pas les gestionnaires personnalisés. |
| activerhttpcompression | boolean | false | Lorsqu'il est défini sur true les fonctions Lambda @ Edge pour les demandes SSR et API utiliseront GZIP pour comprimer la réponse. Notez que vous ne devriez pas avoir besoin d'activer cela, car CloudFront compressera les réponses pour vous hors de la boîte. |
| authentification | object | undefined | Objet d'authentification à utiliser avec l'authentification de base (disponible à partir de 1.19.0-alpha.3). Il ne prend en charge qu'une seule combinaison de nom d'utilisateur / mot de passe pour l'instant et est incliné en texte en clair dans le gestionnaire de lambda. Vous devez également transmettre l'en-tête Authorization pour les comportements CloudFront, par exemple defaults , api/* et _next/data/_ . Remarque: Ceci est destiné à un moyen simple de protéger un environnement tel qu'un site de développement / test, il n'est pas recommandé pour l'utilisation de la production. |
| authentification.Username | string | undefined | Nom d'utilisateur pour l'authentification de base. |
| Active3ACCELERATION | boolean | true | S'il faut permettre l'accélération de transfert S3. Cela peut être utile pour désactiver car certaines régions AWS ne le soutiennent pas. Voir référence. |
| Supprimer lesAmbdaversions | boolean | false | Support de base pour supprimer les anciennes versions Lambda après le déploiement pour assurer. Si vous êtes réglé sur true, chaque fois que vous déploiez, il supprime automatiquement jusqu'à ~ 50 anciennes versions (à partir de la plus ancienne) de toutes les lambdas qui ne sont pas déployées / reproduites. Si vous avez besoin de stratégies plus complexes, il est recommandé d'écrire votre propre script pour supprimer les anciennes versions. |
Les entrées personnalisées peuvent être configurées comme ceci:
myNextApp :
component : " @sls-next/serverless-component@{version_here} "
inputs :
bucketName : my-bucket(Expérimental) - Plus de travail requis pour mettre cette construction à la vitesse et également pour réutiliser une partie de la logique sans serveur. En conséquence, la construction est susceptible de s'adapter / changer en conséquence.
La documentation peut être trouvée ici.
Comme nous émulons la logique de routage suivante. Cependant, nous pensons que nous avons couvert la majorité des fonctionnalités et avons ajouté une bonne couverture de test d'unité et de bout en bout pour assurer la stabilité (par exemple dans plus de 10 suites de test de bout en bout). Plusieurs personnes l'utilisent pour alimenter leur startup, les sites Web personnels, etc.
Les limitations du fournisseur de cloud s'appliquent également - par exemple sur AWS Lambda @ Edge, il y a des départs à froid, des limites de taille de code, 1 Mo Limite de taille de réponse, etc. pour n'en nommer que quelques-uns. Vous êtes bien sûr également lié à une seule plate-forme pour l'instant (aws lambda @ edge; plus à venir bientôt!).
Nous continuons également d'améliorer le processus de déploiement en considérant de meilleures solutions d'infrastructure en tant que code dans un avenir proche (CDK, CDK Terraform, Pulumi, etc.).
Assurez-vous que votre serverless.yml utilise le format serverless-components (BETA). Les composants sans serveur diffèrent du framework d'origine sans serveur, même s'ils sont tous deux accessibles via la même CLI.
✅ faire
# serverless.yml
myNextApp :
component : " @sls-next/serverless-component@{version_here} "
myTable :
component : serverless/aws-dynamodb
inputs :
name : Customers
# other componentsNe le faites pas
# serverless.yml
provider :
name : aws
runtime : nodejs10.x
region : eu-west-1
myNextApp :
component : " @sls-next/serverless-component@{version_here} "
Resources : ... Notez comment le bon YAML ne déclare pas un provider , Resources , etc.
Pour le déploiement, n'exécutez pas serverless deploy . Exécutez simplement serverless et qui déploie vos composants déclarés dans le fichier serverless.yml .
Pour plus d'informations sur les composants sans serveur, allez ici.
Le gestionnaire API et les packages de gestionnaire par défaut sont déployés séparément, mais chacun a une limite de 50 Mo zippé ou 250 Mo non compressé par AWS - voir ici et ici. Par conception, il n'y a actuellement qu'une seule Lambda @ Edge pour tous les itinéraires de page et un Lambda @ Edge pour tous les itinéraires API. Cela pourrait entraîner des problèmes de taille de code, surtout si vous avez de nombreuses routes API, pages SSR, etc.
Si vous rencontrez des problèmes de taille de code, veuillez essayer ce qui suit:
Optimisez la taille de votre code: réduisez # les dépendances dans vos pages SSR et vos itinéraires API, ont moins de pages SSR (c'est-à-dire n'utilisez pas getInitialProps() ou getServerSideProps() ).
Minify le code de gestionnaire lui-même en utilisant l'entrée minifyHandlers . Cela réduira la taille du gestionnaire de ~ 500 Ko à ~ 200 Ko.
Minify / Minimiser votre code côté serveur à l'aide de TERSER en ajoutant la configuration Webpack suivante à votre next.config.js . Il utilise la variable d'environnement NEXT_MINIMIZE pour lui dire pour minimiser le code SSR. Notez que cela augmentera les temps de construction et minivera le code afin qu'il puisse être plus difficile de déboguer les erreurs de cloudwatch.
Tout d'abord, ajoutez terser-webpack-plugin à vos dépendances. Puis mettez à jour 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 ;
} ;Notez que si vous n'utilisez aucun itinéraire API, tous les fichiers JS utilisés uniquement pour la prétention des pages statiques sont automatiquement supprimés du bundle. Cependant, si vous utilisez des itinéraires API, nous ne les supprimons pas car ils peuvent être utilisés pour le mode d'aperçu. Il n'y a aucun moyen officiel / non hacky d'identifier et de supprimer ces fichiers JS non utilisés en mode prévisualisation même lorsque les routes API sont utilisées. Mais nous pouvons ajouter une nouvelle entrée pour les exclure manuellement, si nécessaire.
useServerlessTraceTarget dans serverless.yml . Cela entraînera Next.js à ne pas regrouper les dépendances dans chaque page (créant plutôt des pages légères), puis serverless-next.js référencera un seul ensemble de dépendances dans node_modules . Ceci est probablement à cause d'un problème de taille de code Lambda @ Edge (voir ci-dessus pour les solutions potentielles. Problème de github associé) ou si vous avez une vitesse de téléchargement de réseau lente et / ou essayez de déployer un grand package Lambda.
Dans le deuxième cas, le package NPM aws-sdk utilisé a un délai d'expiration par défaut de 120 secondes. À l'heure actuelle, ce n'est pas configurable, mais nous pouvons prendre en charge les délais d'attente plus longs dans un avenir proche (similaire à Serverless / Serverless # 937, qui ne s'applique qu'à un framework sans serveur, pas à des composants sans serveur).
Par défaut, CloudFront définit l'en-tête Host sur le nom d'hôte S3 Origin. Vous devez transmettre l'en-tête Host jusqu'à l'origine. Voir l'exemple ci-dessous pour le transmettre pour votre comportement api/* CACHE:
myNextApplication :
component : " @sls-next/serverless-component@{version_here} "
inputs :
cloudfront :
api/* :
forward :
headers : [Host] Les utilisateurs sont encouragés à utiliser ce composant au lieu du serverless-plugin . Ce composant a été construit et conçu en utilisant les leçons apprises du plugin sans serveur.
Voir examples/dynamodb-crud pour un exemple d'application TODO qui interagit avec DynamoDB. Vous pouvez trouver une liste complète des exemples ici
Malheureusement, en raison de la façon dont les composants sans serveur fonctionnent (au moins la version bêta), l'état de déploiement doit être synchronisé en dehors de la commande principale serverless . Afin que vous puissiez essayer les solutions suivantes:
.serverless . Bien que cela ne soit pas recommandé car cela ne fonctionne pas bien pour plusieurs étapes..serverless , voir un exemple ici, ici (utilise plusieurs fichiers serverless.yml ), ou ici (GitHub Actions, basé sur plusieurs fichiers serverless.yml ).distributionId CloudFront pour spécifier une distribution CloudFront existante à déployer vers.À l'avenir, nous chercherons à améliorer cela en intégrant une gestion appropriée de scène dans le composant lui-même.
Ce projet a été lancé par l'auteur d'origine lorsque Serverless Components était en version bêta, et malheureusement GA Components a été publié peu de temps après. Mais cela est devenu de plus en plus grand, plusieurs sous-composants importés dans ce monorepo car ils n'ont pas été maintenus par Serverless. Et puis il est devenu difficile de mettre à niveau.
Il y avait un plan pour passer aux composants GA, mais il a été suspendu pour plusieurs raisons:
Nous examinons actuellement des solutions IAC appropriées (telles que CDK pour Terraform, CDK, Pulumi, etc.) pour y remédier et pour faciliter la charge du maintien de la logique de déploiement complexe, afin que nous puissions nous concentrer sur l'expérience du développeur et la parité de fonctionnalités avec Next.js.
Oui! Le bloqueur principal était que la logique de routage suivante était très associée à la logique Lambda @ Edge / CloudFront. Cependant, nous avons générique la majeure partie de la logique principale (dans le package @sls-next/core ) afin qu'il puisse être réutilisé sur d'autres plates-formes, simplement en créant un gestionnaire d'emballage, en mettant en œuvre un client spécifique à la plate-forme (par exemple pour récupérer des pages, déclencher une régénération statique, etc.) et créer un déploiement. Si vous étiez attentif, vous avez remarqué un nouveau package actuellement en cours pour les déploiements Lambda via API Gateway: https://github.com/serverless-nextjs/serverless-next.js/tree/master/packages/libs/lambda. Les autres plateformes comme Azure et Google Cloud devraient, espérons-le, suivre bientôt.
us-east-1 . Comment puis-je le déployer dans une autre région? Serverless Next.js est sans région . Par conception, serverless-next.js Applications sera déployée à travers le monde à chaque emplacement Edge CloudFront. La Lambda pourrait sembler être déployée uniquement dans us-east-1 mais dans les coulisses, elle est reproduite dans toutes les autres région.
Voir l'échantillon ci-dessous pour une configuration build avancée qui comprend le passage des arguments supplémentaires et des variables d'environnement à la construction.
# 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 vous essayez de concaténer une variable d'environnement avec une autre chaîne, comme ${env.VARIABLE}-blah , le framework sans serveur semble le résoudre à ${env.VARIABLE} .
Il semble que ce soit un bogue dans les composants sans serveur - il peut être dû à ne pas utiliser la dernière version GA, où elle pourrait avoir été corrigée (c'est toujours sur les composants bêta, malheureusement). Pour l'instant, la solution de contournement est:
serverless.yml , puis concatenate: stage : ${env.STAGE}
my-app :
component : " @sls-next/[email protected] "
inputs :
domain :
- " ${stage}-front-end "
- mydomain.com Vous pouvez utiliser la nouvelle entrée domainRedirects , ainsi que le transfert de l'en-tête Host et domainType: both , pour rediriger les demandes vers le domaine correct. Voir l'exemple de configuration ci-dessous qui redirige les demandes www.example.com vers 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 Tout cela se produit dans les gestionnaires de demande d'origine Lambda @ Edge. Veuillez noter que cela ne vous permettra pas de rediriger les demandes sur _next/static/* ou /static/* , car ces comportements de cache n'ont pas de gestionnaire lambda @ edge qui s'y attache.
Sinon, vous pouvez également utiliser la solution de contournement manuelle à l'aide d'un seau S3 décrit ici. En résumé, vous devrez créer un nouveau seau S3 et le configurer avec un site Web statique pour rediriger les demandes vers votre type de sous-domaine pris en charge (ex. "Www.example.com" ou "example.com"). Pour pouvoir prendre en charge les redirections HTTPS, vous devrez configurer une distribution CloudFront avec le seau de redirection S3 comme origine. Enfin, vous devrez créer un enregistrement "A" dans la route 53 avec votre distribution CloudFront nouvellement créée comme cible d'alias.
build.env ne s'affichent pas dans mon application Pour permettre à votre application d'accéder aux variables d'environnement définies, vous devez les exposer via le next.config.js comme indiqué ici.
Étant donné un serverless.yml comme celui-ci
myApp :
inputs :
build :
env :
API_HOST : " http://example.com "Votre prochain.config.js devrait ressembler à ça:
module . exports = {
env : {
API_HOST : process . env . API_HOST
}
} ; Vous pouvez voir une erreur comme ci-dessous:
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)
Il se produit généralement lorsque la taille de la réponse est trop grande. Lambda @ Edge a actuellement une limitation de 1 Mo renvoyée par le gestionnaire de demande d'origine. Voir: https://docs.aws.amazon.com/amazoncloudfront/latest/developerguide/lambda-generating-http-responses-in-requests.html#lambda-generating-http-resesponsses-errors. Malheureusement, il n'y a peut-être pas de contournement autre que d'essayer de s'assurer que vos réponses sont plus petites.
Assurez-vous de transférer l'en-tête d' Accept-Language via la configuration CloudFront, il n'est pas en mesure de déterminer les langages que l'utilisateur comprend et / ou préfère. Par défaut, il est transmis, mais si vous remplacez votre propre configuration, vous devez l'ajouter.
Si vous utilisez des bibliothèques tierces (seulement next-i18next pour l'instant) et utilisez des chemins par défaut, certains fichiers peuvent devoir être copiés dans les répertoires Lambda. Ce composant essaiera de détecter les fichiers par défaut et de les copier pour vous. Cependant, si vous avez une configuration personnalisée, vous devrez peut-être rédiger vos propres postBuildCommands pour copier des fichiers, etc.
Reportez-vous à la lecture pour plus d'informations et de mises en garde.
Vous pouvez ouvrir un nouveau numéro ici. Si vous publiez un problème, veuillez d'abord suivre le wiki de débogage pour quelques conseils utiles et essayer d'inclure autant d'informations pour reproduire le problème.
Si vous signalez une vulnérabilité de sécurité, veuillez suivre la politique de sécurité à la place.
Veuillez noter qu'il n'y a qu'un seul mainteneur de base en ce moment (@DPhang) et une poignée de contributeurs communautaires, qui contribuent tous à cette bibliothèque pendant leur temps 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. [Contribuer].
Made with contributors-img.
Become a financial contributor and help us sustain our community. [Contribuer]
Support this project with your organization. Your logo will show up here with a link to your website. [Contribuer]
