Smashing Podcast ตอนที่ 29 กับ Leslie Cohn-Wein: Netlify Dogfood The Jamstack เป็นอย่างไร?

ในตอนนี้ เราจะถามว่าการลองใช้ Jamstack ที่ Netlify เป็นอย่างไร คุณสามารถปรับใช้ทั้งแอปกับ CDN ได้หรือไม่ Drew McLellan คุยกับ Netlify Staff Engineer Leslie Cohn-Wein เพื่อหาคำตอบ

แสดงหมายเหตุ

• เว็บไซต์ส่วนตัวของเลสลี่
• เลสลี่บน Twitter
• Netlify

อัพเดทประจำสัปดาห์

• เจาะลึก React และ Three.js โดยใช้ react-three-fiber
  เขียนโดย ฟอร์จูน อิเคจิ
• แนวทางปฏิบัติที่ดีที่สุดสำหรับการออกแบบ UI ของอีคอมเมิร์ซ
  เขียนโดย Suzanne Scacca
• การตรวจสอบแอป React ด้วย Auth0
  เขียนโดย Nefe Emadamerho-Atori
• จากผู้เชี่ยวชาญ: การพัฒนาการเข้าถึงข้อมูลดิจิทัลทั่วโลกในช่วง COVID-19
  เขียนโดย โรบิน คริสโตเฟอร์สัน
• มีอะไรใหม่ใน Vue 3?
  เขียนโดย Timi Omoyeni

การถอดเสียง

Drew McLellan: เธอเป็นผู้เชี่ยวชาญด้านส่วนหน้าซึ่งได้รับรางวัลซึ่งมีพื้นเพมาจากออสติน แต่ตอนนี้อาศัยอยู่ที่ดัลลาส รัฐเท็กซัส ผ่านการคุมขังในนิวยอร์กซิตี้ ในช่วงเวลานั้นทำงานให้กับเอเจนซี่ เธอได้สร้างไซต์สำหรับลูกค้า เช่น Nintendo, WorldPride และ Jerry Seinfeld ตอนนี้เธอเป็นวิศวกรส่วนหน้าของพนักงานที่ Netlify ซึ่งเหนือสิ่งอื่นใด เธอทำงานเพื่อสร้างแอปพลิเคชันที่ลูกค้าใช้เพื่อจัดการบริการและการปรับใช้ เรารู้ว่าเธอเป็นวิศวกรส่วนหน้า ที่ประสบความสำเร็จ แต่คุณรู้หรือไม่ เมื่ออาศัยอยู่ในนิวยอร์กซิตี้ เธอทำหน้าที่เป็นผู้ช่วยผู้พิพากษาทำอาหารพริกสามปีติดต่อกัน และนั่นก็เป็นความจริง เพื่อนที่ยอดเยี่ยมของฉัน ยินดีต้อนรับ Leslie Cohn-Wein สวัสดีเลสลี่ คุณเป็นอย่างไรบ้าง?

Leslie Cohn-Wein: ฉันยอดเยี่ยมมาก

Drew: วันนี้ฉันอยากจะคุยกับคุณเกี่ยวกับวิธีที่ Netlify กินอาหารสุนัขของตัวเอง เพื่อใช้ท่าทางที่มีเสน่ห์นั้น เมื่อพูดถึงการสร้างบน Jamstack ฉันควรใส่บริบทนี้เล็กน้อยโดยบอกว่าเมื่อไม่กี่เดือนที่ผ่านมา เราทำงานร่วมกันในทีมเดียวกันที่ Netlify และเมื่อผมไปถึงที่นั่น จริงๆ แล้ว กระบวนการพัฒนาเป็นสิ่งที่แปลกใหม่สำหรับผม แม้ว่าจะผ่านไป 20 ปีในฐานะนักพัฒนาก็ตาม ฉันคิดว่ามันน่าสนใจจริงๆ และควรค่าแก่การสำรวจสักหน่อยกับผู้ชมที่กว้างขึ้น ฉันน่าจะชี้ให้เห็นว่าเรากำลังพูดถึงเรื่องนี้เพราะมันเป็นกรณีศึกษาที่น่าสนใจอย่างแท้จริง และไม่ใช่โฆษณาขนาดใหญ่ที่ได้รับการสนับสนุนสำหรับ Netlify ทุกคนควรตรวจสอบ Vercel แต่ฉันคิดว่ามีหลายสิ่งล้ำค่าที่สามารถเรียนรู้จากการพูดคุย โดยเฉพาะอย่างยิ่งจากมุมมองของ Jamstack เนื่องจาก Netlify เป็นผู้เสนอแนวทาง Jamstack รายใหญ่จริง ๆ และให้บริการแก่ลูกค้าและสร้างขึ้นจากแนวคิดดังกล่าวในการสร้างโครงการ Jamstack แต่บริการนี้สร้างขึ้นโดยใช้หลักการเหล่านั้นด้วย ใช่มั้ย?

เลสลี่: นั่นสินะ ผู้คนจำนวนมากคิดว่าสถาปัตยกรรม Jamstack นั้นเป็นไซต์แบบคงที่ แต่เรากำลังลองใช้จริงๆ ว่าการสร้างแอป Jamstack ด้วยฟรอนต์เอนด์ Netlify มีความหมายอย่างไร เนื่องจากเป็นแอป React ที่เป็นแอป Jamstack เต็มรูปแบบที่เราปรับใช้ Netlify บน Netlify ดังนั้น... ใช่ เรากำลังทดลองใช้จริงและผลักดันขีดจำกัดของสิ่งที่เป็นไปได้

Drew: ฉันคิดว่าบางครั้งมีแนวคิดที่ว่า Jamstack นั้นยอดเยี่ยมสำหรับไซต์สแตติกอย่างที่คุณพูด และด้าน API ก็เข้ามา หากคุณต้องการส่งแบบฟอร์มไปยังที่อยู่อีเมล และคุณสามารถทำอะไรง่ายๆ แบบนั้นได้ แต่คุณ สามารถสร้างเว็บแอปทั้งหมดได้ด้วยวิธีนี้ แต่คุณกำลังทำอย่างนั้นใช่ไหม

เลสลี่: ใช่แน่นอน แอปของเราพูดถึงสิ่งที่คุณเห็นโดยเฉพาะหากคุณลงชื่อเข้าใช้ที่ app.netlify.com ขับเคลื่อนโดย... เรามี REST API ภายใน แต่ส่วนหน้าอย่างที่ฉันพูดคือ Jamstack ล้วนๆ ดังนั้น เรามีขั้นตอนการสร้างของเราเอง เราดูแอปในขณะที่สร้างในแอป และเราปรับใช้บนระบบของเราเอง

Drew: ดังนั้น เมื่อมีกระบวนการแบ็กเอนด์เข้ามาเกี่ยวข้อง และมักจะมีระดับของกระบวนการแบ็กเอนด์อยู่เสมอ เก็บข้อมูลถาวร หรือในกรณีของ Netlify เริ่มต้นด้วยการปรับใช้หรือสิ่งที่คุณมี แบ็กเอนด์นั้นก็แค่ ชนิดของการสร้างเป็นชุดของ API ที่ส่วนหน้าสามารถใช้ได้หรือไม่

เลสลี่: ใช่ มีรูปแบบที่แตกต่างกันสองสามแบบที่คุณจะทำให้งานนี้สำเร็จ ในกรณีส่วนใหญ่ ในแอปของเรา เราใช้การดึงข้อมูลฝั่งไคลเอ็นต์ด้วย React ใช่ไหม ดังนั้นเราจึงให้บริการประเภทสแตติกเชลล์ของแอป จากนั้นเราดึงข้อมูลของผู้ใช้จาก REST API ภายในของเราในเวลาที่ร้องขอ Jamstack น่าสนใจเพราะมีบางสิ่งที่คุณสามารถสร้างไว้ล่วงหน้า และเราพยายามวางใจในสิ่งนั้นเมื่อเราทำได้ และเมื่อเราพูดถึงข้อมูลที่มีไดนามิกมากขึ้น เราจะใช้การดึงข้อมูลฝั่งไคลเอ็นต์เพื่อให้แน่ใจว่าเรากำลังดึงข้อมูลใหม่ล่าสุด

Drew: ฉันคิดว่ามันทำให้ฉันประหลาดใจเมื่อเริ่มทำงานกับแอป ว่าส่วนหน้าทำสำเร็จมากน้อยเพียงใด โดยเฉพาะอย่างยิ่งเมื่อพูดถึงการโต้ตอบกับ API ภายนอกและสิ่งต่างๆ ฉันรู้ว่าเมื่อ Netlify โต้ตอบกับผู้ให้บริการ Git ของคุณ มันจึงไปที่ GitHub และรับรายการ repos ทั้งหมดนั้นจะเกิดขึ้นระหว่างเบราว์เซอร์ของคุณกับ GitHub และนอกเหนือจากบางที... การผ่านฟังก์ชันแบบไม่ใช้เซิร์ฟเวอร์ที่ซ่อนความลับบางอย่างเกี่ยวกับคำขอหรือบางอย่างที่ไม่ซับซ้อนเช่นนั้น ส่วนใหญ่เกิดขึ้นในลักษณะ Jamstack-y มันไม่ได้ผ่านโครงสร้างพื้นฐานแบ็กเอนด์หลักประเภท Netlify นั่นจึงน่าสนใจทีเดียว นั่นเป็นมากกว่าแค่ไซต์คงที่ที่มีการเรียก API สองสามตัวเพื่อทำสิ่งเล็กน้อย นั่นคือฟังก์ชันการทำงานหลักที่แท้จริง ใช่ไหม ที่กำลังใช้งานในเบราว์เซอร์

เลสลี่: แน่นอน ฉันคิดว่ามันเป็นการผลักดันแนวคิดของวิศวกรนักพัฒนาส่วนหน้าใช่ไหม และเป็นสิ่งที่ผลักดันให้ฉันในฐานะวิศวกรส่วนหน้าให้ดีขึ้นและคิดมากขึ้นเกี่ยวกับ... เลเยอร์ API ซึ่งไม่ใช่สิ่งที่ฉันคุ้นเคย ฉันทำงานมากขึ้นใน UI และสีและระบบการออกแบบ และจริงๆ แล้ว… ฉันพบว่าการทำงานบนแอป Jamstack ในปริมาณมาก ได้ผลักดันให้ฉันเป็นนักพัฒนาที่ดีขึ้น

Drew: การเป็นนักพัฒนา frontend นั้นไม่รู้ว่า CSS back to front แม้ว่านั่นจะเป็นส่วนหนึ่งก็ตาม มันไม่รู้จัก HTML กลับไปข้างหน้า แต่นั่นก็เป็นส่วนหนึ่งของมัน นอกจากนี้ยังหลงเข้าไปในอาณาเขตนี้ซึ่งเดิมเป็นการอนุรักษ์วิศวกรส่วนหลังซึ่งค่อนข้างน่าสนใจ Netlify ใช้การเรนเดอร์ฝั่งเซิร์ฟเวอร์ใหม่สำหรับ-

เลสลี่: ไม่ใช่ว่าฉันรู้

Drew: ดังนั้น ทุกอย่างเสร็จสิ้นตามตัวอักษร อย่างที่คุณพูด คุณให้บริการเชลล์ จากนั้นระบบจะเติมคำขอกลับไปยังจุดสิ้นสุด API ต่างๆ เพื่อจัดเรียงการเติมข้อมูลทั้งหมด

เลสลี่: ถูกต้อง

Drew: แล้วคุณบอกว่าเป็นแอพ React เหรอ?

เลสลี่: ครับ ใช่. ตอบสนอง ตอนนี้เราใช้ React Redux และตอนนี้เราคือ PostCSS แต่เรากำลังทดลองกับสถาปัตยกรรม CSS ของเราด้วย

Drew: พวกเราทุกคนไม่ใช่เหรอ? ดังนั้นคุณสร้างแอปใน React แล้วปรับใช้บน Netlify หรือไม่

เลสลี่: ครับ บางทีส่วนที่ฉันชอบที่สุดในกระบวนการทั้งหมดนั้นก็คือความมหัศจรรย์ของ Deploy Previews ซึ่งเราดำเนินการผ่าน Netlify สิ่งที่เกิดขึ้นคือ คุณจะ... คุณกำลังทำงานใน GitHub ผลักดันการประชาสัมพันธ์ของคุณ ดังนั้น คุณเปิด PR ของคุณใน GitHub และนั่นจะสร้างบิลด์ของ Deploy Preview ของแอปโดยอัตโนมัติ ดังนั้นเราจึงใช้ Deploy Previews ของแอปเพื่อทดสอบ เพื่อให้แน่ใจว่าทุกอย่างทำงานตามที่ควรจะเป็น เราทำการทดสอบ นั่นคือสิ่งที่เราใช้เพื่อยืนยันด้วยตนเองระหว่างการตรวจสอบโค้ด ดังนั้นเราจึงได้ตั้งค่าการปรับใช้อย่างต่อเนื่องทั้งหมดจาก GitHub

เลสลี่: แล้วสิ่งที่ยอดเยี่ยมอีกอย่างหนึ่งที่เราได้ตั้งค่าไว้ก็คือ เรามีไซต์ Netlify สองแห่งที่ดึงมาจากที่เก็บข้อมูลเดียวกันกับที่แอปของเราอาศัยอยู่ ดังนั้นเราจึงมีทั้งแอปของเรา เรามีตัวอย่าง Storybook ที่มีส่วนประกอบ UI ของเราสำหรับแอป ดังนั้นเราจึงมีทั้งแอปของเรา เรามีส่วนประกอบ Storybook UI และโดยพื้นฐานแล้วเรามีไซต์ Netlify ที่แสดง Storybook UI ของเรา แล้วเรายังมีไซต์ที่สามที่รันตัววิเคราะห์บันเดิลของ webpack ดังนั้น มันเป็น UI แบบภาพที่ให้คุณมีแผนผังต้นไม้ การแสดงชุดแอปทั้งหมด และเราสามารถวัดขนาดของมันได้ และนี่เป็นเพียงการเตือนให้เราตรวจสอบการจัดเรียงอีกครั้ง เมื่อมีการปรับใช้แอปทุกครั้ง เราสามารถตรวจสอบและทำให้แน่ใจว่าเราไม่ได้ทำอะไรแปลก ๆ กับขนาดบันเดิลของเราที่นั่น ดังนั้นทั้งสามไซต์ดังกล่าวจึงถูกสร้างขึ้นในคำขอดึงแอปเดียว ดังนั้น คุณจะได้รับลิงก์ไปยังหน้าตัวอย่าง Deploy Previews โดยพื้นฐานแล้ว ของทั้ง Storybook ของแอปและโปรไฟล์ของแอปนั้นเพื่อให้เราตรวจสอบได้

Drew: และด้วย Deploy Previews สิ่งนั้นจะกลายเป็นสภาพแวดล้อมการแสดงละครของคุณใช่ไหม

เลสลี่: ถูกต้อง เราไม่ได้ใช้งานสภาพแวดล้อมการแสดงละครแบบเดิมๆ เพราะเราเชื่อมั่นจริงๆ ว่าตัวอย่างการปรับใช้ของเราเป็นสิ่งที่กำลังจะเผยแพร่เมื่อเรากดปุ่มผสานนั้นและเริ่มต้นการสร้างอย่างเป็นทางการของสาขาหลักในแอปหลักของเรา ฉันชอบที่เราสามารถพึ่งพา Deploy Previews เป็นสภาพแวดล้อมการแสดงละครได้ เราเชื่อมั่นอย่างยิ่งว่ามันจะเข้ากับการผลิต เรากำลังสร้างด้วยตัวแปรการผลิตทั้งหมด ทุกอย่างที่... ตัวแปรสภาพแวดล้อม ทุกสิ่งนั้นสร้างขึ้นใน Deploy Preview ดังนั้นจึงค่อนข้างเหมือนกับสถานการณ์ที่ไม่ต้องกังวล ตราบใดที่ Deploy Preview ของคุณยังทำงานอยู่ คุณก็รู้ว่าแอพนั้นก็ใช้งานได้เช่นกัน

Drew: และฉันเดาว่าในฐานะองค์กร ถ้า Deploy Preview ของคุณไม่ตรงกับสิ่งที่ถูกเผยแพร่ นั่นเป็นปัญหาด้านบริการที่ Netlify ต้องการแก้ไข ดังนั้น มันใช้ได้ผลค่อนข้างดีจากมุมมองนั้น ดังนั้น คุณได้ตรวจสอบ Deploy Preview แล้ว ทุกอย่างดูดี PR จะถูกรวมเข้าด้วยกัน แล้วจะเกิดอะไรขึ้น?

เลสลี่: ดังนั้น เนื่องจาก Netlify ใช้งานการปรับใช้อย่างต่อเนื่องทั้งหมดของเรา โดยพื้นฐานแล้วเราจึงเชื่อมต่อทั้งหมดเข้าด้วยกันเพื่อให้การผสานเข้ากับสาขาหลักของเราจะเริ่มการใช้งานจริงกับแอปโดยอัตโนมัติ โดยทั่วไปแล้ว หากคุณเป็นนักพัฒนาซอฟต์แวร์ที่รวม PR ของคุณเองเข้าด้วยกัน คุณจะเข้าสู่โลกแห่งความเป็นจริง... คุณต้องแน่ใจว่า ตรวจสอบแท็บของคุณอีกครั้ง เพราะหากคุณเปิด Deploy Preview ของแอปและแอปนั้นไว้ คุณต้องแน่ใจว่า... คุณมักจะต้องการติดตามในแอปจริง ดังนั้น คุณต้องตรวจสอบแท็บของคุณ แต่ใช่ ในแอป คุณมักจะเข้าไปข้างใน คุณสามารถดูบันทึกการสร้างสำหรับการผสานที่คุณเพิ่งเริ่มต้น ดังนั้นจึงเป็นไปโดยอัตโนมัติทั้งหมด จากนั้นทันทีที่บันทึกการสร้างเหล่านั้นเสร็จสมบูรณ์ และไซต์ใช้งานได้จริง สิ่งที่คุณต้องทำคือรีเฟรชหน้าต่างเบราว์เซอร์ของคุณ และคุณจะเห็นสิ่งที่คุณเพิ่งปรับใช้ ควรได้รับการอัปเดตในแอป

Drew: และสมมติว่าคุณพบปัญหาเมื่อเผยแพร่แล้ว คุณจะทำอย่างไร

เลสลี่: นั่นเป็นคำถามที่ดีมาก และอาจเป็นหนึ่งในสิ่งที่ฉันโปรดปรานเกี่ยวกับการใช้ Netlify ก่อนที่ฉันจะทำงานที่ Netlify นี่เป็นเหมือนเวทมนตร์เล็กน้อยสำหรับฉัน เพราะ Netlify มีการหลอมรวมสิ่งที่เราเรียกว่าการย้อนกลับ ดังนั้น โดยพื้นฐานแล้ว การปรับใช้บน Netlify ทุกครั้ง… เนื่องจากเรากำลังใช้สถาปัตยกรรม Jamstack นี้ การปรับใช้ทุกครั้งจึงเป็นแบบอะตอม นั่นหมายความว่าคุณมีประวัติทั้งหมดของการปรับใช้ทุกประเภทที่คุณเคยทำบนไซต์ และคุณสามารถย้อนกลับไปยังรายการใดรายการหนึ่งได้ทันที ดังนั้น หากเรานำจุดบกพร่องไปใช้งานโดยไม่ได้ตั้งใจหรือมีบางอย่างเสียหาย สิ่งแรกที่เราทำคือหยุดการรวมระบบอย่างต่อเนื่องนั้นจริง ๆ เราจะเข้าไปข้างใน มีเพียงปุ่มเดียวใน Netlify UI ที่คุณพูดว่า "หยุดการเผยแพร่อัตโนมัติ" และสิ่งที่จะทำคือหยุดการเชื่อมต่อกับ GitHub ดังนั้น ถ้าจู่ๆ เพื่อนร่วมทีมของฉันกำลังรวม PR เข้าด้วยกัน เราจะไม่แนะนำจุดบกพร่องนี้อีก ไม่มีอะไรแบบนั้นที่จะเกิดขึ้น

เลสลี่: ดังนั้น เราหยุดการปรับใช้อัตโนมัติเหล่านั้นทั้งหมด จากนั้นทั้งหมดที่ฉันต้องทำคือกลับไปที่รายการการปรับใช้ของฉันและค้นหาการปรับใช้ที่ทำงานล่าสุด กดปุ่มอีกปุ่มหนึ่งที่ระบุว่า "เผยแพร่สิ่งนี้" และใช้งานได้จริง ดังนั้น สิ่งที่ทำ คือ ขจัดความกดดันที่จะย้อนกลับไปได้จริงๆ ดูโค้ด หาว่าเกิดอะไรขึ้นจริงๆ บางครั้งนั่นหมายถึงการทำ Git กลับคืนบนแบรนช์หลักของคุณและนำแบรนช์หลักกลับมาอยู่ในตำแหน่งที่จำเป็น และบางครั้งก็เป็นโปรแกรมแก้ไขด่วนหรือหากคุณออกไปที่สาขาและได้รับการแก้ไขแล้ว และคุณไม่จำเป็นต้องกังวลเกี่ยวกับการคืนค่าใน Git ด้วยซ้ำ จากนั้น เมื่อคุณพร้อมที่จะย้อนกลับ คุณต้องแน่ใจว่าทุกอย่างทำงานบน Deploy Preview ของแอป และคุณสามารถรีเซ็ตข้อมูลทั้งหมดนั้นกลับคืนมาได้ ดังนั้น ทันทีที่คุณเริ่มการทำให้ใช้งานได้อัตโนมัติ คุณก็จะกลับมาทำธุรกิจได้อีกครั้ง

Drew: ดังนั้น ฉันพบปัญหาที่นี่

เลสลี่: เอ่อ.

Drew: คุณกำลังใช้ Netlify เพื่อปรับใช้การเปลี่ยนแปลงกับแอป Netlify จะเกิดอะไรขึ้นถ้าจุดบกพร่องที่คุณได้ทำให้หยุดคุณย้อนกลับ แล้วคุณจะทำอย่างไร?

เลสลี่: ฉันฝันร้าย ไม่ ที่จริงแล้ว เรามีสองวิธีที่จะจัดการกับมันได้ ดังนั้น หากเราลบแอปและเราไม่สามารถใช้ UI เพื่อดำเนินการตามขั้นตอนนี้ การแสดงตัวอย่างการปรับใช้ของเราจะทำงานกับ API ที่ใช้งานจริงของเรา นั่นหมายความว่า แม้ว่าแอปจะไม่ทำงาน เราก็ยังมีการปรับใช้อะตอมมิกเหล่านั้น ดังนั้น หากคุณมีลิงก์จาก GitHub อาจมาจาก PR เก่าหรือใหม่ และคุณมี URL แสดงตัวอย่างการใช้งาน คุณจะสามารถเข้าถึง Deploy Preview ของแอปได้จริง และทำการเปลี่ยนแปลงตามที่คุณต้องการ ย้อนกลับและเผยแพร่การปรับใช้ที่เก่ากว่า จากตัวอย่างการทำให้ใช้งานได้ และมันยังกระทบกับ API การผลิตของเราอยู่ ดังนั้นสิ่งนั้นจะยังส่งผลต่อแอพ จากนั้นจะทำให้แอพกลับมาทำงานอีกครั้ง มันเหมือนกับว่าอีโมจิสมองระเบิดอยู่ที่นั่น แต่เป็นวิธีหนึ่งที่จะทำได้ เราสามารถเผยแพร่การปรับใช้ที่เก่ากว่าจากระบบแบ็กเอนด์บางระบบของเราได้ เราสามารถให้วิศวกรแบ็กเอนด์ของเราเผยแพร่สิ่งนั้นให้เราได้ หรือคุณสามารถใช้ Git เพื่อย้อนกลับและพยายามดันมันขึ้นมาได้เสมอ แต่มันค่อนข้างน่ากลัวเพราะคุณไม่สามารถดูสิ่งที่คุณทำ

Drew: ฉันเดาว่าคุณแค่ต้องมีความคิดที่ชัดเจนในการจัดการสถานการณ์นั้น

เลสลี่: ครับ

Drew: แต่มันสามารถกู้คืนได้ทั้งหมด ดูเหมือนว่าจะเป็นเช่นนั้น

เลสลี่: ครับ และเมื่อคุณเผยแพร่การปรับใช้การทำงานของคุณแล้ว แรงกดดันทั้งหมดก็หายไป นั่นเป็นส่วนที่อร่อยที่สุด และฉันพบว่าสิ่งนี้ใช้งานได้ในหน่วยงานเช่นกัน ความสามารถในการย้อนกลับเป็นเครื่องช่วยชีวิตจริงๆ ... นอกจากนี้ยังทำให้คุณกังวลเกี่ยวกับการเผยแพร่การเปลี่ยนแปลงใหม่น้อยลง หากคุณทำบางสิ่งพัง อาจต้องใช้เวลาสักครู่ในการพลิกกลับ ซึ่งเข้ากันได้ดีกับการเคลื่อนไหวอย่างรวดเร็วและดึงสิ่งต่าง ๆ ออกมาเป็นแบบจำลอง

ดริว : แน่นอน ฉันคิดว่าโดยปกติแล้วเวิร์กโฟลว์ทั้งหมดนี้จะทำงานได้ดีที่สุดเมื่อคุณต้องรับมือกับการเปลี่ยนแปลงเล็กๆ น้อยๆ ฉันหมายถึงในอุดมคติแล้ว คุณต้องการสร้างสาขา ดำเนินการเปลี่ยนแปลงเล็กน้อย เพิ่มการประชาสัมพันธ์ แล้วนำกลับมารวมกันโดยเร็วที่สุด ซึ่งเห็นได้ชัดว่าทำงานได้ดีสำหรับการปรับแต่งและแก้ไขข้อบกพร่องและเรื่องเล็กน้อย แต่ใช้งานไม่ได้ดีสำหรับฟีเจอร์หลักเมื่อฟีเจอร์นั้นอาจใช้เวลาเป็นสัปดาห์หรืออาจถึงเป็นเดือนตั้งแต่เริ่มพร้อมที่จะปรับใช้ คุณจัดการกระบวนการประเภทนั้นอย่างไร?

เลสลี่: ใช่ นั่นเป็นคำถามที่ดี ดังนั้น เมื่อเร็วๆ นี้ เราจึงได้เริ่มใช้การตั้งค่าสถานะคุณลักษณะอีกเล็กน้อย ก่อนที่ฉันจะพูดถึงวิธีการทำแบบนั้นอีกสักหน่อย ฉันจะพูดถึงสิ่งที่เราเคยทำกันมาก่อน ดังนั้น ก่อนที่เราจะใช้แฟล็กคุณลักษณะ ฉันคิดว่าทุกคนคงคุ้นเคยกับแนวคิดของแบรนช์ฟีเจอร์ที่ทำงานยาวนาน เราทุกคนเกลียดพวกเขาใช่มั้ย? แต่เราจะทำงานกับ PR ที่มีขนาดเล็กกว่าของเรา เราจะรวมแต่ละส่วนแยกกัน หลังจากตรวจสอบโค้ดแล้ว ลงในสาขาคุณลักษณะที่ทำงานยาวนานกว่านี้ ดังนั้น โดยพื้นฐานแล้ว คุณจะมีคุณลักษณะใหม่ทั้งหมดของคุณในที่เดียว คุณสามารถมี Deploy Preview หนึ่งรายการที่คุณสามารถทดสอบคุณลักษณะใหม่นั้นด้วย บางครั้ง โมเดลนี้จำเป็นต้องมีการประสานงานร่วมกันในทีมอื่นๆ ดังนั้น เมื่อเราพร้อมที่จะพูดว่า “โอเค ฟีเจอร์แบรนช์นี้ เราพร้อมที่จะรวมมันและใช้งานจริง” บางครั้งนั่นก็หมายความว่า “โอเค คุณต้องแน่ใจว่าแบ็กเอนด์ได้ปรับใช้การเปลี่ยนแปลงของพวกเขาแล้ว” ดังนั้นอะไรก็ตาม งาน API ที่เราทำในคุณลักษณะของเราพร้อมใช้งานแล้ว หากมีเอกสารบนไซต์เอกสารของเราที่จำเป็นต้องเผยแพร่พร้อมกันกับฟีเจอร์ คุณจะต้องประสานงานและกดปุ่มพร้อมกัน

Leslie: โมเดลนี้… มันใช้ได้ผลสำหรับเรา แต่คุณพูดถูก มันอาจจะไม่ได้ราบรื่นที่สุด เป็นเรื่องตลกจริงๆ ที่ Matt Biilmann ผู้ร่วมก่อตั้งและ CEO ของเราที่ Netlify ได้เปิดตัวฟีเจอร์การวิเคราะห์ของเราโดยใช้กระบวนการนี้บนเวทีที่ Jamstack Conf London เมื่อปีที่แล้ว ดังนั้น เขาจึงใช้คุณลักษณะการปรับใช้ล็อกของเราเพื่อนำตัวอย่างการปรับใช้ของคุณลักษณะใหม่ของการวิเคราะห์และเผยแพร่แบบสดบนเวทีโดยพื้นฐาน ดังนั้นมันจึงค่อนข้างเจ๋ง

เลสลี่: แต่อย่างที่คุณพูด มันคือ… คุณมีความมั่นใจน้อยลงเล็กน้อย ทุกอย่างยังคงซ่อนอยู่ในคำขอดึงนี้ มันจะกลายเป็นเทอะทะเล็กน้อย ใครบางคนต้องอนุมัติ Pull Request ขั้นสุดท้ายที่มักจะมีขนาดค่อนข้างใหญ่ ที่ล้นหลามเล็กน้อย ดังนั้น ทุกวันนี้ เราใช้แฟล็กคุณลักษณะเป็นส่วนใหญ่ เราใช้บริการที่เรียกว่า LaunchDarkly ซึ่งช่วยให้เรารวม UI ฟีเจอร์ใหม่ของเราด้วยแฟล็กเหล่านี้ เพื่อให้เราสามารถรวมโค้ดได้อย่างต่อเนื่อง แม้ว่า UI จะไม่ใช่สิ่งที่เราต้องการให้ลูกค้าเห็น ดังนั้น คุณแค่ต้องแน่ใจว่าในสภาพแวดล้อมการใช้งานจริงว่าการตั้งค่าสถานะคุณลักษณะของคุณปิดอยู่ เราสามารถปรับใช้โค้ด รวมและไม่มีใคร... สมมติว่าคุณเป็นผู้ใช้ทั่วไป คุณจะไม่เห็น UI ใหม่นั้น

Drew: ดังนั้น แฟล็กคุณลักษณะก็เหมือนกับสวิตช์ในโค้ดที่ระบุว่า "หากเปิดใช้งานคุณลักษณะนี้ ให้ใช้โค้ดใหม่นี้ มิฉะนั้น ให้ใช้โค้ดเก่านี้"

เลสลี่: ถูกต้อง

Drew: นั่นหมายความว่าคุณได้รับฐานโค้ดที่ยุ่งเหยิงด้วยส้อมเหล่านี้หรือไม่? คุณจัดการกับสิ่งนั้นอย่างไร?

เลสลี่: ใช่ ฉันคิดว่านั่นคือ… ใครก็ตามที่ใช้แฟล็กคุณลักษณะอาจคุ้นเคยกับการต่อสู้แบบนี้ เมื่อใดที่คุณล้างแฟล็กคุณลักษณะ คุณทิ้งพวกเขาไว้ที่นั่นนานแค่ไหน? เราได้ลงจอดประมาณสองสัปดาห์หลังจากที่คุณลักษณะหลักได้รับการเผยแพร่ นั่นคือเรามีการเตือนความจำ โชคดีที่ LaunchDarkly เพิ่งตั้งค่าคุณสมบัติที่จะแจ้งเตือน Slack ดังนั้น คุณสามารถเชื่อมต่อกับ Slack ได้ และมันจะบอกคุณว่า “นี่ แฟล็กฟีเจอร์ของคุณคือ… คุณอยู่ในขั้นตอนการผลิตมาสองสัปดาห์แล้ว ถึงเวลาต้องไปตรวจสอบให้แน่ใจว่าคุณล้างการตั้งค่าสถานะของคุณในโค้ดแล้ว”

เลสลี่: ดังนั้นเราจึงพยายามและทำความสะอาดอย่างรวดเร็ว แต่ในระหว่างนั้น เป็นเรื่องดีที่รู้ว่าธงยังคงอยู่ที่นั่น แม้ว่าคุณจะเปิดตัวคุณลักษณะนี้แล้ว แต่ก็หมายความว่าคุณสามารถเข้าไปข้างในและสลับการตั้งค่าสถานะกลับเป็นการปิดได้อีกครั้งด้วยการคลิกเพียงครั้งเดียว หากมีบางอย่างปรากฏขึ้น ดังนั้น เราชอบที่จะปล่อยพวกเขาไว้ชั่วคราวในขณะที่ฟีเจอร์นี้กำลังดำเนินการอยู่ ในขณะที่ผู้คนเริ่มชินกับมัน เพื่อให้แน่ใจว่าจะไม่มีปัญหาสำคัญใดๆ แต่จากนั้นเราก็ลองกลับเข้าไปในโค้ด และมันก็เป็นการล้างข้อมูลเล็กน้อย ดังนั้นจึงไม่ใช่กระบวนการในอุดมคติ แต่โดยปกติการลบแฟล็กนั้นใช้เวลาไม่นานนัก คุณเพียงแค่ลบโค้ดสองสามบรรทัด

ดรูว์: ดังนั้น ฉันเดาว่าวิธีที่ง่ายที่สุดในการติดตั้งแฟล็กคุณลักษณะอาจเป็น... เหมือนกับตัวแปรการกำหนดค่าในแอปของคุณที่ระบุว่า "ฟีเจอร์นี้เปิดหรือปิดอยู่" แต่แล้ว คุณต้องการวิธีบางอย่างเพื่อให้แน่ใจว่า เปิดเพื่อคนที่ใช่และปิดเพื่อคนที่ใช่ และฉันเดาว่านั่นคือที่มาของบริการอย่าง LaunchDarkly เพราะมันต้องใช้… ฉันหมายความว่าโดยพื้นฐานแล้วสิ่งที่เปิดและปิดตัวแปรไปสู่ระดับสูงสุดใช่ไหม

เลสลี่: ครับ ใช่. แค่นั้นเอง ดังนั้นจึงมีหลายวิธีที่เราสามารถทำได้ แม้จะไม่มี LaunchDarkly โดยพื้นฐานแล้วจะตั้งค่าตัวแปรการกำหนดค่าด้วยตัวเราเอง ซึ่งเราจะจัดการในส่วนของเรา สิ่งหนึ่งที่ฉันชอบเกี่ยวกับ LaunchDarkly คือมีสภาพแวดล้อมที่แตกต่างกัน ดังนั้น สิ่งที่เราทำได้ก็คือเปิดการตั้งค่าสถานะคุณลักษณะสำหรับตัวอย่างการทำให้ใช้งานได้ของเรา ดังนั้น ใครก็ตามที่กำลังดูภายในที่ Netlify ซึ่งเป็น Deploy Preview ของแอปสามารถเข้าถึงคุณลักษณะใหม่ได้ สามารถทดสอบได้ แต่แล้วอีกครั้ง ทันทีที่ใช้งานจริงในเวอร์ชันที่ใช้งานจริง แฟล็กนั้นจะถูกปิด มีน้อยมาก… อีกครั้ง คุณต้องตรวจสอบแท็บของคุณและให้แน่ใจว่าคุณรู้ว่าคุณอยู่ในกลุ่มใด เพราะคุณไม่ต้องการแปลกใจตัวเองและคิดว่าคุณเปิดตัวบางสิ่งที่ คุณไม่ได้ คุณต้องระมัดระวังที่นั่น แต่โดยทั่วไปแล้ว มันใช้งานได้ค่อนข้างดี และ LaunchDarkly ให้คุณทำการเปิดตัวแบบเลือกได้เหล่านี้ด้วย ดังนั้น คุณจึงสามารถเปิดตัวคุณลักษณะกับฐานโค้ดบางส่วนหรือกลุ่มผู้ใช้เฉพาะ ผู้ที่มีแผนประเภทใดประเภทหนึ่ง หรือผู้ใช้บางประเภท ดังนั้นจึงช่วยให้คุณควบคุมได้มากขึ้นว่าคุณจะปล่อยตัวให้ใคร

ดริว : ครับ นั่นอาจมีประสิทธิภาพมาก ฉันเดาโดยเฉพาะอย่างยิ่งกับคุณสมบัติหรือคุณสมบัติใหม่ที่คุณอาจคาดหวังว่าจะแก้ไขปัญหาได้ บางทีคุณอาจกำลังปรับปรุงคุณลักษณะเพื่อให้เข้าใจได้ง่ายขึ้น คุณอาจลองใช้กับผู้ใช้ 10% และดูว่าพวกเขากำลังประสบปัญหาเดียวกันหรือไม่และ...

เลสลี่: ถูกต้อง เป็นวิธีที่ยอดเยี่ยมในการรับข้อเสนอแนะเช่นกัน

Drew: ฉันเดาว่าการใช้ LaunchDarkly ในลักษณะนี้ แทนที่จะใช้โซลูชันของคุณเอง เป็นอีกแง่มุมหนึ่งของแนวทาง Jamstack ใช่ไหม เป็นเพียงการใช้ API ที่ให้ฟังก์ชันนี้แก่คุณโดยไม่ต้องกังวลว่าคุณจะปรับใช้อย่างไรและจะพัฒนาสิ่งนั้นอย่างไรและจะดูแลรักษาและรักษาไว้อย่างไรเพื่อให้คุณสามารถจ้างภายนอกได้กล่าวว่า "ใช่แล้ว จะใช้ API นี้และทุกอย่างจะได้รับการดูแล”

เลสลี่: อ๋อ ครับแม่นๆ

Drew: ดังนั้น แนวทางนี้ทำให้คุณสามารถมอบคุณลักษณะใหม่ๆ เล็กๆ น้อยๆ ให้กับการผลิตได้อย่างแท้จริง แต่สิ่งเหล่านี้ซ่อนอยู่หลังแฟล็ก และเมื่อทุกอย่างพร้อมแล้ว คุณก็เพียงแค่พลิกธงแล้วเปลี่ยนกลับได้อย่างรวดเร็วหากมีสิ่งผิดปกติเกิดขึ้น

เลสลี่: ใช่เลย ทำให้การเปิดตัวของเราน่าตื่นเต้นน้อยลงเล็กน้อย เมื่อก่อนคุณกำลังกดปุ่มใหญ่ๆ เหล่านี้ และมีโค้ดทั้งหมดที่ถูกรวมเข้าด้วยกัน และคุณกำลังดูบันทึกบิลด์ของคุณอยู่ และนี่คือช่วงเวลาแห่งการรอคอย และตอนนี้คุณเข้าสู่การโทรด้วย Zoom แล้ว คลิกปุ่มเดียวก็ใช้งานได้แล้ว

ดริว : ครับ ฉันคิดว่าการเปิดตัวฟีเจอร์ครั้งล่าสุด ฉันทำงานกับ Netlify เราใช้แนวทางนี้ และเป็นเวลาหลายสัปดาห์ของการทำงานสำหรับทีมงานทั้งหมด และเราได้รับโทรศัพท์จาก Zoom เพื่อประสานงานการเปิดตัว และทุกคนก็ยืนยันว่าชิ้นส่วนของพวกเขาพร้อมแล้ว จากนั้นฉันก็พลิกแฟล็กคุณลักษณะและเปิดใช้งานสำหรับผู้ใช้ทั้งหมด แค่นั้นเอง

เลสลี่: เสร็จแล้ว

ดรูว์: และมันก็จบลงในไม่กี่นาที และมันก็เป็นการต่อต้านไคลแมกซ์จริงๆ

เลสลี่: ใช่ มันน่าเศร้า

Drew: ฝ่ามือไม่มีเหงื่อ ไม่มีอะไรเลย นั่นคือสิ่งที่คุณต้องการจริงๆ ใช่ไหม นั่นคือวิธีที่คุณรู้ว่าคุณมีกระบวนการที่แข็งแกร่ง หากการเปิดใช้งานบางอย่างสำหรับทุกคนนั้นไม่ใช่เรื่องใหญ่

เลสลี่: ถูกต้อง และถ้าคุณต้องย้อนกลับ มันง่ายมาก แค่คลิกเดียว มันบรรเทาความกดดันความวิตกกังวลบางอย่าง

Drew: ดังนั้น ฉันหมายความว่า ไม่ใช่การเปลี่ยนแปลงทั้งหมดจะเป็นเพียงการเปลี่ยนแปลงส่วนหน้า บางครั้งจะมีการเปลี่ยนแปลงแบ็กเอนด์ และน่าจะมีแฟล็กคุณลักษณะของตนเองเช่นกันในระบบแบ็กเอนด์ส่วนใหญ่ คุณพูดถึงเอกสารเช่นกัน มีวิธีประสานงานทั้งหมดนี้ร่วมกันหรือไม่? ทุกคนแค่พลิกธงพร้อมกันหรือไม่? หรือว่ามันทำงานอย่างไร?

เลสลี่: ครับ ดังนั้นนี่คือพื้นที่ที่เรากำลังดำเนินการอย่างแข็งขันในทีมต่างๆ ในขณะนี้ที่ Netlify กำลังทำงานเพื่อแก้ปัญหาที่จะช่วยให้เราสามารถเชื่อมโยงทุกอย่างเข้ากับการตั้งค่าสถานะเดียวใน LaunchDarkly ซึ่งระบบทั้งหมดของเราใช้อยู่ ฐานรหัสทั้งหมดของเราใช้อยู่ ดังนั้น ในโลกอุดมคติ เราสามารถพลิกธงแล้วพูดว่า “โอเค นี่คือการสลับที่ปลายทาง API ใหม่ที่กำลังถูกใช้ในส่วนหน้าด้วย UI ใหม่นี้ที่หุ้มด้วยแฟล็กฟีเจอร์ เช่นเดียวกับส่วนนี้ของไซต์ doc ที่มีข้อมูลใหม่เกี่ยวกับคุณลักษณะใหม่นี้” และคุณพลิกแฟล็กนั้นในนั้นส่งผลกระทบต่อที่เก็บทั้งหมดเหล่านั้น เรายังไปไม่ถึงจุดนั้น เรากำลังดำเนินการแก้ไขอยู่ แต่ฉันตื่นเต้นที่จะได้เห็นว่าเราสามารถประสานงานและทำงานทั้งหมดได้หรือไม่

Drew: Netlify เนื่องจากบริการได้รับการปรับแต่งให้เหมาะกับไซต์ก่อสร้างในลักษณะนี้ งานที่คุณและทีมของคุณกำลังทำโดยใช้ผลิตภัณฑ์นั้นมีอิทธิพลต่อการพัฒนาผลิตภัณฑ์หรือไม่?

เลสลี่: ฉันจะบอกว่ามันไม่แน่นอน ทุกคนมักพูดว่าคุณไม่ใช่ผู้ใช้ของคุณ ซึ่งฉันคิดว่าเป็นเรื่องจริงเกือบตลอดเวลา ยกเว้นบางครั้งเมื่อคุณเป็นผู้ใช้ของคุณ ซึ่งเป็นเรื่องตลกที่ Netlify เพราะฉันคิดว่าคนส่วนใหญ่ในทีมส่วนหน้าโดยเฉพาะคือคนที่เคยใช้ Netlify มาก่อนเป็นผลิตภัณฑ์ และแน่นอนว่าเพราะเราใช้ Netlify เพื่อปรับใช้ Netlify เราจึงพบกับความท้าทายแบบเดียวกับที่ฉันคิดว่าผู้ใช้ของเราบางคนทำ ดังนั้น ในบางวิธี หากเราประสบปัญหา เราจะพยายามนำปัญหานั้นไปแจ้งกับส่วนที่เหลือของบริษัท เราจะพูดถึงเรื่องนี้ในการประชุมทางวิศวกรรม มิฉะนั้นเราจะดึง CTO ของเราเข้ามาแล้วพูดว่า "เฮ้ นี่คือสิ่งที่เรากำลังดิ้นรน มีบางอย่างที่เราสามารถสร้างลงในผลิตภัณฑ์ที่จะทำให้สิ่งนี้ง่ายขึ้นสำหรับเราและสำหรับผู้ใช้ทั้งหมดที่ปรับใช้สิ่งที่คล้ายกันอย่างเราหรือไม่” ดังนั้นจึงเป็นตำแหน่งที่ไม่เหมือนใคร แต่ก็สนุกที่ได้เห็นว่าแผนงานผลิตภัณฑ์ได้รับการพัฒนาอย่างไร

Drew: ฉันเดาว่าอาจมีคนไม่กี่คนที่ใช้ Netlify อย่างจริงจังพอๆ กับที่ Netlify ทำเอง

เลสลี่: ครับ ใช่. ฉันคิดว่ามันถูกต้อง ฉันจ้องไปที่ Netlify ทั้งตอนที่ฉันสร้างมันและเมื่อฉันปรับใช้มัน ดังนั้นฉันจึงค่อนข้างคุ้นเคยกับมัน

Drew: และในช่วงสุดสัปดาห์ คุณทำงานด้านโปรเจ็กต์ และพบว่าตัวเองกลับมาอยู่ใน Netlify อีกครั้ง

เลสลี่: ครับ นั่นเป็นเรื่องจริงมาก ใช่. ใช่. ใช่แน่นอน.

Drew: คุณมีตัวอย่างว่าทิศทางผลิตภัณฑ์ได้รับอิทธิพลจากงานที่ทีมทำหรือไม่?

เลสลี่: ครับ ดังนั้นเราจึงเพิ่งเปิดตัวแดชบอร์ดการลงจอดประเภทใหม่สำหรับแอปที่เราเรียกว่าภาพรวมของทีม ดังนั้น เมื่อก่อนคุณเข้าสู่ระบบ Netlify คุณจะเข้าสู่หน้าของเว็บไซต์ ซึ่งโดยพื้นฐานแล้วจะเป็นรายการเว็บไซต์ของคุณจำนวนมาก และเราต้องการเพิ่มพื้นที่ควบคุมภารกิจให้ผู้คนได้ดูข้อมูลสำคัญมากมายในพริบตา เข้าถึงสิ่งต่าง ๆ ที่จะเป็นประโยชน์ต่อพวกเขามากที่สุด นั่นคือคุณลักษณะใหม่ที่เราสร้างขึ้น ในการทำซ้ำครั้งแรก เรากำลังพยายามทำให้มันออกมาอย่างรวดเร็ว เรามีการ์ดเล็กๆ บน UI นั้นที่เชื่อมโยงกับงานสร้างล่าสุดของคุณ มันแสดงให้คุณเห็นโครงสร้างใด ๆ ในทั้งทีมของคุณควรปรากฏในการ์ดนั้น

Leslie: และในตอนแรก เราไม่ได้เชื่อมโยงสิ่งเหล่านี้กับบิลด์… บันทึกการแสดงผลเอง ดังนั้นจึงเป็นเพียงรายการที่คุณสามารถตรวจสอบได้ คุณสามารถคลิกเข้าไปในหน้าบิลด์เพื่อดูมุมมองที่คล้ายกันได้ แต่จริงๆ แล้ว ฉันกำลังทำงานบางอย่างในช่วงสุดสัปดาห์ เป็นไซต์ส่วนตัว และฉันได้เปิดภาพรวมของทีมนี้ และฉันรู้สึกหงุดหงิดเพราะรู้ว่าฉันลงชื่อเข้าใช้ Netlify และฉันต้องการไปดูงานสร้างนี้ที่เกิดขึ้นกับโครงการของฉัน และฉันไม่สามารถคลิกเข้าไปที่มันได้เลย ฉันต้องคลิกเข้าไปในหน้าบิลด์แล้วคลิกอีกครั้ง วันรุ่งขึ้นที่ทำงาน ฉันเข้าไปเพิ่มการเปลี่ยนแปลงนั้นและเชื่อมโยงงานสร้างเหล่านั้นเพราะมันทำให้ฉันรำคาญ นั่นคือตัวอย่างหนึ่งของการใช้ผลิตภัณฑ์ว่า มีโอกาสเพียงเล็กน้อยในการปรับปรุง และเราเอาสิ่งนั้น

เลสลี่: แต่เราก็มีตัวอย่างอื่นๆ ด้วยเช่นกัน น่าจะมีผลมากกว่านิดหน่อย หนึ่งคือเราได้เพิ่มคุณสมบัติการตรวจจับแบบฟอร์มนี้ พื้นหลังเล็กน้อย ถ้าคุณไม่คุ้นเคย แบบฟอร์ม Netlify เป็นคุณลักษณะใน Netlify ที่ช่วยให้คุณสร้างแบบฟอร์มส่วนหน้าได้ และ Netlify ทำหน้าที่จัดการการส่งงานแบ็กเอนด์ทั้งหมด มันเหมือนกับฐานข้อมูลของคุณสำหรับแบบฟอร์มที่คุณสร้างขึ้นบนส่วนหน้าของคุณ หมายความว่าคุณไม่จำเป็นต้องเขียนโค้ดฝั่งเซิร์ฟเวอร์หรือ JavaScript เพิ่มเติมจำนวนมากเพื่อจัดการการส่งแบบฟอร์ม จริงๆ ไซต์ใดๆ ที่คุณปรับใช้กับ Netlify ในขณะที่บิลด์ของคุณกำลังเกิดขึ้น บอทบิลด์ของเรากำลังแยกวิเคราะห์ HTML ของไซต์ของคุณ ณ เวลาที่ใช้เพื่อตรวจสอบว่าคุณมีฟอร์ม Netlify ที่ Netlify จำเป็นต้องให้ความสนใจและจัดการหรือไม่ และการตรวจหาแบบฟอร์มนี้ บอทบิวด์กำลังมองหาสิ่งนั้น โดยค่าเริ่มต้น

เลสลี่: แต่ความหมายก็คือ อย่างที่คุณจินตนาการได้ นั่นทำให้เสียเวลาในการสร้างของคุณเล็กน้อย เพราะบอทต้องไปมองหาขั้นตอนพิเศษนี้ ดังนั้น ที่จริงแล้ว แอป Netlify เราไม่ได้ใช้งาน เราไม่มีแบบฟอร์ม Netlify ในแอปในขณะนี้ ดังนั้น นี่เป็นขั้นตอนที่โดยทั่วไปแล้วจะเพิ่มเวลาในการสร้างของเราเล็กน้อย แต่ก็ไม่จำเป็นต้องเกิดขึ้นเสมอไป ดังนั้น Netlify จึงได้สร้างคุณลักษณะใหม่ที่อนุญาตให้ผู้ใช้ปิดใช้งานการตรวจหาแบบฟอร์มนั้นได้ หมายความว่าคุณสามารถปิดการตั้งค่านั้นในการตั้งค่าไซต์ของคุณ บิวด์บอทตระหนักดีว่าไม่จำเป็นต้องมองหาสิ่งใด ดังนั้นคุณจึงประหยัดเวลาในการประมวลผลเพิ่มเติมเล็กน้อยในบิลด์

Drew: ฉันเดาว่ามันยอดเยี่ยมในแง่ของประสิทธิภาพการทำงาน เพราะสิ่งต่างๆ นั้นเพิ่งจะเสร็จเร็วขึ้นเล็กน้อย

เลสลี่: ถูกต้อง

Drew: แต่ในฐานะบริการแบบคิดค่าบริการตามปริมาณข้อมูล ยังช่วยให้คุณได้รับเบี้ยเลี้ยงที่มากขึ้นอีกด้วย

เลสลี่: อ๋อ อย่างแน่นอน. ดังนั้น นี่คือสิ่งที่เราได้ยินจากผู้ใช้และลูกค้าของเราบางคนด้วย และมันเป็นสิ่งที่เราสังเกตเห็นเช่นกัน นั่นคือ “เราไม่ต้องการขั้นตอนพิเศษนี้ในผลิตภัณฑ์ของเราเอง มีวิธีใดบ้างที่เราสามารถมอบให้กับผู้ใช้ทั้งหมดของเราเพื่อทำให้ชีวิตของทุกคนง่ายขึ้นเล็กน้อย ทำให้ทุกคนสร้างเร็วขึ้นเล็กน้อยหากพวกเขาไม่ได้ใช้คุณสมบัตินี้”

Drew: มีอันตรายไหม… ฉันหมายถึง คุณบอกว่าคุณไม่ใช่ผู้ใช้ของคุณ แต่สำหรับ Netlify คุณมักจะเป็นผู้ใช้ของคุณ มีอันตรายไหมว่าด้วยความเข้มข้นที่คุณใช้ผลิตภัณฑ์ คุณอาจมองข้ามประเภทผู้ใช้ที่ใช้มันเพียงเล็กน้อยเท่านั้น และทุกอย่างอาจซับซ้อนเกินไปและก้าวหน้าเกินไป และกลายเป็นเรื่องยากมาก เริ่มด้วย?

เลสลี่: นั่นเป็นคำถามที่ดี นอกจากนี้เรายังได้สร้างฟังก์ชันการวิจัยผู้ใช้ของเราที่ Netlify และฟังก์ชันวิทยาศาสตร์ข้อมูลของเรา และฉันคิดว่า โดยรวมแล้ว เราเชื่อมั่นในพวกเขามากกว่าประสบการณ์ที่เคยใช้และปรับใช้แอป แต่ฉันคิดว่าข้อมูลทั้งหมดนั้นมารวมกันเพื่อให้เราได้ภาพที่ดีขึ้นว่าใครกำลังใช้ Netlify เรากำลังพูดถึงผู้ใช้ประเภทใด มีคนที่มีความต้องการแตกต่างกัน เรามีทีมงานเริ่มต้นของเราที่จัดการบล็อกและไซต์ส่วนบุคคล และเรามีองค์กรขนาดใหญ่ด้วยเช่นกัน ซึ่งกำลังเปิดตัวแคมเปญการตลาดขนาดใหญ่และเว็บแอปขนาดใหญ่ ซึ่งไม่ต่างจาก Netlify มากนัก ดังนั้นจึงเป็นเรื่องที่น่าตื่นเต้นที่จะเห็นฐานผู้ใช้เติบโตขึ้น และคิดเกี่ยวกับกรณีการใช้งานเหล่านี้ทั้งหมด และค้นหาว่าเราสามารถรองรับผู้ใช้เหล่านั้นทั้งหมดได้อย่างไร และแน่นอนว่าใช้ฟังก์ชันการวิจัยของเรามากขึ้นเพื่อให้เข้าใจว่าผู้ใช้เหล่านั้นเป็นใคร ไม่ใช่แค่ประสบการณ์ภายในของเรา

Drew: บอกฉันสิ เลสลี่ เกี่ยวกับบริการสกรีนช็อตที่ Netlify มีให้ไหม เพราะฉันพบว่าน่าสนใจจริงๆ

เลสลี่: ครับ ใน UI ที่เรามี… เมื่อคุณปรับใช้ไซต์บน Netlify ใน UI เรามีภาพหน้าจอเล็กๆ ที่แสดงให้คุณเห็นว่าโดยทั่วไปแล้วหน้าแรกของไซต์ที่คุณรู้สึกว่าเป็นอย่างไร เป็นเรื่องตลกจริงๆ ที่เรานำเรื่องนี้ขึ้นมา เพราะฉันกำลังฟัง Chris Coyier ตอนของเขาใน Serverless เมื่อไม่นานมานี้ และเขากำลังพูดถึงวิธีที่พวกเขาทำภาพหน้าจอใน CodePen ด้วยเช่นกัน ซึ่งจริงๆ แล้วไม่ต่างกับวิธีที่ Netlify ทำ แต่โดยพื้นฐานแล้ว เราเรียกใช้ Puppeteer เพื่อจับภาพหน้าจอของไซต์ผู้ใช้ และวิธีการทำงานทั้งหมดคือตั้งค่าด้วยฟังก์ชัน Netlify นี่เป็นอีกตัวอย่างหนึ่งที่เราลองใช้ผลิตภัณฑ์ของเราเอง โดยพื้นฐานแล้ว เราใช้จุดสิ้นสุดซึ่งเป็นฟังก์ชัน Netlify ภายในแอปของเราเพื่อส่งคืน URL ของภาพหน้าจอนั้น จากนั้นเราสามารถให้บริการนั้นในแอปได้

Drew: ดังนั้นฟังก์ชั่น Netlify คือการใช้งานฟังก์ชั่น Serverless ของ Netlify ใช่ไหม โดยพื้นฐานแล้วคุณเพียงแค่วางไฟล์ JavaScript ลงในโฟลเดอร์ที่กำหนดโดยเป็นส่วนหนึ่งของซอร์สของคุณ จากนั้นไฟล์นั้นจะพร้อมให้ดำเนินการเป็นฟังก์ชันคลาวด์

เลสลี่: ใช่ แน่นอน

Drew: ฉลาดสุด ๆ ใช่ไหม

เลสลี่: ครับ มันยอดเยี่ยมมาก 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?