Smashing Podcast ตอนที่ 25 กับ Anthony Campolo: RedwoodJS คืออะไร?

เรากำลังพูดถึง RedwoodJS การเป็นเฟรมเวิร์ก Jamstack แบบฟูลสแตกหมายความว่าอย่างไร ฉันได้พูดคุยกับแชมป์ชุมชน Anthony Campolo เพื่อหาคำตอบ

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

• RedwoodJS
• แอนโทนี่บน Twitter
• บทความชุดของ Anthony A First Look at RedwoodJS

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

• “บทนำสู่การวิ่งไลท์เฮาส์แบบเป็นโปรแกรม”
  เขียนโดย Katy Bowman
• “ส่วนประกอบปฏิกิริยาเคลื่อนไหวด้วย GreenSock”
  เขียนโดย Blessing Krofegha
• “การออกแบบเพื่อความสนใจ”
  เขียนโดย Victor Yocco
• “การใช้ GraphQL ขั้นสูงในเว็บไซต์ Gatsby”
  เขียนโดย อาลีม อิเซียกะ
• “การเปรียบเทียบวิธีการจัดแต่งทรงผมใน Next.js”
  เขียนโดย Adebiyi Adedotun

การถอดเสียง

Drew McLellan: เขาเป็นนักเรียนของ Lambda School กำลังศึกษาการพัฒนาเว็บแบบฟูลสแตก รวมทั้งเป็นผู้สนับสนุน RedwoodJS ในฐานะที่เป็นแชมป์ชุมชน เขาเพิ่งเขียนชุดบทความ 12 ตอนชื่อ A First Look at RedwoodJS ที่ช่วยอธิบายที่มาและแรงจูงใจของ Redwood พร้อมกับแนวคิดต่างๆ มากมายที่เฟรมเวิร์กนี้แนะนำ เรารู้ว่าเขาเป็นผู้เชี่ยวชาญที่ RedwoodJS แต่คุณรู้หรือไม่ว่าเขาไม่เคยเห็นสุนัข เพื่อนที่ยอดเยี่ยมของฉัน ยินดีต้อนรับแอนโธนี่ แคมโปโล

ดรูว์: สวัสดี แอนโทนี่ คุณเป็นอย่างไรบ้าง?

แอนโธนี่ คัมโปโล: สวัสดี ฉันยอดเยี่ยมมาก ขอบคุณมากที่มีฉัน

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

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

Drew: ดังนั้น มันเป็นเฟรมเวิร์กแบบฟูลสแตกที่พยายามรวบรวมแนวคิดมากมายเกี่ยวกับระบบนิเวศการพัฒนา Jamstack? นั่นถูกต้องใช่ไหม?

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

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

แอนโธนี่: พวกเขาช่ำชอง ใช่ จริงๆ แล้ว ฉันใช้เวลาพอสมควรในการเขียนเกี่ยวกับประวัติของกรอบงานและแนวคิดที่นำไปสู่มัน และ Tom Preston-Werner เป็นผู้สร้าง และเขาก็เป็นที่รู้จักในนามผู้สร้าง Jekyll ซึ่ง เป็นเครื่องกำเนิดไซต์แบบคงที่ที่มีอิทธิพลจริงๆ เขายังทำ TOML ซึ่งเป็นภาษาไฟล์การกำหนดค่า และเดิมเขาเป็น CEO ของ GitHub ดังนั้นงานของเขากับเพจ Jekyll และ GitHub และสิ่งที่ฉันคิดว่าได้นำไปสู่สิ่งที่เราคิดว่าเป็น Jamstack ในตอนนี้ หลายคนคงพูดว่า "โอ้ Jamstack ใหม่ พวกเขาทำอย่างนี้ตลอดไป” นั่นเป็นวิธีที่เรากำลังพูดถึงวิธีที่มันเป็นส่วนขยายของแนวคิดเก่า ๆ เหล่านี้ การสร้างไซต์แบบสแตติก แต่ด้วย GraphQL และไร้เซิร์ฟเวอร์ และแนวคิดเหล่านี้เกี่ยวกับวิธีใช้โค้ดกาวและ API เพื่อทำให้แอปของคุณทำงานได้

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

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

Drew: โอเค เริ่มจากด้านหน้าอย่างที่คุณพูดถึง มันอิงจาก React React นั้นบวกกับโค้ด Redwood จำนวนมากหรือเป็นเพียง React ธรรมดา? ความสมดุลที่นั่นคืออะไร?

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

Drew: ดังนั้น React ที่กำหนดค่าด้วยเครื่องมืออื่นๆ จำนวนมากที่ทำงานได้ดีกับ React เพื่อให้คุณมีระบบนิเวศที่ใช้งานได้สำหรับการทำงานในลักษณะนี้โดยเฉพาะ นั่นเป็นคำอธิบายที่ยุติธรรมหรือไม่?

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

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

แอนโธนี่: ใช่ มันเป็นแบบแผนมากกว่าแนวคิดประเภทการกำหนดค่า เพราะคุณมี… ทอม เหมือนกับที่เขาสร้าง GitHub ด้วย Ruby บน Rails และ Rob ซึ่งเป็นหนึ่งในผู้สนับสนุนหลักอื่นๆ เขาเป็นนักพัฒนา Rails ตลอดไป พวกเขามีแนวคิดมากมายที่สอดคล้องกับปรัชญาในแง่ของ Rails แต่พวกเขาต้องการนำแบบแผนเหล่านั้นมาแทนที่แนวคิดการกำหนดค่า แนวคิดกรอบงานเต็มสแต็ก และนำสิ่งนั้นไปใช้กับเทคโนโลยีสมัยใหม่ทั้งหมดที่เรามีตอนนี้

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

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

ดรูว์: งั้น บางทีเราเข้าไปข้างในกันสักหน่อยได้ไหม? เซลล์ในแง่ของเรดวูดคืออะไร?

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

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

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

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

แอนโธนี่: ใช่ ฉันคิดว่าน่าสนใจจริงๆ ที่เราได้เห็นความพยายามหลายครั้งในการแก้ปัญหานี้ เพราะฉันหมายความว่าคุณมีคนที่พูดแบบนี้มาตลอดว่า “ทำไมไม่มี Rails for JavaScript หรือ Rails for React?” มีบทสัมภาษณ์ทางวิทยุเต็มรูปแบบที่ยอดเยี่ยมระหว่าง Michael Chan และ Adam Wathan ที่เรียกว่า React ไม่ใช่คู่แข่งของ Rails นี่เป็นหนึ่งในเฟรมเวิร์กที่แตกต่างกัน

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

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

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

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

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

Drew: ดังนั้น เรามี GraphQL ไว้ที่นั่น ซึ่งช่วยให้เราสามารถสืบค้นแบ็กเอนด์บางประเภทได้ ใน Redwood แบ็กเอนด์คืออะไร?

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

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

Drew: ดังนั้น Prisma จึงเป็นชั้นเชิงนามธรรมระหว่างรหัสของคุณกับที่เก็บข้อมูลใด ๆ ที่คุณใช้ซึ่งสันนิษฐานว่า Prisma รองรับ นั่นคือ… หรือมันทำสิ่งที่ฉลาดกว่านั้นหรือไม่

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

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

แอนโทนี่: ครับ ใช่ นั่นแหละ ดังนั้น ในโฟลเดอร์ API ของแบ็กเอนด์ คุณมีโฟลเดอร์ lib ที่มี db.js และตามค่าเริ่มต้นแล้วที่มีไคลเอนต์ Prisma ของคุณตั้งค่าไว้ นั่นคือทุกสิ่งที่คุณได้รับจากกล่อง และอย่างที่คุณพูด Prisma สามารถทำงานกับฐานข้อมูลต่างๆ ได้ มันสามารถสลับไปมาระหว่าง SQLite สำหรับการพัฒนาและ Postgres สำหรับการผลิตได้ ขณะนี้ส่วนใหญ่เป็นความสัมพันธ์เชิงสัมพันธ์ แต่แผนงานมีสิ่งต่างๆ เช่น Mongo และ Fauna

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

แอนโธนี่: นั่นคือวิธีการตั้งค่าบทช่วยสอน นั่นคือขั้นตอนการทำงานที่แสดงให้คุณเห็น

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

แอนโธนี่: ใช่ ไม่ นั่นเป็นจุดที่ดี เพราะฉันบอกว่าสำหรับสิ่งใหม่ทั้งหมดที่ Redwood ผสมผสานเข้าด้วยกัน มีบางสิ่งที่จริง ๆ แล้ววิธีที่เก่า พยายาม และจริงนั้นดีที่สุด ดังนั้นจึงเป็นเรื่องใหญ่ในฐานข้อมูลเชิงสัมพันธ์ นั่นมาจากประสบการณ์ของ Tom ในการใช้ Rails และมีแบ็คเอนด์เชิงสัมพันธ์ Active Record คือเลเยอร์ O/RM ที่ Prisma ตั้งใจจะประมาณ

Drew: ฉันเดาว่าเรากำลังพูดถึงสถาปัตยกรรมแบบไร้เซิร์ฟเวอร์กับ Redwood และเราคุยกับ Chris Coyier ฉันคิดว่าย้อนกลับไปสองหรือสามตอน ทั้งหมดนี้เกี่ยวกับการใช้ API แบบไร้เซิร์ฟเวอร์และฟังก์ชันระบบคลาวด์และสิ่งต่างๆ ดังนั้น ย้อนกลับไปถ้าคุณคิดในแง่ของเฟรมเวิร์กที่ใช้เซิร์ฟเวอร์ เช่นที่เราพูดถึง Ruby on Rails หรืออย่างอื่นเช่น Laravel ในโลกของ PHP แม้จะมีส่วนหน้า React คำขอ API ของคุณก็ยังเรียกใช้โค้ดที่เป็นรหัส Rails หรือรหัส Laravel บวกกับรหัสผู้ใช้และการกำหนดค่าของคุณ เป็นเช่นเดียวกันกับเรดวูดหรือไม่? มีโค้ดเซิร์ฟเวอร์ Redwood ที่ใช้งานได้จริงหรือเป็นเพียงเครื่องมือและโครงสร้างและกาวที่ช่วยให้คุณสามารถใช้โค้ดของคุณเองได้

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

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

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

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

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

Drew: ผู้ที่ชื่นชอบ Jamstack จะคุ้นเคยกับบริการต่างๆ เช่น FaunaDB ที่คุณกล่าวถึงซึ่งมีที่เก็บข้อมูลเป็น API, AWS มี DynamoDB, Google มี Cloud SQL และอื่นๆ คุณบอกว่า Redwood กำลังมองหาการบูรณาการ หรือฉันเดาว่า Prisma เป็นส่วนประกอบที่นี่ที่กำลังมองหาการผสานรวมกับบริการประเภทอื่นๆ ต่อไปหรือไม่

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

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

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

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

แอนโธนี่: นี่อาจเป็นคุณสมบัติหลักที่ใหญ่ที่สุดที่คุณได้รับจากเรดวูด คือคุณมีเครื่องกำเนิดไฟฟ้าที่ซับซ้อนมากทั้งชุด สำหรับทุกคนที่เคยดูการสาธิต Ruby on Rails ดั้งเดิมที่ DHH มอบให้ เขาสร้างบล็อกในเวลาเพียง 15 นาที และเขาทำทุกอย่างด้วย Rails และผู้คนก็แบบว่า “ว้าว นี่มันน่าทึ่งมาก” นั่นคือผลที่เรดวูดจะเกิดขึ้น พวกเขาต้องการให้คุณหมุนทุกอย่างได้อย่างรวดเร็ว คุณจึงสามารถสร้างเพจได้ คุณสามารถสร้างเลย์เอาต์ คุณสามารถสร้างเซลล์ของคุณ ซึ่งฉันกำลังพูดถึงอยู่ และคุณสามารถทำคำสั่ง scaffold ที่จะสร้างทั้งหมดของคุณ อินเทอร์เฟซ CRUD ฉันมีทั้งส่วน ส่วนที่สี่ของชุดบล็อก เพียงอธิบายรหัสทั้งหมดที่โครงให้คุณ มันให้รหัสมากมายแก่คุณ มีเครื่องกำเนิดไฟฟ้าแบบปิด มีแม้แต่เครื่องกำเนิดลม Tailwind ที่กำหนดค่าลมส่วนท้ายให้กับคุณ

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

Drew: หากคุณต้องการปรับใช้สิ่งนั้นและใช้งานจริง สันนิษฐานว่าคุณสามารถปรับใช้มันพร้อมกับโค้ดส่วนหน้าของคุณ แต่คุณต้องการวิธีที่จะรักษาความปลอดภัยด้านนั้น รากเหล่านั้นในแอปพลิเคชันของคุณ

แอนโธนี่: ใช่ มีสองตัวเลือกสำหรับการตรวจสอบสิทธิ์ คุณสามารถใช้ข้อมูลประจำตัว Netlify นั่นเป็นค่าเริ่มต้นหากคุณเข้าสู่บทช่วยสอน จากนั้นคุณสามารถใช้ Auth0 และอีกอันที่ฉันไม่คุ้นเคยเรียกว่า Magic.Link และอาจมีเพิ่มอีกสองสามรายการในอนาคต แต่ใช่ ดังนั้นจึงมีวิธีแก้ปัญหาสองสามแบบอยู่แล้ว และนั่นเป็นสิ่งสุดท้ายที่คุณทำ นั่นคือส่วนสุดท้ายของชุดบล็อกทั้ง 12 ส่วนของฉันคือส่วน Auth ฉันไม่คิดว่าฉันจะเคยรู้จัก Auth มาก่อนใช้ Redwood มันยากและพวกเขาทำได้ดีมากกับมัน

Drew: มันรวมที่ระดับเส้นทางหรือระดับเส้นทาง ขออภัย คุณรักษาความปลอดภัยของสิ่งต่าง ๆ ได้อย่างไร?

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

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

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

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

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

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

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

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

Drew: ถ้าฉันต้องการเริ่มต้นและสร้างแอพและนำไปผลิตในสัปดาห์นี้ Redwood พร้อมสำหรับสิ่งนั้นหรือไม่ โตแล้วเหรอ?

แอนโธนี่: ใช่ เรามีแอพประมาณครึ่งโหลที่อยู่ระหว่างการผลิต ตัวแรกชื่อ Predict COVID ซึ่งออกมาในเดือนมีนาคม และมันเหมือนกับแอปพลิเคชั่นแสดงภาพข้อมูลแบบเรียลไทม์ จากนั้น เราก็มี repeater.dev ที่ทำโดย Rob มันเหมือนกับงาน cron เหมือนกับ Jamstack แล้วมี Tape.sh, Duoflag ฉันคิดว่าเป็นอีกอันหนึ่ง ดังนั้น อย่างน้อยก็มีกำมือหนึ่ง หากคุณไปที่ Redwood repo ที่ยอดเยี่ยม คุณสามารถดูรายการทั้งหมดได้ ถ้าคุณไปที่ฟอรัมชุมชน คุณจะพบข้อเขียนเกี่ยวกับสิ่งเหล่านี้ได้เช่นกัน เพราะผู้คนได้นำสิ่งเหล่านี้ไปใช้ในการผลิตและบอกว่ามันไปได้อย่างไร จนถึงตอนนี้ พวกเขาทั้งหมดประสบความสำเร็จและไม่มีใครพูดว่า "ฉันจะไม่ใช้สิ่งนี้อีก"

Drew: แต่มันใหม่มาก ฉันเดาว่าคงหนีไม่พ้นเรื่องนั้น แต่ในแง่ของวุฒิภาวะแล้ว Redwood นั้นค่อนข้างใหม่ และได้รับการติดตามที่ดี

แอนโทนี่: มันตลก มันเป็นเรื่องจริง และมันไม่ใช่ ประกาศเมื่อเดือนมีนาคม ณ จุดนั้น ทอมและปีเตอร์ทำงานประมาณหนึ่งปี So, they'd already put a ton of upfront work into this, so it wasn't like I'm going to announce this project with a Read Me and then start building it. By the time they announced it, it wasn't… It's not a 1.0 now, but it's pretty dang close in terms of what people would expect out of a 1.0. But, Tom is very against what we call type driven development so he always errs on the say it's not ready. So, we say it's not ready for production even though it's in production.

Drew: I think one thing that people sometimes get burned on using frameworks is that they'll build a project around the framework and then that framework will very quickly go to another major version that had backwards incompatibilities, and they're then left with a big project to update everything onto the new version of the framework. Is that something that's likely to happen with Redwood? I mean, none of us has got a crystal ball, but just with the technologies that are involved and the way it's structured, do you think that's a big danger or a little danger?

Anthony: Yeah, it's a super valid concern and definitely something the team has thought about. The CLI has an upgrade command, so you can basically every time there's a version bump, you just do a command and it bumps you up the version. I've been dealing with this a little bit just because of the series I wrote, I started it when it was on version 11 or 0.11, it's like 0.17 or something now. So, I've been slowly iterating on it as it's gone but nothing breaks. It's all, you get slowly things, or like “Oh, this is kind of a nice little touch you've got here,” but it's pretty much set in stone architecturally. Redwood as it's structured, the front or the back end is not going to change at all. It was very well thought out in terms of what they want architecturally. That's why they built it, so they could get something that's structured like this thing.

Drew: I guess with modern web development, there is a certain point where you're just never going to get away from being reliant on dependencies updating themselves and changing. I mean, even using React, React goes through as many different changes as anything else.

Anthony: That's exactly why Tom inventing semantic versioning.

Drew: I guess from the other side of that coin, if Redwood did happen to go away, which is always something we consider when picking a framework, if development stopped somehow, I guess the impact on a particular app might not be too great because it is just so heavily built on existing other projects around. Is that-

Anthony: Well, some would say that a Redwood tree can survive a lot, it survives for a very long time. That may have been why it's called that, is that you can just make a site and deploy it and it's not going to break, it's just going to work. So yeah, maintainability, sustainability, all that kind of stuff, that's huge. Being built by people who tried to scale Rails apps, I imagine they've thought a lot about that. But in terms of the going away part, that's always going to be a danger with any open source project, so I think what you have to look for is how enthusiastic is the community to continue it without the team if that ever happens. I don't think you even need to worry about that because Tom's a billionaire and he has a venture funding thing that is funding some of the development. It is an open source project that is well funded actually. It has four full time members, Tom, Rob, David, and Peter. You just go to the forums, you can see the activity that's going on, so I wouldn't worry about that too much-

ดรูว์: แน่นอน

Anthony: Beyond normal open source worries that come along with that stuff.

Drew: What is the community like? You mentioned the community, are there lots of people using it and contributing to the code base or is it mainly the core team who are doing the development?

Anthony: Yeah, it's very much structured to be a community thing. They want to get as much buy in from the community as possible, and this comes from the lineage like you said. There's few people with more open source cred than Tom, so he's done a really great job of bringing people into the fold. I think just my story in general is a big win for the community because I came in, I'm a boot camp student, I'm learning all this stuff as I go. I'm not pushing code to the repo, I'm making doc fixes and writing blog articles and stuff, but they still invited me to the core contributors meeting because they saw what I was doing and they thought it was adding value. Yeah, there's really a lot of things about how they approach community building that I have a lot of respect for, and that is why I've been so invested in it and putting so much of myself into it.

Drew: Some frameworks have got this sort of natural bent for certain types of projects. For example. The Python framework, Django came out of online news publishing, and so it's a really good fit if you want to rapidly publish content like you would in a news organization. Does Redwood lean in any particular direction when it comes to the type of projects? Is it suited for content publishing or building web applications or-

Anthony: It's made to be fairly agnostic to that. It wants to be a tool that you use for a lot of stuff. First, before it was called Redwood, it was called Hammer, the idea being that you do a lot of stuff with a hammer. But, there definitely is a kind of sweet spot, which I think is the multi client type applications. So, if you know that you're starting with a web front end but you're pretty sure you're going to end up with a mobile client as well, then it's a really good fit for that because it starts you off in a way that you're going to be able to extend into having multiple clients with GraphQL, which we kind of talked about a little bit. So, I'd say that'd probably be the first thing that I would say is its sweet spot. But, it's meant to work for as many things as possible.

Drew: Does Redwood have a published roadmap of where it's going? What can we expect to be coming in the near future?

Anthony: Glad you asked. We just put out a roadmap to 1.0 less than a month ago, it was probably like two or three weeks ago. It kind of itemizes things that we're working on, things we think we're kind of close on, things we think we still have a long ways to go on. That kind of helps the community see where can I help contribute. That's one of the things we're really great about is showing here are the things that still need to be worked on. They're aiming for 1.0 by the end of the year. We'll see where we get with that, but that's the trajectory we're currently on.

Drew: One of the beauties of a Jamstack and a serverless approach I always think is that it's this idea of lots of pieces loosely joined that has served us so well in computer science up until this point. It should be really easy to scale up a Jamstack and serverless project because you can add multiple front ends or you could put more resources behind running your functions, and you can scale up a big engineering team by having people work on different small pieces. Is there a danger that adopting a framework around all of that, that you might be taking a distributed architecture and creating a tighter binding than you might otherwise have? Could Redwood become the monolith that acts as a bottleneck in your engineering efforts?

Anthony: Yeah, this is something I think about a lot because as I learned web development, I was taking… I'm in a boot camp that supposedly is full stack development, but you learn each piece in isolation. We're essentially learning the PERN stack, but you learn React, and then we learned Express. We never talked about how it actually works together. So, I do think that there is definitely a danger of not being able to comprehend in your project because of how it's all wired up. So, what I really liked about Redwood is that it just made sense. It was a mental model of how to think about my entire app and all the pieces and how they fit together in a way that really made sense to me. But, what I was surprised to find doing the Fauna project is that it's much more modular than you would think based on… You talk about it, and like you said, it sounds like it's a monolith thing, but you can rip pieces out and replace them with other pieces and they can still work. So, it's made to be a fully integrated solution, but not a solution that is tightly coupled just because this is a good way to integrate all these technologies doesn't mean you need to tightly couple them to integrate them well.

Drew: Yeah, that sounds a very promising way of structuring things, and it's going to be really exciting to see what happens with Redwood as it gets to version 1.0. Is there anything else we should know about it that we haven't talked about?

Anthony: No. I mean, I would say if you're interested, just check out the tutorial on YouTube, the RedwoodJS tutorial. They have what they call tutorial driven development, which is kind of a play on Read Me driven development, which is another thing Tom coined, that you should start with a Read Me, and then create your code to make sense with what your Read Me was. This is the idea of you create a tutorial and then you write your framework to make the tutorial work. So, that's why it's a really easy way to get spun up with it because it was made to make sense of going through the process of learning it. They've really thought about how to actually get onboarded into a massive framework with all these different pieces and all this different new tech. They progressively reveal it to you as you go. The series that I wrote is very heavily influenced by it. I essentially built the same project, but I write my own stuff as I go, and reference the docs. So, if you're interested in just learning Redwood, start with the actual tutorial and then check out my series.

Drew: So, I've been learning all about Redwood, what have you been learning about?

Anthony: Yeah, so I've been learning about CMSs, and I was actually really curious to get your thoughts on this because I imagine you've been around the block, you know a lot of CMSs. Obviously, you know you've got your WordPress's, your Drupal, but what's really interesting with something like Redwood is since you have this GraphQL stuff baked in, it has the CMS, it's just such a natural fit. So, I'm trying to figure out, what are interesting headless CMSs to check out? Which ones have GraphQL integration? Which ones have different sweet spots? If I wanted to take a CMS to build an app with RedwoodJS, what would you recommend?

Drew: That is a good question, and I'm not sure I have an immediate answer. I have looked at lots of different CMSs, not particularly with a view to GraphQL. I've not worked with GraphQL myself yet, and so that was not-

Anthony: Oh man, you've got to join the club, dude.

Drew: Yeah, no, I'm definitely getting onboard. But yes, I have a requirement at work that may be coming up to know a bit more about GraphQL, so it's certainly one of the things that I need to be learning.

Anthony: I actually learned GraphQL through Redwood. I didn't really know GraphQL, and I'd say you should know a little bit before going into it, and I had a very, very tiny basic knowledge. You can actually learn what a schema definition language is, and that GraphQL kind of jargon. You'll learn a lot and you'll pick it up as you go with Redwood.

Drew: Yeah, I should definitely get onboard and maybe doing some Redwood is the way to do it. Perhaps I need to pick up a project and start going with Redwood and see where it takes me.

Anthony: Yeah, at the very least I would say just check it out, just because it's interesting. I find it to be just a really fascinating thought experiment of how do we do modern web application development differently and more coherently.

Drew: If you, dear listener, would like to hear more from Anthony, you can find him on Twitter at ajcwebdev. His comprehensive series of articles about getting started with Redwood are on the Redwood community site, which we'll link to from the show notes. Of course, you can find all about Redwood and get started at RedwoodJS.com. Thanks for joining us today, Anthony. คุณมีคำพรากจากกันบ้างไหม?

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