serverless next.js
v3.7.0
تكوين صفر next.js 10/11 مكون بدون خادم لـ AWS lambda@edge يهدف إلى تكافؤ الميزة الكاملة.
يرجى مراجعة الميزات للحصول على قائمة بالميزات المدعومة حاليًا.
️ يعكس هذا ReadMe أحدث التغييرات على الفرعmaster. قد يتم نشرها أو لا يتم نشرها بعد إلىlatestإصدار (مستقر) أوalphaفي NPM. يرجى الانتقال إلى الإصدارات ، والعثور على إصدار@sls-next/serverless-componentالذي تستخدمه ، وافتح ReadMe لهذا الإصدار للحصول على معلومات أكثر دقة. إذا تم إدراج ميزة في هذا ReadMe ولكن لا تعمل ، فيرجى محاولة الترقية أولاً إلى أحدث إصدارalphaفي NPM.
يستخدم هذا حاليًا Beta Beta (وليس إصدار GA) حيث بدأ المشروع قبل GA. نحن نعيد صياغة كيفية عمل عمليات النشر في المستقبل واستكشاف حلول IAC أفضل مثل CDK ، و CDK لـ Terraform ، وما إلى ذلك ، وسوف يصدر إعلانًا قبل نهاية العام بشأن أي تحديثات.
منذ Next.js 8.0 ، تم تقديم وضع الخادم الذي يوفر واجهة برمجة تطبيقات جديدة منخفضة المستوى يمكن أن تستخدمها مثل هذه المشاريع للنشر على مزودي السحابة المختلفين. ومع ذلك ، لا يوفر Next.js منطق التوجيه الكامل بدون خادم ، وبالتالي سبب حاجة هذا المشروع لملء الفجوة. تتمثل الرؤية طويلة الأجل في السماح لك بالاستضافة الذاتي مع السحب المختلفة ، بدءًا من AWS.
يعد هذا المشروع إصدارًا أفضل من المكون الإضافي بدون خادم يركز على معالجة المشكلات الأساسية مثل الدعم 9 التالي ، وتجربة تطوير أفضل ، وحد 200 CloudFormation Morder وأداء.
هناك القليل أو بدون تكوين مطلوب. يمكنك تمديد الإعدادات الافتراضية بناءً على احتياجات التطبيق الخاصة بك.
يجب أن يكون مستخدمو هذا المكون قادرين على استخدام أدوات تطوير Next.js ، ويعرف أيضًا باسم next dev . إن وظيفة المكون هي نشر طلبك لضمان التكافؤ مع جميع ميزات Next التي نعرفها ونحبها. نحاول محاكاة كل أو معظم المنطق التوجيه والمنطق من جانب الخادم من Next.js وتحسينه لبيئة بدون خادم. أدناه يمكنك العثور على قائمة بالميزات المدعومة حاليًا.
من خلال بنية مبسطة وعدم استخدام CloudFormation ، لا توجد حدود لعدد الصفحات التي يمكن أن تحصل عليها في التطبيق الخاص بك ، بالإضافة إلى أن أوقات النشر سريعة جدًا! باستثناء أوقات الانتشار السحابية بالطبع.
نظرًا لأننا نحاكي منطق توجيه Next.js ، للأسف لسنا دائمًا في التكافؤ الكامل. يظهر التالية جميع الميزات المدعومة أو الميزات المخطط لها. إذا تم وضع علامة مربع الاختيار ، فهذا يعني أن الميزة مدعومة. خلاف ذلك ، من المحتمل ألا يكون مدعومًا بعد أو حاليًا في مرحلة التخطيط أو التنفيذ. يرجى الرجوع إلى وصف العنصر للحصول على تفاصيل محددة.
لاحظ أن بعض الميزات قد تكون فقط على أحدث إصدار ألفا. إذا تم إدراج ميزة على أنها مدعومة ولكن لا تعمل على latest علامة ، فمن المحتمل أن تكون في علامة alpha . إذا استطعت ، يرجى مساعدتنا في اختبار أحدث تغييرات ألفا وإرسال تقرير الأخطاء إذا وجدت أي مشكلات. شكرًا لك!
هل هناك ميزة تريدها ولكن لم يتم دعمها بعد؟ يرجى فتح مشكلة جديدة لإعلامنا!
/_next/* يتم تقديمها من CloudFront. getStaticProps . getServerSideProps . getStaticPaths . _next/static/* و static/* ، لأن سلوكيات ذاكرة التخزين المؤقت هذه لا تحتوي على معالجات lambda متصلة بها. لاحظ أن التنسيق الجديد has مطابقة (https://nextjs.org/docs/api- المرجع/next.config.js/redirects#header-cookie-and-query-matching) لم يتم دعمه بعد. _next/static/* و static/* ، لأن سلوكيات ذاكرة التخزين المؤقت هذه لا تحتوي على معالجات lambda متصلة بها. لاحظ أن التنسيق الجديد has مطابقة (https://nextjs.org/docs/api- المرجع/next.config.js/redirects#header-cookie-and-query-matching) لم يتم دعمه بعد. _next/static/* و static/* ، لأن سلوكيات ذاكرة التخزين المؤقت هذه لا تحتوي على معالجات lambda متصلة بها. لاحظ أن التنسيق الجديد has مطابقة (https://nextjs.org/docs/api- المرجع/next.config.js/redirects#header-cookie-and-query-matching) لم يتم دعمه بعد. next-i18next . أولاً ، تأكد من تثبيت Node.js 12+ على جهاز النشر حيث يتم الآن نقل جميع التعليمات البرمجية إلى ES2019. أضف تطبيقك التالي إلى 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 إذا قمت بتحديد @sls-next/serverless-component في ملف serverless.yml الخاص بك ، لا تقم بإضافة @sls-next/serverless-component إلى ملف package.json الخاص بك ، فهو غير مستخدم فقط في ملف serverless.yml ، وهو ما يسحبه الخادم من NPM بمفرده. إذا لم تحدد الإصدار ، فسيستخدم latest علامة ، والتي تشير إلى أحدث إصدار مستقر هنا (أي إصدارات Alpha).
يمكنك أيضًا توجيهه إلى تثبيت محلي ، على سبيل المثال إذا كنت تريد الإصدار باستخدام package.json .
في هذه الحالة ، قم بتكوين ما يلي:
# serverless.yml
myNextApplication :
component : " ./node_modules/@sls-next/serverless-component "ثم اضبط بيانات اعتماد AWS الخاصة بك كمتغيرات بيئة:
AWS_ACCESS_KEY_ID=accesskey
AWS_SECRET_ACCESS_KEY=sshhhوببساطة نشر:
$ serverlessإذا كانت لديك مشكلات تم نشرها بسبب إصدار جديد بدون خادم ، فيرجى محاولة تحديد الإصدار المحدد على سبيل المثال 2.72.2. انظر #2320 (تعليق)
[alpha-قد يكون عربات التي تجرها الدواب] يمكنك أيضًا نشرها باستخدام npx @sls-next/serverless-patched @serverless/cli أو serverless-patched إذا قمت بتثبيتها محليًا) ، وهي نسخة مصححة من serverless التي تعمل على إصلاح بعض المشكلات (eg outpug). يتولى صامتة Next.js الفشل.
يوصى أيضًا بإضافة علامة --debug للحصول على المزيد من السجلات المفيدة لما يحدث وراء الكواليس.
لا تحاول النشر عن طريق تشغيل serverless deploy ، استخدم فقط serverless
في معظم الحالات ، لا ترغب في استخدام مجال توزيع CloudFront للوصول إلى التطبيق الخاص بك. بدلاً من ذلك ، يمكنك تحديد اسم مجال مخصص.
يمكنك استخدام أي اسم مجال ولكن يجب أن تستخدم AWS Route53 لاستضافة DNS. لترحيل سجلات DNS من مجال موجود ، اتبع التعليمات هنا. متطلبات استخدام اسم مجال مخصص:
mydomain.com ) مع مجموعة من خوادم الأسماء.سيقوم مكون Next.js بدون خادم بإنشاء شهادة SSL تلقائيًا وإنشاء سجل جديد للإشارة إلى توزيع 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" يمكنك أيضًا تكوين subdomain :
# serverless.yml
myNextApplication :
component : " @sls-next/serverless-component@{version_here} "
inputs :
domain : ["sub", "example.com"] # [ sub-domain, domain ] لتحديد مدخلات CloudFront الخاصة بك ، ما عليك سوى إضافة أي مدخلات AWS-Cloudfront ضمن 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 : val2هذا مفيد بشكل خاص لتخزين أي من صفحات Next.js في مواقع حافة CloudFront. انظر هذا للحصول على تطبيق مثال مع تكوين ذاكرة التخزين المؤقت المخصصة. يمكنك أيضًا تحديث توزيع CloudFront الحالي باستخدام مدخلات CloudFront المخصصة.
الصفحات التي يتم تقديمها بشكل ثابت (أي صفحات HTML التي تم تحميلها إلى S3) لها مجموعة التحكم في ذاكرة التخزين المؤقت التالية:
cache-control: public, max-age=0, s-maxage=2678400, must-revalidate
يسمح s-maxage CloudFront بتخزين الصفحات في مواقع الحافة لمدة 31 يومًا. max-age=0 بالاشتراك مع must-revalidate المتصفحات ، لا تخدع أبدًا الصفحات الثابتة. هذا يسمح لـ CloudFront بالتحكم الكامل في التخزين المؤقت TTLs. في كل نشر يتم إنشاء إبطال /* لضمان حصول المستخدمين على محتوى جديد.
بشكل افتراضي ، تنسيقات الصور الشائعة ( gif|jpe?g|jp2|tiff|png|webp|bmp|svg|ico ) تحت /public أو /static لها سياسة Cache-Control المؤقت لمدة عام واحد ( public, max-age=31536000, must-revalidate ). يمكنك تخصيص value رأس Cache-Control و regex من أي ملفات test ، مع 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 سياسة صالحة Cache-Control ويجب أن تكون test regex صالحة لأنواع الملفات التي ترغب في اختبارها. إذا كنت لا تريد أن تتخبط المستعرضات من الأصول من الدليل العام ، فيمكنك تعطيل هذا:
myNextApplication :
component : " @sls-next/serverless-component@{version_here} "
inputs :
publicDirectoryCache : falseبشكل افتراضي ، يتم تشغيل وظائف Lambda@Edge باستخدام AwslambdabasicexecutionRole والتي تسمح فقط بتحميل سجلات CloudWatch. إذا كنت بحاجة إلى أذونات تتجاوز هذا ، على سبيل المثال الوصول إلى DynamoDB أو أي مورد آخر AWS ، فستحتاج إلى سياسة أو دورك المخصص الخاص بك:
# 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 "تأكد من إضافة أذونات سجل CloudWatch إلى سياستك أو دورك المخصص. الحد الأدنى من السياسة json مثال:
{
"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 " ]
}
]
} يجب أن يشمل الدور علاقة الثقة مع lambda.amazonaws.com و edgelambda.amazonaws.com .
ملاحظة : حدد bucketName وقم بإعطاء أذونات للوصول إلى هذا الدلو عبر policy أو roleArn حتى تتمكن Lambdas من الوصول إلى الموارد الثابتة.
القائمة الشاملة لإجراءات AWS المطلوبة للنشر:
"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"
سيتم تعيين Lambdas الافتراضي و API و Image (من أجل تحسين الصورة next.js) 512 ميجابايت من الذاكرة بشكل افتراضي. يمكن تغيير هذه القيمة عن طريق تعيين رقم إلى إدخال memory
# serverless.yml
myNextApplication :
component : " @sls-next/serverless-component@{version_here} "
inputs :
memory : 1024 يمكن تعريف قيم Lambdas الافتراضي و API و Image بشكل منفصل عن طريق تعيين memory لكائن مثل SO:
# serverless.yml
myNextApplication :
component : " @sls-next/serverless-component@{version_here} "
inputs :
memory :
defaultLambda : 1024
apiLambda : 2048
imageLambda : 2048يمكن اتباع نفس النمط لتحديد وقت تشغيل Node.js (NodeJS14.x افتراضيًا):
# 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 runtimesوبالمثل ، فإن المهلة بشكل افتراضي هي 10 ثوان. لتخصيص يمكنك:
# serverless.yml
myNextApplication :
component : " @sls-next/serverless-component@{version_here} "
inputs :
timeout :
defaultLambda : 20
apiLambda : 15
imageLambda : 15لاحظ أن الحد الأقصى للمهلة المسموح بها لـ Lambda@Edge هي 30 ثانية. انظر https://docs.aws.amazon.com/amazoncloudfront/latest/developerguide/lambda-requirements-limits.html
يمكنك أيضًا تعيين اسم مخصص للافتراضيات و API و Image Lambdas - إذا لم يكن يتم تعيين الافتراضي بواسطة مكون AWS -Lambda بدون خادم إلى معرف المورد:
# serverless.yml
myNextApplication :
component : " @sls-next/serverless-component@{version_here} "
inputs :
name :
defaultLambda : fooDefaultLambda
apiLambda : fooApiLambda
imageLambda : fooImageLambdaهناك Lambda التجديد الرابع ، والذي يمكن تكوينه بشكل مشابه ويستخدم للتجديد الثابت المتزايد. ومع ذلك ، فإنه لا يستخدم Lamda@Edge ويمكن ، على سبيل المثال ، أن يكون لديه إعداد مهلة أطول.
يتم إنشاء أربعة سلوكيات ذاكرة التخزين المؤقت في CloudFront.
أول اثنين _next/* و static/* توجيه الطلبات إلى S3.
والثالث يرتبط بوظيفة Lambda المسؤولة عن التعامل مع ثلاثة أنواع من الطلبات.
صفحة الخادم المقدمة. سيتم تقديم أي صفحة تحدد طريقة getInitialProps على هذا المستوى ويتم إرجاع الاستجابة فورًا إلى المستخدم.
صفحة محسّنة بشكل ثابت. يتم إعادة توجيه طلبات الصفحات التي تم تجميعها مسبقًا بجوار HTML إلى S3.
الموارد العامة. طلبات إلى موارد مستوى الجذر مثل /robots.txt ، /favicon.ico ، /manifest.json ، إلخ. يتم إعادة توجيهها إلى S3.
السبب في أن 2. و 3. يجب أن تمر عبر lambda@edge أولاً هو أن الطرق لا تتوافق مع نمط مثل _next/* أو static/* . أيضًا ، يعد سلوك ذاكرة التخزين المؤقت لكل مسار فكرة سيئة لأن CloudFront يسمح فقط 25 لكل توزيع.
يتولى سلوك ذاكرة التخزين المؤقت الرابع طلبات API api/* .
| اسم | يكتب | القيمة الافتراضية | وصف |
|---|---|---|---|
| نشر | boolean | true | عند التعيين على FALSE ، لن ينشر التطبيق إلى المزود (مثل AWS). |
| اِختِصاص | Array | null | على سبيل المثال ['admin', 'portal.com'] |
| domainredirects | object | {} | يضيف إعادة توجيه مستوى المجال عند الحافة باستخدام إعادة توجيه 308. حدد كائن اسم المجال -> إعادة توجيه الوجهة مع البروتوكول. على سبيل المثال ، www.example.com: https://example.com . انظر هنا لمزيد من المعلومات. |
| اسم الجدل | string | null | اسم دلو مخصص حيث يتم تخزين الأصول الثابتة. بشكل افتراضي هو المولد تلقائيًا. |
| دلو | string | null | المنطقة التي تريد استضافة دلو S3 الخاص بك. تأكد من أن هذا أقرب جغرافياً إلى غالبية المستخدمين النهائيين لتقليل الكمون عندما يكون CloudFront Presies طلبًا إلى S3. |
| Buckettags | object | undefined | علامات دلو مخصصة لتعيين دلوتك. إذا لم يتم تحديدها ، فلن يقوم المكون بتحديث أي علامات. إذا تم ضبطها على كائن فارغ ، فسيقوم بإزالة جميع العلامات. |
| NextConfigdir | string | ./ | الدليل حيث يكون تطبيق التطبيق الخاص بك next.config.js . يكون هذا الإدخال مفيدًا عندما لا يكون serverless.yml في نفس الدليل مثل التطبيق التالي.ملاحظة: يجب تعيين nextConfigDir إذا تم استخدام next.config.js distDir |
| NextStaticdir | string | ./ | إذا لم يكن الدليل static أو public الخاص بك طفلًا مباشرًا لـ nextConfigDir فهذا مطلوب |
| وصف | string | *lambda-type*@Edge for Next CloudFront distribution | الوصف الذي سيتم استخدامه لكلا lambdas. لاحظ أنه سيتم إلحاق "(API)" بوصف API Lambda. |
| سياسة | string|object | arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole | سياسة ARN أو المضمنة التي سيتم تعيينها لكل من Lambdas. |
| روليرن | string|object | باطل | ARN من الدور الذي سيتم تعيينه لكلا lambdas. |
| وقت التشغيل | string|object | nodejs14.x | عند تعيين قيمة ، سيتم تعيين كل من Lambdas الافتراضي و API في وقت التشغيل المحدد في القيمة. عند تعيينه إلى كائن ، يمكن تعريف قيم Lambdas الافتراضي و API بشكل منفصل |
| ذاكرة | number|object | 512 | عند تعيين رقم ، سيتم تعيين ذاكرة هذه القيمة الافتراضية و API. عند تعيينه إلى كائن ، يمكن تعريف قيم Lambdas الافتراضي و API بشكل منفصل |
| العلامات | object | undefined | علامات لتعيين Lambda. إذا لم يتم تحديدها ، فلن يقوم المكون بتحديث أي علامات. إذا تم ضبطها على كائن فارغ ، فسيقوم بإزالة جميع العلامات. |
| نفذ الوقت | number|object | 10 | نفسه على النحو الوارد أعلاه |
| معالج | string | index.handler | عند تعيين قيمة ، يتجاوز معالج الوظيفة الافتراضي للسماح بالتكوين. نسخ handler.js في الطريق إلى مجلدات lambda. لا يزال يتعين على معالجك الاتصال default-handler بعد ذلك أو لن تعمل وظيفتك مع Next.js |
| اسم | object | / | يمكن تعريف أسماء جميع lambdas بشكل صريح |
| يبني | boolean|object | true | عندما يقوم True .serverless_nextjs .next nextConfigDir للنشر. إذا تم build كائن ما يسمح بتجاوز ما يتم استدعاؤه البرنامج النصي ومع ما هي الحجج. |
| build.cmd | string | node_modules/.bin/next | أمر بناء ، يمكنك تمرير أمر no-op (على سبيل المثال true أو : في الأنظمة المستندة إلى UNIX) والتي ستتخطي بعد ذلك. js build |
| build.args | Array|string | ['build'] | الحجج لتمريرها إلى البناء |
| build.cwd | string | ./ | تجاوز دليل العمل الحالي |
| build.enabled | boolean | true | مثل التمرير build:false ولكن من داخل التكوين |
| build.env | object | {} | أضف متغيرات بيئة إضافية إلى البرنامج النصي |
| build.postbuildCommands | Array | [] | أي أوامر لتشغيل ما بعد البناء و pre-deploy. على سبيل المثال ، يمكنك تشغيل أي رمز مخصص على دليل .serverless_nextjs ، على سبيل المثال ، يمكنك نسخ ملفات إضافية إلى Lambda: انظر #767 (تعليق) للحصول على مثال لـ next-18n . ينطبق فقط أثناء تنفيذ الأمر serverless . |
| build.cleanupdotnext | boolean | true | ما إذا كان لتنظيف دليل .next قبل تشغيل خطوة البناء |
| build.assetignorepatterns | string[] | [] | أنماط الكرة الأرضية التي يجب تجاهلها عند اكتشاف الملفات لنسخ من الدلائل الثابتة/الثابتة ، العامة. |
| build.usev2handler | boolean | false | قم بتعيين هذا على True لاستخدام معالجات V2 التي تبدأ في استخدام المعالجات العامة. ملحوظة: هذا له وظيفة separateApiLambda و disableOriginResponseHandler بحيث لا ينبغي استخدامها معًا. أيضًا ، لم يتم تحسينه تمامًا بعد من حيث حجم الرمز ، ولكن يجب أن يكون أداءه. في المستقبل ، من المحتمل أن نستخدم هذا الوضع افتراضيًا. |
| Cloudfront | object | {} | يتم تمرير المدخلات إلى AWS-Cloudfront |
| شهادة | string | `` | شهادة محددة ARN لاستخدامها لتوزيع CloudFront. مفيد إذا كان لديك شهادة Wildcard SSL التي ترغب في استخدامها. هذا يعمل حاليًا فقط جنبًا إلى جنب مع إدخال domain . يرجى التحقق من تكوين CloudFront المخصص لكيفية تحديد certificate دون الحاجة إلى استخدام إدخال domain (لاحظ أن القيام بذلك سيجلب أي شهادة بسبب إدخال المجال). |
| المجال | string | "both" | يمكن أن يكون واحدًا من: "apex" - Apex Domain فقط ، لا تنشئ نطاقًا فرعيًا للوزارة العالمية. "www" - المجال www فقط ، لا تنشئ نطاقًا فرعيًا من قمة. "both" - قم بإنشاء كل من مجالات www و Apex عندما يتم توفير أي منهما. |
| domainminimumprotocolversion | string | "TLSv1.2_2018" | يمكن أن تكون واحدة من: "SSLv3", "TLSv1", "TLSv1.1_2016", "TLSv1.2_2018", "TLSv1.2_2019", "TLSv1.2_2021" or "TLSv1_2016" . انظر المرجع. |
| publicdirectorycache | boolean|object | true | تخصيص سياسة التخزين المؤقت للأصول public / static . يتيح لك تعيين كائن ذي value و/أو test تخصيص سياسة التخزين المؤقت وأنواع الملفات المخزنة مؤقتًا. تعيين تعطيل كاذب التخزين المؤقت |
| useerlistless arcetarget | boolean | false | استخدم الهدف التجريبي الذي لا يتجاوز التتبع لإنشاء تطبيقك التالي. هذا هو نفس هدف البناء الذي يستخدمه Vercel الآن. انظر هذا RFC للحصول على التفاصيل. ملاحظة: أثناء استخدام هذا ، قد تحتاج إلى تعيين متغير NODE_ENV على production . |
| MinifyHandlers | boolean | false | استخدم معالجات مصغرة مسبقًا لتقليل حجم الرمز. لا يعزل معالجات مخصصة. |
| enableHttpcompression | boolean | false | عند true وظائف Lambda@Edge لطلبات SSR و API ، ستستخدم GZIP لضغط الاستجابة. لاحظ أنه لا يجب أن تحتاج إلى تمكين هذا لأن CloudFront سوف يضغط على الاستجابات لك خارج المربع. |
| المصادقة | object | undefined | كائن المصادقة للاستخدام مع المصادقة الأساسية (متوفر من 1.19.0-alpha.3). إنه يدعم مزيج اسم مستخدم/كلمة مرور واحد فقط في الوقت الحالي ويتم إدخاله في نص عادي في معالج Lambda. يجب أيضًا إعادة توجيه رأس Authorization لسلوكيات CloudFront ، على سبيل المثال defaults ، api/* ، و _next/data/_ . ملاحظة: هذا يعني كوسيلة بسيطة لحماية بيئة مثل موقع التطوير/الاختبار ، لا ينصح به لاستخدام الإنتاج. |
| المصادقة. اسم المستخدم | string | undefined | اسم المستخدم للمصادقة الأساسية. |
| تمكين 3Acceleration | boolean | true | سواء لتمكين S3 نقل تسريع. قد يكون هذا مفيدًا للتعطيل لأن بعض مناطق AWS لا تدعمها. انظر المرجع. |
| removeoldlambdaversions | boolean | false | الدعم الأساسي لإزالة إصدارات Lambda القديمة بعد الانتشار لضمان. إذا تم ضبطها على TRUE ، في كل مرة تقوم فيها بنشرها ، ستزيل تلقائيًا ما يصل إلى حوالي 50 إصدارات قديمة (بدءًا من أقدم) من جميع Lambdas التي لم يتم نشرها/تكرارها. إذا كنت بحاجة إلى استراتيجيات أكثر تعقيدًا ، فمن المستحسن كتابة البرنامج النصي الخاص بك لإزالة الإصدارات القديمة. |
يمكن تكوين مدخلات مخصصة مثل هذا:
myNextApp :
component : " @sls-next/serverless-component@{version_here} "
inputs :
bucketName : my-bucket(تجريبي) - مزيد من العمل المطلوب لرفع هذا البناء إلى السرعة وأيضًا لإعادة استخدام بعض المنطق بدون خادم. نتيجة لذلك ، من المحتمل أن يتكيف البناء/التغيير وفقًا لذلك.
يمكن العثور على الوثائق هنا.
نظرًا لأننا نحاكي منطق توجيه Next.js تقريبًا من نقطة الصفر لتحسينه لبيئة بدون خادم ، فقد يكون هناك بعض الميزات غير المكتملة أو المفقودة (كما ذكرنا سابقًا). ومع ذلك ، نشعر بأننا قمنا بتغطية غالبية الميزات وأضفنا تغطية اختبار جيدة وتغطي لضمان الاستقرار (على سبيل المثال عبر 10+ أجنحة اختبار شاملة). يستخدم العديد من الأشخاص هذا لتشغيل بدء التشغيل ، ومواقع الويب الشخصية ، إلخ.
تنطبق قيود مزود السحابة أيضًا - على سبيل المثال على AWS lambda@Edge ، هناك بدايات باردة ، وحدود حجم الرمز ، وحد حجم استجابة 1 ميغابايت ، وما إلى ذلك على سبيل المثال لا الحصر. أنت بالطبع مرتبطة أيضًا بمنصة واحدة في الوقت الحالي (AWS Lambda@Edge ؛ المزيد قريبًا!).
نحن نستمر أيضًا في تحسين عملية النشر من خلال النظر في حلول بنية تحتية أفضل في المستقبل القريب (CDK ، CDK Terraform ، Pulumi ، إلخ).
تأكد من استخدام serverless.yml تنسيق serverless-components (Beta). تختلف المكونات بدون خادم عن الإطار الأصلي بدون خادم ، على الرغم من أنهما يمكن الوصول إليهما عبر نفس CLI.
✅ افعل
# serverless.yml
myNextApp :
component : " @sls-next/serverless-component@{version_here} "
myTable :
component : serverless/aws-dynamodb
inputs :
name : Customers
# other componentsلا
# serverless.yml
provider :
name : aws
runtime : nodejs10.x
region : eu-west-1
myNextApp :
component : " @sls-next/serverless-component@{version_here} "
Resources : ... لاحظ كيف أن YAML الصحيح لا يعلن عن provider ، Resources ، إلخ.
للنشر ، لا تقم بتشغيل serverless deploy . ما عليك سوى تشغيل serverless والتي تنشر مكوناتك المعلنة في ملف serverless.yml .
لمزيد من المعلومات حول مكونات الخادم ، تذهب هنا.
يتم نشر معالج API وحزم المعالج الافتراضية بشكل منفصل ، ولكن لكل منها حد 50 ميجابايت مضغوط أو 250 ميجابايت غير مضغوط لكل AWS - انظر هنا وهنا. حسب التصميم ، يوجد حاليًا فقط Lambda@Edge لجميع طرق الصفحة و@Lambda@Edge لجميع طرق API. قد يؤدي ذلك إلى مشكلات في حجم الكود خاصة إذا كان لديك العديد من طرق API وصفحات SSR ، إلخ.
إذا كنت تواجه مشكلات في حجم الرمز ، فيرجى تجربة ما يلي:
قم بتحسين حجم الكود الخاص بك: قلل من تبعيات # في صفحات SSR وطرق API ، ولديها عدد أقل من صفحات SSR (أي لا تستخدم getInitialProps() أو getServerSideProps() ).
Minify رمز المعالج نفسه باستخدام مدخلات minifyHandlers . سيؤدي ذلك إلى تقليل حجم المعالج من حوالي 500 كيلو بايت إلى 200 كيلو بايت.
Minify/تقليل رمز جانب الخادم الخاص بك باستخدام Terser عن طريق إضافة تكوين WebPack التالي إلى next.config.js . يستخدم متغير البيئة NEXT_MINIMIZE لإخباره لتقليل رمز SSR. لاحظ أن هذا سيزيد من أوقات البناء ، ويضعف الرمز بحيث يكون من الصعب تصحيح أخطاء CloudWatch.
أولاً ، أضف terser-webpack-plugin إلى تبعياتك. ثم تحديث 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 ;
} ;لاحظ أنه إذا لم تستخدم أي طرق API ، فسيتم إزالة جميع ملفات JS المستخدمة فقط للصفحات الثابتة المسبقة تلقائيًا من الحزمة. ومع ذلك ، إذا كنت تستخدم طرق API ، فنحن لا نزيلها حيث يمكن استخدامها لوضع المعاينة. لا توجد طريقة رسمية/غير مميتة لتحديد وإزالة ملفات JS التي لا تستخدم في وضع المعاينة حتى عند استخدام طرق API. ولكن يمكننا إضافة مدخلات جديدة لاستبعادها يدويًا ، إذا لزم الأمر.
useServerlessTraceTarget في serverless.yml . سيؤدي ذلك إلى عدم وجود تبعيات Next.js في كل صفحة (بدلاً من ذلك إنشاء صفحات خفيفة الوزن) ، ثم سيشير serverless-next.js إلى مجموعة واحدة من التبعيات في node_modules . من المحتمل أن يكون هذا إما بسبب مشكلة حجم رمز Lambda@Edge (انظر أعلاه للحصول على حلول محتملة. مشكلة github ذات الصلة) أو إذا كان لديك سرعة تحميل بطيئة على الشبكة و/أو تحاول نشر حزمة Lambda كبيرة.
في الحالة الثانية ، فإن حزمة aws-sdk NPM المستخدمة لها مهلة افتراضية تبلغ 120 ثانية. في الوقت الحالي ، هذا غير قابل للتكوين ، ولكن قد ندعم مهلة أطول في المستقبل القريب (على غرار الخادم/الخادم رقم 937 ، والذي ينطبق فقط على إطار الخادم ، وليس مكونات الخادم).
بشكل افتراضي ، يقوم Cloudfront بتعيين رأس Host على اسم مضيف Origin S3. تحتاج إلى إعادة توجيه رأس Host إلى الأصل. انظر المثال أدناه لإعادة توجيهه لسلوك ذاكرة التخزين المؤقت api/*
myNextApplication :
component : " @sls-next/serverless-component@{version_here} "
inputs :
cloudfront :
api/* :
forward :
headers : [Host] يتم تشجيع المستخدمين على استخدام هذا المكون بدلاً من serverless-plugin . تم تصميم هذا المكون وتصميمه باستخدام الدروس المستفادة من المكون الإضافي بدون خادم.
راجع examples/dynamodb-crud للحصول على مثال على تطبيق Tode الذي يتفاعل مع DynamoDB. يمكنك العثور على قائمة كاملة من الأمثلة هنا
لسوء الحظ ، نظرًا للطريقة التي تعمل بها مكونات الخادم (على الأقل إصدار بيتا) ، يجب مزامنة حالة النشر خارج الأمر الرئيسي serverless . لذلك يمكنك تجربة الحلول التالية:
.serverless . على الرغم من أن هذا لا ينصح به لأنه لا يعمل بشكل جيد لمراحل متعددة..serverless ، ومشاهدة مثال هنا ، هنا (يستخدم ملفات متعددة serverless.yml ) ، أو هنا (يعتمد على إجراءات github ، يستخدم ملفات serverless.yml متعددة).distributionId CloudFront لتحديد توزيع CloudFront الحالي للنشر إليه.في المستقبل ، سوف نتطلع إلى تحسين هذا من خلال دمج إدارة المرحلة المناسبة في المكون نفسه.
بدأ هذا المشروع من قبل المؤلف الأصلي عندما كانت مكونات Serverless في الإصدار التجريبي ، وللأسف تم إصدار مكونات GA بعد ذلك بوقت قصير. ولكن هذا نما أكبر وأكبر ، مع استورد العديد من المكونات الفرعية في هذا المونوروبو لأنه لم يتم الحفاظ عليه بواسطة الخادم. ثم أصبح من الصعب الترقية.
كانت هناك خطة للترقية إلى مكونات GA ، ولكن تم تعليقها لعدة أسباب:
نحن نبحث حاليًا في حلول IAC المناسبة (مثل CDK لـ Terraform و CDK و Pulumi وما إلى ذلك) لمعالجة هذا وتخفيف عبء الحفاظ على منطق النشر المعقد ، حتى نتمكن من التركيز على تجربة المطور والتعرض للتكافؤ مع Next.js.
نعم! كان المانع الرئيسي هو أن منطق توجيه Next.js يستخدم بشكل كبير مع منطق Lambda@Edge/CloudFront. ومع ذلك ، قمنا بتشكيل معظم المنطق الأساسي (في الحزمة @sls-next/core ) بحيث يمكن إعادة استخدامه في منصات أخرى ، وذلك ببساطة عن طريق إنشاء معالج تغليف ، وتنفيذ بعض العميل الخاص بالمنصة (على سبيل المثال لاسترداد الصفحات ، وتجديد ثابت ثابت ، وما إلى ذلك) ، وإنشاء مُشكل. إذا كنت متاحًا ، فستلاحظ حزمة جديدة حاليًا في أعمال نشر Lambda عبر API Gateway: https://github.com/serverless-nextjs/serverless-next.js/tree/master/packages/libs/lambda. يجب أن تتبع منصات أخرى مثل Azure و Google Cloud قريبًا.
us-east-1 . كيف يمكنني نشرها في منطقة أخرى؟ Serverless next.js هو بلا منطقة . حسب التصميم ، سيتم نشر تطبيقات serverless-next.js في جميع أنحاء العالم إلى كل موقع Cloudfront Edge. قد يبدو أن Lambda يتم نشره فقط في us-east-1 ولكن خلف الكواليس ، يتم تكراره إلى كل منطقة أخرى.
راجع العينة أدناه للحصول على إعداد build متقدم يتضمن تمرير وسيطات إضافية ومتغيرات البيئة إلى البناء.
# 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} إذا حاولت تسلسل متغير البيئة بسلسلة أخرى ، مثل ${env.VARIABLE}-blah ، يبدو أن إطار عمل بدون خادم يحلها إلى ${env.VARIABLE} فقط.
يبدو أنه خطأ في مكونات بدون خادم - قد يكون بسبب عدم استخدام أحدث إصدار من GA ، حيث ربما تم إصلاحه (لا يزال هذا على المكونات بيتا ، للأسف). في الوقت الحالي ، يكون الحل البديل هو:
serverless.yml أولاً ، ثم Concatenate: stage : ${env.STAGE}
my-app :
component : " @sls-next/[email protected] "
inputs :
domain :
- " ${stage}-front-end "
- mydomain.com يمكنك استخدام مدخلات domainRedirects الجديدة ، إلى جانب إعادة توجيه رأس Host و domainType: both ، لإعادة توجيه الطلبات إلى المجال الصحيح. راجع تكوين المثال أدناه الذي يعيد توجيه www.example.com طلبات إلى 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 كل هذا يحدث في معالجات طلب Origin Lambda@Edge. يرجى ملاحظة أن هذا لن يسمح لك بإعادة توجيه الطلبات على _next/static/* أو /static/* ، لأن سلوكيات ذاكرة التخزين المؤقت هذه لا تحتوي على معالج lambda@الحافة المرفقة بها.
خلاف ذلك ، يمكنك أيضًا استخدام الحلول اليدوي باستخدام دلو S3 المبين هنا. باختصار ، سيتعين عليك إنشاء دلو S3 جديد وإعداده مع استضافة موقع ويب ثابت لإعادة توجيه الطلبات إلى نوع النطاق الفرعي المدعوم (على سبيل المثال. "www.example.com" أو "example.com"). لتكون قادرًا على دعم عمليات إعادة توجيه HTTPS ، ستحتاج إلى إعداد توزيع CloudFront مع دلو إعادة توجيه S3 كأصل. أخيرًا ، ستحتاج إلى إنشاء سجل "A" في الطريق 53 مع توزيع CloudFront الذي تم إنشاؤه حديثًا كهدف الاسم المستعار.
build.env لا تظهر في تطبيقي للسماح لتطبيقك بالوصول إلى متغيرات البيئة المحددة ، تحتاج إلى فضحها عبر the next.config.js كما هو موضح هنا.
إعطاء serverless.yml هل مثل هذا
myApp :
inputs :
build :
env :
API_HOST : " http://example.com "يجب أن تبدو your next.config.js هكذا:
module . exports = {
env : {
API_HOST : process . env . API_HOST
}
} ; قد ترى خطأ مثل أدناه:
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)
يحدث عادة عندما يكون حجم الاستجابة كبيرًا جدًا. لدى Lambda@Edge حاليًا قيود على 1 ميغابايت يتم إرجاعها بواسطة معالج طلب الأصل. راجع: https://docs.aws.amazon.com/amazoncloudfront/latest/developerguide/lambda-generating-http-responses-in-requests.html#lambda-generating-http-respons-errors. لسوء الحظ ، قد لا يكون هناك حل بديل بخلاف محاولة التأكد من أن ردودك أصغر.
تأكد من أنك Accept-Language عبر تكوين CloudFront ، فهو غير قادر على تحديد اللغات التي يفهمها المستخدم و/أو يفضله. بشكل افتراضي ، يتم إعادة توجيهه ولكن إذا تجاوزت التكوين الخاص بك ، فيجب عليك إضافته مرة أخرى.
إذا كنت تستخدم مكتبات أطراف ثالثة ( next-i18next في الوقت الحالي) واستخدمت المسارات الافتراضية ، فقد تحتاج بعض الملفات إلى نسخها إلى أدلة Lambda. سيحاول هذا المكون اكتشاف الملفات الافتراضية ونسخها لك. ومع ذلك ، إذا كان لديك تكوين مخصص ، فقد تحتاج إلى كتابة postBuildCommands الخاصة بك لنسخ الملفات ، إلخ.
ارجع إلى ReadMe لمزيد من المعلومات والتحذيرات.
يمكنك فتح مشكلة جديدة هنا. إذا نشرت مشكلة ، فيرجى اتباع تصحيح الأخطاء الويكي أولاً للحصول على بعض النصائح المفيدة ، ومحاولة تضمين الكثير من المعلومات لإعادة إنتاج المشكلة.
إذا كنت تقوم بالإبلاغ عن ثغرة أمنية ، فيرجى اتباع سياسة الأمان بدلاً من ذلك.
يرجى ملاحظة أنه لا يوجد سوى مشرف أساسي واحد في الوقت الحالي (dphang) ، وحفنة من المساهمين في المجتمع ، الذين يساهمون جميعًا في هذه المكتبة في أوقات فراغهم. 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.
هذا المشروع موجود بفضل جميع الأشخاص الذين يساهمون. [يساهم].
Made with contributors-img.
Become a financial contributor and help us sustain our community. [يساهم]
Support this project with your organization. سيظهر شعارك هنا مع رابط لموقع الويب الخاص بك. [يساهم]
