serverless next.js
v3.7.0
Eine null Konfiguration Next.js 10/11 Serverlose Komponente für AWS lambda@Edge, die auf eine vollständige Funktionsparität abzielen.
Bitte überprüfen Sie die Funktionen für eine Liste der derzeit unterstützten Funktionen.
Euen Diese Readme spiegelt die neuesten Änderungen immaster-Zweig wider. Es kann noch nicht zurlatest(stabilen) oderalpha-Version in NPM veröffentlicht werden. Bitte gehen Sie zu Releases, finden Sie die korrekte@sls-next/serverless-component, die Sie verwenden, und öffnen Sie die ReadMe für diese Version, um genauere Informationen zu erhalten. Wenn in diesem Readme eine Funktion aufgeführt ist, aber nicht funktioniert, versuchen Sie es mit dem Upgrade auf die neuestealpha-Version in NPM.
Dies verwendet derzeit Serverless -Komponenten Beta (nicht GA -Version), da das Projekt vor GA gestartet wurde. Derzeit überarbeiten wir, wie Bereitstellungen in Zukunft funktionieren und bessere IAC -Lösungen wie CDK, CDK für Terraform usw. erforschen und vor Ende des Jahres eine Ankündigung für Updates machen werden.
Seit dem nächsten.js 8.0 wurde der Serverless -Modus eingeführt, der eine neue API auf niedriger Ebene bietet, mit der Projekte wie diese auf verschiedenen Cloud -Anbietern bereitgestellt werden können. Next.js liefert jedoch nicht die vollständige serverlose Routing -Logik, weshalb dieses Projekt erforderlich ist, um die Lücke zu schließen. Die langfristige Vision ist es, sich mit verschiedenen Wolken zu veranstalten, beginnend mit AWS.
Dieses Projekt ist eine bessere Version des serverlosen Plugins, das sich auf die Behandlung von Kernproblemen wie den nächsten 9 -Support, die bessere Entwicklungserfahrung, die 200 CloudFormation Resource Limit und die Leistung von 200 CloudFormation konzentriert.
Es ist wenig bis gar keine Konfiguration erforderlich. Sie können Standardeinstellungen basierend auf Ihren Anwendungsanforderungen erweitern.
Benutzer dieser Komponente sollten in der Lage sein, Next.js Development Tooling zu verwenden, auch bekannt als next dev . Es ist die Aufgabe der Komponente, Ihre Anwendung bereitzustellen, um die Parität mit allen Funktionen von Next zu gewährleisten, die wir kennen und lieben. Wir versuchen, alle oder den größten Teil der Routing- und Server-Seiten-Logik von Next.js zu emulieren und für eine serverlose Umgebung zu optimieren. Im Folgenden finden Sie eine Liste der Funktionen, die derzeit unterstützt werden.
Mit einer vereinfachten Architektur und ohne Verwendung von CloudFormation gibt es keine Grenzen für die Anzahl der Seiten, die Sie in Ihrer Anwendung haben können, und die Bereitstellungszeiten sind sehr schnell! Mit Ausnahme der Cloudfront -Ausbreitungszeiten natürlich.
Da wir die nächste Routing -Logik emulieren, sind wir leider nicht immer die volle Parität. Im Folgenden werden alle unterstützten Funktionen oder geplanten Funktionen angezeigt. Wenn das Kontrollkästchen angekreuzt ist, bedeutet dies, dass die Funktion unterstützt wird. Andernfalls wird es wahrscheinlich noch nicht oder derzeit in der Planungs- oder Implementierungsphase unterstützt. Weitere Informationen finden Sie in der Beschreibung eines Artikels.
Beachten Sie, dass einige Funktionen möglicherweise nur in der neuesten Alpha -Version enthalten sein. Wenn eine Funktion als unterstützt aufgeführt ist, aber nicht auf dem latest Tag funktioniert, ist es höchstwahrscheinlich im alpha -Tag. Wenn Sie können, helfen Sie uns bitte, die neuesten Alpha -Änderungen zu testen und einen Fehlerbericht einzureichen, wenn Sie Probleme finden. Danke schön!
Gibt es eine Funktion, die Sie möchten, die Sie aber noch nicht unterstützt haben? Bitte eröffnen Sie ein neues Problem, um uns mitzuteilen!
/_next/* Serviert von Cloudfront. getStaticProps . getServerSideProps . getStaticPaths . _next/static/* und static/* umzuleiten, da diese Cache -Verhaltensweisen keine Lambda -Handler mit sich haben. Beachten Sie, dass das neue has Format (https://nextjs.org/docs/api-reference/next.config.js/redirects#header-cookie-and-query-matching) noch nicht unterstützt wird. _next/static/* und static/* umzuschreiben, da diese Cache -Verhaltensweisen keine Lambda -Handler mit sich haben. Beachten Sie, dass das neue has Format (https://nextjs.org/docs/api-reference/next.config.js/redirects#header-cookie-and-query-matching) noch nicht unterstützt wird. _next/static/* und static/* zu haben, da diese Cache -Verhaltensweisen nicht an Lambda -Handlern angebracht sind. Beachten Sie, dass das neue has Format (https://nextjs.org/docs/api-reference/next.config.js/redirects#header-cookie-and-query-matching) noch nicht unterstützt wird. next-i18next -Paket verwenden. Stellen Sie zunächst sicher, dass Sie über Node.js 12+ auf dem Bereitstellungsgerät installiert sind, da der gesamte Code jetzt auf ES2019 umgesetzt wird. Fügen Sie Ihre nächste Anwendung zum serverless.yml hinzu:
# serverless.yml
myNextApplication :
component : " @sls-next/serverless-component@{version_here} " # it is recommended you pin the latest stable version of serverless-next.js Wenn Sie @sls-next/serverless-component in Ihrer serverless.yml Datei angeben, fügen Sie Ihrer Datei package.json nicht @sls-next/serverless-component hinzu, sie wird nicht verwendet, und nur die Version in serverless.yml Datei wird verwendet, die serverless von NPM von selbst von NPM abzieht. Wenn Sie die Version nicht angeben, wird das latest Tag verwendet, das sich auf die neueste stabile Version hier bezieht (dh keine Alpha -Versionen).
Sie können es auch auf eine lokale Installation verweisen, beispielsweise wenn Sie mit package.json Version versionieren möchten.
Konfigurieren Sie in diesem Fall Folgendes:
# serverless.yml
myNextApplication :
component : " ./node_modules/@sls-next/serverless-component "Stellen Sie dann Ihre AWS -Anmeldeinformationen als Umgebungsvariablen fest:
AWS_ACCESS_KEY_ID=accesskey
AWS_SECRET_ACCESS_KEY=sshhhUnd einfach einsetzen:
$ serverlessWenn Sie Probleme mit der Bereitstellung von Problemen aufgrund einer neuen serverlosen Version haben, versuchen Sie bitte, sich an eine bestimmte Version zu erhalten, z. B. 2.72.2. Siehe #2320 (Kommentar)
[Alpha-Möglicherweise ist Sie möglicherweise auch mit npx @sls-next/serverless-patched (oder serverless-patched , wenn Sie es lokal installiert haben). Dies ist eine gepatchte Version von serverless , die einige Probleme behebt, indem die zugrunde liegenden @serverless/cli : 1) kontinuierlichen "kontinuierlichen" Bereitstellungen "Making" -Antiefing gedruckt werden. Stille Next.js bauen Misserfolge auf.
Es wird auch empfohlen, die Flagge --debug , um mehr nützliche Protokolle darüber zu erhalten, was hinter den Kulissen passiert.
Versuchen Sie nicht, durch das Ausführen serverless deploy bereitzustellen. Verwenden Sie nur serverless
In den meisten Fällen möchten Sie die Verteilungsdomäne von CloudFront nicht verwenden, um auf Ihre Anwendung zuzugreifen. Stattdessen können Sie einen benutzerdefinierten Domänennamen angeben.
Sie können jeden Domänennamen verwenden, müssen jedoch AWS -Route53 für Ihr DNS -Hosting verwenden. Um DNS -Aufzeichnungen aus einer vorhandenen Domäne zu migrieren, folgen Sie den Anweisungen hier. Die Anforderungen für die Verwendung eines benutzerdefinierten Domainnamens:
mydomain.com ) mit einer Reihe von Namenserver enthalten.Die serverlose Next.js -Komponente generiert automatisch ein SSL -Zertifikat und erstellt einen neuen Datensatz, der auf Ihre CloudFront -Verteilung verweist.
# 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" Sie können auch eine subdomain konfigurieren:
# serverless.yml
myNextApplication :
component : " @sls-next/serverless-component@{version_here} "
inputs :
domain : ["sub", "example.com"] # [ sub-domain, domain ] Um Ihre eigenen CloudFront-Eingänge anzugeben, fügen Sie einfach alle AWS-Cloudfront-Eingänge unter cloudfront hinzu:
# 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 : val2Dies ist besonders nützlich, um eine Ihrer nächsten.js -Seiten an CloudFront -Randspitzen zwischenzuspeichern. Eine Beispielanwendung mit benutzerdefinierter Cache -Konfiguration finden Sie in dieser Beispiel. Sie können auch eine vorhandene CloudFront -Verteilung mit benutzerdefinierten CloudFront -Eingaben aktualisieren.
Statisch gerenderte Seiten (dh HTML-Seiten, die auf S3 hochgeladen werden) haben den folgenden Cache-Kontroll-Set:
cache-control: public, max-age=0, s-maxage=2678400, must-revalidate
s-maxage ermöglicht CloudFront die Seiten 31 Tage an den Randorten. max-age=0 in Kombination mit must-revalidate stellen sicher, dass Browser die statischen Seiten niemals zwischenspeichern. Auf diese Weise kann CloudFront die volle Kontrolle über Caching -TTLs haben. Bei jeder Bereitstellung wird eine Invalidierung /* erstellt, um sicherzustellen, dass Benutzer neue Inhalte erhalten.
Standardmäßig sind gemeinsame Bildformate (gif | jpe /static G Cache-Control /public gif|jpe?g|jp2|tiff|png|webp|bmp|svg|ico public, max-age=31536000, must-revalidate Sie können entweder den Cache-Control Header- value und den Regex- test mit publicDirectoryCache anpassen:
myNextApplication :
component : " @sls-next/serverless-component@{version_here} "
inputs :
publicDirectoryCache :
value : public, max-age=604800
test : /.(gif|jpe?g|png|txt|xml)$/i value muss eine gültige Cache-Control -Richtlinie sein, und test muss ein gültiger regex der Dateien-Arten sein, die Sie testen möchten. Wenn Sie nicht möchten, dass Browser Vermögenswerte aus dem öffentlichen Verzeichnis zwischenspeichern, können Sie dies deaktivieren:
myNextApplication :
component : " @sls-next/serverless-component@{version_here} "
inputs :
publicDirectoryCache : falseStandardmäßig werden die Lambda@Edge -Funktionen mit AWSLambDabaSicexecutionRol ausgeführt, mit dem nur Protokolle in CloudWatch hochgeladen werden können. Wenn Sie darüber hinaus Berechtigungen benötigen, wie z.
# 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 "Stellen Sie sicher, dass Sie Ihrer benutzerdefinierten Richtlinie oder Rolle CloudWatch -Protokollberechtigungen hinzufügen. Mindestpolitik JSON Beispiel:
{
"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 " ]
}
]
} Die Rolle sollte die Vertrauensbeziehung zu lambda.amazonaws.com und edgelambda.amazonaws.com beinhalten.
HINWEIS : Geben Sie bucketName an und geben Sie Berechtigungen an, um auf diesen Eimer über policy oder roleArn zugreifen zu können, damit Standard- und API -Lambdas auf statische Ressourcen zugreifen können.
Die ausführliche Liste der für einen Bereitstellungsvorgang erforderlichen AWS -Aktionen:
"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"
Die Standard -API und das Bild (für das Bildoptimieren von Next.JS) werden standardmäßig 512 MB Speicher zugewiesen. Dieser Wert kann geändert werden, indem der memory eine Zahl zugewiesen wird
# serverless.yml
myNextApplication :
component : " @sls-next/serverless-component@{version_here} "
inputs :
memory : 1024 Werte für Standard- , API- und Bild -Lambdas können separat definiert werden, indem ein Objekt wie SO memory zugewiesen wird:
# serverless.yml
myNextApplication :
component : " @sls-next/serverless-component@{version_here} "
inputs :
memory :
defaultLambda : 1024
apiLambda : 2048
imageLambda : 2048Das gleiche Muster kann zur Angabe der Laufzeit von Node.js (standardmäßig NodeJS14.x) befolgt werden:
# 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 runtimesIn ähnlicher Weise beträgt das Timeout standardmäßig 10 Sekunden. Um anzupassen, können Sie:
# serverless.yml
myNextApplication :
component : " @sls-next/serverless-component@{version_here} "
inputs :
timeout :
defaultLambda : 20
apiLambda : 15
imageLambda : 15Beachten Sie, dass das maximale Zeitlimit für Lambda@Edge 30 Sekunden beträgt. Siehe https://docs.aws.amazon.com/amazoncloudfront/latest/developerguide/lambda-requirements-limits.html
Sie können auch einen benutzerdefinierten Namen für Standard- , API- und Bild -Lambdas festlegen. Wenn nicht der Standard von der AWS -Lambda Serverless -Komponente für die Ressourcen -ID festgelegt wird:
# serverless.yml
myNextApplication :
component : " @sls-next/serverless-component@{version_here} "
inputs :
name :
defaultLambda : fooDefaultLambda
apiLambda : fooApiLambda
imageLambda : fooImageLambdaEs gibt eine vierte Regenerations -Lambda, die ähnlich konfiguriert werden kann und zur inkrementellen statischen Regeneration verwendet wird. Es wird jedoch keine Lamda@Edge verwendet und kann beispielsweise eine längere Zeitüberschreitungseinstellung haben.
In Cloudfront werden vier Cache -Verhaltensweisen erstellt.
Die ersten beiden _next/* und static/* Leiten Sie die Anfragen an S3 weiter.
Der dritte ist einer Lambda -Funktion verbunden, die für die Behandlung von drei Arten von Anfragen verantwortlich ist.
Serverseite gerenderte Seite. Jede Seite, die getInitialProps -Methode definiert, wird auf dieser Ebene gerendert und die Antwort wird sofort an den Benutzer zurückgegeben.
Statisch optimierte Seite. Anfragen an Seiten, die neben HTML vor dem Kompilieren wurden, werden an S3 weitergeleitet.
Öffentliche Ressourcen. Anfragen zu Root -Ressourcen wie /robots.txt , /favicon.ico , /manifest.json usw. Diese werden an S3 weitergeleitet.
Der Grund, warum 2. und 3.. Zuerst durch lambda@edge gehen müssen, ist, dass die Routen nicht einem Muster wie _next/* oder static/* entsprechen. Außerdem ist ein Cache -Verhalten pro Route eine schlechte Idee, da CloudFront nur 25 pro Verteilung zulässt.
Das vierte Cache -Verhalten bearbeitet die nächste API fordert api/* an.
| Name | Typ | Standardwert | Beschreibung |
|---|---|---|---|
| einsetzen | boolean | true | Wenn Sie auf False festgelegt sind, werden die App nicht für den Anbieter (z. B. AWS) bereitgestellt. |
| Domain | Array | null | Zum Beispiel ['admin', 'portal.com'] |
| DomainRedirects | object | {} | Fügt mit einer 308-Umleitung an der Kante eine Umleitung auf Domänenebene hinzu. Geben Sie ein Objekt des Domänennamens an -> Ziel mit Protokoll umleiten. Zum Beispiel www.example.com: https://example.com . Weitere Informationen finden Sie hier. |
| Bucketname | string | null | Benutzerdefinierte Eimer -Name, bei dem statische Vermögenswerte gespeichert werden. Standardmäßig wird autogeneriert. |
| Bucketregion | string | null | Region, in der Sie Ihren S3 -Eimer ausrichten möchten. Stellen Sie sicher, dass dies geografisch näher an den meisten Ihrer Endbenutzer liegt, um die Latenz zu reduzieren, wenn Cloudfront eine Anfrage an S3 stellt. |
| Buckettags | object | undefined | Benutzerdefinierte Bucket -Tags für Ihren Eimer. Wenn nicht definiert, aktualisiert die Komponente keine Tags. Wenn Sie auf ein leeres Objekt eingestellt sind, werden alle Tags entfernt. |
| NEXTCONFIGDIR | string | ./ | Verzeichnis, in der Ihre Anwendung next.config.js -Datei steht. Diese Eingabe ist nützlich, wenn sich das serverless.yml nicht im selben Verzeichnis wie die nächste App befindet.Hinweis: nextConfigDir sollte festgelegt werden, wenn next.config.js distDir verwendet wird |
| NextstaticDir | string | ./ | Wenn Ihr static oder public Verzeichnis kein direktes Kind von nextConfigDir ist, wird dies benötigt |
| Beschreibung | string | *lambda-type*@Edge for Next CloudFront distribution | Die Beschreibung, die für beide Lambdas verwendet wird. Beachten Sie, dass "(API)" an die Beschreibung der API Lambda beigefügt wird. |
| Politik | string|object | arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole | Die ARN- oder Inline -Richtlinie, die beiden Lambdas zugewiesen wird. |
| Rolearn | string|object | NULL | Die Rolle der Rolle, die beiden Lambdas zugeordnet wird. |
| Laufzeit | string|object | nodejs14.x | Wenn ein Wert zugewiesen wird, erhalten sowohl die Standard- als auch die API -Lambdas die im Wert definierte Laufzeit. Wenn ein Objekt zugewiesen wird, können Werte für die Standard- und API -Lambdas separat definiert werden |
| Erinnerung | number|object | 512 | Wenn eine Nummer zugewiesen wird, wird sowohl dem Standard- als auch dem API -Lambdas Speicher dieses Wertes zugewiesen. Wenn ein Objekt zugewiesen wird, können Werte für die Standard- und API -Lambdas separat definiert werden |
| Tags | object | undefined | Tags, die einem Lambda zuweisen können. Wenn nicht definiert, aktualisiert die Komponente keine Tags. Wenn Sie auf ein leeres Objekt eingestellt sind, werden alle Tags entfernt. |
| Time-out | number|object | 10 | Gleich wie oben |
| Handler | string | index.handler | Wenn Sie einen Wert zugewiesen haben, überschreiben Sie den Standardfunktionshandler, um die Konfiguration zu ermöglichen. Kopiert handler.js auf dem Weg in die Lambda -Ordner. Ihr Handler muss immer noch den default-handler anrufen, oder Ihre Funktion funktioniert nicht mit next.js |
| Name | object | / | Namen für alle Lambdas können explizit definiert werden |
| bauen | boolean|object | true | Wenn True App baut und die App bereitstellt, wird die App angenommen .serverless_nextjs .next nextConfigDir zur Bereitstellung verwendet. Wenn ein Objekt übergeben wird, ermöglicht build das Überschreiben, was das Skript aufgerufen wird und mit welchen Argumenten. |
| Build.cmd | string | node_modules/.bin/next | Erstellen Befehl, können Sie einen Befehl no-op (z. B. true oder : in Unix-basierten Systemen) übergeben, das dann den nächsten.js-Build überspringt |
| Build.Args | Array|string | ['build'] | Argumente, die an den Bau gelangen sollten |
| Build.cwd | string | ./ | Überschreiben Sie das aktuelle Arbeitsverzeichnis |
| build.enabled | boolean | true | Gleich wie das Bestehen von build:false , aber aus der Konfiguration |
| Build.env | object | {} | Fügen Sie dem Skript zusätzliche Umgebungsvariablen hinzu |
| build.postbuildcommands | Array | [] | Alle Befehle zum Ausführen von Post-Build und Pre-Deploy. Beispielsweise können Sie jeden benutzerdefinierten Code im Verzeichnis .serverless_nextjs ausführen, z next-18n Gilt nur während der Ausführung des serverless Befehls. |
| Build.CleanUpDotNext | boolean | true | Ob Sie das Verzeichnis .next vor dem Ausführen des Build -Schritts beseitigen sollen |
| Build.assetignorepatterns | string[] | [] | Glob -Muster, die ignorieren können, wenn Dateien entdeckt werden, um aus _next/statischen, öffentlichen, statischen Verzeichnissen zu kopieren. |
| Build.usev2Handler | boolean | false | Experimentell setzt dies auf wahr, um V2 -Handler zu verwenden, die generizierte Handler verwenden. HINWEIS: Dies hat die Funktionalität von separateApiLambda und disableOriginResponseHandler , sodass es nicht zusammen verwendet werden sollte. Außerdem ist es in Bezug auf die Codegröße noch nicht vollständig optimiert, sollte aber dennoch leistungsfähig sein. In Zukunft werden wir diesen Modus wahrscheinlich standardmäßig verwenden. |
| Cloudfront | object | {} | Eingänge, die an AWS-Cloudfront übergeben werden sollen |
| Zertifikat | string | `` | Spezifische Zertifikat -ARN, die für die Verteilung von CloudFront verwendet werden soll. Hilfreich, wenn Sie ein Wildcard -SSL -Zertifikat haben, das Sie verwenden möchten. Dies funktioniert derzeit nur zusammen mit der domain . Bitte überprüfen Sie die benutzerdefinierte CloudFront -Konfiguration, um certificate anzugeben, ohne die domain zu verwenden (beachten Sie, dass dies aufgrund der Domäneneingabe ein Zertifikat überschreibt). |
| Domaintyp | string | "both" | Kann einer von: "apex" - nur Apex -Domäne sein, erstellen Sie keine WWW -Subdomäne. "www" - nur www domain, erstellen Sie keine Apex -Subdomain. "both" - Erstellen Sie sowohl WWW- als auch Apex -Domänen, wenn einer von einer bereitgestellt wird. |
| DomainminimumProtokolversion | string | "TLSv1.2_2018" | Kann einer von "SSLv3", "TLSv1", "TLSv1.1_2016", "TLSv1.2_2018", "TLSv1.2_2019", "TLSv1.2_2021" or "TLSv1_2016" sein. Siehe Referenz. |
| publicDirectoryCache | boolean|object | true | Passen Sie die Richtlinie zur Vermögenswerte public / static Ordner an. Durch das Zuweisen eines Objekts mit value und/oder test können Sie die Caching -Richtlinie und die Arten der zwischengespeicherten Dateien anpassen. Zuweisen falscher Deaktivierungen Caching |
| useServerlessTracetarget | boolean | false | Verwenden Sie das Experimental-Serverless-Trace-Ziel, um Ihre nächste App zu erstellen. Dies ist das gleiche Build -Ziel, das Vercel jetzt verwendet. Weitere Informationen finden Sie in diesem RFC. HINWEIS: Während Sie dies verwenden, müssen Sie möglicherweise NODE_ENV -Variable für production festlegen. |
| MinifyHandlers | boolean | false | Verwenden Sie vorgefertigte Minimed-Handler, um die Codegröße zu reduzieren. Miniiert keine benutzerdefinierten Handler. |
| EnableHttpCompression | boolean | false | Wenn die Lambda@Edge -Funktionen für SSR- und API -Anfragen auf true eingestellt sind, werden GZIP verwendet, um die Antwort zu komprimieren. Beachten Sie, dass Sie dies nicht aktivieren müssen, da CloudFront die Antworten für Sie aus dem Box komprimiert. |
| Authentifizierung | object | undefined | Authentifizierungsobjekt zur Verwendung mit der grundlegenden Authentifizierung (verfügbar ab 1.19.0-alpha.3). Es unterstützt vorerst nur eine einzelne Benutzername/Passwort -Kombination und ist in Klartext im Lambda -Handler eingeführt. Sie müssen auch den Authorization für Cloudfront -Verhaltensweisen, z. B. defaults , api/* und _next/data/_ weiterleiten. HINWEIS: Dies ist als einfaches Mittel zum Schutz einer Umgebung wie einer Entwicklungs-/Teststelle gedacht. Sie wird nicht für den Produktionsgebrauch empfohlen. |
| Authentifizierung.username | string | undefined | Benutzername für die grundlegende Authentifizierung. |
| aktiviert3Acceleration | boolean | true | Ob S3 -Übertragungsbeschleunigung aktiviert werden soll. Dies kann nützlich sein, um zu deaktivieren, da einige AWS -Regionen es nicht unterstützen. Siehe Referenz. |
| REMODLAMBDAVERSIONEN | boolean | false | Grundlegende Unterstützung für die Entfernung alter Lambda -Versionen nach dem Einsatz, um sicherzustellen. Wenn Sie auf True gesetzt sind, werden jedes Mal, wenn Sie bereitstellen, automatisch bis zu ~ 50 alte Versionen (ab dem ältesten) aller Lambdas, die nicht bereitgestellt/repliziert werden. Wenn Sie komplexere Strategien benötigen, wird empfohlen, Ihr eigenes Skript zu schreiben, um alte Versionen zu entfernen. |
Benutzerdefinierte Eingänge können so konfiguriert werden:
myNextApp :
component : " @sls-next/serverless-component@{version_here} "
inputs :
bucketName : my-bucket(experimentell) - Mehr Arbeit, die erforderlich ist, um dieses Konstrukt auf den neuesten Stand zu bringen und auch einige der serverlosen Logik wiederzuverwenden. Infolgedessen wird das Konstrukt wahrscheinlich entsprechend anpassen/verändert.
Dokumentation finden Sie hier.
Da wir die NEXT.JS -Routing -Logik fast von vorne emulieren, um sie für eine serverlose Umgebung zu optimieren, gibt es möglicherweise einige unvollständige oder fehlende Funktionen (wie bereits erwähnt). Wir sind jedoch der Ansicht, dass wir die meisten Funktionen behandelt und gute Einheiten und End-to-End-Testabdeckungen hinzugefügt haben, um die Stabilität zu gewährleisten (z. B. in 10+ End-to-End-Testsuiten). Mehrere Personen nutzen dies, um ihr Startup, ihre persönlichen Websites usw. zu betreiben.
Auch die Einschränkungen des Cloud -Anbieters gelten - zum Beispiel auf AWS Lambda@Edge gibt es Kaltstarts, Codegrößengrenzen, 1 MB Antwortgrößengrenze usw., um nur einige zu nennen. Sie sind natürlich auch mit einer einzigen Plattform gebunden (AWS Lambda@Edge; mehr in Kürze!).
Wir verbessern auch weiterhin den Bereitstellungsprozess, indem wir in naher Zukunft eine bessere Lösungen für Infrastruktur-As-Code (CDK, CDK-Terraform, Pulumi usw.) in Betracht ziehen.
Stellen Sie sicher, dass Ihr serverless.yml das serverless-components (Beta) -Format verwendet. Serverlose Komponenten unterscheiden sich vom ursprünglichen serverlosen Framework, obwohl beide über dieselbe CLI zugänglich sind.
✅ tun
# serverless.yml
myNextApp :
component : " @sls-next/serverless-component@{version_here} "
myTable :
component : serverless/aws-dynamodb
inputs :
name : Customers
# other componentsNicht
# serverless.yml
provider :
name : aws
runtime : nodejs10.x
region : eu-west-1
myNextApp :
component : " @sls-next/serverless-component@{version_here} "
Resources : ... Beachten Sie, wie der richtige YAML keinen provider , Resources usw. deklariert.
Führen Sie zur Bereitstellung keine serverless deploy aus. Führen Sie einfach serverless aus und bereitet Ihre Komponenten bereit, die in der serverless.yml -Datei deklariert sind.
Weitere Informationen zu serverlosen Komponenten finden Sie hier.
Die API -Handler- und Standard -Handler -Pakete werden separat eingesetzt, aber jeder hat eine Grenze von 50 MB Reißverschluss oder 250 MB unkomprimiert pro AWS - siehe hier und hier. Für Design gibt es derzeit nur eine Lambda@Edge für alle Seitenrouten und eine Lambda@Edge für alle API -Routen. Dies könnte zu Problemen mit Codegröße führen, insbesondere wenn Sie viele API -Routen, SSR -Seiten usw. haben.
Wenn Sie Probleme mit der Codegröße stoßen, probieren Sie Folgendes aus:
Optimieren Sie Ihre Codegröße: Reduzieren Sie # Abhängigkeiten auf Ihren SSR -Seiten und API -Routen, haben Sie weniger SSR -Seiten (dh nicht verwenden getInitialProps() oder getServerSideProps() ).
Minimieren Sie den Handler -Code selbst, indem Sie die minifyHandlers -Eingabe verwenden. Dies wird die Handlergröße von ~ 500 kb auf ~ 200 kb verringern.
Minimieren/minimieren Sie Ihren serverseitigen Code mithilfe von Terser, indem Sie die folgende Webpack-Konfiguration zu Ihrem next.config.js addieren. Es verwendet NEXT_MINIMIZE -Umgebungsvariable, um es zu sagen, dass der SSR -Code minimiert wird. Beachten Sie, dass dies die Build -Zeiten erhöht und den Code minifiert, sodass es schwieriger sein kann, Cloudwatch -Fehler zu debuggen.
Fügen Sie zuerst Ihre Abhängigkeiten terser-webpack-plugin hinzu. Dann aktualisieren Sie 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 ;
} ;Beachten Sie, dass alle JS -Dateien, die nur zum Vorbereiten statischer Seiten verwendet werden, automatisch aus dem Bundle entfernt werden, wenn Sie keine API -Routen verwenden. Wenn Sie jedoch API -Routen verwenden, entfernen wir sie nicht, da sie möglicherweise für den Vorschau -Modus verwendet werden. Es gibt keine offizielle/nicht-hackige Möglichkeit, diese JS-Dateien zu identifizieren und zu entfernen, die nicht im Vorschaudermodus verwendet werden, selbst wenn API-Routen verwendet werden. Wir können jedoch eine neue Eingabe hinzufügen, um sie bei Bedarf manuell auszuschließen.
useServerlessTraceTarget in serverless.yml . Dies führt dazu, dass Next.js Abhängigkeiten nicht in jede Seite (stattdessen leichte Seiten erstellen) und dann serverless-next.js auf einen einzigen Satz von Abhängigkeiten in node_modules verweisen. Dies ist wahrscheinlich entweder aufgrund eines Lambda@Edge -Code -Problemgröße (siehe oben für potenzielle Lösungen. Verwandte Github -Problem) oder wenn Sie eine langsame Hochladungsgeschwindigkeit für Netzwerk -Uploads haben und/oder versuchen, ein großes Lambda -Paket bereitzustellen.
Im zweiten Fall hat das verwendete aws-sdk NPM-Paket ein Standard-Timeout von 120 Sekunden. Im Moment ist dies nicht konfigurierbar, aber wir können in naher Zukunft längere Zeitüberschreitungen unterstützen (ähnlich wie serverloser/serverloser#937, das nur für serverlosen Framework und nicht für serverlose Komponenten gilt).
Standardmäßig legt Cloudfront den Host -Header auf den Namen S3 Origin Host fest. Sie müssen den Host -Header an den Ursprung weiterleiten. Siehe das Beispiel unten, um es für Ihr api/* Cache -Verhalten weiterzuleiten:
myNextApplication :
component : " @sls-next/serverless-component@{version_here} "
inputs :
cloudfront :
api/* :
forward :
headers : [Host] Benutzer werden aufgefordert, diese Komponente anstelle des serverless-plugin zu verwenden. Diese Komponente wurde unter Verwendung von Lektionen aus dem serverlosen Plugin erstellt und entworfen.
examples/dynamodb-crud finden Sie ein Beispiel für die Todo-Anwendung, die mit DynamoDB interagiert. Hier finden Sie eine vollständige Liste von Beispielen
Leider muss der Bereitstellungsstatus aufgrund der Art und Weise, wie serverlose Komponenten funktioniert (zumindest die Beta -Version), außerhalb des serverlosen Hauptbefehls serverless synchronisiert werden. Sie können also die folgenden Lösungen ausprobieren:
.serverless . Dies wird zwar nicht empfohlen, da es für mehrere Phasen nicht gut funktioniert..serverless Dateien zu speichern, siehe hier ein Beispiel hier (verwendet mehrere serverless.yml Dateien) oder hier (GitHub-Aktionen basiert, verwendet mehrere serverless.yml Dateien).distributionId -CloudFront -Eingabe verwenden, um eine vorhandene CloudFront -Verteilung anzugeben, um sie bereitzustellen.In Zukunft werden wir dies verbessern, indem wir dies verbessern, indem wir das richtige Bühnenmanagement in die Komponente selbst integrieren.
Dieses Projekt wurde vom ursprünglichen Autor gestartet, als Serverless -Komponenten in Beta waren, und leider wurde kurz darauf die GA -Komponenten veröffentlicht. Dies wurde jedoch immer größer, wobei mehrere Unterkomponenten in diesen Monorepo importiert wurden, da sie nicht von Serverless gepflegt wurden. Und dann wurde es schwierig zu aktualisieren.
Es gab einen Plan, um auf GA -Komponenten zu upgraden, aber er wurde aus einigen Gründen auf Eis gelegt:
Wir befassen uns derzeit mit ordnungsgemäßen IAC -Lösungen (wie CDK für Terraform, CDK, Pulumi usw.), um dies zu beheben und die Belastung der Aufrechterhaltung einer komplexen Bereitstellungslogik zu erleichtern, damit wir uns auf die Entwicklererfahrung konzentrieren und Parität mit Next.js.
Ja! Der Hauptblocker war, dass die nächste. Wir haben jedoch den größten Teil der Kernlogik (in das @sls-next/core Paket) generiert, damit sie auf anderen Plattformen wiederverwendet werden können, indem Sie einfach einen Verpackungshandler erstellen, einen plattformspezifischen Client implementieren (z. B. zum Abrufen von Seiten, die statische Regeneration ausgelöst) und das Erstellen eines Bereitstellers auszulösen. Wenn Sie aufmerksam waren, haben Sie über API Gateway ein neues Paket für Lambda-Bereitstellungen bemerkt: https://github.com/serverless-nextjs/serverless-next.js/tree/master/packages/libs/lambda. Andere Plattformen wie Azure und Google Cloud sollten hoffentlich bald folgen.
us-east-1 eingesetzt. Wie kann ich es in einer anderen Region bereitstellen? Serverless Next.js ist regionlos . Durch Design werden serverless-next.js -Anwendungen weltweit für jeden Cloudfront-Kantenort bereitgestellt. Der Lambda mag aussehen, als würde sie nur in us-east-1 eingesetzt, aber hinter den Kulissen wird sie in jede andere Region repliziert.
In der Stichprobe unten finden Sie ein fortschrittliches build -Setup, das zusätzliche Argumente und Umgebungsvariablen an den Build enthält.
# 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} Wenn Sie versuchen, eine Umgebungsvariable mit einer anderen Zeichenfolge wie ${env.VARIABLE}-blah zu verkettet, scheint das serverlose Framework es nur auf ${env.VARIABLE} zu beheben.
Es scheint ein Fehler in serverlosen Komponenten zu sein - es kann möglicherweise nicht die neueste GA -Version verwendet werden, in der sie möglicherweise behoben wurde (dies befindet sich leider noch auf Komponenten -Beta). Im Moment ist die Problemumgehung:
serverless.yml -Variable, dann verkettet: stage : ${env.STAGE}
my-app :
component : " @sls-next/[email protected] "
inputs :
domain :
- " ${stage}-front-end "
- mydomain.com Sie können die neue domainRedirects -Eingabe sowie die Weiterleitung Host -Headers und domainType: both , um Anforderungen in die richtige Domäne umzuleiten. Siehe Beispielkonfiguration unten, die www.example.com Anfragen auf https://example.com weiterleitet.
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 All dies geschieht innerhalb der Lambda@Edge Origin Request -Handler. Bitte beachten Sie, dass Sie dies nicht ermöglichen können, Anfragen unter _next/static/* oder /static/* umzuleiten, da diese Cache -Verhaltensweisen keinen Lambda@Edge -Handler mit sich haben.
Andernfalls können Sie auch die manuelle Problemumgehung mit einem hier beschriebenen S3 -Eimer verwenden. Zusammenfassend müssen Sie einen neuen S3 -Bucket erstellen und ihn mit der statischen Website -Hosting einrichten, um Anfragen an Ihren unterstützten Subdomain -Typ zu leiten (z. B. "www.example.com" oder "example.com"). Um HTTPS -Weiterleitungen zu unterstützen, müssen Sie eine CloudFront -Verteilung mit dem S3 -Umleitungseimer als Ursprung einrichten. Schließlich müssen Sie mit Ihrer neu erstellten CloudFront -Distribution als Alias -Ziel einen "A" -Ektrat in Route 53 erstellen.
build.env werden nicht in meiner App angezeigt Damit Ihre App auf die definierten Umgebungsvariablen zugreifen kann, müssen Sie sie über die hier next.config.js enthüllen.
Bei einem serverless.yml wie diesem
myApp :
inputs :
build :
env :
API_HOST : " http://example.com "Ihr nächstes.config.js sollte so aussehen:
module . exports = {
env : {
API_HOST : process . env . API_HOST
}
} ; Möglicherweise sehen Sie einen Fehler wie unten:
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)
Es tritt üblicherweise auf, wenn die Größe der Reaktion zu groß ist. Lambda@Edge hat derzeit eine vom Origin Request -Handler zurückgegebene Einschränkung von 1 MB. Siehe: https://docs.aws.amazon.com/amazoncloudfront/latest/developerguide/lambda-generating-http-responses-requests.html#lambda-generat-http-respons-reors. Leider gibt es möglicherweise keine andere Problemumgehung, als zu versuchen, sicherzustellen, dass Ihre Antworten kleiner sind.
Stellen Sie sicher, dass Sie über die CloudFront-Konfiguration Accept-Language Header weiterleiten. Standardmäßig wird es weitergeleitet, aber wenn Sie Ihre eigene Konfiguration überschreiben, sollten Sie es wieder hinzufügen.
Wenn Sie Bibliotheken von Drittanbietern verwenden (vorerst nur next-i18next ) und Standardpfade verwenden, müssen einige Dateien möglicherweise in die Lambda-Verzeichnisse kopiert werden. Diese Komponente versucht, Standarddateien zu erkennen und für Sie zu kopieren. Wenn Sie jedoch eine benutzerdefinierte Konfiguration haben, müssen Sie möglicherweise Ihre eigenen postBuildCommands zum Kopieren von Dateien usw. schreiben.
Weitere Informationen und Vorbehalte finden Sie im Readme.
Hier können Sie ein neues Problem eröffnen. Wenn Sie ein Problem veröffentlichen, befolgen Sie das Debugging -Wiki zuerst für einige nützliche Tipps und versuchen Sie, so viele Informationen einzuschließen, um das Problem zu reproduzieren.
Wenn Sie eine Sicherheitsanfälligkeit melden, befolgen Sie stattdessen die Sicherheitsrichtlinie.
Bitte beachten Sie, dass es momentan nur einen Kernbetreuer gibt (@dphang) und eine Handvoll Community -Mitwirkende, die alle in ihrer Freizeit zu dieser Bibliothek beitragen. 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.
Dieses Projekt besteht dank aller Menschen, die einen Beitrag leisten. [Beitragen].
Made with contributors-img.
Become a financial contributor and help us sustain our community. [Beitragen]
Support this project with your organization. Ihr Logo wird hier mit einem Link zu Ihrer Website angezeigt. [Beitragen]
