أساسيات JAMstack: ماذا وماذا وكيف

نحن نحب تجاوز الحدود على الويب ، ولذا قررنا تجربة شيء جديد. ربما تكون قد سمعت عن JAMstack - مكدس الويب الجديد المستند إلى JavaScript و APIs و Markup - ولكن ماذا يعني ذلك بالنسبة لسير عملك ومتى يكون منطقيًا في مشاريعك؟

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

لقد طلبنا من Phil Hawksworth إجراء ندوة عبر الإنترنت لشرح ما يعنيه JAMStack في الواقع ومتى يكون منطقيًا ، بالإضافة إلى كيفية تأثيره على الأدوات وبنية الواجهة الأمامية. الندوة عبر الإنترنت التي مدتها ساعة واحدة متاحة الآن أيضًا. لا يمكننا أن نكون أكثر سعادة للترحيب بـ Phil للمشاركة في MC ، SmashingConf Toronto القادم (25-26 يونيو) وتشغيل JAMStack_conf London ، الذي شاركنا في تنظيمه يومي 9 و 10 يوليو من هذا العام أيضًا. لذا ، دعنا ندخله!

فيل هوكسورث: ممتاز ، حسنًا ، حسنًا ، دعنا ندخله بعد ذلك. فقط عن طريق الترحيب السريع جدًا ، أعني أنني قلت مرحبًا بالفعل ، لقد أعطاني سكوت مقدمة لطيفة. لكن نعم ، أنا أعمل حاليًا في Netlify ، وأعمل في فريق تجربة المطور هناك. نأمل أن يكون لدينا متسع من الوقت للأسئلة والأجوبة ، ولكن ، كما ذكر سكوت ، إذا لم تتح لك الفرصة لطرح الأسئلة هناك ، أو إذا كنت تفضل ذلك ، فيمكنك إرسالها إليّ مباشرةً على Twitter ، لذا فإن التعامل مع Twitter الخاص بي هي أسماءي ، إنها Phil Hawksworth ، لذا في أي وقت يمكنك بالتأكيد أن تسألني أسئلة حول JAMstack أو في الواقع أي شيء على Twitter.

فيل هوكسورث: لكني أريد أن أبدأ اليوم فقط من خلال العودة بالزمن إلى الوراء قليلاً إلى هذا الاقتباس الذي يتردد صداه معي بشدة. هذا اقتباس من الرائع آرون شوارتز الذي ، بالطبع ، ساهم كثيرًا في Creative Commons والشبكة المفتوحة وقد كتب هذا على مدونته في عام 2002 ، وقال ، "أنا مهتم بعدم الاضطرار إلى الحفاظ على غريب الأطوار تثبيتات خادم AOL و Postgres و Oracle ". خادم AOL ، كان عليّ البحث لأذكر نفسي كان خادم ويب مفتوح المصدر في ذلك الوقت.

فيل هوكسورث: لكن هذا ينسجم معي بقوة. كما أنني لا أرغب في الحفاظ على البنية التحتية لإبقاء المدونة حية ، وهذا ما كان يتحدث عنه. وكان ذلك في منشور المدونة هذا على مدونته الخاصة وكان بعنوان "Bake، Don't Fry". لقد كان ينتقي مصطلحًا بدأ استخدامه مؤخرًا شخصًا قام ببناء CMS ، وقام نوعًا ما بترويج هذا المصطلح حول الخبز (Bake ، Don't Fry) ؛ ما يتحدث عنه هناك هو العرض المسبق بدلاً من التقديم عند الطلب ، لذا خبز المحتوى مسبقًا ، بدلاً من قليه عند الطلب عندما يأتي الناس ويطلبونه - إبعاد الأشياء عن وقت الطلب وفي نوع من وقت البناء.

فيل هوكسورث: وعندما نتحدث عن العرض المسبق والعرض ، ما نعنيه بذلك هو أننا نتحدث عن إنشاء العلامات. أشعر ببعض الخجل أحيانًا عندما أتحدث عن نوع من تصيير الخادم أو العرض المتماثل أو الكثير من هذه المصطلحات الرنانة ؛ تم استدعائي قبل بضع سنوات في مؤتمر ، مؤتمر فرونتيرز في أمستردام عندما كنت أتحدث عن العرض على الخادم وقال لي أحدهم ، "هل تقصد إنشاء HTML؟ فقط شيء يخرج HTML؟ " وهذا ما أعنيه بالطبع.

فيل هوكسوورث: لكن كل هذا النوع يقطع شوطًا طويلاً نحو تبسيط المكدس. عندما نفكر في المكدس الذي نخدم المواقع منه ؛ أنا كل شيء عن محاولة تبسيط الأشياء ، أنا حريص جدًا على محاولة تبسيط المكدس. وهذا نوع من جوهر هذا الشيء المسمى "JAMstack" وأريد أن أحاول شرح هذا قليلاً. يرمز "JAM" في JAMstack إلى JavaScript و APIs و Markup. لكن هذا لا يكفي حقًا لمساعدتنا على فهم ما يعنيه - ما الذي يعنيه هذا حقًا؟

فيل هوكسورث: حسنًا ، ما أريد أن أحاول القيام به في النصف ساعة القادمة أو نحو ذلك ، هو أنني أريد أن أتوسع في هذا التعريف وأعطي المزيد من الوصف لما هو JAMstack. أريد أن أتحدث قليلاً عن تأثير وانعكاسات JAMstack ، كما تعلمون ، فكر فيما يمكن أن يقدمه لنا ذلك ولماذا قد نختاره. على طول الطريق ، سأحاول أن أذكر بعض الأدوات والخدمات التي ستكون مفيدة ، وآمل أن أختتم ببعض الموارد التي قد ترغب في البحث فيها وربما أذكر بعض الخطوات الأولى للحصول عليها قيد التنفيذ.

فيل هوكسوورث: إذن ، هذه هي الخطة للنصف ساعة القادمة. لكن ، أريد ، نوعًا ما ، العودة إلى هذه الفكرة حول تبسيط المكدس ، لأنه ، على أمل ، الأشخاص الذين انضموا إلى هذا أو جاءوا لمشاهدة هذا الفيديو لاحقًا ، ربما لديك فكرة عن ماهية JAMstack ، أو ربما يكون مصطلحًا جديدًا تمامًا ، وأنت فضولي فقط. ولكن ، في النهاية ، هناك الكثير من المداخن الموجودة بالفعل. هناك العديد من الطرق التي يمكنك من خلالها تقديم موقع على شبكة الإنترنت. يبدو أننا قمنا ببناء أنواع مختلفة من البنية التحتية لفترة طويلة حقًا ، سواء كانت حزمة LAMP أو مكدس MAMP ، أو - لا أعرف - مكدس MEAN. هناك مجموعة منهم تطفو على الشاشة هنا. هناك الكثير والكثير منهم.

فيل هوكسورث: إذن ، لماذا نحتاج إلى واحد آخر؟ حسنًا ، JAMstack ، كما ذكرت ، عبارة عن JavaScript / API / Markup ، ولكن إذا حاولنا أن نكون أكثر وصفية قليلاً ، فإن JAMstack يهدف إلى أن يكون بنية حديثة ، للمساعدة في إنشاء مواقع سريعة وآمنة وتطبيقات ديناميكية باستخدام JavaScript / واجهات برمجة التطبيقات (API) والترميز المُقدم مسبقًا ، والذي يتم تقديمه بدون خوادم ويب ، وهذه النقطة الأخيرة هي ، نوعًا ما ، الشيء الذي يميزها عن بعضها ، وربما يجعلها أكثر قليلاً ، نوعًا ما ، مثيرة للاهتمام وغير عادية.

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

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

فيل هوكسورث: وستنفذ هذه الخوادم بعض المنطق لتقول ، "حسنًا ، هذا هو النموذج الخاص بنا ، نحتاج إلى ملء ذلك ببعض البيانات." قد نحصل على بياناتنا من أحد خوادم قواعد البيانات التي ستقوم ببعض المنطق للبحث عن بعض البيانات ، وإعادة ذلك إلى خادم الويب ، وإنشاء طريقة عرض نمررها مرة أخرى عبر موازن التحميل. ربما ، على طول الطريق ، الاتصال بـ CDN ، وإخفاء بعض الأصول في CDN ، ويجب أن أوضح ، أن CDN هي شبكة توصيل المحتوى ، لذا فإن شبكة من الأجهزة الموزعة حول الإنترنت لمحاولة الحصول على خدمة الطلب في أقرب وقت ممكن للمستخدم وإضافة أشياء ، مثل التخزين المؤقت.

فيل هوكسورث: لذلك ، قد نقوم بتخزين بعض الأصول هناك ، وفي النهاية ، نعيد عرضًا إلى المتصفح ، في مقل عيون المستخدم ، الذي يمكنه بعد ذلك تجربة الموقع الذي أنشأناه. لذلك ، من الواضح أن هذا إما تبسيط مفرط أو نظرة عامة جدًا لكيفية خدمة طلب ما في مكدس تقليدي. إذا قارنا ذلك بـ JAMstack ، الذي يخدم الأشياء بطريقة مختلفة قليلاً ، فهذا هو الشكل الذي قد يبدو عليه.

فيل هوكسورث: إذن ، مرة أخرى ، نفس السيناريو ، بدأنا في متصفح الويب. نحن نقدم طلبًا لعرض الصفحة ، وهذه الصفحة موجودة بالفعل في شبكة توصيل المحتوى. إنه يعمل بشكل ثابت من هناك ، لذلك يتم إرجاعه إلى المستخدم ، في المتصفح ، وقد انتهينا. لذلك ، من الواضح ، نظرة مبسطة للغاية ، ولكن على الفور ، يمكنك البدء في رؤية الاختلافات هنا من حيث التعقيد. فيما يتعلق بالأماكن التي نحتاجها لإدارة الكود ، والتشفير العميق ، كل تلك الأشياء المختلفة. لذا ، بالنسبة لي ، فإن إحدى السمات الأساسية لـ JAMstack ، هي أنها تعني أنك تبني موقعًا يمكن تقديمه مباشرة من CDN ، أو حتى من خادم ملفات ثابت. CDN هو شيء قد نرغب في وضعه للتعامل مع التحميل ، ولكن في النهاية ، يمكن تقديم ذلك مباشرة من أي نوع من خوادم الملفات الثابتة ، نوع من البنية التحتية للاستضافة الثابتة.

فيل هوكسورث: JAMstack ، نوعًا ما ، يقدم فرصة لتقليل التعقيد. بمجرد مقارنة هذين الجزأين من الرسم البياني الذي سنعود إليه عدة مرات ، على مدار النصف ساعة القادمة ، يمكنك أن ترى أنها فرصة لتقليل التعقيد وتقليل المخاطر. وبالتالي ، فهذا يعني أنه يمكننا البدء في الاستمتاع ببعض مزايا خدمة الأصول الثابتة ، وسأتحدث عما هي عليه بعد قليل. لكن ربما تنظر إلى هذا وتفكر ، "حسنًا ، رائع ، لكن أليس هذا مجرد الاسم الجديد لمواقع الويب الثابتة؟" هذا شيء معقول أن أضعه في وجهي عندما أقول ، "سنقوم بخدمة الأشياء بشكل ثابت."

فيل هوكسورث: لكني أريد أن أعود إلى ذلك. أريد أن أتحدث عن ذلك أكثر قليلاً ، لكن أولاً وقبل كل شيء ، أريد ، نوعًا ما ، التحدث عن فكرة المكدس هذه وماذا على الأرض هو مكدس ، على أي حال؟ وأعتقد أن المكدس هو طبقات التكنولوجيا التي تقدم موقع الويب أو التطبيق الخاص بك. ونحن لا نتحدث عن خط أنابيب البناء ، أو عملية التطوير ، ولكن بالتأكيد الطريقة التي نخدم بها المواقع يمكن أن يكون لها تأثير كبير على كيفية تطويرنا وكيفية نشر الأشياء ، وما إلى ذلك.

فيل هوكسوورث: ولكن هنا ، نتحدث عن مجموعة التكنولوجيا ، طبقات التكنولوجيا ، التي تقدم موقع الويب الخاص بك وتطبيقك للمستخدمين. لذلك ، دعونا نجري مقارنة صغيرة أخرى. دعنا نتحدث عن حزمة LAMP لثانية واحدة.

فيل هوكسورث: قد تتذكر أن مكدس LAMP يتكون من خادم ويب اباتشي ، للقيام بأشياء مثل توجيه HCP وخدمة الأصول الثابتة. PHP ، لبعض المعالجة المسبقة ، معالجة النصوص المفرطة جدًا ؛ تطبيق المنطق ، وربما بناء وجهات النظر للقوالب وماذا لديك. ولديه بعض الوصول إلى بياناتك ، عن طريق My NISQL ، ثم LINUX هو نظام التشغيل الذي يجلس تحت كل ذلك ، ويحافظ على كل هذا التنفس. يمكننا اختتام ذلك معًا بشكل افتراضي كخادم الويب هذا. وقد يكون لدينا العديد من هذه الخوادم ، نوعًا ما ، تجلس معًا لخدمة موقع ويب.

فيل هوكسورث: هذه ، نوعًا ما ، نظرة تقليدية على حزمة LAMP ، وإذا قارنا ذلك بمكدس JAMstack ، حسنًا ، هنا ، هناك تغيير حاسم. هنا ، نحن في الواقع نرتقي إلى مستوى أعلى ، بدلاً من التفكير في نظام التشغيل والتفكير في كيفية تشغيل المنطق لتقديم موقع ويب. نحن هنا نفترض أننا سنخدم هذه الأشياء بشكل ثابت. لذلك ، نحن نقوم بتوجيه ACP ، وخدمة الأصول من خادم ثابت. يمكن القيام بذلك بشكل معقول. لقد أصبحنا جيدًا جدًا في هذا ، على مر السنين ، في بناء طرق لتقديم مواقع ويب ثابتة أو أصول ثابتة.

فيل هوكسورث: قد يكون هذا CDN ، ومرة ​​أخرى ، سنتحدث عن ذلك بعد قليل. لكن مجال الاهتمام بالنسبة لنا ، يحدث أكثر في المتصفح. لذلك ، هنا ، هذا هو المكان الذي يتم فيه تسليم العلامات الخاصة بنا وتحليلها. هذا هو المكان الذي يمكن أن تنفذ فيه JavaScript ، وهذا يحدث في المتصفح. من نواح كثيرة ، أصبح المتصفح هو وقت تشغيل الويب الحديث. بدلاً من وجود وقت التشغيل في البنية الأساسية للخادم ، نفسها ، قمنا الآن برفع ذلك المستوى ، أقرب إلى المستخدم ، وفي المتصفح.

Phil Hawksworth: عندما يتعلق الأمر بالوصول إلى البيانات ، فهذا يحدث ، على الأرجح ، من خلال واجهات برمجة التطبيقات الخارجية ، وإجراء مكالمات عبر JavaScripts إلى واجهات برمجة التطبيقات الخارجية هذه للوصول إلى الخادم ، أو يمكننا التفكير في واجهات برمجة التطبيقات على أنها واجهات برمجة تطبيقات المتصفح ، والقدرة على التفاعل مع JavaScript مع الإمكانات الموجودة في متصفحك.

فيل هوكسورث: في كلتا الحالتين ، المفتاح هنا حول JAMstack هو أننا نتحدث عن الأشياء التي تم تقديمها مسبقًا: يتم تقديمها بشكل ثابت وبعد ذلك ، ربما يتم تحسينها بشكل تدريجي في المتصفح للاستفادة من واجهات برمجة تطبيقات المتصفح وجافا سكريبت وماذا لديك.

فيل هوكسورث: إذن ، دعونا نجري هذه المقارنة الصغيرة جنبًا إلى جنب هنا. مرة أخرى ، أريد فقط أن أكرر نوعًا ما أن JAMstack قد انتقل إلى مستوى أعلى في المتصفح. وإذا رأينا جانبي هذا الرسم التخطيطي ، مع حزمة LAMP على اليسار وبشكل فعال ، JAMstack على اليمين ، قد تعتقد أنه ، حسنًا ، حتى عندما كنا نبني الأشياء باستخدام حزمة LAMP ، ما زلنا إخراج العلامات. ما زلنا نخرج JavaScript. ربما لا نزال نقوم بالوصول إلى واجهات برمجة التطبيقات. لذلك ، من نواحٍ عديدة ، فإن JAMstack يشبه تقريبًا مجموعة فرعية مما كنا نبنيه من قبل.

فيل هوكسورث: كنت أتحدث أحيانًا عن JAMstack باعتباره المكدس المؤكد ، لأنه يضمن مجموعة من الأدوات والتقنيات التي نحتاجها لتقديم موقع. ولكن ، في كلتا الحالتين ، إنها طريقة مبسطة كثيرًا لتقديم موقع يلغي ، نوعًا ما ، الحاجة إلى تنفيذ الأشياء وتنفيذ المنطق على الخادم في وقت الطلب.

فيل هوكسورث: هذا يمكن أن يفعل الكثير من الأشياء. هذا يمكن ، نوعًا ما ، تبسيط عمليات النشر ومرة ​​أخرى ، سأعاود الاتصال بهذا الرسم التخطيطي من وقت لآخر. إذا فكرنا في كيفية نشر الكود الخاص بنا وموقعنا ، لكل عملية نشر ، من أول عملية نشر ، مروراً بدورة حياة التطوير بأكملها ، طوال فترة حياة الموقع. في المكدس التقليدي ، قد نضطر إلى تغيير المنطق والمحتوى لكل مربع في هذا الرسم التخطيطي.

فيل هوكسورث: بينما ، في JAMstack ، عندما نتحدث عن النشر ، نتحدث عن نقل الأشياء إلى CDN ، ونقل الأشياء إلى الخادم الثابت ، وهذا ما يستلزمه النشر. البناء ، نوع المنطق الذي يدير البناء - يمكن تشغيله في أي مكان. لا يلزم تشغيل ذلك في نفس البيئة التي تستضيف خادم الويب. في الحقيقة ، لا! يبدأ مفتاح JAMstack. نضع الفصل في ما يحدث في وقت الطلب ، ونخدم هذه الأصول الثابتة ، مقابل ما يحدث في وقت الإنشاء ، والذي يمكن أن يكون منطقك الذي تقوم بتشغيله للبناء ثم إلى النشر.

فيل هوكسورث: إذن ، هذا النوع من الفصل هو أمر أساسي ، وسأعود إلى ذلك لاحقًا. لدينا جيد جدًا في تقديم الملفات الثابتة ، وإيصال الأشياء إلى CDN أو نقل الأشياء إلى نظام الملفات (خادم الملفات) في مكان ما رأيناه تقدمًا هائلاً نوعًا ما خلال السنوات القليلة الماضية. هناك الكثير من الأدوات والعمليات ، الآن ، التي يمكن أن تساعدنا في القيام بذلك بشكل جيد حقًا. فقط لاستدعاء عدد قليل من الخدمات التي يمكن أن تخدم الأصول الثابتة بشكل جيد وإعطاء مهام سير العمل لتوصيل جهازك إلى تلك البيئة ، فهم المشتبه بهم المعتادون أنك قد تتخيل موفري البنية التحتية السحابية الكبيرة ، مثل Azure و AWS و Google Cloud.

فيل هوكسورث: ولكن هناك آخرون. لذا ، فإن الجزء العلوي على اليمين هو خدمة تسمى Surge ، والتي كانت موجودة منذ بضع سنوات. يسمح لك بتشغيل أمر في بيئة البناء الخاصة بك ونشر الأصول الخاصة بك من خلال بيئة الاستضافة الخاصة بهم. Netlify ، التالي التالي ، هو المكان الذي أعمل فيه ونفعل الشيء نفسه إلى حد كبير ولكن لدينا أتمتة مختلفة أيضًا. يمكنني الذهاب إليه مرة أخرى. والموجود في الأسفل ، موقع بيئة استضافة ثابت آخر ، يسمى الآن.

فيل هوكسورث: هناك مجموعة من الخيارات المختلفة للقيام بذلك ، وكل هذه المساحات توفر أدوات مختلفة للوصول إلى شبكة توصيل المحتوى بأسرع ما يمكن. نشر مواقعك بأسهل طريقة ممكنة. ولديهم جميعًا شيء مشترك حيث يبنون على مبدأ تشغيل شيء محليًا. غالبًا ما أفكر في مُنشئ الموقع الثابت كشيء قد نقوم بتشغيله في بناء والذي عندما نقوم بتشغيله ، فإنه يأخذ أشياء مثل المحتوى والقوالب وربما البيانات من خدمات مختلفة ويخرج شيئًا يمكن تقديمه بشكل ثابت.

فيل هوكسورث: يمكننا معاينة ذلك محليًا في خادمنا الثابت. شيء من السهل القيام به في أي بيئة تطوير محلية ، ومن ثم عملية نشر ذلك هو إيصال ذلك إلى بيئة الاستضافة وبشكل مثالي ، إلى CDN من أجل الحصول على نوع من الحجم. لذلك ، مع وضع هذا النوع من الأساس ، أريد معالجة بعض المفاهيم الخاطئة الشائعة عندما يتعلق الأمر بمواقع JAMstack. ولم أفعل أي خدمة بنفسي من خلال فتح هذا على أنه وصف مواقع JAMstack بأنها JavaScript و APIs و Markup. لأن الاعتقاد الخاطئ الشائع هو أن كل موقع من مواقع JAMstack يجب أن يكون جافا سكريبت وواجهات برمجة تطبيقات ، و Markup ، ولكن هذا النوع من الأشياء التي أغفلناها هو أننا لسنا مضطرين لاستخدام الثلاثة - كل واحد من هؤلاء ، نوع من ، اختياري. يمكننا استخدام الكثير أو القليل من هؤلاء كما نحب. بنفس الطريقة التي لا يحتاج فيها موقع مكدس LAMP بالضرورة إلى الوصول إلى قاعدة بيانات. الآن ، لقد قمت ببناء أشياء في الماضي يتم تقديمها بواسطة خادم Apache ، على جهاز Linux ، وكنت أستخدم PHP ، لكنني لم أصب قاعدة بيانات ولن أبدأ في إعادة تسمية مكدس بالضرورة من أجل ذلك.

فيل هوكسورث: إذا فكرنا في ما هو موقع JAMstack ، فقد يكون مجموعة من الأشياء المختلفة. قد يكون شيئًا تم إنشاؤه باستخدام منشئ موقع ثابت ، مثل Jekyll ، حيث يقوم بسحب المحتوى من ملفات YAML لبناء موقع لا يحتوي على JavaScript ، ولا يصل إلى واجهات برمجة التطبيقات على الإطلاق ، ونحن نقدمه على شيء ، مثل GitHub Pages. أو ، سيكون هذا موقع JAMstack. أو ربما نستخدم مولد موقع ثابت ، مثل Gatsby ، وهو بالأحرى في بيئة Ruby لـ Jekyll ، الآن هذا هو مولد موقع ثابت JavaScript مبني في النظام البيئي React.

فيل هوكسورث: قد يؤدي ذلك إلى سحب المحتوى مرة أخرى ، وهو ينظم ملفات Markdown. قد يكون ذلك مثريًا من خلال الاستدعاءات لواجهات برمجة التطبيقات ، واجهات برمجة تطبيقات GraphQL. قد يكون يقوم بأشياء في المتصفح ، مثل إجراء ترطيب JavaScript لملء القوالب هناك في المتصفح. وقد يتم تقديمه على Amazon S3. هل هذا موقع JAMStack؟ نعم على الاطلاق!

فيل هوكسورث: الانتقال إلى مولد موقع ثابت مختلف ، هوغو ، الذي تم إنشاؤه باستخدام Go! مرة أخرى ، قد ننظم المحتوى في ملفات Markdown ، ونضيف تفاعلات في المتصفح باستخدام JavaScript. ربما لا تستدعي أي واجهات برمجة تطبيقات خارجية وربما تستضيفها على Google Cloud. هل هو جامستاك؟ إطلاقا! كما ترى ، أنا أقوم ببناء موضوع هنا. باستخدام شيء مثل Nuxt ، منشئ موقع ثابت آخر ، تم إنشاؤه الآن في النظام البيئي View. ربما يؤدي ذلك إلى سحب المحتوى من ملفات متجاورة مختلفة؟ مرة أخرى ، ربما نستخدم تفاعلات JavaScript في المتصفح ، وربما ندعو واجهات برمجة التطبيقات للقيام بأشياء مثل التجارة الإلكترونية ، وتقديمها إلى موقع ثابت آخر. بنية تحتية استضافة أخرى مثل Netlify ، هل هي JAMstack؟ نعم إنه كذلك!

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

فيل هوكسورث: وكما تعلمون ، يمكن اعتبار كل هذه الأشياء ، وغيرها الكثير ، JAMstack ، لأنها تشترك جميعًا في سمة واحدة وهي لا يتم تقديم أي منها مع خادم أصلي. لا يتعين على أي منهم الوصول إلى الخادم الذي يؤدي المنطق في وقت الطلب. يتم تقديمها كأصول ثابتة ، ثم يتم إثرائها بجافا سكريبت واستدعاءات لواجهات برمجة التطبيقات بعد ذلك.

فيل هوكسوورث: لذا ، مرة أخرى ، أريد فقط أن أكرر أن JAMstack يعني أنه يمكن تقديمه مباشرة من CDN. لذا ، أريد فقط أن أستدعي بعض التأثيرات والآثار المترتبة على ذلك ، فلماذا نرغب في القيام بذلك؟ حسنًا ، الفكرة الأولى تتعلق بالأمن ، ولدينا مساحة صغيرة جدًا للهجوم ، هنا. إذا فكرنا في (العودة إلى هذا الرسم التخطيطي القديم مرة أخرى) ، الأماكن التي قد نضطر فيها للتعامل مع هجوم ، يتعين علينا تأمين أشياء مثل موازن التحميل وخوادم الويب وخوادم قاعدة البيانات. كل هذه الأشياء ، علينا التأكد من عدم قدرتنا على الاختراق من قبل أي نوع من الهجمات ، وفي الواقع ، CDN.

فيل هوكسورث: إذا زاد عدد القطع التي يمكننا إخراجها من هذا اللغز ، قل عدد الأماكن التي يمكن مهاجمتها وقل عدد الأماكن التي يتعين علينا تأمينها. وجود عدد قليل من الأجزاء المتحركة للهجوم هو حقًا مفيد للغاية. في Netlify ، نقوم بتشغيل شبكات CDN الخاصة بنا ، لذلك نحصل على رفاهية القدرة على مراقبة حركة المرور التي تأتي عبرها ، وعلى الرغم من أن جميع المواقع المستضافة على Netlify ، فإن جميع مواقع JAMstack التي قد تتخيلها ، لا شيء منها لديك صفحة مسؤول WordPress عليها لأنها منفصلة تمامًا. لا يوجد مسؤول WordPress ، لكننا نرى حجمًا هائلاً من حركة المرور ، والبحث عن أشياء مثل WP Admin ، والبحث عن طرق ، والبحث عن ناقلات الهجوم.

فيل هوكسورث: أحب حقًا بعض الأشياء التي قام بها كينت سي دودز. لا أعرف ما إذا كنت معتادًا على مجتمع React ، فمن المحتمل أنك واجهت Kent C. Dodds في الماضي. إنه لا يستخدم WordPress ، لكنه لا يزال يوجه عنوان URL هذا ، WPAdmin. أعتقد أنه اعتاد أن يوجهها إلى فيديو ريك رول على موقع يوتيوب. إنه بالتأكيد يتصيد الأشخاص الذين ذهبوا للبحث عنه. لكن النقطة المهمة هي ، من خلال فصل الأشياء بهذه الطريقة ، وتحريك الأشياء التي تحدث ، وبناء الوقت مما يحدث في وقت الطلب ، يمكننا فقط تقليل تعرضنا بشكل كبير. ليس لدينا أجزاء متحركة وقت الطلب. يتم فصل جميع الأجزاء المتحركة تمامًا في وقت الإنشاء. من المحتمل ، تمامًا ، حسنًا ، بالضرورة على بنية تحتية مختلفة تمامًا.

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

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

فيل هوكسورث: هذا ، إذن ، يبدأ نوعًا ما ، في تلميح إلى التوسع أيضًا. وبالمقياس الذي أتحدث عنه ، كيف نتعامل مع كميات كبيرة من حركة المرور؟ ستبدأ المداخن التقليدية في إضافة البنية التحتية من أجل التوسع. لذا ، نعم ، للتخزين المؤقت. لقد بدأنا في وضع مكدسنا التقليدي. سيساعد ذلك - إلى حد ما. ما يحدث عادةً هو ، من أجل التعامل مع كميات كبيرة من حركة المرور ، سنبدأ في توسيع البنية التحتية والبدء في إضافة المزيد من الخوادم ، والمزيد من القطع للتعامل مع هذه الطلبات ، وتكلفة هذه الأشياء وتقدير الحمل هو عبء كبير ويمكن أن تكون مصدر إزعاج لأي شخص يقوم بعمل الهندسة المعمارية التقنية. كان ذلك بالتأكيد بالنسبة لي ، وهذا هو السبب في أنني بدأت في الميل أكثر نحو القيام بنهج JAMstack حيث أعرف فقط أن كل شيء يتم تقديمه من CDN ، المصمم افتراضيًا للتعامل مع المقياس ، للتعامل مع الأداء مباشرة خارج البوابة .

فيل هوكسورث: حسنًا ، أريد أيضًا أن أعطي إيماءة لتجربة المطور ، والتأثير الذي يمكن أن يحدث هناك. الآن ، لا ينبغي أبدًا اعتبار تجربة المطور شيئًا يتفوق على تجربة المستخدم ، لكنني أعتقد أن تجربة المطور الجيدة يمكن أن تقلل الاحتكاك ، ويمكن أن تسمح للمطورين بالقيام بعمل أفضل بكثير في بناء تجارب مستخدم رائعة!

فيل هوكسوورث: لذلك ، عندما نفكر في المكان الذي تعيش فيه تجربة المطور ، وأين توجد مجالات اهتمام المطور هنا: حسنًا ، في المكدس التقليدي ، قد نحتاج إلى التفكير في كيفية حصولنا على الكود لكل هذه الأشياء المختلفة أجزاء من البنية التحتية ، وكيف يلعبون جميعًا معًا. في عالم JAMstack ، حقًا ، ما نتحدث عنه هو هذا المربع الموجود في الأسفل. كما تعلم ، كيف قمنا بتشغيل البناء وهم ، كيف يمكننا أتمتة النشر للحصول على شيء يتم تقديمه في المقام الأول؟ والشيء الجميل هو أنه في نموذج JAMstack ، ما تفعله في هذا البناء متروك لك تمامًا.

فيل هوكسورث: هذه مساحة مشكلة محددة جيدًا حقًا ، لأنك في النهاية تحاول بناء شيء يمكنك تقديمه مباشرة من CDN. تريد عرض شيء ما مسبقًا ، باستخدام أي أدوات تريدها: سواء كان مولد موقع ثابتًا مبنيًا في Ruby أو Python أو JavaScript أو Go أو PHP ، فلديك الحرية في تحديد هذا الخيار. وهكذا ، يمكن أن يخلق ذلك بيئة أفضل بكثير للعمل فيها. وأيضًا ، يخلق فرصة للحصول على ثقة مطور حقيقية لأن السمة الحقيقية لمواقع JAMstack هي أنه يمكن استخدامها بسهولة أكبر كنشر ثابت وغير قابل للتغيير.

فيل هوكسورث: وأريد ، نوعًا ما ، القفز بعيدًا عن الشرائح للحظة فقط ، لوصف ما يعنيه ذلك ، لأن النشر الثابت والنشر الذري يمكن ... (قد يبدو ذلك قليلاً مثل كلام التسويق) ولكن ما سأفعله ، هو أنني سأنتقل إلى متصفحي. الآن ... في الواقع ، سأعود لثانية واحدة. اسمحوا لي ... فقط افعل هذا.

فيل هوكسورث: ها نحن ذا. سيكون هذا أسهل. القفز مباشرة إلى الصفحة. الآن ، سكوت ، ستخبرني ، سكوت ، إذا لم تتمكن من رؤية المتصفح الخاص بي ، آمل ذلك. الآن ، على افتراض أن كل شخص يمكنه رؤية متصفحي.

سكوت: كل شيء يبدو جيدًا.

فيل هوكسورث: ممتاز! شكرا جزيلا!

فيل هوكسوورث: ما أفعله هنا ، هو أنني أستخدم Netlify كمثال ، كمثال على الخدمة. ولكن ، هذه سمة مشتركة للمواقع التي يمكن استضافتها بشكل ثابت. لذلك ، عندما نتحدث عن نشر غير قابل للتغيير ، ما نعنيه هو ، أنه بدلاً من ذلك ، يجب أن تلمس كل عملية نشر للكود أجزاء مختلفة من البنية التحتية ، وتغيير الكثير من الأشياء ، فنحن لا نغير حالة الموقع على الخادم. نقوم بإنشاء مثيل جديد تمامًا للموقع لكل عملية نشر تحدث. ويمكننا فعل ذلك لأن الموقع عبارة عن مجموعة من الأصول الثابتة.

فيل هوكسورث: هنا ، أنظر إلى النشر الذي حدث من موقع الويب الخاص بي. سأعطيك علاج. ها أنت ذا ، هذا ما يبدو عليه الأمر. إنها مجرد مدونة ، لا تبدو وكأنها أي شيء مميز أو مثير بشكل خاص. إنها مدونة تم إنشاؤها بشكل ثابت ، ولكن ما لدي هنا هو كل عملية نشر حدثت على الإطلاق ، وتستمر إلى الأبد ، لأنها مجموعة من الأصول الثابتة التي يتم تقديمها من خلال CDN. الآن ، يمكنني العودة بقدر ما يمكن أن يحملني تاريخي وينظر إلى الموقع ، حيث كان مرة أخرى ... متى كان هذا؟ كان هذا في أغسطس 2016. وبفضل كونه مجموعة من الأصول الثابتة ، يمكننا استضافة هذا على عنوان URL الخاص به والذي يستمر إلى الأبد ، وإذا أردت ذلك ، يمكنني أن أقرر الدخول ونشر ذلك تعيين.

فيل هوكسورث: إذن ، الآن ، أي شخص يبحث في موقع الويب الخاص بي ، إذا عدت إلى موقع الويب الخاص بي هنا ، إذا قمت بتحديث تلك الصفحة ، يتم الآن تقديمها مباشرة من CDN مع الأصول التي كانت موجودة من قبل. الآن ، يمكنني التنقل مرة أخرى. هنا تستطيع ان ترى. انظر ، كنت أتحدث عن هذا ، كنت أستخدم هذه المصطلحات الرهيبة مثل العرض المتماثل وأتحدث عن JAMstack مرة أخرى في عام 2016. لذلك ، هذا الآن ما يتم تقديمه مباشرة على موقعي. مرة أخرى ، لأن هناك عمليات نشر متبادلة تستمر إلى الأبد. سأضع راحة البال ، نوعًا ما ، راحة البال ، سأذهب - هل هذه هي الصفحة الأولى؟ نعم. سأعود إلى آخر عملية نشر. سأضطر إلى الإغلاق مرة أخرى ، وإعادتي إلى العالم الحقيقي. اسمحوا لي فقط أن أتأكد من أن هذا على ما يرام.

فيل هوكسورث: حسنًا! رائعة! إذن ، الآن ، يعود هذا إلى خدمة إصداري السابق ، أو أحدث إصدار من الموقع. سأعود إلى الكلمة الرئيسية. لذا ، هذا ممكن لأن الأشياء غير قابلة للتغيير وذرية. ويعني الجزء الذري من ذلك ، مرة أخرى ، أن الانتشار قد تم احتواؤه بالكامل. لذلك ، لا تعرف أبدًا النقطة التي تتوفر بها بعض الأصول على خادم الويب ، لكن بعضها لن يتوفر. فقط عندما يكون كل شيء موجودًا في السياق ويكون كل شيء هناك ، مكتمل ، نقوم بتبديل خدمة الموقع إلى الإصدار الجديد. مرة أخرى ، هذا هو نوع الأشياء التي يمكنك القيام بها بسهولة أكبر إذا كنت تبني الأشياء كموقع JAMstack يخدم مباشرة من CDN كمجموعة من الأصول.

فيل هوكسورث: لقد لاحظت أن المؤقت الخاص بي قد تمت إعادة ضبطه ، بعد الرجوع والتقديم من الكلمة الرئيسية ، لذلك أعتقد أن لدي حوالي ست أو سبع دقائق متبقية. قل لي ، سكوت ، إذا -

سكوت: حسنًا ، ما زلنا بحالة جيدة لمدة عشر دقائق تقريبًا.

فيل هوكسورث: عشر دقائق؟ حسنًا ، رائع!

سكوت: ليس هناك استعجال.

فيل هوكسورث: شكرًا لك ، يجب أن يكون ذلك جيدًا!

فيل هوكسوورث: لذا ، ما عليك سوى تبديل الترس قليلاً والتحدث عن واجهات برمجة التطبيقات والخدمات (نظرًا لأن واجهات برمجة التطبيقات جزء من JAMstack) ، فإن نوع الخدمات التي قد نكون قادرين على استخدامها في الغالب هو JAMstack. كما تعلم ، ربما نستخدم الخدمات التي أنشأناها داخل الشركة ، أو ربما نستخدم الخدمات المشتراة. هناك الكثير من مقدمي الخدمات المختلفين الذين يمكنهم القيام بأشياء لنا ، وذلك لأن هذه هي خبرتهم. من خلال واجهات برمجة التطبيقات ، قد نقوم بسحب المحتوى من أنظمة إدارة المحتوى كخدمة ، وهناك مجموعة من مقدمي الخدمات المختلفين لهذا الغرض ، والذين يتخصصون في تقديم تجربة إدارة محتوى رائعة ، ثم كشف المحتوى من خلال واجهة برمجة التطبيقات ، لذلك اعتدت أن تكون قادرة على جذبهم.

فيل هوكسورث: وبالمثل ، هناك طرق مختلفة يمكنك من خلالها خدمة الأصول. الأشخاص مثل Cloudary رائعون في هذا ، للقيام بتحسين الصور ، وتقديم الأصول مباشرة إلى مواقعك ، مرة أخرى ، من خلال واجهات برمجة التطبيقات. أو ماذا عن التجارة الإلكترونية؟ كما تعلم ، هناك أماكن مثل Stripe أو Snipcart يمكنها تزويدنا بواجهة برمجة التطبيقات ، حتى لا نضطر إلى بناء هذه الخدمات بأنفسنا والدخول في المشكلات المعقدة للغاية التي تأتي مع محاولة بناء محرك تجارة إلكترونية. وبالمثل ، الهوية ، من أشخاص مثل Auth0 الذين يستخدمون Oauth. هناك الكثير من الخدمات المتاحة ويمكننا استهلاك هذه الأشياء من خلال واجهات برمجة التطبيقات ، إما في المتصفح أو في وقت الإنشاء ، أو في بعض الأحيان مزيج من الاثنين.

Phil Hawksworth: Now, some people might think, “Well, that's fine, but I don't want to give the keys to the kingdom away. I don't want to risk giving these services over to external providers,” and to that, I say, well, you know, vendors who provide a single service really depend on its success. If there's a company that's core business, or entire business, is in building-out an e-Commerce engine, an e-Commerce service for you, they're doing that for all of their clients, all of their customers, so they really depend on its success and they have the specialist skills to do that.

Phil Hawksworth: So, that kind of de-risks it from you a great deal. Especially when you start to factor in the fact that you can have your technical and service-level contracts to give you that extra security. But it's not all about bought services, it's also about services you can build yourselves. Now, there's a number of ways that this can happen, but sometimes, you absolutely need a little bit of logic on the server. And so far, I've just been talking about taking the server out of the equation. So, how do we do that?

Phil Hawksworth: Well, this is where serverless can really come to the rescue. Serverless and JAMstack, they just fit together really beautifully. And when I'm talking about serverless, I'm talking about no functions as a service. I know that serverless can be a bit of a loaded term, but here, I'm talking about functions as a service. Because functions as a service can start to enable a real micro-services architecture. Using things like AWS Lambda or Google Cloud functions or similar functions as a service, can allow you to build out server infrastructure without a server. Now, you can start deploying JavaScript logic to something that just runs on demand.

Phil Hawksworth: And that means, you can start supplementing some of these other services with, maybe, very targeted small services you build yourselves that can run the serverless functions. These kind of smaller services are easier to reason about, understand, build out and they create much greater agility. I want to just mention a few examples and results from JAMstack sites. I'm not going to go down the server list avenue too much, right now. We can, maybe, come back to that in the questions. I really just kind of want to switch gear and, thinking about time a little bit, talk about some examples and results.

Phil Hawksworth: Because there are some types of sites that lend themselves in a very obvious way to a JAMstack site. Things like the documentation for React, or Vuejs, those [inaudible 00:32:40], pre-rendered JAMstacks sites. As do sites for large companies, such as Citrix, this is a great example of Citrix multi-language documentation. You can actually view the video from the JAMstack conference that happened in New York, where Beth Pollock had worked on this project, talked about the change that went on in that project. From building on traditional, non-enterprised infrastructure to a JAMstack approach and building with Jekyll, which is not necessarily the fastest generating static site generator, but still, they saw a huge improvement.

Phil Hawksworth: Beth talked about the turnaround time for updates went from weeks to minutes. Maybe people are kind of frowning at the idea of weeks for updates to sites, but sometimes in big complex infrastructure, with lots of stakeholders and lots of moving parts, this really is the situation we're often finding ourselves in. Beth also talked about estimating the annual cost savings for this move to a JAMstack site. To get the site running properly, estimated their savings of around 65%. That's huge kind of savings. Changing gear to a slightly different type of site, something a little closer to home, Smashing Magazine itself is a JAMstack site, which might be a little bit surprising, because on one hand, yes, there's lots of articles and it's also content, which is published regularly, but not every minute of the day, for sure.

Phil Hawksworth: So, that might lend itself, perhaps, for something that's pre-generated, but of course, there's also a membership area and an event section, and a job board, and e-Commerce, and all of these things. This is all possible on the JAMstack because not only are we pre-rendering, but we're also enriching things with JavaScript and the front end to call out to APIs, which let some of these things happen. The project that I think I saw Vitaly arrive in the call, so that's going to be good, we might be able to come back to this in a few minutes.

Phil Hawksworth: But the project that migrated, Smashing Magazine onto a JAMstack approach, I believe, simplified the number of platforms from five, effectively down to one. And I'm using Vitaly's words directly here: Vitaly talked about having some caching issues, trying to make the site go quickly, using probably every single WordPress caching plug-in out there, and goodness knows, there are a few of them! So, Smashing Magazine saw an improvement in performance, time to first load went from 800 milliseconds to 80 milliseconds. Again, I'm simplifying the infrastructure that served the site up in the first place. So, it's kind of interesting to see the performance gains that can happen there.

Phil Hawksworth: Another totally different type of site. This is from the Google Chrome team, who built this out to demonstrate at Google I/O this year. This very much feels like an application. This is Minesweeper in a browser. I apologize if you're watching me play this. I'm not playing it while talking to you; I recorded this sometime ago and it's agony to see how terrible I seem to be at Minesweeper while trying to record. That's not a mine, that can't be!

Phil Hawksworth: Anyway, we'll move on.

Phil Hawksworth: The point of that is, this is something that feels very much more like an app, and it was built in a way to be very responsible about the way it used JavaScript. The payload to interactive was 25KB. This progressively would download and use other resources along the way, but it meant that the time to interact was under five seconds on a very slow 3G network. So, you can be very responsible with the way you use JavaScript and still package up JavaScript, as part of the experience for a JAMstack site.

Phil Hawksworth: So, I'm kind of mindful of time. We're almost out of time, so what is the JAMstack? Well, it's kind of where we started from. JAMstack sites are rendered in advance: they're not dependent on an origin server (that's kind of key), and they may be progressively enhanced in the browser with JavaScript. But as we've shown, you don't have to use JavaScript at all. You might just be serving that statically, ready to go, without that. It's an option available to you.

Phil Hawksworth: This key tenant, I think of, JAMstack sites is they're served without web service. They're pre-rendered and done in advance.

Phil Hawksworth: If you're interested in more, it's already been mentioned a little bit, there is a conference in London in July — July 9th and 10th. The speakers are going to be talking about all kinds of things to do with performance in the browser, things that you can do in the browser, results of building on the JAMstack and things to do with serverless.

Phil Hawksworth: There's also a bunch of links in this deck that I will share, after this presentation, including various bits and pieces to do with static site generation, things like headless CMS, the jamstack.org site itself, and a great set of resources on a website called “The New Dynamic” which is just always full of latest information on JAMstack. We're out of time, so I'll wrap it up there, and then head back across to questions. So, thanks very much for joining and I'd love to take questions.

Scott: Thanks, Phil. That was amazing, thank you. You made me feel quite old when you pulled up the Minesweeper reference, so—

Phil Hawksworth: (laughs) Yeah, I can't take any credit for that, but it's kind of fascinating to see that as well.

Scott: So, I do think Vitaly is here.

Vitaly: Yes, always in the back.

Phil Hawksworth: I see Vitaly's smiling face.

Vitaly: Hello everyone!

Phil Hawksworth: So, I'm going to hand it over to Vitaly for the Q&A, because I seem to have a bit of a lag on my end, so I don't want to hold you guys up. Vitaly, I'll hand it over to you.

Scott: Okay. Thanks, Scott.

Vitaly: Thanks, Scott.

Vitaly: Hello—

Vitaly: Oh, no, I'm back. مرحبا بالجميع. Now Scott is back but Phil is gone.

Scott: I'm still here! Still waiting for everything.

Vitaly: Phil is talking. Aw, Phil, I've been missing you! I haven't seen you, for what, for days, now? It's like, “How unbelievable!” Phil, I have questions!

Vitaly: So, yeah. It's been interesting for us, actually, to move from WordPress to JAMstack — it was quite a journey. It was quite a project, and the remaining moving parts and all. So, it was actually quite an undertaking. So, I'm wondering, though, what would you say, like if we look at the state of things and if we look in the complexes, itself, that applications have. Especially if you might deal with a lot of legacy, imagine you have to deal with five platforms, maybe seven platforms here, and different things. Maybe, you have an old legacy project in Ruby, you have something lying on PHP, and it's all kind of connected, but in a hacky way. حق؟ It might seem like an incredible effort to move to JAMstack. So, what would be the first step?

Scott: So … I mean, I think you're absolutely right, first of all. Re-platforming any site is a big effort, for sure. Particularly if there's lots of legacy. Now, the thing that I think is kind of interesting is an approach that I've seen getting more popular, is in identifying attributes of the site, parts of the site, that might lend themself more immediately to being pre-generated and served statically than others. You don't necessarily have to everything as a big bang. You don't have to do the entire experience in one go. So, one of the examples I shared, kind of, briefly was the Citrix documentations site.

Scott: They didn't migrate all of Citrix.com across to being JAMstack. They identified a particular part that made sense to be pre-rendered, and they built that part out. And then, what they did was they started to put routing in front of all the requests that would come into their infrastructure. So, it would say, “Okay, well, if it's in this part of the past the domain, either in the sub-domain or maybe, through to a path, route that through something which is static, then the rest of it, pass that through to the rest of the infrastructure.

Scott: And I've seen that happen, time and time again, where with some intelligent redirects, which, thankfully, is something that you can do reasonably simply on the JAMstack. You can start to put fairly expressive redirect engines in front of the site. It means that you can pass things through just that section of the site that you tried to take on as a JAMstack project. So, choosing something and focusing on that first, rather than trying to do a big bang, where you do all of the legacy and migration in one. I think that's key, because, yeah, trying to do everything at once is pretty tough.

Vitaly: It's interesting, because just, I think, two days, maybe even today, Chris Coyier wrote an article renaming JAMstack to SHAMstack where, essentially, it's all about JavaScript in which we need think about steady coasting, because JavaScript could be hosted steadily as well. And it's interesting, because he was saying exactly that. He actually — when we think about JAMstack, very often, we kind of tend to stay in camps. It's either, fully rendered and it lives a static-thing. Somewhere there, in a box and it's served from a city and that's it, or it's fully-expressive and reactive and everything you ever wanted. And actually, he was really right about a few things, like identifying some of the things that you can off-load, to aesthetic-side, generated assets, so to say, to that area.

Vitaly: And, JAMstackify, if you might, say some of the fragments of your architecture. Well, that's a new term, I'm just going to coin, right there! JAMstackify.

Phil Hawksworth: I'm going to register the domain quickly, before anybody else.

Phil Hawksworth: And it's a nice approach. I think, it kind of makes my eye twitch a little bit when I hear that Chris Coyier has been redubbing it the SHAMstack, because it makes it sound like he thinks it's a shambles. But I know that he's really talking about static-hosting and markup, which I—

Vitaly: Yes, that's right.

فيل هوكسورث: يعجبني حقًا ، لأن مصطلح JAMstack يمكن أن يكون مضللًا حقًا ، لأنه يحاول تغطية العديد من الأشياء المختلفة ، والنقطة التي كنت أحاول القيام بها ، ربما أعددتها مرات عديدة في تلك الشريحة ، وهي أنه يمكن أن يكون من جميع الأنواع من الأشياء. إنه واسع جدًا ، لكن المفتاح هو العرض المسبق واستضافة جوهر المواقع بشكل ثابت. من السهل جدًا علينا الدخول في حروب دينية حول المكان الذي يجب أن يكون فيه موقع React. يجب أن يكون تطبيق React ، لكي يكون موقع JAMstack ، أو تطبيق React ، لذلك لا يمكن أن يكون JAMstack. ولكن ، في الحقيقة ، فإن جوهرها هو ، سواء كنت تستخدم JavaScript أم لا ، سواء كنت تستدعي واجهات برمجة التطبيقات أم لا ، إذا قمت بالتقديم المسبق وحصلت على الأشياء في مضيف ثابت يمكن أن يكون عالي الأداء ، فهذا هو جوهر JAMstack.

فيتالي: نعم ، بالتأكيد.

فيل هوكسورث: نحن محظوظون جدًا لأن المتصفح أصبح أكثر قدرة ، وواجهات برمجة التطبيقات الموجودة داخل المتصفح نفسها يمكن أن تسمح لنا بعمل المزيد أيضًا. لذلك ، يفتح هذا النوع من الأبواب إلى أبعد من ذلك ، لكن هذا لا يعني أن كل شيء نبنيه كموقع JAMstack يجب أن يستفيد من كل شيء. اعتمادًا على ما نحاول تقديمه ، هذه هي الطريقة التي يجب أن نبدأ بها في اختيار الأدوات التي نلعب بها لنشر هذه الأشياء.

فيتالي: بالتأكيد. لدينا دوران هنا. دوران ، أعتقد أنني أعرف ، دوران. لدي شعور بأنني أعرف دوران. إنه يسأل ، "هل تتوقع أن ينجذب بدون خادم نحو التكامل السلس مع JAMstack من [غير مسموع 00:44:36]؟ ما يشار إليه باسم A في JAM.

فيل هوكسورث: هذا سؤال رائع ، لأنني أعتقد أن الوظائف التي لا تحتاج إلى خادم هي - إنها تسير بشكل جيد مع مواقع JAMstack ، لأنه من نواح كثيرة ، في الواقع ، أعتقد أن أحدهم سألني ذات مرة عما إذا كانت مواقع JAMstack بدون خادم ، ولذا فقد تراجعت بشأن هذا السؤال ، لأن مصطلح بدون خادم تحميل مثل هذا المصطلح. ولكن ، من نواحٍ عديدة ، يعد هذا أمرًا رائعًا لأنني كنت أتحدث مرارًا وتكرارًا ، حول عدم وجود خادم أصل. لا توجد بنية أساسية للخادم يمكنك إدارتها. في الواقع ، لقد كتبت ذات مرة مدونة بعنوان "Web Serverless" ، لأن العالم يحتاج إلى مصطلح آخر للطنين ، أليس كذلك؟

فيل هوكسورث: وفي الحقيقة ، كان هذا نوعًا ما ، نعم ، نحن نبني أشياء بدون خوادم. لا نريد أن نضطر إلى إدارة هذه الخوادم ، والوظائف التي لا تحتاج إلى خادم ، أو الوظائف كخدمة ، تتناسب تمامًا مع ذلك تمامًا. لذلك ، في الحالات التي تحتاج فيها إلى واجهة برمجة التطبيقات (API) التي تريد تقديم طلب إليها ، حيث لا يكون من المنطقي حقًا تقديم هذا الطلب مباشرة من المتصفح. لذلك ، على سبيل المثال ، إذا كان لديك أسرار أو مفاتيح في هذا الطلب ، فقد لا ترغب في الكشف عن هذه الطلبات - تلك المعلومات - في العميل. ولكن يمكننا بالتأكيد تفويض هذه الأشياء ، وعادة ما نحتاج إلى القيام به بعد ذلك ، عادةً ، هو إنشاء خادم ، ولديه بعض البنية التحتية التي كانت تفعل أكثر قليلاً من معالجة الطلبات ، وإضافة مصادقة الأمان إليها ، وتمرير هذه الطلبات ، وكيلة لهم مرة أخرى.

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

فيتالي: حسنًا ، هذه إجابة شاملة للغاية. في الواقع ، حضرت حديثًا مؤخرًا ، حيث كان مهندس الواجهة الأمامية من أمازون يتحدث عن وظائف بدون خادم ووظائف Lamda التي يستخدمونها - لقد كنت على وشك الانتهاء. كان يتحدث دائمًا عن Docker و Kubernetes وكل هذه الأشياء ، Devox World ، كنت جالسًا هناك أفكر ، "كيف انتهى به المطاف هناك. أنا لا أفهم ما الذي يحدث! " لم يكن لدي أي فكرة عما يحدث.

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

فيل هوكسورث: من المرجح أن أكون قادرًا على استخدام بعض هذه الأشياء ، وتقديم الأشياء بطريقة آمنة ، بدلاً من مجرد تجربة خاصة بي ، وهو المكان الذي اعتدت أن أكون فيه مرقطًا. لذلك ، يبدو أننا أصبحنا أكثر قوة كمطورين ويب ، وهو أمر مثير بالنسبة لي.

فيتالي: مثل باور رينجرز ، هاه؟

فيتالي: على الرغم من ذلك ، هناك شيء واحد أريد أن أسألك عنه ، وهذا في الواقع شيء ناقشناه بالفعل ، ربما ، منذ أسبوع ، لكنني ما زلت أريد طرحه ، لأن الشيء الوحيد الذي ذكرته في الجلسة كان الفكرة من الحصول على مثيل مستقل لكل عملية نشر ، وهو أمر رائع حقًا. ومع ذلك ، فإن السؤال هو إذا كان لديك مهمة كبيرة ، مع عشرات الآلاف من الصفحات ، فأنت لا تريد حقًا إعادة نشر كل شيء ، في كل مرة. لذلك ، بشكل أساسي ، إذا كان لديك ، مثل ، إذا كنت تستخدم في الغالب الجانب الثابت للأشياء. لذلك ، خطرت لنا هذه الفكرة لفترة من الوقت وأنا أعلم أن هذا في الواقع شيء ذكرته في المرة السابقة. فكرة الانتشار الذري.

فيتالي: حيث تم تقديم نوع ما من div بين نسختين مختلفتين من لقطات الإعداد. لذلك ، إذا قلت ، قم بتغيير العنوان في كل مكان ، ثم بالطبع ، يجب إعادة نشر كل صفحة على حدة. ولكن إذا غيرت ، ربما ، مكونًا ، لنفترض ، دائريًا ، ربما يؤثر فقط على 1000 صفحة ، فسيكون من المنطقي إعادة نشر 15000 صفحة. لكن فقط هذه الألف. لذا ، هل يمكننا الوصول إلى هناك؟ هل هي فكرة سحرية موجودة ، أم أنها شيء ملموس تمامًا في هذه المرحلة؟

فيل هوكسورث: أعتقد أن هذا هو ، على الأرجح ، الكأس المقدسة لمولدات المواقع الثابتة وهذا النوع من النماذج لأنك ، بالتأكيد ، قد حددت أكبر عقبة يجب التغلب عليها. أو أكبر سقف تصطدم به. وهي مواقع الويب التي تحتوي على العديد ، أو عشرات الآلاف أو مئات الآلاف ، أو الملايين من عناوين URL - فكرة أن الإنشاء يمكن أن يصبح طويلًا جدًا. أن تكون قادرًا على اكتشاف عناوين URL التي ستتغير ، بناءً على تغيير الرمز ، يمثل تحديًا. ليس من المستحيل التغلب عليه ، لكنه تحد كبير. فهم ماهية الرسم البياني للتبعية عبر موقعك بالكامل ثم نشر ذلك بذكاء - هذا أمر صعب حقًا.

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

فيل هوكسورث: لكن هذا ليس مثاليًا بالنسبة لي. هذا ليس السيناريو المثالي حقًا. أحد الأساليب التي قمت باستكشافها قليلاً ، فقط كدليل على المفهوم ، هو التفكير في كيفية قيامك بالأشياء ، مثل الاستخدام الذكي لـ 404s. لذلك ، على سبيل المثال ، حالة استخدام كبيرة للعلامات الكبيرة جدًا ، ربما تكون المواقع الإخبارية ، عندما تحتاج إلى عنوان URL عند حدوث قصة إخبارية عاجلة ، يجب أن يكونوا أول من ينشرها هناك. إنهم بحاجة إلى الحصول على عنوان URL هناك. أشياء مثل بي بي سي نيوز ، سترى أن القصة الإخبارية ستصل إلى الموقع الإلكتروني ، ثم العمل الإضافي ، سوف يضيفون إليها ، بشكل تدريجي ، لكن الوصول إلى هناك أولاً هو المفتاح. لذلك ، امتلاك تصميم يستغرق 10 دقائق ، 20 دقيقة ، مهما كان ، قد يكون ذلك مشكلة.

فيل هوكسورث: ولكن ، إذا كان المحتوى مجردًا وربما تم استدعاؤه من واجهة برمجة التطبيقات. لقد ذكرت أنظمة إدارة المحتوى المستخرجة ، مثل Contentful ، أو Sanity ، أو مجموعة من هؤلاء. يتغير أي شيء يحتوي على واجهة برمجة تطبيقات للمحتوى إلى بنية المحتوى التي ستؤدي إلى إنشاء بنية وسنمر بالتشغيل ، ولكن الشيء الآخر الذي يمكن أن يحدث هو ، حسنًا ، إذا قمت بنشر عنوان URL الخاص بك لذلك ، ثم نشر عنوان URL هذا ، حتى إذا لم يتم تشغيل الإصدار ، إذا قام شخص ما بالنقر فوق عنوان URL هذا ، إذا كانت المحطة الأولى في 404 بدلاً من قول ، "لم نحصل عليه" ، هي في الواقع النقر على واجهة برمجة التطبيقات هذه مباشرةً ، ثم يمكنك القول ، "حسنًا ، لم ينته الإصدار من ملء ذلك بعد ، ولكن يمكنني القيام بذلك في العميل." يمكنني الذهاب مباشرة إلى API ، والحصول على ذلك ، ونشره في العميل.

فيتالي: حسنًا ، ممتع.

فيل هوكسوورث: لذا ، حتى بينما لا يزال البناء قائمًا ، يمكنك البدء في نشر هذه الأشياء. وبعد ذلك ، بمجرد انتهاء البناء ، بالطبع لن يصل إلى 404. ستضغط على تلك الصفحة التي تعمل بشكل ثابت. لذا ، هناك تقنيات وهناك استراتيجيات للتعامل معها ، ولكن مع ذلك ، إنها إجابة طويلة جدًا ومتجولة ، أنا آسف ، لكن استنتاجي هو ، نعم ، هذا يمثل تحديًا. عبرت الأصابع سنحصل على استراتيجيات أفضل.

فيتالي: نعم ، هذا رائع. لذلك ، أنا أتساءل ، لذلك ، في هذه المرحلة ، لا نفكر حقًا ، ليس فقط في الأداء من حيث تقديم المحتوى ، ولكن في الأداء من حيث سرعة الإنشاء. مثل بناء النشر. لذلك ، هذا أيضًا شيء كنا نبحث عنه ، بعض الوقت الآن أيضًا.

فيتالي: أردت أن أسألك شيئًا آخر. لذلك ، هذا مثير للاهتمام ، مثل هذه التقنية التي ذكرتها. كيف تعرف عن هذا؟ هذا مجرد شيء يميل الأشخاص إلى نشره على مدوناتهم الخاصة ، أو هل هو نوع من الوسائط أم أن هناك مستودعًا مركزيًا حيث يمكنك الحصول على نوع من استوديوهات الحالة ، وكيفية انتقال JAMstack - كيف انتقلت الشركات أثناء التفريغ ، أو فشلت في الانتقال إلى جامستاك.

فيل هوكسورث: حسنًا ، إنه نوع من نضج هذا المشهد قليلاً ، في الوقت الحالي. أعني ، بعض هذه الأمثلة ، أعتقد ، أنني في وضع محظوظ جدًا ، أعمل في مكان ما حيث ألعب دورًا ألعب فيه بالألعاب ، وأبتكر طرقًا ممتعة لاستخدامها والبدء في التجربة معهم. لذا ، فهذه البراهين على المفاهيم هي ، نوعًا ما ، أشياء يمكنني تجربتها ومحاولة مواجهة هذه التحديات. لكن ، كما ذكرت سابقًا ، دراسة حالة تم عرضها في مؤتمر JAMstack في نيويورك ، وبالتأكيد ، أحداث من هذا القبيل ، بدأنا نرى أفضل الممارسات أو الممارسات الصناعية وأساليب الصناعة التي يتم الحديث عنها في هذا النوع من الأحداث. وبالتأكيد ، أرغب في رؤية المزيد والعمل على المزيد من دراسات الحالة للوصول إلى أماكن مثل Smashing Magazines ، حتى نتمكن من مشاركة هذه المعلومات بسهولة أكبر.

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

فيتالي: حسنًا ، إذن ، ربما كان السؤال الأخير مني ، لأنني دائمًا أحب قراءة الأسئلة. لذا ، أرض JAMstack ، إذا كان بإمكانك تغيير شيء ما ، فربما يكون هناك شيء ترغب بشدة في رؤيته ، بخلاف عمليات النشر. أي شيء آخر يجعلك سعيدًا جدًا حقًا؟ هذا من شأنه أن يجعل يومك؟ ما يكون ذلك؟ ماذا يوجد في قائمة أمنياتك لـ JAMstack؟

فيل هوكسورث: يا له من سؤال. أعني ، لو لم نتحدث عن الإنشاءات المتزايدة ، لكان ذلك -

فيتالي: لقد فعلنا ذلك. لقد فات الأوان الآن. تم تمرير هذه البطاقة بالفعل. نحن بحاجة لشيء آخر.

فيل هوكسورث: إذن ،

فيتالي: ما أعنيه ، مثل المنصة ، إذا نظرت إلى المنصة الخلفية ، فهناك الكثير من الأشياء المثيرة التي تحدث. لدينا Houdini ، لدينا مكونات ويب قادمة ، وكل شيء ، حيث يمكنك تغيير المشهد بأكمله لجميع المكونات الصحيحة. على الجانب الآخر ، لدينا كل هذا العالم السحري الخيالي مع SS NGS ، وبالطبع ، لدينا أيضًا تطبيقات من صفحة واحدة وكلها. ما هو أكثر شيء أنت متحمس من أجله؟

فيل هوكسورث: سأكون منزعجًا هنا ، لأن هناك الكثير من الأشياء التي تحدث ، إنه مثير ، وهناك الكثير من الإمكانات الجديدة التي يمكنك الاستفادة منها في المتصفح. الشيء الذي أثارت حماستي حقًا هو أن الناس يظهرون ضبط النفس (يضحك) وكما قلت ، إجابة مملة ، لكني أحب رؤية عمليات الإعدام الرائعة التي يتم تنفيذها بضبط النفس ، بطريقة مدروسة - حول الجمهور الأوسع. إنه حقًا ممتع وممتع للبناء باستخدام مكتبة JavaScript الجديدة الأكثر لمعانًا أو واجهة برمجة تطبيقات المتصفح الجديدة التي ، لا أعرف ، خدش واستنشاق الإمكانات في المتصفح ، والتي نحتاجها بشدة في أي يوم الآن.

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

فيل هوكسورث: ربما لم تكن هذه هي الإجابة بالضرورة -

فيتالي: أوه ، هذه نهاية جميلة. شكرا جزيلا. لا ، هذا مثالي ، هذا حقًا. حسنًا ، شعرت أن كل شيء سار على ما يرام! شكرا جزيلا لوجودك معنا! أنا أسلم لسكوت!

فيل هوكسورث: عظيم!

فيتالي: أنا هنا فقط لألعب الأسئلة والأجوبة. لذا ، شكراً جزيلاً لك يا فيل! ما زلت هنا ، لكن سكوت ، المسرح لك الآن! ربما يمكنك مشاركة ما سيحدث بعد ذلك على Smashing TV معنا؟

سكوت: سأفعل ، ولكن أولاً ، فيل ، لا أطيق الانتظار لأرى كيف يعمل تطبيق Sc scratch-and-sniff API. يبدو مثيرة جدا للاهتمام. و ، فيتالي ، JAMstackify مأخوذ بالفعل.

فيتالي: (حزين) مأخوذة ؟! هل يمكننا شرائه؟

سكوت: لا ، إنه موجود!

فيتالي: حسنًا ، لقد فات الأوان. أنا دائما في وقت متأخر.

فيل هوكسورث: هذا مثير بطريقته الخاصة.

فيتالي: هذه قصة حياتي. أنا دائما في وقت متأخر.

سكوت: الأعضاء القادمون ، أعتقد ، الخميس ، الثالث عشر ، لدينا ol 'pa ، Zach Leatherman ، يتحدث عن أفضل ما يتحدث عنه ، وهو الخطوط. لذا ، فهو يتحدث عن خمسة من تطبيقات الخطوط العامة. وبعد ذلك ، أنا أيضًا مهتم جدًا بالذي سيأتي في التاسع عشر ، وهو تحرير الفيديو ، باستخدام JavaScript و CSS ، مع Eva Faria. لذا ، ترقبوا كلاهما.

سكوت: هذا مرة أخرى ، الخميس المقبل ، مع Zach Leatherman ، ثم في التاسع عشر ، مع Eva ، التي ستتحدث عن تحرير الفيديو في JavaScript و CSS. إذن ، في تلك الملاحظة ، يا فيل ، لا يمكنني رؤيتك بعد الآن ، هل ما زلت هناك؟

فيل هوكسورث: أنا هنا!

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

فيتالي: شكرا جزيلا للجميع!

فيتالي: بالمناسبة ، شيء واحد فقط! ربما ذكرها فيل ، لكن لدينا أيضًا مؤتمر JAMstack في لندن ، في يوليو. لذلك ، هذا شيء يجب الانتباه إليه أيضًا. لكنني سأقوم بالتسجيل وسأحضر سلطتي! لست متأكدًا مما -

سكوت: حسنًا ، وداعًا للجميع!

فيتالي: حسنًا ، وداعًا للجميع.

هذا هو التفاف!

نشكر Smashing members من أعماق قلوبنا لدعمهم المستمر واللطيف - ولا يمكننا الانتظار لاستضافة المزيد من الندوات عبر الإنترنت في المستقبل.

أيضًا ، سيكون فيل هو MCing في SmashingConf Toronto 2019 الأسبوع المقبل وفي JAMstack_conf - نود أن نراك هناك أيضًا!

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