Smashing Podcast ตอนที่ 22 กับ Chris Coyier: Serverless คืออะไร?

วันนี้ เรากำลังพูดถึงสถาปัตยกรรมแบบ Serverless หมายความว่าอย่างไร และแตกต่างจากที่เราสร้างไซต์ในปัจจุบันอย่างไร ฉันคุยกับ Chris Coyier เพื่อหาคำตอบ

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

• microsite ของ Chris พลังของ Serverless สำหรับนักพัฒนา Front-end
• คริสในทวิตเตอร์
• ShopTalk Show พอดคาสต์

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

• “การตั้งค่า Redux สำหรับใช้งานในโลกแห่งความเป็นจริง”
  โดย Jerry Navi
• “คุณออกแบบเว็บไซต์สำหรับประสาทสัมผัสทั้งห้าได้ไหม”
  โดย Suzanne Scacca
• “การสร้างบล็อกแบบคงที่ด้วย Sapper และ Strapi”
  โดย Daniel Madalitso Phiri
• “คู่มือเชิงปฏิบัติสำหรับการแนะนำผลิตภัณฑ์ในแอป React”
  โดย พรโครเฟฆะ
• “วิธีการสร้างรถปอร์เช่ 911 ด้วยภาพสเก็ตช์ ”
  โดย นิโคลา ลาซาเรวิช

การถอดเสียง

Drew McLellan: เขาเป็นนักออกแบบเว็บไซต์และนักพัฒนาที่คุณอาจรู้จักจาก CSS-Tricks ซึ่งเป็นเว็บไซต์ที่เขาเริ่มต้นเมื่อ 10 ปีที่แล้ว และยังคงเป็นแหล่งข้อมูลการเรียนรู้ที่ยอดเยี่ยมสำหรับการสร้างเว็บไซต์เหล่านั้น เขาเป็นผู้ร่วมก่อตั้ง CodePen ซึ่งเป็นสนามเด็กเล่นเข้ารหัสบนเบราว์เซอร์และชุมชนที่ front-ender ทั่วโลกใช้เพื่อแชร์สิ่งที่พวกเขาสร้างและค้นหาแรงบันดาลใจจากผู้ที่พวกเขาติดตาม ควบคู่ไปกับ Dave Rupert เป็นเจ้าภาพร่วมของ ShopTalk Show ซึ่งเป็นพอดคาสต์เกี่ยวกับการสร้างเว็บไซต์ เรารู้ว่าเขารู้มากเกี่ยวกับการพัฒนาเว็บ แต่คุณรู้ไหมว่าเขาเคยชนะการแข่งขันกินฮอทดอกด้วยเสน่ห์ของเขาเท่านั้น? เพื่อนที่ยอดเยี่ยมของฉัน ได้โปรดต้อนรับคริส โคเยียร์ด้วย สวัสดีคริส สบายดีไหม

Chris Coyier: เฮ้ ฉันยอดเยี่ยมมาก

Drew: ฉันต้องการคุยกับคุณวันนี้ไม่เกี่ยวกับ CodePen และฉันไม่ต้องการคุยกับคุณเกี่ยวกับ CSS-Tricks ซึ่งเป็นหนึ่งในแหล่งข้อมูลที่น่าทึ่งที่ฉันแน่ใจว่าทุกคนรู้จักจะปรากฏที่ด้านบนของ Google ผลการค้นหาเมื่อค้นหาคำตอบเกี่ยวกับคำถามเกี่ยวกับการพัฒนาเว็บ ใบหน้าของคุณปรากฏขึ้นและมีบล็อกโพสต์ที่มีประโยชน์ซึ่งเขียนโดยคุณหรือหนึ่งในผู้ร่วมให้ข้อมูลที่เป็นแขกของคุณ

Chris: โอ้ ฉันเคยทำแบบนั้นจริงๆ มี… ฉันไม่รู้ อาจเป็นช่วงที่ Google มีโซเชียลเน็ตเวิร์กแปลกๆ เมื่อกี้คืออะไร? กูเกิลพลัส?

ดรูว์: อ้อ อีกอย่าง ใช่

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

ดรูว์ : ฉันคิดอย่างนั้น ใช่-

คริส: ครับ

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

คริส: อืม (ยืนยัน)

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

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

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

คริส : ครับ ครับ แค่นั้นแหละ.

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

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

Chris: แต่ฉันคิดว่ามันน่าสนใจที่… มันเริ่มที่จะเป็นเช่นนั้น บางทีจริง ๆ แล้วไม่มีเซิร์ฟเวอร์ที่เกี่ยวข้องในบางครั้ง ฉันคิดว่าสิ่งหนึ่งที่ล็อก Serverless ไว้เป็นแนวคิดคือ AWS Lambda พวกเขาเป็นคนแรกในที่เกิดเหตุ แลมบ์ดาเป็นเหมือนฟังก์ชันที่คุณมอบให้ AWS และวางไว้บนท้องฟ้าที่มีมนต์ขลัง จากนั้น... มันมี URL และคุณสามารถกดใช้งาน และมันจะเรียกใช้ฟังก์ชันนั้นและส่งคืนบางสิ่งหากคุณต้องการ คุณรู้? นั่นเป็นเพียง HTTP หรืออะไรก็ตาม นั่นเป็นวิธีที่มันทำงาน ซึ่ง… ครั้งแรกที่คุณได้ยินแบบนั้น คุณจะแบบ “ทำไม? ฉันไม่สนใจ” แต่แล้วก็มีบางสิ่งที่ชัดเจน มันสามารถรู้คีย์ API ของฉันที่ไม่มีใครเข้าถึงได้ นั่นเป็นสาเหตุว่าทำไมคุณจึงเรียกใช้แบ็คเอนด์ตั้งแต่แรก ก็คือมันรู้ข้อมูลลับที่ไม่จำเป็นต้องอยู่ใน JavaScript ทางฝั่งไคลเอ็นต์ ดังนั้นหากต้องการพูดคุยกับฐานข้อมูลก็สามารถทำได้ สามารถทำได้อย่างปลอดภัยโดยไม่ต้องเปิดเผยคีย์ API ที่อื่น หรือแม้แต่ข้อมูลนั้นอยู่ที่ไหน หรือได้มาอย่างไร มันคือ...

คริส: งั้นก็เยี่ยมไปเลย ฉันสามารถเขียนฟังก์ชันที่พูดกับฐานข้อมูล รับข้อมูล แล้วคืนค่านั้น เย็น. แลมบ์ดาก็เป็นอย่างนั้น แต่ AWS ใช้งานได้ คุณต้องเลือกภูมิภาค คุณเป็นเหมือน "ฉันไม่รู้ มันควรจะอยู่ที่ไหนเวอร์จิเนีย? โอเรกอน? ฉันควรเลือกออสเตรเลียหรือไม่ ฉันไม่รู้” พวกเขามี 20, 30. ฉันไม่รู้ด้วยซ้ำว่าพวกเขามีกี่วัน แต่แม้แต่แลมบ์ดาก็มีภูมิภาค ฉันคิดว่าพวกเขาทุกวันนี้มี Lambda@Edge ซึ่งหมายความว่ามันเป็นทุกภูมิภาคซึ่งค่อนข้างเจ๋ง แต่พวกเขาเป็นคนแรก และตอนนี้ทุกคนมีบางอย่างที่เหมือนกับแลมบ์ดา บริการคลาวด์ทั้งหมด พวกเขาต้องการบริการบางอย่างในโลกนี้ หนึ่งในนั้นคือ CloudFlare CloudFlare มีผู้ปฏิบัติงาน พวกเขามีที่ตั้งมากกว่าที่ AWS มี แต่พวกเขาก็ดำเนินการได้ในเวลาที่ต่างกันเช่นกัน… วิธีที่พนักงาน CloudFlare… คล้ายกับแลมบ์ดาที่คุณสามารถเรียกใช้ Node ได้ คุณสามารถเรียกใช้จาวาสคริปต์ คุณสามารถใช้ภาษาอื่นได้หลายภาษาเช่นกัน แต่... ฉันคิดว่าสิ่งนี้ส่วนใหญ่ ภาษาที่น่าสนใจที่สุดคือ JavaScript เพียงเพราะความชุกของมัน

Chris: มันเกิดขึ้นที่ระดับ CDN เท่านั้น ซึ่งฉันคิดว่าเป็นเซิร์ฟเวอร์ แต่ฉันมักไม่คิดว่า CDN เป็นเซิร์ฟเวอร์ ไม่ชัดเท่าอย่างอื่น ระยะหลังนี้เริ่มรู้สึกว่าไม่มีเซิร์ฟเวอร์มากขึ้น CDN เป็นเซิร์ฟเวอร์หรือไม่ ฉันหมายถึง ฉันเดาว่ามันคือคอมพิวเตอร์ที่ไหนสักแห่ง แต่รู้สึกเหมือนกับว่าเซิร์ฟเวอร์-y น้อยกว่า

Drew: รู้สึกเหมือนใช่ CDN อาจเป็นเซิร์ฟเวอร์ แต่เป็นเซิร์ฟเวอร์รุ่นเล็กที่สุด มันเหมือนกับเซิร์ฟเวอร์ที่บางถ้าคุณต้องการ

คริส: ครับ แน่นอน.

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

คริส: ใช่ ไม่ได้หมายความว่าไม่มีรถยนต์อยู่จริง อืมที่ดี

Drew: คุณเพียงแค่เรียกมันออกมาเมื่อคุณต้องการ แต่ในขณะเดียวกัน คุณไม่ต้องจ่ายค่าซื้อรถล่วงหน้า คุณไม่ได้จ่ายค่าบำรุงรักษาหรือค่าน้ำมันหรือ-

Chris: ใช่และราคาก็สมเหตุสมผลด้วยใช่ไหม ที่ดี นั่นเป็นการเปรียบเทียบที่ดี ฉันคิดว่า และเนื่องจากอยู่ในระดับ CDN ด้วย มันแค่สกัดกั้นคำขอ HTTP ที่เกิดขึ้นแล้ว ซึ่งหมายความว่าคุณไม่ต้องถาม… คุณไม่ได้ส่งคำขอไปและคำขอนั้นจะส่งคำขอกลับ มันเพิ่งเกิดขึ้นระหว่างการร้องขอตามธรรมชาติ ซึ่งทำให้รู้สึกเซิร์ฟเวอร์-y น้อยลง ไม่รู้สิ น่าสนใจ มันน่าสนใจอย่างแน่นอน มันเป็นเรื่องใหญ่ แต่ที่คุณพูดถึงเรื่องการกำหนดราคา ที่คุณจ่ายเฉพาะสิ่งที่คุณใช้ นั่นก็สำคัญเช่นกัน เพราะ… สมมติว่าคุณเป็นแบ็คเอนด์ dev ที่เคยปั่นเซิร์ฟเวอร์มาทั้งชีวิต และพวกเขารับผิดชอบค่าใช้จ่าย "ฉันต้องการเซิร์ฟเวอร์ประเภทนี้ที่มีหน่วยความจำประเภทนี้และ CPU ประเภทนี้และข้อกำหนดประเภทนี้ และต้องใช้เงินเท่าไหร่” Serverless มาพร้อมและตัดหัวของราคานั้น

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

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

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

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

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

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

Chris: มันไม่ใช่แค่ JAMstack เหมือนกัน เรายังอยู่ในยุคของกรอบงาน JavaScript เรากำลังอยู่ในยุคที่มันเริ่มมีความคาดหวังมากขึ้นเล็กน้อยว่าวิธีที่แอปพลิเคชัน JavaScript เริ่มทำงาน คือการเมาต์ส่วนประกอบบางอย่าง และเมื่อส่วนประกอบเหล่านั้นเมานต์ ก็จะขอข้อมูลที่ต้องการ ดังนั้นจึงอาจเป็นเรื่องปกติสำหรับบางอย่างเช่นเว็บไซต์ React ที่จะเป็น "ฉันจะใช้ฟังก์ชันแบบไร้เซิร์ฟเวอร์เพื่อกระจายข้อมูลที่ต้องการ มันกระทบ JSON API เป็นหลัก ฉันได้รับข้อมูล JSON ที่ต้องการ และสร้างตัวเองจากข้อมูลนั้น จากนั้นจึงแสดงผลบนหน้า” ตอนนี้ไม่ว่าจะดีหรือไม่ดีสำหรับเว็บก็ตาม "ฉันไม่รู้ เลวมาก. เรือแล่นแล้ว นั่นเป็นวิธีที่ผู้คนจำนวนมากสร้างไซต์” เป็นเพียงสิ่งที่ลูกค้าแสดงผล ดังนั้น JavaScript แบบไร้เซิร์ฟเวอร์และทันสมัยจึงไปด้วยกันได้

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

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

ดรูว์: อืม (ยืนยัน)

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

Drew: แน่นอน ผู้คนจำนวนมากกำลังจัดการกับระบบเดิมที่... สิ่งฐานข้อมูลเก่าที่สร้างขึ้นในปี 2000 ที่พวกเขาอาจสามารถติดชั้น JSON API ที่ด้านบนสุดของ...

คริส: ครับ

Drew: … และสร้างสิ่งที่ทันสมัยกว่าและบางทีอาจไร้เซิร์ฟเวอร์แล้วยังคงโต้ตอบกับระบบเดิมเหล่านั้นด้วยการติดกาวเข้าด้วยกันในลักษณะแปลก ๆ

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

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

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

Drew: น่าสนใจทีเดียว งานประเภทใดที่คุณวางบน CodePen แบบไร้เซิร์ฟเวอร์?

คริส : อืม มีหลายอย่างเลย หนึ่งในนั้นคือ ฉันคิดว่า หวังว่าค่อนข้างชัดเจนคือ ฉันต้องการ… ประเด็นของ CodePen คือคุณเขียน HTML, CSS และ JavaScript แต่ละรายการในเบราว์เซอร์และแสดงผลต่อหน้าคุณใช่ไหม แต่คุณสามารถเลือกภาษาของตัวประมวลผลล่วงหน้าได้เช่นกัน สมมติว่าคุณชอบ Sass คุณเปิด Sass ใน CSS และคุณเขียน Sass มีบางอย่างต้องประมวลผล Sass ทุกวันนี้ Sass เขียนด้วยภาษา Dart หรืออะไรสักอย่าง

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

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

คริส: นี่คือตัวอย่าง ปากกาทุกอันบน CodePen มีภาพหน้าจอ แบบนั้นก็เจ๋งใช่มั้ยล่ะ? ดังนั้น ผู้คนจึงสร้างสิ่งต่างๆ ขึ้นมา จากนั้นเราต้องการ PNG หรือ JPEG หรือบางอย่างของสิ่งนั้น เพื่อที่เราจะสามารถ... เมื่อคุณทวีตมัน คุณจะได้พรีวิวเล็กๆ น้อยๆ ของมัน หากคุณแชร์ใน Slack คุณจะได้ดูตัวอย่างเล็กน้อย เราใช้มันบนเว็บไซต์เพื่อแสดงผล… แทนที่จะเป็น iframe หากเราตรวจพบว่าปากกาไม่เคลื่อนไหว เนื่องจากภาพของ iframe นั้นเบากว่ามาก เหตุใดจึงไม่ใช้รูปภาพนั้น มันไม่เคลื่อนไหวอยู่แล้ว เพียงแค่ประสิทธิภาพที่เพิ่มขึ้นเช่นนั้น ดังนั้นภาพหน้าจอแต่ละภาพจึงมี URL ของมันอย่างชัดเจน และเราได้ออกแบบสถาปัตยกรรมเพื่อให้ URL นั้นเป็นฟังก์ชันแบบไร้เซิร์ฟเวอร์จริงๆ มันเป็นคนงาน ดังนั้น หาก URL นั้นถูกโจมตี เราสามารถตรวจสอบได้อย่างรวดเร็วว่าเราได้จับภาพหน้าจอนั้นแล้วหรือไม่

Chris: CloudFlare Workers ใช้งานได้จริงเพราะ CloudFlare Workers ไม่ได้เป็นเพียงฟังก์ชันแบบไร้เซิร์ฟเวอร์ แต่พวกเขามีที่เก็บข้อมูลด้วย พวกเขามีสิ่งนี้เรียกว่าที่เก็บคีย์-ค่า ดังนั้น ID ของสิ่งนั้น เราสามารถตรวจสอบได้อย่างรวดเร็วจริงๆ และมันจะเป็น "จริงหรือเท็จ คุณมีหรือไม่" ถ้าได้ก็จัดให้ครับ และให้บริการบน CloudFlare ซึ่งเร็วมากในการเริ่มต้น และจากนั้นก็ให้ความสามารถทั้งหมดนี้แก่คุณด้วย เนื่องจากเป็น CDN อิมเมจ คุณสามารถพูดได้ว่า “แสดงในรูปแบบที่เหมาะสมที่สุด ทำหน้าที่เป็นมิติเหล่านี้” ฉันไม่ต้องสร้างภาพในมิติเหล่านั้น คุณเพียงแค่ใส่ขนาดใน URL และมันกลับมาเป็นขนาดนั้นอย่างน่าอัศจรรย์ นั่นเป็นสิ่งที่ดีจริงๆ หากไม่มี ระบบจะถามฟังก์ชันไร้เซิร์ฟเวอร์อื่นเพื่อให้ทำงานได้รวดเร็วมาก มันจะสร้างมันขึ้นมา แล้วก็ใส่มันลงในถังที่ไหนสักแห่ง… เพราะคุณต้องมีที่มาของภาพใช่ไหม? คุณต้องโฮสต์จริงที่ไหนสักแห่งโดยปกติ ดังนั้นเราจึงใส่มันลงในถัง S3 อย่างรวดเร็วจริง ๆ แล้วให้บริการ

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

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

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

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

คริส: อืม (ยืนยัน)

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

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

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

คริส: หวัดดีครับ

Drew: … ประเภทของความคิด แต่สิ่งหนึ่งที่เรารู้เกี่ยวกับเว็บก็คือ เว็บได้รับการออกแบบมาให้มีความยืดหยุ่น เนื่องจากเครือข่ายมีความเปราะบาง

คริส: อืม (ยืนยัน)

Drew: วิธีการแบบไร้เซิร์ฟเวอร์ที่แข็งแกร่งเพียงใด? จะเกิดอะไรขึ้นถ้ามีบางอย่าง... ถ้าชิ้นเล็กๆ ชิ้นหนึ่งหายไป?

คริส: นั่นคงจะแย่มาก คุณรู้? มันจะเป็นหายนะ เว็บไซต์ของคุณจะล่มเหมือนเซิร์ฟเวอร์อื่น ๆ ครับ ผมคิดว่าถ้าเกิดว่าเว็บล่ม

ดรูว์: มีวิธีบรรเทาไหม โดยเฉพาะอย่างยิ่ง-

คริส: ฉันไม่รู้

Drew: … เหมาะกับวิธีการแบบนี้ที่คุณเคยเจอมา?

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

คริส: ฉันไม่รู้จริงๆ บางทีคุณอาจรู้กลยุทธ์บางอย่างที่ฉันไม่รู้ เกี่ยวกับความยืดหยุ่นของเซิร์ฟเวอร์ไร้เซิร์ฟเวอร์

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

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

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

คริส: ใช่ ฉันชอบความคิดที่จะลองมากกว่าหนึ่งครั้ง มากกว่าที่จะพูดว่า "ไม่นะ ล้มเหลว. ยกเลิก” “ไม่รู้ ทำไมไม่ลองอีกครั้งล่ะเพื่อน”

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

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

Chris: มันเป็นเรื่องที่แตกต่างกันเล็กน้อยเมื่อพูดถึงคำขอ HTTP นั่นคือสิ่งที่คุณกำลังพยายามทดสอบ มันตอบสนองต่อการร้องขออย่างถูกต้องหรือไม่? และคืนของได้ถูกต้องหรือไม่? ฉันไม่รู้ เครือข่ายอาจมีส่วนร่วมที่นั่น ดังนั้นคุณอาจต้องการเขียนการทดสอบในระดับนั้น ไม่เป็นไร. ฉันไม่รู้ เรื่องราวปกติที่นั่นคืออะไร? คุณหมุนเซิร์ฟเวอร์ในเครื่องบางประเภทหรือบางอย่างที่ให้บริการ ใช้บุรุษไปรษณีย์ฉันไม่รู้ แต่มี… กรอบงานพยายามช่วยเช่นกัน ฉันรู้ว่า ".com" แบบไร้เซิร์ฟเวอร์ซึ่งสร้างความสับสนอย่างมาก แต่มีบริษัทที่ชื่อว่า Serverless อย่างแท้จริง และพวกเขาสร้างกรอบงานสำหรับการเขียนฟังก์ชันแบบไร้เซิร์ฟเวอร์ที่ช่วยให้คุณปรับใช้ได้

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

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

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

คริส: ครับ I mean, if you want to use no tooling at all, I think they have a really… like AWS, specifically, has a really rudimentary GUI for the thing. You can paste the code in there and hit save and be like, “Okay, I guess it's live now.” That's not the best dev story, but I think you could do it that way. I know CloudFlare workers have this thing called Wrangler that you install locally. You spin it up and it spins up a fake browser on the top and then dev tools below. Then you can visit the URL and it somehow intercepts that and runs your local cloud function against it. Because one of the interesting things about workers is… you know how I described how it… you don't hit a URL and then it returns stuff. It just automatically runs when you… when it intercepts the URL, like CDN style.

Chris: So, one of the things it can do is manipulate the HTML on the way through. The worker, it has access to the complete HTML document. They have a jQuery-esque thing that's like, “Look for this selector. Get the content from it. Replace it with this content. And then continue the request.” So you can mess with code on the way through it. To test that locally, you're using their little Wrangler tool thing to do that. Also, I think the way we did it was… it's also a little dangerous. The second you put it live, it's affecting all your web traffic. It's kind of a big deal. You don't want to screw up a worker. คุณรู้? You can spin up a dev worker that's at a fake subdomain, and because it's CloudFlare, you can… CloudFlare can just make a subdomain anyway. ฉันไม่รู้ It's just kind of a nice way to do a… as you're only affecting sub-domain traffic, not your main traffic yet. But the subdomain's just a mirror of a production anyway, so that's kind of a… that's a testing story there.

Chris: It brings up an interesting thing, though, to me. It's like… imagine you have two websites. One of them is… for us it's like a Ruby on Rails app. อะไรก็ตาม. It's a thing. But we don't have a CMS for that. That's just like… it's not a CMS, really. I think there's probably Ruby CMSs, but there's not any renowned ones. คุณรู้? It seems like all the good CMSs are PHP, for some reason. So, you want a quality CMS. Drew, you've lived in the CMS market for a long time -

Drew: Absolutely.

Chris: … so you know how this goes. Let's say you want to manage your sites in Perch or whatever, because it's a good CMS and that's the proper thing to use to build the kind of pages you want to build. But you don't want to run them on the same server. Unless you want to manage the pages on one site, but show them on another site. Well, I don't know, there's any number of ways to do that. But one JavaScript way could be, “Okay, load the page. There's an empty div there. Run some JavaScript. Ask the other site for the content of that page and then plunk it out on the new page.” That's fine, I guess, but now you're in a client side rendered page. It's going to be slow. It's going to have bad SEO, because… Google will see it eventually, but it takes 10 days or something. It's just a bad story for SEO. It's not very resilient, because who knows what's going to happen in the network. It's not the greatest way to do this kind of “content elsewhere, content on site B, show page of site A”, situation.

Chris: You could also do it on the server side, though. Let's say you had… Ruby is capable of granting a network request too, but that's even scarier because then if something fails on the network, the whole page could die or something. It's like a nervous thing. I don't love doing that either. But we did this just recently with a worker, in that we… because the worker's JavaScript, it can make a fetch request. So, it fetches site A, it finds this div on the page, and then it goes and asks site B for the content. Gets the content. Plugs it into that div, and serves the page before it gets anything. So it looks like a server rendered page, but it wasn't. It all happened at the… on the edge, at the worker level, at the serverless level.

Chris: So it's kind of cool. I think you can imagine a fetch request on the browser probably takes, I don't know, a second and a half or something. It probably takes a minute to do it. But because these are… site B is hosted on some nice hosting and Cloudflare has some… who knows what kind of super computers they use to do it. พวกเขาทำ. Those are just two servers talking to each other, and that fetch request happens just so super duper, duper fast. It's not limited to the internet connection speed of the user, so that little request takes like two milliseconds to get that data. So it's kind of this cool way to stitch together a site from multiple sources and have it feel like, and behave like, a server rendered page. I think there's a cool future to that.

Drew: Are there any sort of conventions that are sort of springing up around serverless stuff. I'm sort of thinking about how to architect things. Say I've got something where I want to do two sort of requests to different APIs. I want to take in a postal address and geocode it against one, and then take those coordinates and send that to a florist who's going to flower bomb my front yard or something. How would you build that? Would you do two separate things? Or would you turn that into one function and just make the request once from the browser?

Chris: Mm (affirmative). That's a fascinating question. I'd probably have an architect function or something. One function would be the one that's in charge of orchestrating the rest of them. It doesn't have to be, your website is the hub and it only communicates to this array of single sources. Serverless functions can talk to other serverless functions. So I think that's somewhat common to have kind of an orchestrator function that makes the different calls and stitches them together, and returns them as one. I think that is probably smart and faster, because you want servers talking to servers, not the client talking to a whole bunch of servers. If it can make one request and get everything that it needs, I think that's probably generally a good idea-

Drew: Yeah, that sounds smart. ใช่.

Chris: But I think that's the ultimate thing. You get a bunch of server nerds talking, they'll talk about the different approaches to that exact idea in 10 different ways.

ดริว : ครับ No, that sounds pretty smart. I mean, you mentioned as well that this approach is ideal if you're using APIs where you've got secret information. You've got API keys or something that you don't want to live in the client. Because I don't know, maybe this florist API charges you $100 dollars every time flower bomb someone.

Chris: Easily.

Drew: You can basically use those functions to almost proxy the request and add in the secret information as it goes, and keep it secret. That's a viable way to work?

Chris: Yeah, yeah. ฉันคิดอย่างนั้น. I mean, secrets are, I don't know, they're interesting. They're a form of buy in I think to whatever provider you go with, because… I think largely because of source control. It's kind of like, you could just put your API key right in the serverless function, because it's just going to a server, right? You don't even have to abstract it, really. The client will never see that code that executes, but in order for it to get there, there's probably a source control along the way. It's probably like you commit to master, and then master… then some kind of deployment happens that makes that thing go to the serverless function. Then you can't put your API key in there, because then it's in the repo, and you don't put your API keys in repos. That's good advice. Now there's stuff. We've just done… at CodePen recently, we started using this git-crypt thing, which is an interesting way to put keys safely into your repos, because it's encrypted by the time anybody's looking at that file.

Chris: But only locally they're decrypted, so they're useful. So it's just kind of an interesting idea. I don't know if that helps in this case, but usually, cloud providers of these things have a web interface that's, “Put your API keys here, and we'll make them available at runtime of that function.” Then it kind of locks… it doesn't lock you in forever but it kind of is… it's not as easy to move, because all your keys are… you put in some input field and some admin interface somewhere.

Drew: Yeah, I think that's the way that Netlify manage it.

Chris: They all do, you know?

ดริว : ครับ You have the secret environment variables that you can set from the web interface. That seems to work quite nicely.

Chris: Yeah, right. But then you got to leave… I don't know, it's not that big of a deal. I'm not saying they're doing anything nefarious or anything. How do you deal with those secrets? Well, it's a hard problem. So they kind of booted it to, I don't know, “Just put them in this input field and we'll take care of it for you, don't worry about it.”

Drew: Is there anything that you've seen that stands out as an obvious case for things that you can do with serverless, that you just couldn't do with a traditional kind of serverfull approach? Or is it just taking that code and sort of almost deploying it in a different way?

Chris: It's probably mostly that. I don't know that it unlocks any possibility that you just absolutely couldn't run it any other way. Yeah, I think that's a fair answer, but it does kind of commoditize it in an interesting way. Like, if somebody writes a really nice serverless function… I don't know that this exists quite yet, but there could kind of a marketplace, almost, for these functions. Like, I want a really good serverless function that can take a screenshot. That could be an open source project that lots of eyeballs around, that does a tremendously good job of doing it and solves all these weird edge cases. That's the one I want to use. I think that's kind of cool. คุณรู้? That you can kind of benefit from other people's experience in that way. I think that will happen more and more.

Drew: I guess it's the benefit that we talked about, right at the top, of enabling people who write JavaScript and may have written JavaScript only for the front-end, to expand and use those skills on the back-end as well.

คริส : ครับ ครับ ฉันคิดอย่างนั้น ฉันคิดว่านั่น… เพราะมีช่วงเวลาเช่น… คุณไม่จำเป็นต้องมีทักษะมากมายเพื่อที่จะรู้ว่าสิ่งใดเหมาะสมและสิ่งใดที่ไม่เหมาะกับเว็บไซต์ อย่างที่ฉันทำบทเรียนเล็กๆ น้อยๆ ในสัปดาห์ก่อน ซึ่งมีข้อผิดพลาดนี้ใช้สิ่งเหล่านี้... เมื่อคุณบันทึกความผิดพลาด พวกเขาจะให้กระสุนสำหรับสิ่งที่คุณสร้างขึ้น นั่นคือ "วิสกี้ แทงโก้ ฟอกซ์ทรอต 1,000” มันเหมือนสิ่งเล็กน้อยที่ฉลาด โอกาสที่มันจะมีเอกลักษณ์เฉพาะตัวนั้นสูงมาก เพราะฉันคิดว่าพวกเขาใส่ตัวเลขต่อท้ายหรืออะไรทำนองนั้นด้วย แต่กลับกลายเป็นสิ่งเล็กๆ น้อยๆ ที่สนุกสนานเหล่านี้ พวกเขาเปิดห้องสมุดซึ่งมีคำทั้งหมดอยู่ในนั้น แต่ก็เหมือนเป็นร้อยเป็นพันคำ ไฟล์มีขนาดใหญ่ คุณรู้? มีเมกะไบต์ขนาดใหญ่เพียงแค่พจนานุกรมคำศัพท์ คุณอาจเรียนรู้ในปีแรกของการพัฒนา "อย่าส่งไฟล์ JavaScript ที่มีขนาดเมกะไบต์ของพจนานุกรม" มันไม่ดีที่จะส่ง คุณรู้? แต่โหนดไม่สนใจ คุณสามารถจัดส่งได้หลายร้อยรายการ มันไม่เกี่ยวข้องกับความเร็วบนเซิร์ฟเวอร์

ดริว : ครับ

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

Chris: เป็นเพียง… นักพัฒนา JavaScript ระดับปานกลางหรือมือใหม่ ฉันคิดว่าสามารถดึงสิ่งนั้นออกมาได้ ซึ่งเยี่ยมมาก นั่นคือสิ่งที่เปิดใช้งานที่พวกเขาไม่เคยมีมาก่อน ก่อนหน้านี้พวกเขาประมาณว่า "นี่คืออาร์เรย์ของคำ 2MB" “โอ้ ฉันไม่สามารถส่งสิ่งนั้นให้กับลูกค้าได้” “อือ เดี๋ยวก็ปิดเอง” คุณอาจชนกำแพงนี้แบบว่า “ฉันทำส่วนนั้นไม่ได้แล้ว ฉันต้องขอให้คนอื่นช่วยฉันด้วยหรือไม่ทำหรือเลือกทากที่น่าเบื่อหรือบางตัว…” ก็แค่คุณต้องไปทางอื่นที่เป็นกำแพงให้คุณเพราะคุณทำไม่ได้ และตอนนี้ คุณ "โอ้ ฉันก็แค่..." แทนที่จะมีสิ่งนั้นในสแลชสคริปต์ของฉัน หรือในโฟลเดอร์สแลชสคริปต์ต้นทาง ฉันจะใส่ไว้ในโฟลเดอร์ฟังก์ชันแทน

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

ดริว : มันเจ๋งมาก คุณได้รวบรวมไมโครไซต์เล็กๆ น้อยๆ เกี่ยวกับแนวคิดเหล่านี้ ใช่ไหม

คริส: ครับ ฉันเร็วไปหน่อยสำหรับเกม ฉันเพิ่งทำงานกับมันวันนี้ เพราะ... มันได้รับคำขอดึง แนวคิด… ก็อยู่ที่ serverless.css-tricks.com และ… มี CSS-Tricks อยู่ด้วย ดังนั้นมันจึงเป็นโดเมนย่อยของ CSS-Tricks และฉันก็สร้างมันขึ้นมาโดยไร้เซิร์ฟเวอร์ด้วย ดังนั้นนี่คือ… CSS-Tricks ก็เหมือนไซต์ WordPress แต่นี่เป็นไซต์ตัวสร้างไซต์แบบสแตติก เนื้อหาทั้งหมดอยู่ใน GitHub repo ซึ่งเป็นโอเพ่นซอร์ส ดังนั้น หากคุณต้องการเปลี่ยนเนื้อหาของไซต์ คุณสามารถส่งคำขอสำรวจความคิดเห็นได้ ซึ่งก็ดีเพราะว่าเมื่อเวลาผ่านไปมีมากกว่าร้อยรายการ แต่ฉันสร้างเนื้อหาต้นฉบับทั้งหมด

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

คริส: นั่นคือทั้งหมดที่ ค่อนข้างจะเป็นรายการของเทคโนโลยี ใช่.

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

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

Chris: อันที่จริง ฉันรู้สึกประหลาดใจมากที่ได้รวบรวมเว็บไซต์นี้ไว้ด้วยกัน มาดูกัน. มีบริการหก, เก้า, สิบสอง, สิบห้า, สิบแปด, ยี่สิบเอ็ด, ยี่สิบสองบริการที่ต้องการช่วยให้คุณประมวลผลแบบฟอร์มของคุณบนไซต์นี้แบบไร้เซิร์ฟเวอร์ หากคุณต้องการเป็นวันที่ 23 ยินดีต้อนรับ แต่คุณมีการแข่งขันอยู่บ้าง ดังนั้น แนวคิดเบื้องหลังนี้คือ คุณเขียนแบบฟอร์มใน HTML เหมือนกับองค์ประกอบแบบฟอร์มอย่างแท้จริง แล้วแอ็ตทริบิวต์แอ็ตทริบิวต์ของแบบฟอร์ม ซึ่งไม่สามารถชี้ไปที่ใดก็ได้ภายใน เนื่องจากไม่มีอะไรให้ชี้ไป คุณไม่สามารถดำเนินการได้ จึงชี้ไปที่ภายนอก มันชี้ไปที่สิ่งที่พวกเขาต้องการให้คุณชี้ไป พวกเขาจะประมวลผลแบบฟอร์ม จากนั้นพวกเขามักจะทำสิ่งที่คุณคาดหวัง เช่น ส่งการแจ้งเตือนทางอีเมล หรือส่งของหย่อนคล้อย หรือส่งไปที่ Zapier แล้ว Zapier จะส่งไปที่อื่น พวกเขาทั้งหมดมีชุดคุณลักษณะ ราคา และสิ่งต่างๆ ที่แตกต่างกันเล็กน้อย แต่พวกเขากำลังพยายามแก้ปัญหานั้นให้คุณ เช่น "คุณไม่ต้องการประมวลผลแบบฟอร์มของคุณเองหรือ ไม่มีปัญหา. เราจะดำเนินการให้คุณ”

Drew: ใช่ มันเป็นทรัพยากรที่มีประโยชน์มาก ฉันขอแนะนำให้ทุกคนลองดู เป็น serverless.css-tricks.com ดังนั้นฉันจึงได้เรียนรู้ทุกอย่างเกี่ยวกับการใช้เซิร์ฟเวอร์แบบไร้เซิร์ฟเวอร์ ช่วงนี้คุณเรียนรู้อะไรไปบ้าง คริส?

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

Drew: เรียกเก็บเงินเป็นครั้งที่สอง ใช่.

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

Chris: ฉันเพิ่งรู้เมื่อไม่นานนี้เอง เพราะมีคนเริ่มทำ podcast เกี่ยวกับเรื่องนี้อีกครั้ง… ฉันไม่รู้ว่าฉันเจอมันได้อย่างไร แต่ฉันเพิ่งรู้ ฉันก็แบบ “เกมนี้มีชีวิตและดีในโลกปัจจุบัน คุณล้อฉันเล่นหรือเปล่า? สิ่งนี้เป็นพื้นฐานของข้อความ” และฉันก็ดีใจมากที่ได้เปิดใช้งานอีกครั้งและนำตัวละครเก่ากลับมาเล่นอีกครั้ง แต่เพียงเพื่อจะพบว่าไคลเอนต์ที่พวกเขามีให้คุณดาวน์โหลดสำหรับเกมนี้ ไม่ได้มีการพัฒนาเลย พวกเขาแย่มาก พวกเขาเกือบจะคิดว่าคุณกำลังใช้ Windows มีเพียงการแสดงผลที่ไม่ดีอย่างน่ากลัวเหล่านี้ ... และมันเป็นข้อความ คุณคิดว่าอย่างน้อยน่าจะมีรูปแบบตัวอักษรที่ดี ไม่ ฉันก็แบบว่า “ฉันมีส่วนร่วมได้ ฉันสามารถเขียนลูกค้าสำหรับเกมนี้ ใส่ตัวอักษรที่สวยงามลงไป” แค่ปรับปรุงสิ่งต่าง ๆ ให้ทันสมัยและฉันคิดว่าผู้เล่นของเกมจะซาบซึ้ง แต่มันรู้สึกล้นหลามสำหรับฉัน “ฉันจะทำได้ยังไง” แต่ฉันพบบางโครงการโอเพ่นซอร์ส หนึ่งในนั้นเป็นเหมือน… คุณสามารถเล่นเกมผ่านหน้าต่างเทอร์มินัลจริง และใช้ libs ของโอเพ่นซอร์สเพื่อสร้าง GUI จากหน้าต่างเทอร์มินัล

ดริว : จริงดิ?

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

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

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

คริส: นั่นเป็นวิธีเดียวที่ฉันเรียนรู้สิ่งต่างๆ ฉันถูกลากเข้าไปในบางสิ่งที่… ฉันประมาณว่า “ไม่ใช่…” มันแสดงด้วยไลบรารี JavaScript ชื่อ Mithril ซึ่ง… ฉันไม่รู้ว่าคุณเคยได้ยินเรื่องนี้หรือเปล่า แต่มันแปลก ไม่ใช่… มันเกือบจะเหมือนกับการเขียน React โดยไม่มี JSX คุณต้อง "สร้างองค์ประกอบ" และทำสิ่งเหล่านี้ทั้งหมด... แต่ควรจะเปรียบเทียบได้ดีกว่านั้น... และจริงๆ แล้วมันก็เป็นเรื่องสำคัญเพราะในเกมที่ใช้ข้อความนี้ ข้อความนั้นกำลังลอยอยู่ มีการจัดการข้อมูลจำนวนมาก ซึ่งก็เหมือนกับ... คุณคิดว่าเกมที่ใช้ข้อความนี้จะใช้งานได้ง่ายมากสำหรับหน้าต่างเบราว์เซอร์ที่จะเรียกใช้ แต่จริงๆ แล้วไม่เป็นเช่นนั้น มีการจัดการข้อมูลเกิดขึ้นมากมาย ซึ่งคุณต้องเป็นจริง… เราต้องมีสติสัมปชัญญะเกี่ยวกับความเร็วของการเรนเดอร์ คุณรู้?

ดรูว์: น่าทึ่งมาก-

คริส: เจ๋งไปเลย

ดริว : ครับ หากคุณผู้ฟังที่รัก ต้องการทราบข้อมูลเพิ่มเติมจาก Chris คุณสามารถหาเขาได้ทาง Twitter ซึ่งเขาคือ @chriscoyier แน่นอน CSS-Tricks สามารถพบได้ที่ css-tricks.com และ CodePen ที่ codepen.io แต่ที่สำคัญที่สุด ฉันแนะนำให้คุณสมัครรับข้อมูลพอดคาสต์ของ ShopTalk Show หากคุณยังไม่ได้ดำเนินการ ที่ shoptalkshow.com ขอบคุณที่มาร่วมงานกับเราในวันนี้ คริส คุณมีคำพรากจากกันบ้างไหม?

คริส: Smashingpodcast.com. ฉันหวังว่านั่นคือ URL จริง