تحطيم بودكاست الحلقة 29 مع ليزلي كوهن وين: كيف Netlify Dogfood The Jamstack؟

في هذه الحلقة ، نسأل كيف يبدو الأمر عند تجربة Jamstack في Netlify. هل يمكنك نشر تطبيق كامل على شبكة توصيل المحتوى؟ درو ماكليلان يتحدث إلى ليزلي كوهن وين ، مهندسة فريق Netlify لمعرفة الإجابة.

وتظهر الملاحظات

• موقع Leslie الشخصي
• ليزلي على تويتر
• نيتليفاي

تحديث اسبوعي

• الغوص في التفاعل و Three.js باستخدام تفاعل ثلاثة ألياف
  كتبه Fortune Ikechi
• أفضل الممارسات لتصميم واجهة المستخدم للتجارة الإلكترونية
  بقلم سوزان سكاكا
• مصادقة تطبيقات React باستخدام Auth0
  بقلم Nefe Emadamerho-Atori
• من الخبراء: التطورات العالمية المتعلقة بإمكانية الوصول الرقمي خلال COVID-19
  كتبه روبن كريستوفرسون
• ما الجديد في Vue 3؟
  كتبه تيمي أومويني

نسخة طبق الأصل

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

ليزلي كوهن وين: أنا محطمة.

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

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

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

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

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

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

درو: أعتقد أنه فاجأني ، عندما بدأت العمل على التطبيق ، إلى أي مدى يتم تحقيقه في الواجهة الأمامية ، لا سيما عندما يتعلق الأمر بالتفاعل مع واجهات برمجة التطبيقات الخارجية والأشياء. أعلم أنه عندما يتفاعل Netlify مع موفر Git الخاص بك ، فإنه ينتقل إلى GitHub ويحصل على قائمة من المستودعات ، كل هذا يحدث بين المستعرض الخاص بك و GitHub. وبصرف النظر عن ربما ... المرور بوظيفة لا تحتوي على خادم والتي تضع بعض الأسرار عند الطلب أو شيء خفيف الوزن من هذا القبيل ، فإن معظم ذلك يحدث بطريقة Jamstack-y. لا يمر بنوع من البنية التحتية الأساسية للواجهة الخلفية لـ Netlify. لذلك ، هذا رائع للغاية. هذا حقًا يذهب إلى أبعد من مجرد موقع ثابت مع عدد قليل من استدعاءات API للقيام بأشياء صغيرة. هذه هي الوظيفة الأساسية الحقيقية ، أليس كذلك ، يتم تنفيذها في المتصفح؟

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

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

ليزلي: ليس هذا على علمي.

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

ليزلي: بالضبط.

درو: وأنت تقول إنه تطبيق React؟

ليزلي: نعم. نعم. تتفاعل. نحن نستخدم React Redux الآن ، والآن نحن PostCSS ، لكننا نجرب أيضًا بنية CSS الخاصة بنا.

درو: ألسنا جميعًا؟ إذن ، أنت تبني التطبيق في React ثم تنشره على Netlify؟

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

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

درو: وباستخدام معاينات النشر ، يصبح هذا النوع في الأساس بيئة التدريج ، أليس كذلك؟

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

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

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

درو: دعنا نقول أنك تواجه مشكلة بمجرد إطلاقها ، ماذا تفعل بعد ذلك؟

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

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

درو: لقد اكتشفت مشكلة هنا.

ليزلي: آه أوه.

درو: أنت تستخدم Netlify لنشر التغييرات على تطبيق Netlify. ماذا لو أدى الخطأ الذي نشرته إلى منعك من التراجع؟ ماذا تفعل بعد ذلك؟

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

درو: أعتقد أنك تحتاج فقط إلى عقل واضح للغاية لإدارة هذا الموقف.

ليزلي: أجل.

درو: لكن يمكن استردادها تمامًا ، يبدو الأمر كذلك.

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

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

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

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

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

درو: إذن ، فإن علامة الميزة تشبه في الأساس مفتاح التبديل في الكود الذي يقول ، "إذا تم تمكين هذه الميزة ، فاستخدم هذا الرمز الجديد ، وإلا استخدم هذا الرمز القديم."

ليزلي: بالضبط.

درو: هل هذا يعني أنك تحصل على نوع من قاعدة التعليمات البرمجية الفوضوية مع كل هذه التشعبات في مكانها؟ كيف تتعامل مع ذلك؟

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

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

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

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

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

ليزلي: بالضبط. إنها طريقة رائعة أيضًا للحصول على تعليقات.

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

ليزلي: نعم. نعم ، بالضبط.

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

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

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

ليزلي: انتهى.

درو: وانتهى الأمر في غضون بضع دقائق وكان بالفعل مضادًا للتغير المناخي.

ليزلي: نعم ، إنه نوع من الحزن.

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

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

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

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

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

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

درو: أعتقد أنه من المحتمل أن يكون هناك عدد قليل من الأشخاص يستخدمون Netlify بشكل مكثف تمامًا مثل Netlify نفسه.

ليزلي: أجل. نعم. أعتقد أن هذا صحيح. أحدق في Netlify عندما أقوم ببنائه وعندما أنشره ، لذا فأنا على دراية به.

درو: ثم في عطلة نهاية الأسبوع تعمل في مشروع جانبي وتجد نفسك مرة أخرى في Netlify.

ليزلي: أجل. هذا في الواقع صحيح جدا. نعم. نعم. نعم فعلا.

درو: هل لديك أي أمثلة مثل كيف تأثر اتجاه المنتج على الإطلاق بالعمل الذي قام به الفريق؟

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

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

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

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

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

ليزلي: بالضبط.

درو: ولكن أيضًا ، كخدمة محسوبة ، تمكنك من الحصول على المزيد من نوع البدلات التي لديك.

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

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

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

درو: أخبرني ، ليزلي ، عن خدمة لقطة الشاشة التي توفرها Netlify؟ لأنني وجدت ذلك مثيرًا للاهتمام حقًا.

ليزلي: أجل. في واجهة المستخدم لدينا… عندما تنشر موقعًا على Netlify ، في واجهة المستخدم ، لدينا لقطة شاشة صغيرة توضح لك عادةً شكل الصفحة الرئيسية للموقع الذي شعرت به. من المضحك أننا طرحنا هذا الأمر ، لأنني كنت أستمع إلى Chris Coyier في حلقته على Serverless منذ وقت ليس ببعيد ، وكان يتحدث عن كيفية عمل لقطات الشاشة في CodePen أيضًا ، وهو في الواقع لا يختلف كثيرًا عن كيفية قيام Netlify بذلك. لكننا في الأساس نشغل Puppeteer لالتقاط لقطة شاشة لموقع المستخدم ، والطريقة التي يتم تشغيلها بالكامل هي أنه تم إعدادها باستخدام وظيفة Netlify. إذن ، هذا مرة أخرى ، مثال على قيامنا بتجربة منتجنا الخاص. لذلك ، نستخدم بشكل أساسي نقطة النهاية هذه وهي وظيفة Netlify داخل تطبيقنا الخاص لإرجاع عنوان URL لتلك الصورة من لقطة الشاشة ، ثم يمكننا تقديم ذلك في التطبيق.

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

ليزلي: نعم بالضبط.

درو: سوبر ذكي ، أليس كذلك؟

ليزلي: أجل. إنه رائع. This is one of those areas where it really pushes me as a frontend engineer to really be more of this JavaScript or Serverless engineer, and think a little bit more about how you're basically writing like an internal API end point for yourself when you create one of these Serverless functions. So, it's exciting because there's so much you can do, but that can make it a little intimidating also because there's so much you can do.

Drew: I sort of find it funny how it's like… that's seemingly a core piece of functionality for Netlify, displaying images alongside your site of what it looks like, yet, it's just implemented with another Netlify feature. And you wonder how far you go before it all disappears in on itself in a big cloud of smoke.

Leslie: Yeah. نعم.

Drew: This sounds like a really nice way to be working, and a very modern way to we're working, but it can't be without its challenges, can it?

Leslie: Absolutely not. I think I've spoken a little bit about what it means sort of as a frontend engineer pushing into sort of some new areas just for me to be thinking about in terms of Serverless and how can we leverage this in the product? I think for me, mastering that sort of back of the frontend side has been an exciting challenge, but certainly there's a lot to learn there. An example of that in our app right now, is that we use Cypress for end-to-end testing of some of the critical flows in our app, and right now we have that set up so that the Cypress end-to-end tests are running on our Deploy Previews in Pull Requests using a GitHub action. So, we use the GitHub action to run those Cyprus tests against the Deploy Previews of the app.

Leslie: Which is really cool, but there's probably a better way to do this than actually using a GitHub action. I actually think that we could use a Netlify Serverless function because those can be triggered on certain events, like a deploy succeeded event. So, there's an opportunity there for us to actually leverage again, Netlify, a little bit more, instead of relying on some of these other tools that maybe we're more familiar with or more comfortable using. So, in terms of challenges, I think it's opening our minds to what this sort of new model of development allows us to do and trying to leverage it.

Drew: Yes, there's so many different ways on there to… with the tooling that's available, to be able to attack a particular problem. At Smashing, we probably shouldn't say there's more than one way to skin a cat.

Leslie: Yikes.

Drew: What's interesting about the workflow as well, is that it's really intensively Git based, which I think suits… it's really developer friendly, isn't it? As a frontend engineer, something that's Git based kind of just feels like home. So, is that all great or are there any problems that come in with that?

Leslie: I think as a developer Git is wonderful. I think in general it solves big, big problems and I'm very happy to have it. But, because we rely on it so heavily and as our internal team has grown as well, you end up having the same problems that Git has when you're talking about Netlify in this workflow, right? So, you end up with a bug on your main branch, yes, it's really easy to roll back the app itself, we talked through what that looks like, and then go in the code and fix it. But what if someone else on your team is working from a broken version of that main branch? Everyone's going to have to rebase, everyone's going to have to communicate, or at least be aware of what happened. And so, it's not so much a Jamstack problem or a Netlify problem, but more of just the age old, how do you coordinate on a team of human beings and how do you use the technology to do that properly?

Drew: And of course, as you add more tools and infrastructure in around what you're doing, then you've got the problem of everything taking a long time to run. I mean, you mentioned Cypress is one thing. I know Cypress is a real headache with the amount of time those end-to-end tests can take to run. Is there other challenges around that growing build time?

Leslie: Yeah, I think that's one of the other things that Jamstack… You're introducing this build time, which for developers is not great. I always try and think about it as what I sort of eat up in that build time, my users are saving in the performance of what they're getting. So, I always try to keep that in mind when I'm frustrated about how long something is taking to build, but certainly I think that's an area of opportunity and a challenge, is figuring out how to keep those build times fast, how to make sure that we can deploy as quickly as possible. Some of it is this sort of tension between wanting to run all your tests, wanting to make sure that you don't deploy a build if a test fails, but at the same time, then you've got to run all those tests.

Leslie: So, it's this constant sort of back and forth between wanting to keep the build times fast, while also making sure that you feel like you're doing your due diligence before you actually deploy something. And we're playing around with some ideas here as well about potentially moving our Cypress tests to be running against production and having some alerting setup that would let us know after the fact, if something had failed. Which is sort of an interesting model, too. So yeah, stay tuned.

Drew: I certainly know that, yes, the dangers of growing build times, just from a developer point of view, from productivity point of view, that if something takes too long to run, you context switch, you start working on something else, and then it just… you lose all the momentum, and maybe you forget to go back and find out whether the build succeeded because you're then so far into the next task.

Leslie: Yeah, definitely.

Drew: So, I guess this isn't the ultimate workflow as it stands at the moment. There must be further we can take it. What sort of opportunities might lie ahead for this way of working?

Leslie: Yeah. So, I think for me, and Netlify in particular, is sort of the thought of collaboration for larger teams. I mean, I know a lot of developers are sort of… have used Netlify for side projects and other things that they're working on, on their own, but thinking about how it can be leveraged on larger teams, like mine. As we get larger and we're growing, more of us are in the app, more of us are using Netlify to deploy our own services, and so everything from even more robust audit logs so that you can go and see who changed this site setting, or who was the last person to deploy something. I think having the ability to organize your sites within your Netlify dashboard, even knowing… assigning someone to a build is sort of an interesting idea to me. Could that be helpful if I knew that my teammate had worked on this build, but then I realized they had to roll it back? And maybe I'm just aware of who's managing that process could be a really useful thing within Netlify itself.

Leslie: And one thing that I've seen sort of thrown around a little bit is perhaps the ability to link to a specific log line in build log. So, for debugging, if you have your build log of your Deploy Preview, and there's an error that got thrown, either from Netlify or from your own code, it'd be nice to be able to link directly to that log line. So, that's sort of a fun, small improvement that I've been thinking about a bit. And that's not even to say we have some new features at Netlify as well, that are pretty exciting. Edge handlers and background functions. I'm still trying to wrap my head around what they all do and exactly how they work, but I know that edge handlers are going to give us the opportunity to do some things with localized content, which could be… have some interesting implications for features we could build in the Netlify app as well.

Drew: Yeah, it's really exciting. I think there are all sorts of people within the Jamstack community who are pushing this the whole thing forward. But I think Netlify, as a service, is one that is really behind it and doing exciting things. And, as I say, I didn't want this to be a big ad for Netlify, but I think you and I both really love the service, so it is exciting to talk about isn't it? If listeners want to get more engaged with learning how to build Jamstack sites or want to get more into this ecosystem, is there a good place to go to learn this stuff?

Leslie: I feel like it's exploding right now. I would certainly point you to the Netlify blog. We try and post some tips and tricks there and announce new features as well. I would give a shout out too, to Learn With Jason. My coworker, Jason Lengstorf does sort of a live stream show, and he does cover… he covers a range of topics, but does some Jamstack specific ones as well. And it's a fun hour of live coding and picking that out. Twitter, I think, is huge, too. So check out Jamstack hashtag.

Drew: Good advice. So, we've been learning all about how Netlify builds Netlify on Netlify. What have you been learning about, Leslie?

Leslie: Oh, that's always a big question. I mentioned Cypress before, we've been working through some of our processes around exactly how we want to run our end-to-end tests, and so I would say that, in general, I've been thinking a lot about that workflow. So, less about the technology itself, but more about what workflows exist for end-to-end testing on the frontend, and what makes sense sort of in this Jamstack model. So, that's been a fun sort of side tangent. And then, on the CSS side of things, we talked a bit about CSS architecture, and I'm starting to get my hands dirty with Tailwind, which has been a fun and exciting and lots to learn and lots of class names to memorize and… Yeah.

Drew: That's exciting stuff. If you, dear listener, would like to hear more from Leslie, you can find her on Twitter where she's @lesliecdubs, and her personal site is leslie.dev. Thanks for joining us today, Leslie, did you have any parting words?

Leslie: Have a great day?