โพสต์นี้ได้รับการอัปเดตเมื่อวันที่ 23 พฤษภาคม 2024 เพื่อชี้แจงความแตกต่างในโมเดลและความคงอยู่ของข้อมูลระหว่าง Rails และ Hanami
Ruby on Rails เป็นเฟรมเวิร์กเว็บที่ได้รับความนิยมมากที่สุดในระบบนิเวศของ Ruby และมีฐานผู้ใช้จำนวนมาก ตั้งแต่ฟรีแลนซ์ไปจนถึงบริษัทขนาดใหญ่ ด้วยชุมชนผู้ใช้ที่กระตือรือร้นและเอกสารประกอบที่หลากหลาย สามารถใช้เพื่อสร้างทุกสิ่งตั้งแต่แอปพลิเคชันธรรมดาไปจนถึงแพลตฟอร์มเว็บที่ซับซ้อน
อย่างไรก็ตาม ผู้เข้าแข่งขันรายใหม่กำลังเข้ามาครอบงำ Rails สำหรับชื่อเฟรมเวิร์ก Ruby แบบเต็มสแต็ก:Hanami เป็นเฟรมเวิร์ก Ruby แบบแยกส่วนที่รวดเร็วพร้อมประสิทธิภาพและการบำรุงรักษาที่ดีขึ้นเมื่อเทียบกับ Rails
ในบทความนี้ เราจะสำรวจจุดแข็งและจุดอ่อนของแต่ละเฟรมเวิร์กในแง่ของประสิทธิภาพ คุณลักษณะ การทดสอบ และอื่นๆ ดังนั้นไม่ว่าคุณกำลังมองหาการสร้างเว็บแอปที่พบปะกับลูกค้า เครื่องมือภายใน หรือ API ที่ปรับขนาดได้จำนวนมาก คุณควรได้รับข้อมูลที่ดีขึ้นเกี่ยวกับสิ่งที่จะใช้สำหรับโปรเจ็กต์ถัดไปของคุณ
เริ่มต้นด้วยการแนะนำสั้นๆ เกี่ยวกับแต่ละเฟรมเวิร์ก
ขอแนะนำ Ruby on Rails
Ruby on Rails เป็นเฟรมเวิร์กการพัฒนาเว็บแอปพลิเคชัน Ruby ที่โด่งดังที่สุด โดยมีภารกิจในการเพิ่มประสิทธิภาพการทำงานของนักพัฒนา (โดยการตั้งสมมติฐานหลายประการเกี่ยวกับวิธีการสร้างแอป ซึ่งมักเรียกกันว่า "วิถี Rails")
สมมติฐานเหล่านี้บางส่วนรวมถึงการทำให้แน่ใจว่านักพัฒนาไม่ได้ใช้เวลาในการกำหนดค่าสิ่งต่าง ๆ หรือสิ่งที่เรียกว่า "แบบแผนมากกว่าการกำหนดค่า" และการเน้นที่การใช้หลักการ DRY ("อย่าทำซ้ำตัวเอง") หลักการ DRY สนับสนุนให้นักพัฒนาหลีกเลี่ยงการใช้โค้ดซ้ำแล้วซ้ำอีก แต่ใช้การนำเสนอฟังก์ชันการทำงานของแอปแบบเน้นเดียวและเน้นแทน เพื่อให้มั่นใจถึงการบำรุงรักษาและการจัดระเบียบ
แนะนำฮานามิ
แม้ว่า Rails จะเป็นที่รู้จักอย่างมากในชุมชน Ruby แต่ Hanami ก็มีชื่อเสียงน้อยกว่า เป็นเฟรมเวิร์ก Ruby สมัยใหม่ที่ค่อนข้างใหม่ซึ่งพยายามจะครอบงำพื้นที่เฟรมเวิร์กเว็บแบบเต็มสแต็กของ Rails
ฮานามิถูกสร้างขึ้นใหม่หมดเพื่อให้มีหน่วยความจำขนาดเล็กและมุ่งเน้นไปที่โมดูลาร์ ซึ่งในทางกลับกัน ทำให้เกิดเฟรมเวิร์กที่รวดเร็วและว่องไว
แน่นอนว่าการแนะนำสั้นๆ เหล่านี้ไม่ได้ให้ข้อมูลทั้งหมดที่จำเป็นต่อการตัดสินใจเกี่ยวกับกรอบงานที่เหมาะกับคุณที่สุด เพื่อทำเช่นนั้น เราจะต้องเจาะลึกแต่ละข้อโดยเริ่มจากวิธีจัดโครงสร้าง
โครงสร้างและสถาปัตยกรรมของรางรถไฟและฮานามิ
Rails และ Hanami ค่อนข้างคล้ายกันตรงที่ทั้งคู่เป็นเฟรมเวิร์ก Ruby อย่างไรก็ตาม วิธีการสร้างแต่ละรายการและสถาปัตยกรรมแอปพลิเคชันคือจุดที่คุณจะพบความแตกต่างส่วนใหญ่
สำหรับผู้เริ่มต้น เมื่อใช้ Rails คุณจะมีไฟล์หรือนามธรรมน้อยลง (องค์ประกอบพื้นฐานที่คุณใช้ในการสร้างแอปของคุณ) ซึ่งมีแนวโน้มที่จะขยายขนาดเมื่อคุณพัฒนาแอปของคุณ ในทางกลับกัน Hanami ยกระดับนามธรรมขึ้นไปอีกระดับ ด้วยไฟล์จำนวนมากที่มีแนวโน้มว่ามีขนาดเล็กลง
แผนภาพด้านล่างแสดงประเด็นได้ชัดเจนยิ่งขึ้น เริ่มจาก Rails กันก่อน
ตอนนี้ให้เปรียบเทียบแผนภาพนามธรรมของ Rails กับฮานามิด้านล่าง
อย่างที่คุณเห็น โดยทั่วไปแต่ละเฟรมเวิร์กจะเป็นไปตาม model-view-controller โครงสร้างเอ็มวีซี อย่างไรก็ตาม ฮานามิยกระดับความเป็นนามธรรมขึ้นไปอีกระดับ
ต่อไปนี้คือโครงร่างอย่างง่ายของการจัดระเบียบแต่ละเฟรมเวิร์ก:
- เส้นทาง - แต่ละเฟรมเวิร์กมีคำจำกัดความเส้นทางพร้อมจุดสิ้นสุดของแอปของคุณ
- ตัวควบคุมเทียบกับการกระทำ - ใน Rails คุณจะได้รับคอนโทรลเลอร์ที่มีการกระทำหนึ่งหรือสองอย่างในตัว ผู้ควบคุมจะได้รับและตอบสนองต่อคำขอเส้นทางโดยนำพวกเขาไปยังการดำเนินการที่เกี่ยวข้อง ในฮานามิไม่มีผู้ควบคุม แต่คุณมุ่งตรงไปที่การกระทำที่มีแต่ตนเอง (การกระทำแต่ละอย่างมีระดับที่เป็นของตัวเอง)
- รูปแบบและความเพียร - เลเยอร์โมเดล Rails ดูแลการตรวจสอบข้อมูลและการสื่อสารฐานข้อมูล รวมถึงคำถามใดๆ ที่แอปของคุณอาจมี ความคงอยู่ได้รับการจัดการโดย Ruby Object Mapper (ROM) ในฮานามิ เลเยอร์โมเดลจะเป็นนามธรรมมากกว่า โดยแยกออกเป็นเอนทิตีและที่เก็บ เอนทิตีจัดการตรรกะของโดเมนและไม่เชื่อเรื่องฐานข้อมูล ในขณะที่ พื้นที่เก็บข้อมูล (repos) ใช้ในการสื่อสารกับฐานข้อมูล Hanami 2.0 เป็นต้นไปจัดส่งโดยไม่มีเลเยอร์คงอยู่ที่กำหนดไว้ล่วงหน้า ทำให้คุณสามารถเลือก Object Relational Mapper (ORM) ที่เหมาะกับความต้องการของคุณหรือตั้งโปรแกรม ORM ได้ฟรี
- ดูการแสดงผล - เช่นเดียวกับชั้นคงอยู่ มุมมอง Ruby on Rails มักจะมีทุกสิ่งที่คุณต้องการสำหรับการแสดงผลข้อมูลสู่โลกภายนอกในที่เดียว ซึ่งรวมถึงโครงสร้าง HTML ตัวช่วยดู และตรรกะการดูทั้งหมด เมื่อพูดถึงการเรนเดอร์ใน Hanami สิ่งต่างๆ จะเป็นนามธรรมมากขึ้น สำหรับผู้เริ่มต้น คุณมี การดู ที่ใช้ตัวช่วยดูใดๆ ที่แอปมีและเรนเดอร์ เทมเพลต ด้วย . เทมเพลต จัดการโครงสร้าง HTML จริงในขณะที่ ส่วน ดูแลตรรกะการนำเสนอ
แล้วทั้งหมดนี้หมายความว่าอย่างไรเมื่อพูดถึงการสร้างแอป? ด้วยนามธรรมที่น้อยลง Rails จึงเป็นตัวเลือกที่ดีในการทำให้แอปของคุณใช้งานได้จริงและเป็นมิตรกับผู้เริ่มต้นมากกว่า (ดังที่เราจะเห็นในบทความนี้ต่อไป) ด้วย Rails คุณสามารถสร้างแอปโมโนลิธที่แข็งแกร่งมากได้ แต่โค้ดของคุณจะซับซ้อนมากขึ้นเรื่อยๆ เมื่อคุณขยายขนาด ในทางกลับกัน โครงสร้างที่ซับซ้อนกว่าของ Hanami อาจเป็นเรื่องที่น่ากังวลในการเรียนรู้ แต่จะช่วยให้คุณสร้างแอปพลิเคชันที่สามารถปรับขนาดได้จำนวนมาก และอาจทำให้การจัดระเบียบโค้ดดีขึ้นมาก
ต่อไป มาดูระบบนิเวศของแต่ละเฟรมเวิร์กกัน
ระบบนิเวศและชุมชน
ดังที่เราได้กล่าวไปแล้ว Rails มีกรอบการทำงานที่เป็นที่ยอมรับมากกว่าฮานามิ Rails มีมานานแล้ว และด้วยเหตุนี้ จึงมีชุมชนที่ใหญ่และเป็นผู้ใหญ่มากขึ้น
ความแตกต่างในระบบนิเวศและชุมชนสรุปได้ด้านล่าง:
- เอกสารประกอบ - ไม่สำคัญว่าคุณกำลังพยายามสร้างอะไร หากคุณใช้ Rails คุณจะสามารถเข้าถึงเอกสารที่ทำได้ดีมาก คุณจะได้รับคำแนะนำผ่านทุกส่วนของบิลด์แอพ ตั้งแต่การตรวจสอบสิทธิ์ ไปจนถึงการคงอยู่ของข้อมูล ดูการนำเสนอ และทุกสิ่งในระหว่างนั้น นอกจากนี้ บทช่วยสอนจากบุคคลที่สามที่หลากหลายยังครอบคลุมเกือบทุกอย่างเท่าที่จะเป็นไปได้ในแง่ของการสร้างแอปพลิเคชัน
ที่กล่าวว่าสิ่งต่าง ๆ ไม่ได้ถูกกำหนดไว้ในด้านฮานามิ เนื่องจากเป็นเฟรมเวิร์กที่ค่อนข้างใหม่กว่า Hanami จึงมีฐานเอกสารที่ค่อนข้างจำกัด ทีมงาน Hanami ทำงานได้อย่างน่าประทับใจโดยมีคำแนะนำอย่างเป็นทางการ แต่เมื่อเปรียบเทียบกับฐานเอกสารของ Rails แล้ว ก็ยังทำได้ไม่ใกล้เคียง
- ชุมชน - ที่นี่ เช่นเดียวกับเอกสารประกอบ Rails เป็นผู้ชนะที่ชัดเจน Rails มีอายุการใช้งานยาวนานกว่า Hanami มาก ดังนั้นจึงถูกนำมาใช้มากที่สุด ไม่ว่าคุณจะเป็นนักพัฒนามือใหม่หรือขั้นสูง คุณจะพบชุมชน Rails บน subreddits ที่เกี่ยวข้อง กลุ่ม Slack Discords และอื่นๆ ในทางกลับกัน ฮานามิยังคงเติบโต ซึ่งหมายความว่ามีชุมชนเล็กลงมาก
- อัญมณีและห้องสมุด - เนื่องจากทั้ง Hanami และ Rails เป็นเฟรมเวิร์ก Ruby จึงอาจเป็นที่ถกเถียงกันอยู่ว่า gem ที่ทำงานใน Rails จะทำงานใน Hanami ได้ แม้ว่าสิ่งนี้จะเป็นความจริงในทางเทคนิค แต่คุณมักจะพบว่า Rails มีฐานอัญมณีและไลบรารีที่เป็นที่ยอมรับมากขึ้นสำหรับฟังก์ชันพิเศษทุกประเภท
ที่กล่าวมา เนื่องจาก Hanami มุ่งเน้นไปที่นามธรรมและความเชี่ยวชาญ Hanami จึงมีอัญมณีที่ล้ำหน้ามากซึ่งสามารถยกระดับแอป Rails ของคุณไปสู่อีกระดับได้ ตัวอย่างเช่น dry-rb gems เริ่มต้นใน Hanami อาจทำให้การจัดระเบียบโค้ดและนามธรรมดีขึ้นเมื่อใช้ในแอป Rails
ต่อไป เรามาเปรียบเทียบช่วงการเรียนรู้และการนำไปใช้ของแต่ละเฟรมเวิร์กกันดีกว่า
ความง่ายในการใช้งาน การยอมรับ การกำกับดูแล และเส้นโค้งการเรียนรู้
ด้วยเหตุผลที่ระบุไว้ในส่วนที่แล้ว Ruby on Rails เอาชนะ Hanami ได้อย่างง่ายดายในแง่ของการใช้งานง่าย การนำไปใช้ในอุตสาหกรรม และช่วงการเรียนรู้ โดยเฉพาะ:
- การเรียนรู้ - ลองนึกภาพคุณเป็นมือใหม่ที่ต้องการเรียนรู้ภาษาการเขียนโปรแกรมใหม่ ความคิดแรกของคุณคือลองดูแหล่งข้อมูลการเรียนรู้ออนไลน์ หากเฟรมเวิร์กมีสื่อการเรียนรู้ที่มีอยู่อย่างกว้างขวางซึ่งครอบคลุมกระบวนการสร้างแอปตั้งแต่ต้นจนจบ คุณอาจเลือกภาษานั้นมากกว่าภาษาอื่น และเนื่องจาก Rails มีฐานเอกสารที่เป็นที่ยอมรับมากกว่า Hanami จึงเป็นตัวเลือกเฟรมเวิร์กสำหรับผู้เริ่มต้น นอกจากนี้ Rails ยังเป็นมิตรมากกว่ามากสำหรับผู้เริ่มต้น เนื่องจากมันมีข้อสันนิษฐานมากมาย (เทียบกับ Hanami ซึ่งเสนอวิธีการสร้างแอปที่เป็นนามธรรมมากกว่า) นามธรรมของ Hanami อาจเป็นเรื่องที่น่าหวาดหวั่นแม้แต่กับนักพัฒนา Rails ที่ก่อตั้งแล้ว
- การยอมรับในอุตสาหกรรม - หากไม่รวมการนำเฟรมเวิร์กยอดนิยมและเป็นที่ยอมรับอื่นๆ เช่น Python, React, C# และอื่นๆ มาใช้ หากเราพิจารณาการนำเฟรมเวิร์ก Ruby มาใช้ Rails จะบดบัง Hanami ได้อย่างง่ายดาย หน้าแรกของ Rails แสดงรายการองค์กรชื่อดังบางแห่งที่ใช้เฟรมเวิร์ก ในทางกลับกัน เนื่องจากฮานามิเป็นเด็กใหม่ในกลุ่มนี้ จึงไม่ได้รับการยอมรับอย่างกว้างขวางนัก เราจะต้องรอดูว่าจะมีการเปลี่ยนแปลงในอนาคตหรือไม่
- แนวโน้มตลาดงาน - ในแง่ของโอกาสในการทำงาน คุณจะพบตำแหน่งงานว่างสำหรับนักพัฒนา Rails มากกว่านักพัฒนา Hanami
- การกำกับดูแล - สิ่งสำคัญอีกประการหนึ่งที่ไม่ควรมองข้ามคือการกำกับดูแล ภูมิทัศน์ที่เปลี่ยนแปลงจะเป็นแนวทางว่ากรอบงานโอเพ่นซอร์สมีการพัฒนาและก้าวหน้าอย่างไร อย่างไรก็ตาม ยิ่งไปกว่านั้น สมาชิกในทีมหลักของเฟรมเวิร์กเหล่านี้มักจะใช้พลังอันมหาศาลและสามารถกำหนดสิ่งที่จะเข้าสู่เฟรมเวิร์กได้ การพัฒนาอย่างไร ฯลฯ
ตัวอย่างที่ดีคือการประกาศในเดือนมกราคมโดย David Heinemeier Hansson (DHH) ผู้สร้าง Rails เขากล่าวว่าในอนาคต เขาจะผลักดันให้ Rails ให้การสนับสนุนระดับเฟิร์สคลาสสำหรับการสร้างแอปพลิเคชันเว็บแบบโปรเกรสซีฟแบบฟูลสแตกและการแจ้งเตือนแบบเนทีฟ คุณลักษณะเหล่านี้จะทำให้ Rails น่าสนใจมากสำหรับนักพัฒนามือถือ
ในการโต้ตอบ นักพัฒนาจำนวนมาก บางคนนอกระบบนิเวศ Ruby และแม้แต่คนอื่นๆ ที่ทิ้ง Rails ในช่วงหลายปีที่ผ่านมา ต่างตอบรับอย่างท่วมท้นในแง่บวก โดยกล่าวว่าพวกเขายินดีที่จะรับกรอบการทำงานหรือเรียนรู้หาก DHH รักษาคำพูดของเขา ตัวอย่างนี้แสดงให้คุณเห็นว่าการกำกับดูแลเป็นข้อพิจารณาที่สำคัญมากในการตัดสินใจเลือกกรอบงาน
ตอนนี้เรามาเปลี่ยนเกียร์และพิจารณาด้านเทคนิคและประสิทธิภาพของแอปพลิเคชันเพิ่มเติม
ประสิทธิภาพ:Ruby on Rails กับ Hanami
ในฐานะนักพัฒนา คุณจะต้องกังวลเกี่ยวกับความน่าเชื่อถือ การตอบสนองของแอป และวิธีที่แอปจะใช้ทรัพยากรเซิร์ฟเวอร์เมื่อมีการปรับใช้ในการใช้งานจริง สิ่งเหล่านี้เป็นข้อกังวลพื้นฐานที่อาจส่งผลกระทบอย่างมากต่อการเลือกกรอบงานของคุณ
คุณสามารถใช้วิธีต่างๆ มากมายเพื่อเรียกใช้การทดสอบประสิทธิภาพในแอปของคุณ หนึ่งในวิธีที่ได้รับความนิยมมากที่สุดคือ Apache JMeter ลองใช้ตัวเลขมาตรฐานเพื่อเปรียบเทียบ Hanami และ Rails
ต่อไปนี้คือการทดสอบเกณฑ์มาตรฐานสั้นๆ ที่แสดงจำนวนคำขอที่แต่ละเฟรมเวิร์กสามารถรองรับได้ต่อวินาที:
ฮานามิเอาชนะ Rails โดยสิ้นเชิง ด้วยความสามารถในการจัดการคำขอมากกว่าที่ Rails จะจัดการได้ถึง 3 เท่า
ภาพหน้าจอถัดไปนี้แสดงค่าเวลาแฝงเฉลี่ยสำหรับแต่ละเฟรมเวิร์ก:
เป็นอีกครั้งที่ Hanami เอาชนะ Rails ด้วยเวลาแฝงโดยเฉลี่ยที่สั้นกว่าประมาณ 3 เท่า
หากคุณกำลังมองหาเฟรมเวิร์ก Ruby ที่ทำงานเร็วมาก (สมมติว่า คุณต้องทำงานบน API ที่รวดเร็วและปรับขนาดได้มหาศาล) คุณจะพบสิ่งที่ดีกว่า Hanami ในภาพรวมของ Ruby ได้ยาก
การทดสอบ
เมื่อพูดถึงการทดสอบโค้ด ทั้งสองเฟรมเวิร์กสามารถเปรียบเทียบกันได้อย่างมาก เนื่องจากคุณสามารถทดสอบโดยใช้ไลบรารี RSpec อเนกประสงค์ได้
RSpec ถูกรวมไว้ผ่านทาง hanami-rspec gem สำหรับแอป Hanami ในขณะที่คุณต้องติดตั้ง rspec-rails อัญมณีเพื่อใช้ในแอป Rails ของคุณ ตัวอย่างด้านล่างแสดงข้อกำหนดการทดสอบพื้นฐานที่มาพร้อมกับแอป Hanami ใหม่ของคุณ:
รันด้วย $ bundle exec rspec spec/requests/root_spec.rb ควรส่งผลให้ผ่านการทดสอบ (สมมติว่าคุณไม่ได้แก้ไขเทมเพลตมุมมองเริ่มต้น):
ในด้าน Rails คุณต้องจัดการบางอย่างด้วยตัวเอง ขั้นแรก คุณต้องเพิ่ม RSpec gem ลงในบล็อกการพัฒนา/ทดสอบใน Gemfile ดังภาพด้านล่าง จากนั้นให้รัน bundle :
ขั้นตอนต่อไปคือการรันการติดตั้ง RSpec ด้วยคำสั่ง bundle exec rails generate rspec:install เพื่อเตรียมพร้อมสำหรับโครงการ Rails ของคุณ
สุดท้าย ก่อนที่จะเขียนและดำเนินการทดสอบใดๆ คุณจะต้องติดตั้ง Gem อื่นเพื่อกำหนดข้อมูลการทดสอบสำหรับแอป Rails ของคุณ:FactoryBot
และสมมติว่าคุณได้ตั้งค่าชุดการทดสอบของคุณอย่างถูกต้องและกำหนดการทดสอบบางอย่าง คุณสามารถดำเนินการทดสอบได้เช่นเดียวกับที่คุณทำใน Hanami ด้วย bundle exec rspec spec/models/user_spec.rb . คุณสามารถรับผลการทดสอบได้เช่นเดียวกับที่คุณทำกับแอป Hanami:
สุดท้ายนี้ เรามาดูกันว่าเฟรมเวิร์กมีการเปรียบเทียบอย่างไรเมื่อเป็นเรื่องของการปรับใช้
การปรับใช้
ในปัจจุบัน มีตัวเลือกมากมายในการปรับใช้แอป Ruby ในการใช้งานจริง
ขั้นแรก คุณสามารถเลือกใช้ผู้ให้บริการ Platform-as-a-Service (PaaS) เช่น Heroku หรือ Fly เพื่อประสบการณ์ที่ราบรื่นยิ่งขึ้น คุณยังสามารถทำ DevOps ได้เล็กน้อย:ตั้งค่าการติดตั้ง Docker บน VPS และปรับใช้แอปของคุณที่นั่น
ไม่ว่าคุณจะเลือกตัวเลือกใด คุณสามารถคาดหวังได้ว่าการปรับใช้จะค่อนข้างคล้ายกันในทั้งสองกรณี ข้อแม้เพียงอย่างเดียวคือการไม่มีเอกสารและบทช่วยสอนที่ครอบคลุมสำหรับการปรับใช้แอป Hanami
ดังที่เราได้กล่าวไว้ก่อนหน้านี้ เนื่องจากเป็นเฟรมเวิร์กที่ใหม่กว่า Hanami จึงยังไม่มีเอกสารที่ครอบคลุมเกี่ยวกับกระบวนการปรับใช้และความท้าทายที่อาจเกิดขึ้น หากคุณไม่รังเกียจที่จะแฮ็กข้อมูลนี้ คุณก็ควรจะโอเค
สรุป
ในบทความนี้ เราได้ดูเฟรมเวิร์ก Ruby สองเฟรม — Ruby on Rails และ Hanami — เปรียบเทียบพวกมันในแง่ของคุณสมบัติ สถาปัตยกรรม ประสิทธิภาพ และอื่นๆ ท้ายที่สุดแล้ว เราต้องตอบคำถามว่า "ฉันควรใช้กรอบงานใด และเพราะเหตุใด" เราสามารถสรุปได้ดังนี้:
- หากคุณเป็นนักพัฒนา Ruby มือใหม่ ให้เริ่มต้นด้วย Rails:ง่ายต่อการเรียนรู้และเรียนรู้ หากคุณเป็นนักพัฒนา Ruby ขั้นสูง ให้พัฒนาชุดทักษะ Hanami เนื่องจากจะช่วยให้คุณพัฒนาแอปพลิเคชัน Ruby ที่แข็งแกร่งยิ่งขึ้นได้
- หากคุณต้องการพัฒนาแอปที่ควรจะรวดเร็ว เช่น API ที่ให้บริการไคลเอนต์หลายราย หน่วยความจำขนาดเล็กของ Hanami การตอบสนองที่รวดเร็วทันใจ และเวลาแฝงที่ต่ำจะให้บริการคุณได้ดี อย่างไรก็ตาม หากคุณเพียงแค่ต้องพัฒนาแอปแบบฟูลสแต็กขนาดใหญ่เพื่อตรวจสอบความถูกต้องของแนวคิด SaaS Rails จะช่วยให้คุณไปถึงจุดนั้นได้เร็วขึ้นอย่างแน่นอน
ท้ายที่สุดแล้วสิ่งที่คุณจะเลือกก็ขึ้นอยู่กับคุณจริงๆ การได้รับทักษะในทั้งสองกรอบงานไม่ใช่เรื่องไม่ดี ด้วยวิธีนี้ คุณสามารถตัดสินใจเลือกกรอบงานที่ดีที่สุดได้ ขึ้นอยู่กับความต้องการของโครงการของคุณ
ขอให้สนุกกับการเขียนโค้ด!
ปล. หากคุณต้องการอ่านโพสต์ Ruby Magic ทันทีที่เผยแพร่ สมัครรับจดหมายข่าว Ruby Magic ของเราและไม่พลาดแม้แต่โพสต์เดียว!
พี.พี.เอส. คุณรู้ไหมว่า AppSignal มีการผสานรวมสำหรับ Rails และ Hanami
