كيفية تخزين جميع الصفحات في Next.js في جانب الخادم

Next.js هو إطار SSR رائع لإنشاء التطبيقات ومواقع الويب. يعني SSR أنه يمكنك استخدام رمز React.js على الخادم ويمكن للعميل الوصول إلى أي عنوان url أو موقع في أي وقت وسيتم تقديم HTML مثلما سيتم تقديمه في المستعرض.

SSR + تفاعل = بطيء SSR

المشكلة هي أن React باهظ الثمن عندما يتعلق الأمر بتقديم الصفحة على جانب الخادم. لا بأس بالبشر إذا كانت الصفحة معروضة في 0.1s - في غمضة عين. ولكن بالنسبة للخادم ، فإن هذا الوقت كبير جدًا ويعني انخفاض الإنتاجية. تطلب منك خدمة Google PageSpeed ​​Insights تقليل وقت استجابة الخادم وتكون درجة موقعك على الويب أقل إذا كان عرض الصفحة أطول من 0.2 إلى 0.25 ثانية.

الحل هو تخزين الصفحات مؤقتًا. يمكنك دائمًا استخدام nginx لتخزين كل شيء مؤقتًا. Ngninx جيد في التخزين المؤقت. يمكنك فقط وضعه بين العملاء وتطبيقك. ولكن قد لا تكون قواعد التخزين المؤقت لـ nginx مرنة بما يكفي لحالات الاستخدام الخاصة بك.

يمنحك التخزين المؤقت داخل التطبيق مزيدًا من التحكم. هناك طريقة ملائمة للقيام بذلك في مشروع next.js باستخدام خادم مخصص Express.js. في هذا الخادم المخصص ، يمكنك السماح للتطبيق بتحديد ما إذا كان سيتم عرض صفحة أو إرجاع محتوى مخبأ أو حتى الإصدار الدقيق منه.

يحتوي Next.js repo في Github على كود مصدر لتطبيق المثال حيث يقوم بتخزين صفحات SSR في ذاكرة التخزين المؤقت. لكنه يخزن موقعًا واحدًا فقط كثيرًا ولا يعمل إذا حاولت تخزين جميع الصفحات في ذاكرة التخزين المؤقت. يحدث هذا بسبب استخدام موقع / _next / خاص لتقديم محتوى ثابت ويتطلب معالجة مختلفة. باستخدام هذا المثال ، قمت بإنشاء رمز يسمح بتخزين جميع الصفحات مؤقتًا وعرض المحتوى الثابت بشكل صحيح.

server.js واحد لتخزين كل منهم

ما يحدث بالضبط هنا؟

بادئ ذي بدء ، أقوم بإنشاء مثيل صريح يعالج الطلبات بدلاً من ذلك next.js.

كما أحتاج إلى next.js سبيل المثال للقيام بكل العمل باستثناء التخزين المؤقت. وهي متوفرة في التطبيق ثابت.

ثم أستخدم مثيل LRUcache لتخزين ذاكرة التخزين المؤقت. يمكنك استخدام أي تخزين آخر إذا كنت تريد. تذكر أن إعداد LRUCache max ذو معنى منخفض من تلقاء نفسه ، يتطلب تعريف وظيفة الطول لتوفر لك تحكمًا أفضل في حجم ذاكرة التخزين المؤقت. خاصية maxAge تسمح لك بتحديد الوقت الذي ينتهي فيه الإدخال على أي حال.

مؤشر const هو معالج next.js الافتراضي للطلبات وسيتم استخدامه لخدمة المحتوى الثابت.

يجب معالجة الطلبات ذات عناوين url التي تبدأ بـ / _next / مع next.js نفسها. أقوم بإنشاء المسار / _next / * الذي ينقلهم إلى الوظيفة التالية next.js handler handler وسوف تتم معالجتها الآن بشكل صحيح.

ستذهب جميع الطلبات الأخرى إلى server.get ('*') وسيتم تخزينها مؤقتًا بعد تقديمها. يمكنك تحديد مواقع أخرى للتعامل مع المواقف المختلفة أو حتى استخدام مخازن مختلفة. لا أحتاج إليها ، لذا دعنا نتصفح آلية ميكانيكا renderAndCache.

الكود الخاص به هو نفسه كما في المثال التالي next.js repo. يحتوي على عنوان x-cache ، لكنني لست متأكدًا مما إذا كان له أي معنى آخر باستثناء السماح لك بمشاهدته في المستعرض أو أي برنامج عميل آخر هو عنوان url الذي تم تقديمه من ذاكرة التخزين المؤقت أو تم تقديمه.

لا تحتاج إلى تغيير رمز هذه الوظيفة ، لأن التحكم في ما سيكون الخادم من ذاكرة التخزين المؤقت أو سيتم تقديمه يجب القيام به فقط عن طريق تغيير المفتاح الذي تم إنشاؤه لهذا الطلب.

التخزين ذي القيمة الأساسية لديه فكرة بسيطة - يمكنك وضع شيء يحمل اسمًا للتخزين. وعندما تحتاج إليها ، فأنت فقط تطلب من وحدة التخزين أن تمنحك ما يشتمل عليه بهذا الاسم. إذا كان يعطيك شيئا - يمكنك استخدامه. إذا لم يعطيك شيء - عليك إنشائه.

يمكنني استخدام req.path كمفتاح. يتم إنشاؤه في دالة getCacheKey () التي تحتوي على سطر واحد فقط يقوم بإرجاع متغير واحد فقط. ولكن لماذا استخدام وظيفة لمثل هذه المهمة البسيطة؟ لأن هذه الوظيفة تتيح لك استخدام جميع المعلومات المقدمة مع الطلب لإنشاء مفتاح يتم إنشاؤه من جميع المعلمات التي تؤثر على العرض.

في المرة القادمة ، سأوضح لك كيفية إجراء عمليات إعادة توجيه بسيطة باستخدام next.js.