JAMstack Fundamentals: อะไร อะไร และอย่างไร

เราชอบที่จะก้าวข้ามขีดจำกัดของเว็บ ดังนั้นเราจึงตัดสินใจลองสิ่งใหม่ๆ คุณอาจเคยได้ยินเกี่ยวกับ JAMstack — เว็บสแต็กใหม่ที่ใช้ JavaScript, API และมาร์กอัป — แต่มันมีความหมายอย่างไรสำหรับเวิร์กโฟลว์ของคุณและเมื่อใดจึงจะเหมาะสมในโครงการของคุณ

ในฐานะที่เป็นส่วนหนึ่งของ Smashing Membership เราจัด Smashing TV ซึ่งเป็นชุดการสัมมนาผ่านเว็บแบบสดทุกสัปดาห์ ไม่มีอะไรยุ่งยาก — แค่การสัมมนาผ่านเว็บที่ใช้งานได้จริงและนำไปปฏิบัติได้จริง พร้อมถาม & ตอบแบบสด ดำเนินการโดยผู้ปฏิบัติงานที่ได้รับความนับถือจากอุตสาหกรรม อันที่จริง ตาราง Smashing TV นั้นค่อนข้างจะแน่นอยู่แล้ว และมันฟรีสำหรับ Smashing Members พร้อมกับการอัดเสียง — แน่นอน

เราได้ขอให้ Phil Hawksworth จัดสัมมนาผ่านเว็บเพื่ออธิบายว่า JAMStack หมายถึงอะไรจริง ๆ และเมื่อใดที่มันสมเหตุสมผล รวมถึงผลกระทบต่อเครื่องมือและสถาปัตยกรรมส่วนหน้าอย่างไร ขณะนี้มีการสัมมนาผ่านเว็บความยาวหนึ่งชั่วโมงด้วย เรายินดีเป็นอย่างยิ่งที่ได้ต้อนรับ Phil ให้ร่วมเป็น MC SmashingConf Toronto ที่จะมาถึง (25-26 มิถุนายน) และจัดการ JAMStack_conf London ซึ่งเราจัดงานร่วมกันในวันที่ 9-10 กรกฎาคมปีนี้เช่นกัน เข้าไปกันเถอะ!

ฟิล ฮอว์คสเวิร์ธ: ยอดเยี่ยม โอเค เข้าเรื่องกันดีกว่า แค่สวัสดีอย่างรวดเร็ว ฉันหมายความว่าฉันได้กล่าวสวัสดีแล้ว สกอตต์แนะนำฉันเป็นอย่างดี แต่ใช่ ตอนนี้ฉันทำงานที่ Netlify ฉันทำงานในทีมพัฒนาประสบการณ์ที่นั่น หวังว่าเราจะมีเวลาเหลือเฟือสำหรับการถาม & ตอบ แต่อย่างที่สกอตต์กล่าวไว้ หากคุณไม่มีโอกาสถามคำถามที่นั่น หรือหากคุณต้องการ คุณสามารถ ping มาที่ฉันโดยตรงบน Twitter ดังนั้น Twitter ของฉันจึงจัดการ คือชื่อของฉัน มันคือ Phil Hawksworth ดังนั้นเมื่อใดก็ตามที่คุณสามารถถามคำถามเกี่ยวกับ JAMstack หรืออะไรก็ได้บน Twitter

ฟิล ฮอว์กสเวิร์ธ: แต่ฉันอยากจะเริ่มต้นวันนี้ด้วยการย้อนเวลากลับไปเล็กน้อยกับคำพูดนี้ซึ่งตรงใจฉันมาก นี่เป็นคำพูดจากแอรอน ชวาร์ตษ์ผู้วิเศษ ซึ่งแน่นอนว่ามีส่วนสนับสนุนอย่างมากต่อครีเอทีฟคอมมอนส์และโอเพ่นเว็บ และเขาเขียนสิ่งนี้บนบล็อกของเขาเมื่อย้อนกลับไปในปี 2545 และเขากล่าวว่า “ฉันสนใจที่จะไม่ต้องบ้าๆ บอ ๆ ต่อไป ติดตั้งเซิร์ฟเวอร์ AOL, Postgres และ Oracle” เซิร์ฟเวอร์ AOL ฉันต้องเงยหน้าขึ้นเพื่อเตือนตัวเองว่าเป็นเว็บเซิร์ฟเวอร์โอเพ่นซอร์สในขณะนั้น

ฟิล ฮอว์กสเวิร์ธ: แต่สิ่งนี้เข้ากับฉันอย่างแรง ฉันไม่ต้องการที่จะรักษาโครงสร้างพื้นฐานเพื่อให้บล็อกมีชีวิตอยู่ และนั่นคือสิ่งที่เขากำลังพูดถึง และอยู่ในบล็อกโพสต์นี้ในบล็อกของเขาเองและมีชื่อว่า “Bake, Don't Fry” เขากำลังเลือกคำศัพท์ที่คนที่เพิ่งสร้าง CMS ได้เริ่มใช้ และเขาก็ทำให้คำนี้เป็นที่นิยมในการอบ (Bake, Don't Fry); สิ่งที่เขาพูดถึงคือการเรนเดอร์ล่วงหน้ามากกว่าการเรนเดอร์แบบออนดีมานด์ ดังนั้นการอบเนื้อหาก่อนเวลา แทนที่จะทอดตามความต้องการเมื่อมีคนมาขอ — ทำให้สิ่งต่าง ๆ หมดไปจากเวลาที่ขอและเวลาในการสร้าง

ฟิล ฮอว์กสเวิร์ธ: และเมื่อเราพูดถึงการเรนเดอร์ล่วงหน้าและการเรนเดอร์ สิ่งที่เราหมายถึงนั่นคือเรากำลังพูดถึงการสร้างมาร์กอัป ฉันรู้สึกประหม่าบ้างในบางครั้งที่พูดถึงชนิดของการเรนเดอร์เซิร์ฟเวอร์หรือการเรนเดอร์แบบ isomorphic หรือคำศัพท์เกี่ยวกับคำศัพท์เหล่านี้จำนวนมาก ฉันถูกเรียกตัวไปเมื่อไม่กี่ปีก่อนในการประชุมที่งานประชุม Frontiers Conference ในอัมสเตอร์ดัม เมื่อฉันพูดถึงการเรนเดอร์บนเซิร์ฟเวอร์ และมีคนพูดกับฉันว่า “คุณหมายถึงการสร้าง HTML ใช่ไหม แค่บางอย่างที่ส่งออก HTML?” และนั่นคือสิ่งที่ฉันหมายถึง

ฟิล ฮอว์กสเวิร์ธ: แต่สิ่งเหล่านี้เป็นหนทางยาวไกลในการทำให้สแต็กง่ายขึ้น เมื่อเรานึกถึงสแตกที่เราให้บริการเว็บไซต์ ฉันพยายามที่จะลดความซับซ้อนของสิ่งต่าง ๆ ฉันกระตือรือร้นที่จะพยายามลดความซับซ้อนของสแต็ก และนั่นเป็นหัวใจสำคัญของสิ่งนี้ที่เรียกว่า "JAMstack" และฉันอยากจะลองอธิบายเรื่องนี้สักหน่อย “JAM” ใน JAMstack ย่อมาจาก JavaScript, APIs และ Markup แต่นั่นยังไม่เพียงพอที่จะช่วยให้เราเข้าใจว่ามันหมายถึงอะไร หมายความว่าอย่างไรในโลกนี้จริงๆ

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

Phil Hawksworth: นั่นคือแผนสำหรับครึ่งชั่วโมงข้างหน้า แต่ฉันอยากกลับมาที่แนวคิดนี้ เกี่ยวกับการทำให้สแต็กง่ายขึ้น เพราะหวังว่า ผู้คนที่เข้าร่วมหรือมาดูวิดีโอนี้ในภายหลัง บางทีคุณอาจมีความคิดว่า JAMstack คืออะไร หรือ อาจเป็นศัพท์ใหม่ทั้งหมด และคุณก็แค่สงสัย แต่ท้ายที่สุด ก็มีกองซ้อนอยู่มากมายอยู่แล้ว มีหลายวิธีที่คุณสามารถนำเสนอเว็บไซต์ได้ รู้สึกเหมือนว่าเราได้สร้างโครงสร้างพื้นฐานประเภทต่างๆ มาเป็นเวลานานแล้ว ไม่ว่าจะเป็น LAMP stack หรือ MAMP stack หรือ - ฉันไม่รู้ - MEAN stack มีพวกมันลอยอยู่บนหน้าจอที่นี่ มีจำนวนมากและจำนวนมาก

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

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

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

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

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

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

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

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

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

Phil Hawksworth: คุณอาจจำได้ว่า LAMP stack ประกอบด้วยเว็บเซิร์ฟเวอร์ apache สำหรับทำสิ่งต่าง ๆ เช่นการกำหนดเส้นทาง HCP และการให้บริการสินทรัพย์คงที่ PHP สำหรับการประมวลผลล่วงหน้าบางอย่าง ดังนั้นการประมวลผลไฮเปอร์เท็กซ์ที่สวยงามมาก ใช้ตรรกะอาจสร้างมุมมองสำหรับเทมเพลตและสิ่งที่คุณมี และมีสิทธิ์เข้าถึงข้อมูลของคุณโดย NISQL ของฉัน จากนั้น LINUX ก็คือระบบปฏิบัติการที่อยู่ใต้ระบบทั้งหมดนั้น คอยดูแลทุกอย่าง เราสามารถรวมสิ่งนั้นเข้าด้วยกันเป็นเว็บเซิร์ฟเวอร์นี้ และเราอาจมีเซิร์ฟเวอร์เหล่านี้จำนวนมาก นั่งรวมกันเพื่อให้บริการเว็บไซต์

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

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

ฟิล ฮอว์กสเวิร์ธ: เมื่อพูดถึงการเข้าถึงข้อมูล นั่นอาจเกิดจาก API ภายนอก การโทรผ่าน JavaScript ไปยัง API ภายนอกเหล่านี้เพื่อเข้าถึงเซิร์ฟเวอร์ หรือเราอาจคิดว่า API เป็น API ของเบราว์เซอร์ ความสามารถในการโต้ตอบกับ JavaScript ด้วยความสามารถในเบราว์เซอร์ของคุณ

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

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

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

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

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

ฟิล ฮอว์กสเวิร์ธ: ดังนั้น การแยกส่วนแบบนี้เป็นสิ่งสำคัญ และฉันจะกลับมาที่เรื่องนี้ในภายหลัง เราให้บริการไฟล์แบบคงที่ได้ดีมาก และการนำสิ่งของต่างๆ ไปที่ CDN หรือนำสิ่งของไปยังระบบไฟล์ (ไฟล์เซิร์ฟเวอร์) เป็นสถานที่ที่เราได้เห็นความก้าวหน้าครั้งยิ่งใหญ่ในช่วงไม่กี่ปีที่ผ่านมา ขณะนี้มีเครื่องมือและกระบวนการมากมายที่สามารถช่วยให้เราทำสิ่งนี้ได้ดีมาก เพียงเพื่อเรียกบริการบางอย่างที่สามารถให้บริการสินทรัพย์แบบคงที่ได้ดีและให้เวิร์กโฟลว์ในการสร้างของคุณในสภาพแวดล้อมนั้น พวกเขาเป็นผู้ต้องสงสัยตามปกติที่คุณอาจจินตนาการถึงผู้ให้บริการโครงสร้างพื้นฐานระบบคลาวด์ขนาดใหญ่ เช่น Azure, AWS และ Google Cloud

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

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

ฟิล ฮอว์กสเวิร์ธ: เราสามารถแสดงตัวอย่างนั้นในเซิร์ฟเวอร์แบบคงที่ของเรา สิ่งที่ทำได้ง่ายบนสภาพแวดล้อมการพัฒนาในพื้นที่ และจากนั้นกระบวนการปรับใช้ที่ได้รับสิ่งนั้นไปยังสภาพแวดล้อมการโฮสต์ และในอุดมคติแล้ว ออกไปยัง CDN เพื่อให้ได้ขนาด ด้วยการวางรากฐานแบบนั้น ฉันต้องการแก้ไขความเข้าใจผิดเล็กน้อยเกี่ยวกับไซต์ JAMstack และฉันไม่ได้ช่วยตัวเองด้วยการเปิดสิ่งนี้เพื่ออธิบายไซต์ JAMstack ว่าเป็น JavaScript, API และ Markup เนื่องจากความเข้าใจผิดที่พบบ่อยคือทุกไซต์ JAMstack จะต้องเป็น JavaScript และ API และมาร์กอัป แต่สิ่งที่เรามองข้ามไปคือเราไม่จำเป็นต้องใช้ทั้งสามไซต์นี้ ทุกอันเป็น , ไม่จำเป็น. เราจะใช้มากหรือน้อยก็ได้ตามใจชอบ ในลักษณะเดียวกับที่ไซต์สแต็ก LAMP ไม่จำเป็นต้องกดฐานข้อมูล ในอดีต ฉันได้สร้างสิ่งต่าง ๆ ที่ให้บริการโดยเซิร์ฟเวอร์ apache บนเครื่อง Linux และฉันได้ใช้ PHP แต่ฉันไม่ได้กดฐานข้อมูล และฉันจะไม่เริ่มเปลี่ยนชื่อกอง จำเป็นสำหรับสิ่งนั้น

ฟิล ฮอว์กสเวิร์ธ: ดังนั้น หากเรานึกถึงสิ่งที่เป็นไซต์ JAMstack ก็อาจเป็นได้หลายอย่าง อาจเป็นสิ่งที่สร้างขึ้นด้วยตัวสร้างไซต์แบบสแตติก เช่น Jekyll ที่ดึงเนื้อหาจากไฟล์ YAML เพื่อสร้างไซต์ที่ไม่มี JavaScript ไม่กระทบ API เลย และเราให้บริการบนบางสิ่ง เช่น GitHub Pages หรือนั่นอาจเป็นไซต์ JAMstack หรือบางทีเรากำลังใช้ตัวสร้างไซต์แบบสแตติก เช่น Gatsby ซึ่งอยู่ในสภาพแวดล้อม Ruby สำหรับ Jekyll มากกว่า ตอนนี้เป็นตัวสร้างไซต์แบบสแตติก JavaScript ที่สร้างขึ้นในระบบนิเวศของ React

Phil Hawksworth: นั่นอาจเป็นการดึงเนื้อหาอีกครั้ง และเป็นการจัดระเบียบไฟล์ Markdown อาจทำให้สมบูรณ์ยิ่งขึ้นด้วยการเรียก API, API ของ GraphQL มันอาจจะทำสิ่งต่างๆ ในเบราว์เซอร์ เช่น การทำ JavaScript Hydration ของการเติมเทมเพลตในเบราว์เซอร์ และอาจให้บริการบน Amazon S3 นั่นคือไซต์ JAMStack หรือไม่ ใช่อย่างแน่นอน!

ฟิล ฮอว์กสเวิร์ธ: ย้ายไปยังเครื่องกำเนิดไซต์แบบคงที่อื่น Hugo ซึ่งสร้างด้วย Go! อีกครั้ง เราอาจจัดระเบียบเนื้อหาในไฟล์ Markdown เพิ่มการโต้ตอบในเบราว์เซอร์โดยใช้ JavaScript อาจจะไม่เรียก API ภายนอกใด ๆ และอาจโฮสต์บน Google Cloud JAMstack ใช่ไหม อย่างแน่นอน! คุณเห็นไหม ฉันกำลังสร้างธีมที่นี่ ใช้บางอย่างเช่น Nuxt ซึ่งเป็นตัวสร้างไซต์แบบคงที่อีกตัวหนึ่ง ซึ่งสร้างในระบบนิเวศของ View แล้ว บางทีนั่นอาจเป็นการดึงเนื้อหาจากไฟล์ที่อยู่ติดกันคนละไฟล์? อีกครั้ง เราอาจใช้การโต้ตอบกับ JavaScript ในเบราว์เซอร์ บางทีอาจเรียก API ให้ทำสิ่งต่างๆ เช่น อีคอมเมิร์ซ และให้บริการไซต์แบบสแตติกอีกไซต์หนึ่ง โครงสร้างพื้นฐานโฮสติ้งอื่นเช่น Netlify เป็น JAMstack หรือไม่ ใช่แล้ว!

ฟิล ฮอว์กสเวิร์ธ: แต่เราอาจจะไป คุณก็รู้ ไปที่ด้านนี้ของมาตราส่วนเช่นกัน และลองนึกถึงเว็บแอปแบบโปรเกรสซีฟที่ทำด้วยมือซึ่งเราสร้างด้วย JavaScript อย่างมีฝีมือ ทำด้วยมือ ซึ่งเราสร้างขึ้นเอง เรากำลังบรรจุด้วย webpack เราอาจใช้โทเค็นเว็บของ JavaScript และเรียกใช้ API เพื่อตรวจสอบสิทธิ์ โต้ตอบกับ API ของเบราว์เซอร์ต่างๆ โฮสต์บน Azure ใช่ นั่นคือ JAMstack เช่นกัน!

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

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

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

Phil Hawksworth: ฉันชอบบางสิ่งที่ Kent C. Dodds ทำจริงๆ ฉันไม่รู้ว่าคุณคุ้นเคยกับชุมชน React หรือไม่ คุณอาจเคยพบกับ Kent C. Dodds มาก่อน เขาไม่ได้ใช้ WordPress แต่เขายังคงกำหนดเส้นทาง URL นี้ WPAdmin ฉันคิดว่าเขาเคยกำหนดเส้นทางไปยังวิดีโอของ Rick Roll บน YouTube แน่นอนเขาหลอกล่อคนที่พยายามหามัน แต่ประเด็นก็คือ การแยกส่วนสิ่งต่าง ๆ ออกมาในลักษณะนั้น และการเคลื่อนย้ายสิ่งต่าง ๆ ที่เกิดขึ้น สร้างเวลาจากสิ่งที่เกิดขึ้นในเวลาที่ร้องขอ เราก็สามารถลดการเปิดเผยของเราได้อย่างมาก เราไม่มีชิ้นส่วนที่เคลื่อนไหวตามเวลาที่ร้องขอ ชิ้นส่วนที่เคลื่อนไหวได้ทั้งหมดถูกแยกออกจากกันโดยสมบูรณ์ ณ เวลาสร้าง เป็นไปได้อย่างสมบูรณ์ จำเป็น บนโครงสร้างพื้นฐานที่แตกต่างกันโดยสิ้นเชิง

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

ฟิล ฮอว์กสเวิร์ธ: ดังนั้น มันเหมือนกับการก้าวไปสู่ ​​การเป็นแบบหลอกๆ ในทำนองเดียวกันในเซิร์ฟเวอร์ฐานข้อมูล เราต้องการเพิ่มชั้นแคชในการสืบค้น cache-com แม้แต่ในสมดุลที่ต่ำ CDN ทั้งหมด คุณก็มองว่าเป็นแคชได้ แต่ในสแต็กดั้งเดิม เราจำเป็นต้องหาวิธีจัดการแคชนั้น เพราะไม่ใช่ทุกอย่างจะถูกแคช ดังนั้นจะมีตรรกะบางอย่างเกี่ยวกับ สิ่งที่จำเป็นต้องมีการเติมข้อมูลแบบไดนามิกกับสิ่งที่สามารถแคชได้ และโมเดล JAMstack ทุกอย่างถูกแคชไว้ ทุกอย่างถูกแคชไว้ตั้งแต่ตอนติดตั้งใช้งานเสร็จ ดังนั้นเราจึงสามารถคิดเกี่ยวกับมันแตกต่างไปจากเดิมอย่างสิ้นเชิง

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

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

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

ฟิล ฮอว์กส์เวิร์ธ: นั่นเป็นพื้นที่ปัญหาที่กำหนดไว้อย่างดี เพราะในท้ายที่สุด คุณกำลังพยายามสร้างบางสิ่งที่คุณสามารถให้บริการได้โดยตรงจาก CDN คุณต้องการเรนเดอร์บางสิ่งล่วงหน้า โดยใช้เครื่องมือใดก็ได้ที่คุณต้องการ ไม่ว่าจะเป็นตัวสร้างไซต์สแตติกที่สร้างใน Ruby หรือ Python หรือ JavaScript หรือ Go หรือ PHP คุณมีอิสระในการตัดสินใจเลือก ดังนั้นจึงสามารถสร้างสภาพแวดล้อมที่ดียิ่งขึ้นให้คุณทำงานได้ และยังสร้างโอกาสในการสร้างความมั่นใจให้กับนักพัฒนาอย่างแท้จริง เนื่องจากคุณลักษณะที่แท้จริงของไซต์ JAMstack ก็คือสามารถทำหน้าที่เป็นการปรับใช้แบบไม่เปลี่ยนรูปและอะตอมมิกได้ง่ายขึ้น

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

ฟิล ฮอว์คสเวิร์ธ: อยู่นี่แล้ว นี้จะง่ายกว่า กระโดดเข้าเพจเลย เอาล่ะ สก็อตต์ บอกฉันสิ สก็อตต์ ถ้าคุณไม่เห็นเบราว์เซอร์ของฉัน ฉันหวังว่าจะได้ ตอนนี้ สมมติว่าทุกคนสามารถเห็นเบราว์เซอร์ของฉันได้

สกอตต์: ทุกอย่างดูดี

ฟิล ฮอว์คสเวิร์ธ: ยอดเยี่ยม! ขอบคุณมาก ๆ!

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

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

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

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

ฟิล ฮอว์กสเวิร์ธ: ฉันสังเกตเห็นว่าตัวจับเวลาของฉันถูกรีเซ็ต หลังจากย้อนกลับไปและเดินหน้าจากประเด็นสำคัญ ฉันคิดว่าฉันเหลือเวลาอีกประมาณหกหรือเจ็ดนาที บอกฉันสิ สก็อตต์ ถ้า—

สก็อตต์: ใช่ เรายังดีอยู่ประมาณสิบนาที

ฟิล ฮอว์คสเวิร์ธ: 10 นาที? โอเค วิเศษมาก!

สกอตต์: ไม่มีอะไรเร่งด่วน

Phil Hawksworth: ขอบคุณครับ นั่นควรจะดี!

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

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

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. Hello everyone. 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 หรือไม่ ไม่ว่าคุณจะเรียก API หรือไม่ก็ตาม หากคุณแสดงผลล่วงหน้าและรับสิ่งต่าง ๆ ลงในโฮสต์แบบสแตติกที่มีประสิทธิภาพมาก นั่นคือแกนหลักของ JAMstack

Vitaly: ใช่แน่นอน

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

Vitaly: แน่นอน เรามีโดแรนอยู่ที่นี่ ดอแรน ฉันคิดว่าฉันรู้ ดอแรน ฉันรู้สึกว่าฉันรู้จักโดรัน เขาถามว่า “คุณคาดหวังว่าเซิร์ฟเวอร์ไร้เซิร์ฟเวอร์จะมุ่งไปสู่การรวมอย่างราบรื่นกับ JAMstack จาก [ไม่ได้ยิน 00:44:36] หรือไม่ สิ่งที่เรียกว่า A ใน JAM

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

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

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

Vitaly: เอาล่ะ นั่นเป็นคำตอบที่ครอบคลุมมาก อันที่จริง ฉันเพิ่งเข้าร่วมการพูดคุยเมื่อเร็วๆ นี้ ซึ่งวิศวกรส่วนหน้าจาก Amazon กำลังพูดถึงฟังก์ชันไร้เซิร์ฟเวอร์และ Lamda ที่พวกเขากำลังใช้อยู่ ฉันเกือบไปแล้ว เขามักจะพูดเกี่ยวกับ Docker และ Kubernetes และเรื่องทั้งหมดนั้น Devox World ฉันนั่งอยู่ที่นั่นและคิดว่า "เขาไปอยู่ที่นั่นได้อย่างไร ฉันไม่เข้าใจว่าเกิดอะไรขึ้น!” ฉันไม่รู้ว่าเกิดอะไรขึ้น

ฟิล ฮอว์กสเวิร์ธ: แน่นอน แต่ประเด็นคือ เคยเป็น… ฉัน… ฉันยอมรับว่าฉันไม่เข้าใจโลกนั้นเลย แต่ฉันไม่มีความปรารถนาที่จะทำเช่นนั้น เพราะนั่นเป็นวินัยที่ต่างไปจากเดิมอย่างสิ้นเชิง . และวินัยนั้นยังคงมีความสำคัญจริงๆ คุณรู้ไหมว่าคนที่กำลังออกแบบโครงสร้างพื้นฐาน - นั่นยังคงเป็นกุญแจสำคัญจริงๆ แต่ตอนนี้ฉันรู้สึกว่าฉันถูกล่อลวง ในฐานะคนที่มีพื้นฐานการพัฒนา front-end ในฐานะนักพัฒนา JavaScript ฉันรู้สึกอยากเล่นในโลกนั้นมากขึ้น เพราะเครื่องมือต่างๆ กำลังเข้ามาใกล้ฉันมากขึ้น

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

Vitaly: เช่นเดียวกับ Power Rangers เหรอ?

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

Vitaly: ที่จริงแล้วคุณได้รับบริการ div บางอย่างระหว่างสแน็ปช็อตการตั้งค่าสองเวอร์ชันที่แตกต่างกัน ดังนั้น ถ้าคุณบอกว่า เปลี่ยนส่วนหัวทุกที่ แน่นอนว่าทุกหน้าจะต้องถูกปรับใช้ใหม่ แต่ถ้าคุณเปลี่ยน บางที ส่วนประกอบ เช่น สมมุติว่า ม้าหมุน ที่อาจส่งผลกระทบเพียง 1,000 หน้า ก็สมเหตุสมผลแล้วที่จะปรับใช้ 15,000 หน้าใหม่ แต่ 1,000 นี่เท่านั้น เราไปถึงที่นั่นได้ไหม? มันเป็นความคิดมหัศจรรย์ที่มีอยู่หรือเป็นสิ่งที่จับต้องได้ ณ จุดนี้หรือไม่?

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

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

Phil Hawksworth: แต่นั่นไม่เหมาะกับฉัน นั่นไม่ใช่สถานการณ์ที่สมบูรณ์แบบจริงๆ แนวทางหนึ่งที่ฉันได้สำรวจไปบ้างแล้ว เพื่อเป็นหลักฐานของแนวคิด ก็คือการคิดว่าคุณทำสิ่งต่างๆ อย่างไร เช่น การใช้ 404 อย่างชาญฉลาด ตัวอย่างเช่น กรณีการใช้งานขนาดใหญ่สำหรับป้ายขนาดใหญ่มาก บางทีเว็บไซต์ข่าวก็คือ เมื่อพวกเขาต้องการ URL เมื่อมีข่าวด่วนเกิดขึ้น พวกเขาจะต้องเป็นคนแรกที่ทำให้มันใช้งานได้ พวกเขาต้องได้รับ URL ที่นั่น อย่างเช่น BBC News คุณจะเห็นว่าข่าวดังกล่าวจะมาถึงเว็บไซต์ และจากนั้นการทำงานล่วงเวลาก็จะเพิ่มมากขึ้นเรื่อยๆ แต่การไปถึงที่หมายก่อนเป็นกุญแจสำคัญ ดังนั้น การสร้างที่ใช้เวลา 10 นาที 20 นาที ไม่ว่ามันจะเป็นอะไร นั่นอาจเป็นปัญหาได้

ฟิล ฮอว์กสเวิร์ธ: แต่ถ้าเนื้อหานั้นเป็นนามธรรมและอาจเคยถูกเรียกจาก API ฉันพูดถึงระบบการจัดการเนื้อหาที่เป็นนามธรรม เช่น Contentful หรือ Sanity หรือหลายอย่าง สิ่งใดก็ตามที่มี Content API จะเปลี่ยนโครงสร้างเนื้อหาที่จะเรียกใช้งานบิลด์และเราจะดำเนินการ แต่สิ่งอื่นที่อาจเกิดขึ้นก็คือ ถ้าคุณเผยแพร่ URL ของคุณสำหรับสิ่งนั้น แล้วจึงเผยแพร่ URL นั้น แม้ว่าบิลด์จะไม่ทำงาน ถ้ามีคนฮิก URL นั้น ถ้าการหยุดครั้งแรกบน 404 แทนที่จะพูดว่า "เราไม่เข้าใจ" คือการกด API นั้นโดยตรง คุณก็พูดได้ , “บิลด์ยังไม่เสร็จสิ้นในการเติมข้อมูลนั้น แต่ฉันสามารถทำได้ในไคลเอนต์” ฉันสามารถไปที่ API ได้โดยตรง รับสิ่งนั้น เติมลงในไคลเอนต์

Vitaly: อืม น่าสนใจ

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

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

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

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

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

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

ฟิล ฮอว์คสเวิร์ธ: ช่างเป็นคำถามจริงๆ ฉันหมายถึง ถ้าเราไม่ได้พูดถึงงานสร้างที่เพิ่มขึ้น ก็คงจะเป็น—

Vitaly: เราทำ มันสายเกินไปแล้ว บัตรใบนี้ผ่านไปแล้ว เราต้องการอย่างอื่น

ฟิล ฮอว์คสเวิร์ธ: งั้น—

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

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

ฟิล ฮอว์กสเวิร์ธ: แต่ผมชอบเห็นสิ่งที่ผมรู้ว่าจะได้ผลในหลายๆ ที่ พวกเขาจะมีประสิทธิภาพจริงๆ จะเห็นอกเห็นใจต่อเบราว์เซอร์ที่มีอยู่ - ไม่ใช่แค่บนโต๊ะทำงานของ CEO และ CTO ที่ได้รับของเล่นที่เก๋ไก๋ แต่ยังรวมถึงผู้ที่มีอุปกรณ์ที่ใช้พลังงานต่ำกว่ามากหรือพวกเขา' มีเงื่อนไขเครือข่ายที่ท้าทายและสิ่งต่างๆ เหล่านั้น ฉันชอบเห็นประสบการณ์ที่น่าสนใจและประสบการณ์ที่หลากหลาย นำเสนอในลักษณะที่เห็นอกเห็นใจต่อแพลตฟอร์มและเป็นความเห็นอกเห็นใจต่อผู้ชมในวงกว้างเพราะฉันคิดว่าเว็บเข้าถึงได้ไกลกว่าเรามาก นักพัฒนาที่สร้างสิ่งต่าง ๆ เพื่อมัน . และฉันรู้สึกตื่นเต้นที่ได้เห็นสิ่งที่น่าสนใจทำสำเร็จ ในรูปแบบที่เข้าถึงผู้คนได้มากขึ้น

ฟิล ฮอว์กสเวิร์ธ: นั่นอาจไม่ใช่คำตอบที่คุณต้องการ—

Vitaly: โอ้ นั่นเป็นตอนจบที่ดี ขอบคุณมาก. ไม่ มันสมบูรณ์แบบ นั่นคือสิ่งที่จริงๆ เอาล่ะ ฉันรู้สึกว่าทุกอย่างเป็นไปด้วยดี! ขอบคุณมากที่อยู่กับเรา! ฉันกำลังแจกสกอตต์!

ฟิล ฮอว์คสเวิร์ธ: เยี่ยม!

Vitaly: ฉันมาที่นี่เพื่อเล่นคำถามและคำตอบ ขอบคุณมากนะ ฟิล! ฉันยังอยู่ แต่สก็อตต์ เวทีเป็นของคุณแล้ว! บางทีคุณอาจแบ่งปันกับเราว่ามีอะไรใหม่ใน Smashing TV บ้าง

สกอตต์: ฉันจะทำ แต่ก่อนอื่น ฟิล ฉันแทบรอไม่ไหวที่จะเห็นว่าการใช้งาน API แบบ scratch-and-sniff ทำงานอย่างไร ฟังดูน่าสนใจมาก และ Vitaly JAMstackify ถูกนำไปใช้แล้ว

Vitaly: (สลด) ถ่ายแล้ว?! เราสามารถซื้อได้หรือไม่?

สกอตต์: ไม่ มันมีอยู่!

วิทาลี : นั่นสายเกินไปแล้ว ฉันมาสายเสมอ

ฟิล ฮอว์กสเวิร์ธ: น่าตื่นเต้นในแบบของตัวเอง

Vitaly: นั่นคือเรื่องราวในชีวิตของฉัน ฉันมาสายเสมอ

สก็อตต์: สมาชิกที่กำลังจะตามมา ฉันเชื่อว่าวันพฤหัสบดีที่ 13 เรามีพ่อเก่าของฉัน แซค เลเธอร์แมน พูดถึงสิ่งที่เขาพูดถึงได้ดีที่สุด ซึ่งก็คือฟอนต์ ดังนั้น เขากำลังพูดถึง Five Y's of Font Implementations จากนั้น ฉันก็สนใจวิดีโอที่เราเปิดตัวในวันที่ 19 เช่นกัน ซึ่งก็คือการตัดต่อวิดีโอด้วย JavaScript และ CSS กับ Eva Faria ดังนั้นคอยติดตามทั้งคู่

Scott: นั่นคืออีกครั้งในวันพฤหัสบดีหน้ากับ Zach Leatherman และในวันที่ 19 กับ Eva ซึ่งจะพูดถึงการตัดต่อวิดีโอใน JavaScript และ CSS ในบันทึกนั้น ฟิล ฉันไม่เห็นคุณอีกแล้ว คุณยังอยู่ที่นั่นไหม

ฟิล ฮอว์คสเวิร์ธ: ฉันมาแล้ว!

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

Vitaly: ขอบคุณมากทุกคน!

Vitaly: อ้อ อีกอย่างนะ! บางทีฟิลอาจพูดถึงเรื่องนี้ แต่เราก็มีการประชุม JAMstack Conference ที่ลอนดอนในเดือนกรกฎาคมด้วย ดังนั้นนั่นคือสิ่งที่ต้องระวังเช่นกัน แต่ฉันกำลังจะออกไปและจะไปเอาสลัดของฉัน! ไม่แน่ใจว่าคุณ—

สก็อตต์: โอเค ลาก่อน ทุกคน!

Vitaly: เอาล่ะ ลาก่อน ทุกคน

นั่นคือห่อ!

เราขอขอบคุณ Smashing Members จากก้นบึ้งของหัวใจของเราสำหรับการสนับสนุนอย่างต่อเนื่องและมีน้ำใจ - และเราแทบรอไม่ไหวที่จะเป็นเจ้าภาพการสัมมนาทางเว็บเพิ่มเติมในอนาคต

นอกจากนี้ Phil จะเป็น MC ที่ SmashingConf Toronto 2019 ในสัปดาห์หน้าและที่ JAMstack_conf เราอยากพบคุณที่นั่นเช่นกัน!

โปรดแจ้งให้เราทราบหากคุณพบว่าบทสัมภาษณ์ชุดนี้มีประโยชน์ และคุณอยากให้เราสัมภาษณ์ใคร หรือหัวข้อใดที่คุณต้องการให้เราพูดถึง แล้วเราจะแก้ไขให้ทันที