เรื่องราว

คุณและผู้ร่วมก่อตั้งมีความคิดที่ดีสำหรับธุรกิจใช่ไหม?

คุณได้เพิ่มคุณลักษณะในใจของคุณแล้ว

บ่อยครั้งที่คุณขอความคิดเห็นจากผู้มีโอกาสเป็นลูกค้าและพวกเขาก็ชอบสิ่งนี้

โอเคคนก็อยากได้ ยังมีเงินที่ต้องทำ และเหตุผลเดียวที่พวกเขาไม่มีก็เพราะคุณยังไม่ได้ติดตั้ง

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

“ เสร็จแล้ว! มันได้ผล!' คุณพูด. การพิสูจน์แนวคิดของคุณคือความสำเร็จ! สิ่งที่เหลือก็คือการรวมแพ็กเกจลงในเว็บแอป

“ ตกลงมาสร้างเว็บไซต์กันเถอะ” คุณพูด

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

คุณต้องการที่จะผอมคุณต้องการที่จะคล่องตัว คุณต้องการใช้เทคโนโลยีที่จะช่วยให้คุณประสบความสำเร็จในระยะสั้นและระยะยาว และไม่ใช่เรื่องง่ายที่จะเลือก

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

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

การพิสูจน์แนวคิดของคุณค่อยๆเหี่ยวเฉาและตาย

ข้อเสนอ

หลังจากทิ้งความคิดมากมายด้วยวิธีนี้ฉันจึงตัดสินใจออกแบบวิธีแก้ปัญหา ฉันเรียกมันว่า ‘ ในนั้น ’โครงการ (หรือ init.js)

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

เพื่อให้บรรลุวัตถุประสงค์นี้ได้ดีที่สุดเราต้องคำนึงถึงแนวคิดหลักสองสามประการ เมื่อพัฒนา Init ฉันพิจารณา:

• ส่วนประกอบ

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

• ความง่ายในการพัฒนา

  ปัญหาบางอย่างบางแห่งมีวิธีแก้ปัญหาที่ดีที่สุด Brainf * ck . แต่การใช้โซลูชันนั้น (ใน Brainfuck) แทบจะเป็นไปไม่ได้เลยที่จะเขียนให้อ่านคนเดียว จะทำให้คุณเสียเวลาและความพยายามมหาศาล โดยทั่วไปคุณควรใช้ภาษาและแพลตฟอร์มที่ทำให้การพัฒนาง่ายขึ้นไม่ใช่เรื่องยากสำหรับคุณ (หรือใครก็ตามที่อาจทำงานในภายหลัง)

• ชุมชน

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

เมื่อคำนึงถึงเป้าหมายเหล่านี้ต่อไปฉันจะแสดงให้คุณเห็นว่าฉันตัดสินใจด้วยตัวเองอย่างไรในการสร้าง Init

แก่นแท้ของ Init ใช้ประโยชน์จาก ' JavaScript แบบเต็มสแต็ก กระบวนทัศน์ ’(บางคนอ้างถึงหรือบางส่วนของมันเป็น หมายถึงกอง ). ด้วยการทำงานกับไฟล์ ซ้อนกัน , Init สามารถใช้เพียงภาษาเดียวในขณะที่สร้างสภาพแวดล้อมที่ยืดหยุ่นและมีคุณลักษณะครบถ้วนสำหรับการพัฒนาเว็บแอป กล่าวโดยย่อ Init ให้คุณใช้ JavaScript ไม่เพียง แต่สำหรับการพัฒนาไคลเอ็นต์และเซิร์ฟเวอร์เท่านั้น แต่ยังรวมถึงการสร้างการทดสอบการเทมเพลตและอื่น ๆ อีกด้วย

แต่ให้ชะลอตัวลงสักครู่แล้วถามตัวเองว่าเป็นความคิดที่ดีหรือไม่ที่จะใช้ JavaScript?

ทำไมฉันถึงเลือก JavaScript

ฉันเป็นนักพัฒนาเว็บมาตั้งแต่ปี 1998 ตอนนั้นเราใช้ Perl สำหรับการพัฒนาฝั่งเซิร์ฟเวอร์ส่วนใหญ่ของเรา แต่ตั้งแต่นั้นเป็นต้นมาเราก็มี JavaScript ในฝั่งไคลเอ็นต์ เทคโนโลยีเว็บเซิร์ฟเวอร์มีการเปลี่ยนแปลงอย่างมากนับตั้งแต่นั้นมาเราได้เปลี่ยนไปตามคลื่นของภาษาและเทคโนโลยีเช่น PHP, AP, JSP, .NET, Ruby, Python เพื่อชื่อไม่กี่ นักพัฒนาเริ่มตระหนักว่าการใช้ภาษาที่แตกต่างกันสองภาษาสำหรับสภาพแวดล้อมไคลเอนต์และเซิร์ฟเวอร์นั้นทำให้เกิดความซับซ้อน ความพยายามเริ่มต้นในการรวมกันภายใต้ภาษาเดียวพยายามสร้างคอมโพเนนต์ไคลเอ็นต์บนเซิร์ฟเวอร์และคอมไพล์เป็น JavaScript สิ่งนี้ไม่ได้ผลตามที่คาดไว้และโครงการส่วนใหญ่ล้มเหลว (ตัวอย่างเช่นการแทนที่ ASP MVC แบบฟอร์มเว็บ ASP.NET และ GWT เนื้อหาจะถูกแทนที่ในอนาคตอันใกล้โดย พอลิเมอร์ ). แต่เป็นความคิดที่ดีโดยพื้นฐานแล้ว: ภาษาเดียวบนไคลเอนต์และเซิร์ฟเวอร์ทำให้เราสามารถนำส่วนประกอบและทรัพยากรกลับมาใช้ใหม่ได้ (นี่คือคีย์เวิร์ด: ทรัพยากร ).

คำตอบนั้นง่ายมาก: ใส่ JavaScript บนเซิร์ฟเวอร์

JavaScript จริง เกิดด้วย JavaScript Server Side ใน Netscape Enterprise Server แต่ภาษายังไม่พร้อมใช้งานในขณะนั้น หลังจากลองผิดลองถูกมาหลายปี โหนด js ในที่สุดก็ปรากฏตัวขึ้นซึ่งไม่เพียง แต่วาง JavaScript ไว้บนเซิร์ฟเวอร์เท่านั้น แต่ยังส่งเสริมแนวคิดของ การเขียนโปรแกรมที่ไม่ปิดกั้น เปลี่ยนวิธีการเขียน 'fread' (I / O) ไปตลอดกาล (อ่าน ที่นี่ เพิ่มเติม)

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

แต่ความคิดเหล่านั้นไม่ใช่เรื่องใหม่เหตุใดจึงได้รับความนิยมจาก Node.js การเขียนโปรแกรมที่เรียบง่ายและไม่ปิดกั้นสามารถทำได้หลายวิธี บางทีวิธีที่ง่ายที่สุดคือการใช้การโทรกลับและไฟล์ วนเหตุการณ์ . ในภาษาส่วนใหญ่ไม่ใช่เรื่องง่าย: แม้ว่า 'การเรียกกลับ' เป็นคุณลักษณะทั่วไปในภาษาอื่น ๆ บางภาษาการวนซ้ำของเหตุการณ์ไม่ได้เกิดขึ้นและคุณมักจะพบว่าตัวเองกำลังต่อสู้กับไลบรารีภายนอก (ตัวอย่างเช่น Python กับ ทวิสเตอร์ ). แต่ใน JavaScript โทรกลับ ถูกสร้างขึ้นในภาษาเช่นเดียวกับการวนซ้ำของเหตุการณ์และโปรแกรมเมอร์เกือบทุกคนที่เคยขลุกอยู่กับ JavaScript ก็คุ้นเคยกับพวกเขา (หรืออย่างน้อยก็ใช้พวกเขาแม้ว่าพวกเขาจะ ไม่ค่อยเข้าใจว่า Event Loop คืออะไร ). ทันใดนั้นทุกการเริ่มต้นบน Earth สามารถนำนักพัฒนากลับมาใช้ซ้ำได้ (เช่นทรัพยากร) ทั้งในฝั่งไคลเอ็นต์และฝั่งเซิร์ฟเวอร์โดยแก้ปัญหา“ Python Guru Needed” ปัญหาการโพสต์งาน .

ทันใดนั้นทุกการเริ่มต้นบน Earth สามารถนำนักพัฒนากลับมาใช้ซ้ำได้ (เช่นทรัพยากร) ทั้งในฝั่งไคลเอนต์และฝั่งเซิร์ฟเวอร์เพื่อแก้ปัญหาโพสต์งาน 'Python Guru Needed'

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

• การเขียนโปรแกรมฟังก์ชั่น

  JavaScript เป็นภาษาโปรแกรมแรกที่ นำกระบวนทัศน์การทำงาน สำหรับคนจำนวนมาก (แน่นอนว่า Lisp มาก่อน แต่โปรแกรมเมอร์ส่วนใหญ่ไม่เคยสร้างแอปพลิเคชันที่พร้อมใช้งานจริงโดยใช้ Lisp) เสียงกระเพื่อมและตัวเอง อิทธิพลหลักของ Javascript เต็มไปด้วยแนวคิดใหม่ ๆ ความคิดเหล่านั้นสามารถปลดปล่อยจิตใจของเราในการสำรวจเทคนิครูปแบบและกระบวนทัศน์ใหม่ ๆ และทั้งหมดนี้ส่งต่อไปยัง JavaScript ลองดูที่ monads , หมายเลขคริสตจักร หรือแม้กระทั่ง (สำหรับตัวอย่างที่ใช้ได้จริง) Underscore.js ของ ฟังก์ชันคอลเลกชัน ซึ่งสามารถช่วยคุณประหยัดบรรทัดและบรรทัดของโค้ด

• Dynamic Objects และ Prototypal inheritance

  การเขียนโปรแกรมเชิงวัตถุโดยไม่มีคลาส (และไม่มีลำดับชั้นของคลาสที่ไม่มีที่สิ้นสุด) ช่วยให้สามารถพัฒนาได้อย่างรวดเร็ว (สร้างอ็อบเจ็กต์เพิ่มเมธอดและใช้งาน) แต่ที่สำคัญที่สุดคือลดเวลาในการปรับโครงสร้างใหม่ระหว่างงานบำรุงรักษาโดยให้โปรแกรมเมอร์แก้ไขอินสแตนซ์ของอ็อบเจ็กต์แทน ของชั้นเรียน ความเร็วและความยืดหยุ่นนี้ปูทางไปสู่การพัฒนาอย่างรวดเร็ว

• JavaScript คืออินเทอร์เน็ต

  JavaScript คือ ออกแบบมาสำหรับอินเทอร์เน็ต มันอยู่ที่นี่ตั้งแต่เริ่มต้นและมันก็เป็นเช่นนั้น ไม่หายไปไหน . ความพยายามทั้งหมดที่จะทำลายมันล้มเหลว: ดูตัวอย่างเช่นการล่มสลายของ Java Applets แทนที่ VBScript โดย TypeScript ของ Microsoft (ซึ่งคอมไพล์เป็น JavaScript) และการตายของ Flash ตกอยู่ในมือของตลาดมือถือและ HTML5 เป็นไปไม่ได้ที่จะแทนที่ Javascript โดยไม่ทำลายหน้าเว็บนับล้านดังนั้นเป้าหมายของเราในอนาคตควรจะปรับปรุงให้ดีขึ้น และไม่มีใครเหมาะกับงานนี้ไปกว่า กรรมการเทคนิค 39 จาก ECMA

  ตกลงทางเลือกของ JavaScript เกิดขึ้นทุกวันเช่น CoffeeScript , TypeScript และ ภาษานับล้านที่รวบรวมเป็น JavaScript . ทางเลือกเหล่านี้อาจเป็นประโยชน์สำหรับขั้นตอนการพัฒนา ( ผ่านแผนที่ต้นทาง ) แต่พวกเขาจะล้มเหลวในการแทนที่ JavaScript ในระยะยาวด้วยเหตุผลสองประการ: ชุมชนของพวกเขาจะไม่มีวันใหญ่ขึ้นและคุณลักษณะที่ดีที่สุดของพวกเขาจะถูกนำมาใช้โดยสคริปต์ ECMA (เช่น JavaScript) JavaScript ไม่ใช่ภาษาแอสเซมบลี แต่เป็นภาษาโปรแกรมระดับสูงที่มีซอร์สโค้ดที่คุณเข้าใจได้ดังนั้นคุณควรทำความเข้าใจ

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

End-to-End JavaScript: Node.js และ MongoDB

นั่นคือเหตุผลที่ต้องใช้ JavaScript ตอนนี้ฉันจะใช้ JavaScript เป็นเหตุผลในการใช้ Node.js และ MongoDB

• โหนด js

  Node.js เป็นแพลตฟอร์มสำหรับสร้างแอปพลิเคชันเครือข่ายที่รวดเร็วและปรับขนาดได้ซึ่งเป็นสิ่งที่เว็บไซต์ Node.js กล่าวไว้ แต่ Node.js เป็นมากกว่านั้นนั่นคือสภาพแวดล้อมรันไทม์ที่ต้องการสำหรับแอปพลิเคชัน JavaScript ที่มีการเข้าถึง I / O แม้ว่าคุณจะไม่ได้วางแผนที่จะเขียนแอปพลิเคชันเซิร์ฟเวอร์หลักด้วย Node.js แต่คุณสามารถใช้เครื่องมือที่สร้างขึ้นจาก Node.js เพื่อปรับปรุงกระบวนการพัฒนาของคุณได้ ตัวอย่างเช่น: มอคค่า js สำหรับการทดสอบหน่วย Grunt.js สำหรับงานสร้างอัตโนมัติหรือแม้กระทั่ง วงเล็บ สำหรับการแก้ไขโค้ดแบบเต็ม

  ดังนั้นหากคุณจะเขียนแอปพลิเคชัน JavaScript สำหรับเซิร์ฟเวอร์หรือไคลเอนต์คุณควรดูบางส่วน ตัวอย่าง Node.js เพราะคุณจำเป็นต้องใช้และใช้เป็นประจำทุกวัน มีบางส่วนที่น่าสนใจ ทางเลือกอื่น แต่ไม่มีเลยแม้แต่ 10% ของชุมชน Node.js

• MongoDB

  MongoDB คือ NoSQL ฐานข้อมูลเอกสารที่ใช้ JavaScript เป็นภาษาในการสืบค้นทำให้ฉันสามารถทำแพลตฟอร์ม JavaScript แบบ end-to-end ได้ แต่นั่นไม่ใช่เหตุผลหลักในการเลือกฐานข้อมูลนี้

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

ส่วนประกอบของเซิร์ฟเวอร์ด้วย Express.js

การจัดองค์ประกอบฝั่งเซิร์ฟเวอร์ไม่ใช่เรื่องง่าย แต่ด้วย Express.js (และ Connect.js ) เป็นแนวคิดของ 'มิดเดิลแวร์' ในความคิดของฉันมิดเดิลแวร์เป็นวิธีที่ดีที่สุดในการกำหนดส่วนประกอบบนเซิร์ฟเวอร์ หากคุณต้องการเปรียบเทียบกับรูปแบบที่ทราบแล้วมันค่อนข้างใกล้เคียงกับท่อและตัวกรอง

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

เราเรียก 'ชิ้นส่วนของท่อ' เหล่านี้ว่า 'มิดเดิลแวร์' เห็นได้ชัดว่าเราสามารถสร้างมิดเดิลแวร์ได้สองประเภท:

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

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

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

แอปพลิเคชั่นหน้าเดียว

โครงการ Init มุ่งเน้นไปที่การสร้าง แอปพลิเคชันหน้าเดียว (SPAs) . นักพัฒนาเว็บส่วนใหญ่ถูกล่อลวงให้ลองใช้ SPA มากกว่าหนึ่งครั้ง ฉันได้สร้างไว้หลายตัว (ส่วนใหญ่เป็นกรรมสิทธิ์) และฉันสามารถพูดด้วยความมั่นใจว่าสิ่งเหล่านี้เป็นเพียงอนาคตของเว็บแอปพลิเคชัน คุณเคยเปรียบเทียบ SPA กับเว็บแอปทั่วไปบนการเชื่อมต่อมือถือหรือไม่? ความแตกต่างในการตอบสนองอยู่ที่ลำดับของหลายสิบวินาที

คุณเคยเปรียบเทียบ SPA กับเว็บแอปทั่วไปบนการเชื่อมต่อมือถือหรือไม่? ความแตกต่างในการตอบสนองอยู่ที่ลำดับของหลายสิบวินาที

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

Client Side MV * พร้อม Backbone.js, Marionette.js และ Twitter Bootstrap

มีการพูดถึงมาก เฟรมเวิร์ก MVC * สำหรับ SPAs . เป็นตัวเลือกที่ยาก แต่ฉันบอกว่าสามอันดับแรกคือ Backbone.js , Ember.js และ Angular.js .

ทั้งสามได้รับการยกย่องเป็นอย่างดี แต่อันไหนดีที่สุดสำหรับคุณ?

น่าเสียดายที่ฉันต้องยอมรับว่าฉันมีประสบการณ์กับ Angular.js ที่ จำกัด มากดังนั้นฉันจะไม่พูดถึงเรื่องนี้ (สำหรับข้อมูลเพิ่มเติมเกี่ยวกับเรื่องนี้โปรดอ้างอิง บทช่วยสอน Angular.js ). ตอนนี้ Ember.js และ Backbone.js แสดงถึงสองวิธีที่แตกต่างกันในการโจมตีปัญหาเดียวกัน

Backbone.js มีน้อยเรียบง่ายและให้คุณเพียงพอที่จะสร้างสปาง่ายๆ ในทางกลับกัน Ember.js เป็นกรอบงานที่สมบูรณ์และเป็นมืออาชีพสำหรับการสร้าง SPA มีระฆังและนกหวีดมากขึ้น แต่ยังมีเส้นโค้งการเรียนรู้ที่ใหญ่กว่า

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

ในกรณีของ Init ฉันต้องการครอบคลุมสถานการณ์ส่วนใหญ่ดังนั้นฉันจึงเลือก Backbone.js เพื่อการสร้าง SPA ที่ง่ายด้วย Backbone.Marionette.View สำหรับการจัดองค์ประกอบ ด้วยวิธีนี้ส่วนประกอบทั้งหมดจึงเป็นแอปพลิเคชันที่เรียบง่ายและแอปสุดท้ายอาจมีความซับซ้อนเท่าที่เราต้องการ

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

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

แนวทางปฏิบัติที่ดีที่สุด: Grunt.js, Mocha.js, Chai.js, RequireJS และ CoverJS

สุดท้ายนี้เราควรกำหนดแนวทางปฏิบัติที่ดีที่สุดของเราและดูว่า Init สามารถช่วยคุณปรับใช้และดูแลรักษาได้อย่างไร โซลูชันของเรามีศูนย์กลางอยู่ที่เครื่องมือหลายอย่างซึ่งขึ้นอยู่กับ Node.js เอง

• มอคค่า js และ Chai.js :

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

  มี หลายพัน ของกรอบการทดสอบหน่วยสำหรับ JavaScript ทำไมต้องใช้ Mocha.js? คำตอบสั้น ๆ : มีความยืดหยุ่นและสมบูรณ์

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

  • อินเทอร์เฟซ : บางทีคุณอาจคุ้นเคยกับแนวคิด TDD เกี่ยวกับห้องชุดและการทดสอบหน่วยหรือบางทีคุณอาจชอบแนวคิด BDD เกี่ยวกับข้อกำหนดด้านพฤติกรรมที่มี 'อธิบาย' และ 'ควร' Mocha.js ให้คุณใช้ทั้งสองวิธี

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

  • ขาดห้องสมุดยืนยัน : ห่างไกลจากปัญหา Mocha.js ได้รับการออกแบบมาเพื่อให้คุณใช้ไลบรารีการยืนยันที่คุณเลือกทำให้คุณมีความยืดหยุ่นมากยิ่งขึ้น มี ตัวเลือกมากมาย แต่นี่คือจุดที่ Chai.js เข้ามามีบทบาท

  Chai.js เป็นไลบรารีการยืนยันที่ยืดหยุ่นซึ่งให้คุณใช้รูปแบบการยืนยันหลัก ๆ สามแบบ:

  • ยืนยัน : สไตล์การยืนยันแบบคลาสสิกจากโรงเรียนเก่า TDD เช่น.:

    assert.equal(variable, ”value”);

  • คาดหวัง : รูปแบบการยืนยันแบบลูกโซ่ซึ่งนิยมใช้ใน BDD เช่น.:

    expect(variable).to.equal(“value”);

  • ควร : ยังใช้ใน BDD แต่ฉันชอบ Expect เพราะควรฟังดูซ้ำ ๆ กับข้อกำหนดพฤติกรรม 'it (' ควรทำอะไรสักอย่าง .. ')' เช่น.:

    variable.should.equal(“value”);

  Chai.js ผสมผสานกับ Mocha.js ได้อย่างลงตัว ด้วยการใช้ไลบรารีทั้งสองนี้คุณสามารถเขียนการทดสอบของคุณใน TDD, BDD หรือรูปแบบใดก็ได้

• Grunt.js :

  ตัวอย่างการพิสูจน์ตัวตน Java rest api

  Grunt.js ช่วยให้คุณสามารถสร้างงานบิวด์ได้โดยอัตโนมัติทุกอย่างตั้งแต่การคัดลอกวางและการต่อไฟล์อย่างง่ายไปจนถึงการรวบรวมเทมเพลตล่วงหน้าการคอมไพล์ภาษาสไตล์ (เช่น SASS และ LESS) การทดสอบหน่วย (ด้วย mocha.js) การทำขุยและ การลดรหัส (เช่นกับ UglifyJS หรือ ปิดคอมไพเลอร์ ). คุณสามารถเพิ่มงานอัตโนมัติของคุณเองใน Grunt หรือค้นหาไฟล์ Grunt รีจิสทรี ซึ่งมีปลั๊กอินหลายร้อยหลายร้อยรายการ (อีกครั้งการใช้เครื่องมือที่มีชุมชนที่ยอดเยี่ยมอยู่เบื้องหลังพวกเขาจะคุ้มค่า) ฮึดฮัดได้ด้วย ตรวจสอบไฟล์ของคุณ และทริกเกอร์การดำเนินการเมื่อมีการแก้ไข

• ต้องการ JS :

  RequireJS อาจเป็นอีกวิธีหนึ่งในการโหลดโมดูลด้วย AMD แต่ฉันมั่นใจได้ว่ามันมีมากกว่านั้น เพื่อให้เข้าใจว่าเหตุใดเราจึงต้องพูดถึงแนวคิดของการกำหนดเนมสเปซโมดูลก่อน (เช่น demo.views.hello) ซึ่งหลีกเลี่ยงการสร้างมลพิษให้กับเนมสเปซทั่วโลกโดยการรวมแต่ละโมดูลในเนมสเปซของตัวเอง ปัญหาคือโมดูลเหล่านี้ไม่สามารถใช้ซ้ำได้: หากคุณแก้ไขเนมสเปซของ 'อินสแตนซ์' หนึ่งรายการแสดงว่าคุณกำลังแก้ไขเนมสเปซของ 'อินสแตนซ์' ทั้งหมด ในทางตรงกันข้าม RequireJS ช่วยให้คุณกำหนดโมดูลที่ใช้ซ้ำได้ตั้งแต่เริ่มต้น (นอกจากนี้ยังช่วยให้คุณโอบกอด การฉีดพึ่งพา ถึง หลีกเลี่ยงไม่ให้โมดูลของคุณเข้าถึงตัวแปรส่วนกลาง .)

• CoverJS :

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

การใช้สาขาเพื่อสลับคุณสมบัติ

เมื่อฉันเริ่ม Init ฉันต้องการวิธีให้ผู้ใช้เปิดใช้งานและปิดใช้งานคุณสมบัติต่างๆที่พวกเขาอาจต้องการในโปรเจ็กต์ของพวกเขา ฉันตัดสินใจที่จะใช้วิธีการที่รุนแรงในระบบสาขาของ git เพื่อใช้ฟังก์ชันนี้

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

สำหรับตอนนี้แนวคิดในการผสานเพื่อเพิ่มฟังก์ชันนี้สามารถใช้ได้กับเทมเพลตเทคโนโลยีเท่านั้น (เช่น Backbone, Node, Express) แต่ในอนาคตคุณจะสามารถสลับระหว่างแบ็คเอนด์ (เช่นจาก MongoDB เป็น Postgres) และการใช้งานของไคลเอ็นต์

เริ่มโครงการด้วย Init และปรับใช้กับ Heroku วันนี้

ไม่เคยมีวิธีที่ง่ายกว่านี้ในการเริ่มต้นโครงการ เพียงไปที่ไฟล์ GitHub repo ตรวจสอบสาขาที่มีข้อผูกพันล่าสุด (ตอนนี้เป็น usermanager แม้ว่าสิ่งนี้อาจมีการเปลี่ยนแปลงในอนาคต) จากนั้น:

1. สร้างไดเร็กทอรีสำหรับโครงการของคุณ (หรือใช้ที่มีอยู่)
2. สร้างที่เก็บของคุณด้วย“ git init” (หรือใช้ที่เก็บที่มีอยู่)

3. เพิ่มรีโมทด้วย init

   git remote add init git://github.com/picanteverde/init.git

4. รับสาขาที่คุณต้องการ

   git pull init usermanager

5. รับไฟล์กระบวนการ Heroku

   git pull init heroku-webprocess

6. กับ Heroku Toolbelt ติดตั้งสร้างแอป Heroku

   heroku create

7. ผลักดันสาขาหลักของคุณไปที่ Heroku

   git push heroku master
8. เยี่ยมชมแอปของคุณเริ่มต้นใช้งาน Heroku!

ตอนนี้คุณสามารถเริ่มพัฒนาคุณลักษณะนักฆ่าของคุณได้ด้วยโค้ดเพียงไม่กี่บรรทัด ไม่เพียงแค่นั้น แต่คุณจะได้รับการพัฒนาด้วยเทคโนโลยีล่าสุดที่มีประสิทธิภาพสูงสุดในชุดการพัฒนาที่ทำงานอัตโนมัติอย่างที่เป็นไปได้

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