ฉันกำลังจะสร้างแอปพลิเคชันบนเว็บเป็นจำนวนมากตั้งแต่เริ่มต้น (ดูhttp://50pop.com/codeเพื่อดูภาพรวม) ฉันต้องการให้พวกเขาสามารถเข้าถึงได้จากไคลเอนต์ที่แตกต่างกันมากมาย: เว็บไซต์ส่วนหน้าแอพสมาร์ทโฟนสมาร์ทโฟนบริการเว็บแบ็คเอนด์ ฯลฯ ดังนั้นฉันต้องการ JSON REST API สำหรับแต่ละรายการ

นอกจากนี้ฉันชอบทำงานกับส่วนแบ็คเอนด์ดังนั้นฉันจึงฝันว่าฉันจะยังคงมุ่งเน้นไปที่ API และจ้างคนอื่นเพื่อสร้าง UI ส่วนหน้าไม่ว่าจะเป็นเว็บไซต์ iPhone, Android หรือแอปอื่น ๆ

โปรดช่วยฉันตัดสินใจด้วยว่าฉันควรใช้วิธีใด:

รวมกันในรถไฟ

สร้างเว็บแอพ Rails ที่ได้มาตรฐานมาก ๆ ในคอนโทรลเลอร์ให้ทำสวิตช์ตอบกลับเพื่อให้บริการ JSON หรือ HTML การตอบสนอง JSON นั้นเป็น API ของฉัน

Pro:แบบอย่างมากมาย มาตรฐานที่ยอดเยี่ยมและตัวอย่างมากมายในการทำสิ่งนี้

คอนดิชั่น:ไม่จำเป็นต้องให้ API เหมือนกับแอพเว็บ ไม่ชอบ if / then response_with switch approach การผสมสองสิ่งที่แตกต่างกันมาก (UI + API)

เซิร์ฟเวอร์ส่วนที่เหลือ + ไคลเอนต์ JAVASCRIPT-HEAVY

สร้างเซิร์ฟเวอร์ REST API ของ JSON เท่านั้น ใช้ Backbone หรือ Ember.js สำหรับ JavaScript ฝั่งไคลเอ็นต์เพื่อเข้าถึง API โดยตรงโดยแสดงแม่แบบในเบราว์เซอร์

Pro:ฉันชอบการแยก API และไคลเอนต์ คนฉลาดบอกว่านี่เป็นวิธีที่จะไป ยิ่งใหญ่ในทางทฤษฎี ดูเหมือนทันสมัยและน่าตื่นเต้น

คอนดิชั่น:แบบอย่างไม่มากนัก มีตัวอย่างไม่มากที่ทำได้ดี ตัวอย่างสาธารณะ (twitter.com) รู้สึกซบเซาและเปลี่ยนไปจากแนวทางนี้

เซิร์ฟเวอร์ REST + ไคลเอนต์ HTML ฝั่งเซิร์ฟเวอร์

สร้างเซิร์ฟเวอร์ REST API ของ JSON เท่านั้น สร้างเว็บไซต์เว็บไซต์ HTML พื้นฐานที่เข้าถึง REST API เท่านั้น ลดจาวาสคริปต์ฝั่งไคลเอ็นต์

Pro:ฉันชอบการแยก API และไคลเอนต์ แต่การให้บริการ HTML5 ธรรมดานั้นค่อนข้างจะเข้าใจผิดได้และไม่เน้นลูกค้า

คอนดิชั่น:แบบอย่างไม่มากนัก มีตัวอย่างไม่มากที่ทำได้ดี กรอบงานไม่รองรับสิ่งนี้เช่นกัน ไม่แน่ใจว่าจะเข้าใกล้มันอย่างไร

โดยเฉพาะการหาคำแนะนำจากประสบการณ์ไม่ใช่เฉพาะในเชิงทฤษฎี

ที่Boundlessเราได้เจาะลึกกับตัวเลือก # 2 และแผ่ออกไปสู่นักเรียนหลายพันคน เซิร์ฟเวอร์ของเราคือ JSON REST API (Scala + MongoDB) และรหัสลูกค้าของเราทั้งหมดนั้นให้บริการโดยตรงจาก CloudFront (เช่น: www.boundless.com เป็นเพียงนามแฝงสำหรับ CloudFront)

ข้อดี:

• ตัดขอบ / ที่น่าตื่นเต้น
• มีจำนวนมากสำหรับเจ้าชู้ของคุณ: API ช่วยให้คุณมีพื้นฐานสำหรับเว็บไคลเอ็นต์ของคุณ, ลูกค้ามือถือ, บุคคลที่สามเข้าถึง ฯลฯ
• เหลือเกินเว็บไซต์ได้อย่างรวดเร็วเปลี่ยนโหลด / หน้า

จุดด้อย:

• ไม่เป็นมิตรกับ SEO / พร้อมโดยไม่ต้องทำงานมากขึ้น
• ต้องการชาวบ้านส่วนหน้าเว็บที่มีความพร้อมที่จะรับมือกับความเป็นจริงของประสบการณ์เว็บไซต์ที่เป็นจาวาสคริปต์ 70% และความหมายที่แท้จริง

ฉันคิดว่านี่เป็นอนาคตของเว็บแอปทั้งหมด

ความคิดบางอย่างสำหรับผู้ใช้เว็บส่วนหน้า (ซึ่งเป็นที่ซึ่งความใหม่ / ความท้าทายทั้งหมดได้รับสถาปัตยกรรมนี้):

• CoffeeScript ง่ายขึ้นในการผลิตรหัสที่มีคุณภาพสูง
• กระดูกสันหลัง. วิธีที่ยอดเยี่ยมในการจัดระเบียบตรรกะและชุมชนที่ใช้งานของคุณ
• HAMLC เทมเพลต Haml + CoffeeScript => JS
• SASS

เราได้สร้างบังเหียนสำหรับการพัฒนาส่วนหน้าของเราที่เรียกว่า 'Spar' (Single Page App Rocketship) ซึ่งเป็นระบบที่มีประสิทธิภาพในการพัฒนาแอพพลิเคชั่นหน้าเดียว เราจะเปิดแหล่งจัดหาภายในไม่กี่สัปดาห์ถัดไปในหน้าGitHubของเราพร้อมกับโพสต์บล็อกอธิบายวิธีการใช้งานและสถาปัตยกรรมโดยรวมในรายละเอียดที่มากขึ้น

UPDATE:

ด้วยความเคารพต่อความกังวลของผู้คนที่มีต่อ Backbone ฉันคิดว่าพวกเขาติดอันดับมากเกินไป Backbone เป็นหลักการขององค์กรมากกว่าที่จะเป็นกรอบลึก ไซต์ของ Twitter นั้นเป็นสัตว์ร้ายขนาดใหญ่ของจาวาสคริปต์ที่ครอบคลุมทุกมุมของผู้ใช้หลายล้านคนและเบราว์เซอร์รุ่นเก่าในขณะที่โหลดทวีตแบบเรียลไทม์เก็บขยะแสดงมัลติมีเดียจำนวนมาก ฯลฯ จากไซต์ js ที่ 'บริสุทธิ์' ทั้งหมด เห็นว่า Twitter เป็นสิ่งที่แปลก มีแอพพลิเคชั่นที่ซับซ้อนและน่าประทับใจมากมายที่ส่งมอบผ่านทาง JS ซึ่งมีราคาดี

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

ถามเป็นอย่างดี +1 แน่นอนนี่เป็นข้อมูลอ้างอิงที่มีประโยชน์ในอนาคตสำหรับฉัน @Aaron และคนอื่น ๆ ก็เพิ่มมูลค่าให้กับการสนทนา เช่นเดียวกับ Ruby คำถามนี้ใช้ได้กับสภาพแวดล้อมการเขียนโปรแกรมอื่นอย่างเท่าเทียมกัน

ฉันใช้สองตัวเลือกแรก อันแรกสำหรับแอปพลิเคชั่นมากมายและอันที่สองสำหรับโครงการโอเพ่นซอร์สของฉันCowoop

ตัวเลือกที่ 1

อันนี้ไม่ต้องสงสัยเลยว่าเป็นที่นิยมมากที่สุด แต่ฉันพบว่าการใช้งานนั้นมี http-ish มาก รหัสเริ่มต้นของ API ทุกตัวจะจัดการกับคำขอวัตถุ ดังนั้นรหัส API เป็นมากกว่ารหัสทับทิม / หลาม / ภาษาอื่น ๆ

ตัวเลือก 2

ฉันรักสิ่งนี้เสมอ

ตัวเลือกนี้ก็หมายความว่า HTML ไม่ได้สร้างรันไทม์บนเซิร์ฟเวอร์ นี่คือวิธีที่ตัวเลือก 2 แตกต่างจากตัวเลือก 3 แต่สร้างเป็น html แบบคงที่โดยใช้สคริปต์สร้าง เมื่อโหลดบนฝั่งไคลเอ็นต์ HTML เหล่านี้จะเรียกเซิร์ฟเวอร์ API เป็นไคลเอ็นต์ JS API

• การแยกข้อกังวลเป็นข้อได้เปรียบที่ยิ่งใหญ่ และผู้เชี่ยวชาญของแบ็กเอนด์ชื่นชอบ (และของฉัน) ใช้ API แบ็กเอนด์ทดสอบพวกเขาได้อย่างง่ายดายเหมือนกับรหัสภาษาปกติโดยไม่ต้องกังวลเกี่ยวกับเฟรมเวิร์ก / http ร้องขอรหัส

• มันไม่ยากอย่างที่คิดเพราะฟังที่ด้านหน้า การเรียก API และข้อมูลที่เป็นผลลัพธ์ (ส่วนใหญ่เป็น json) นั้นมีให้สำหรับเทมเพลตฝั่งไคลเอ็นต์หรือ MVC ของคุณ

• การประมวลผลด้านเซิร์ฟเวอร์น้อย หมายความว่าคุณอาจไปหาฮาร์ดแวร์สินค้า / เซิร์ฟเวอร์ราคาถูกกว่า

• ง่ายต่อการทดสอบเลเยอร์อย่างอิสระสร้างเอกสาร API ได้ง่ายขึ้น

มันมีข้อเสียบางอย่าง

• นักพัฒนาหลายคนพบสิ่งนี้ผ่านการออกแบบและเข้าใจยาก โอกาสที่สถาปัตยกรรมนั้นอาจถูกวิพากษ์วิจารณ์

• i18n / l10n นั้นยาก เนื่องจาก HTML ถูกสร้างโดยพื้นฐานแล้วเวลาสร้างเป็นแบบคงที่จึงต้องมีหลายบิลด์ต่อภาษาที่รองรับ (ซึ่งไม่จำเป็นต้องเป็นสิ่งเลวร้าย) แต่ถึงอย่างนั้นคุณก็อาจมีมุมเล็ก ๆ ประมาณ l10n / i18n และต้องระวัง

ตัวเลือก 3

การเข้ารหัสแบ็กเอนด์ในกรณีนี้ต้องเหมือนกับตัวเลือกที่สอง คะแนนส่วนใหญ่สำหรับตัวเลือกที่ 2 มีผลบังคับใช้ที่นี่เช่นกัน

หน้าเว็บเป็นรันไทม์ที่แสดงผลโดยใช้เทมเพลตฝั่งเซิร์ฟเวอร์ สิ่งนี้ทำให้ i18n / l10n ง่ายขึ้นด้วยเทคนิคที่เป็นที่ยอมรับ / ยอมรับมากขึ้น อาจเป็นการเรียก http ที่น้อยกว่าสำหรับบริบทที่จำเป็นบางอย่างที่จำเป็นสำหรับการแสดงผลหน้าเช่นผู้ใช้ภาษาสกุลเงินเป็นต้นดังนั้นการประมวลผลด้านเซิร์ฟเวอร์จะเพิ่มขึ้นด้วยการแสดงผล แต่อาจชดเชยด้วยการเรียก http น้อยไปยังเซิร์ฟเวอร์ API

ตอนนี้หน้าจะแสดงผลเซิร์ฟเวอร์บนเซิร์ฟเวอร์ส่วนหน้าตอนนี้เชื่อมโยงกับสภาพแวดล้อมการเขียนโปรแกรมมากขึ้น สิ่งนี้อาจไม่ได้รับการพิจารณาสำหรับแอปพลิเคชันจำนวนมาก

กรณี Twitter

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

กองโครงการของเรา

ฉันบังเอิญใช้ Python ฉันใช้ JsonRPC 2.0 แทน REST ฉันแนะนำ REST แต่ฉันชอบความคิดของ JsonRPC ด้วยเหตุผลหลายประการ ฉันใช้ห้องสมุดด้านล่าง ใครบางคนกำลังพิจารณาตัวเลือก 2/3 อาจพบว่ามีประโยชน์

• API Server: Python เฟรมเวิร์กไมโครเว็บที่รวดเร็ว - Flask
• เซิร์ฟเวอร์ส่วนหน้า: Nginx
• MVC ฝั่งไคลเอ็นต์: Knockout.js
• เครื่องมือ / libs อื่น ๆ ที่เกี่ยวข้อง:
  • jquery
  • Accounting.jsสำหรับสกุลเงิน
  • Webshim : polyfill ข้ามเบราว์เซอร์
  • ผู้กำกับ : การกำหนดเส้นทางฝั่งไคลเอ็นต์
  • sphc : การสร้าง HTML

บทสรุปและข้อเสนอแนะของฉัน

ตัวเลือก 3!

ทั้งหมดบอกว่าฉันใช้ตัวเลือก 2 เรียบร้อยแล้ว แต่ตอนนี้กำลังมุ่งหน้าไปที่ตัวเลือก 3 เพื่อความเรียบง่าย การสร้างหน้า HTML แบบคงที่ด้วยการสร้างสคริปต์และการให้บริการกับหนึ่งในเซิร์ฟเวอร์ที่เร็วเป็นพิเศษที่เชี่ยวชาญในการให้บริการหน้าคงที่เป็นสิ่งที่ดึงดูดมาก (ตัวเลือก 2)

เราเลือกใช้อันดับ # 2 เมื่อสร้าง gaug.es ฉันทำงานกับ API (ทับทิม, ซินาตร้าและอื่น ๆ ) และ Steve Smith ซึ่งเป็นหุ้นส่วนธุรกิจของฉันทำงานในส่วนหน้า (ไคลเอนต์จาวาสคริปต์)

ข้อดี:

1. เคลื่อนที่อย่างรวดเร็วในแนวขนาน ถ้าฉันทำงานกับ Steve มาก่อนฉันสามารถสร้าง API สำหรับคุณลักษณะใหม่ได้ หากเขาทำงานก่อนหน้าของฉันเขาสามารถปลอม API ได้อย่างง่ายดายและสร้าง UI

2. API ฟรี การมีการเข้าถึงข้อมูลในแอปของคุณแบบเปิดนั้นกำลังกลายเป็นคุณสมบัติมาตรฐานอย่างรวดเร็ว หากคุณเริ่มต้นด้วย API ตั้งแต่เริ่มต้นคุณจะได้รับสิ่งนี้ฟรี

3. ทำความสะอาดแยก เป็นการดีกว่าถ้าคุณคิดว่าแอปของคุณเป็น API กับลูกค้า แน่นอนว่าลูกค้ารายแรกและสำคัญที่สุดอาจเป็นเว็บ แต่มันจะช่วยให้คุณสร้างลูกค้าอื่น ๆ ได้อย่างง่ายดาย (iPhone, Android)

จุดด้อย:

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

ฉันไม่สามารถคิดถึงข้อเสียอีกต่อไปในขณะนี้

สรุป: ลูกค้า API + JS เป็นวิธีที่จะไปหากคุณวางแผนที่จะปล่อย API

ป.ล. ฉันขอแนะนำให้คุณทำเอกสาร API อย่างสมบูรณ์ก่อนที่จะปล่อย ขั้นตอนการทำเอกสาร Gaug.es API ช่วยเราได้จริงๆ

http://get.gaug.es/documentation/api/

ฉันชอบไปเส้นทาง # 2 และ # 3 สาเหตุหลักมาจาก # 1 ละเมิดการแยกความกังวลและการรวมสิ่งต่าง ๆ เข้าด้วยกัน ในที่สุดคุณจะพบว่าจำเป็นต้องมีจุดสิ้นสุด API ที่ไม่มีหน้า HTML ที่ตรงกัน / ฯลฯ และคุณจะเป็นลำห้วยที่มีจุดเชื่อมต่อ HTML และ JSON แบบผสมผสานในฐานรหัสเดียวกัน มันกลายเป็นความยุ่งเหยิงแม้ว่า MVP ของมันคุณจะต้องเขียนใหม่ในที่สุดเพราะมันยุ่งมากจนไม่คุ้มค่าที่จะกู้

การใช้ # 2 หรือ # 3 ช่วยให้คุณมี API ที่ทำงานเหมือนเดิม (ส่วนใหญ่) โดยไม่คำนึงถึง สิ่งนี้ให้ความยืดหยุ่นที่ดีเยี่ยม ฉันยังไม่ได้ขาย 100% กับ Backbone / ember / อะไรก็ตาม ฯลฯ ฉันคิดว่ามันยอดเยี่ยม แต่เมื่อเราเห็นทวิตเตอร์นี่มันไม่เหมาะสม แต่ ... ทวิตเตอร์เป็นสัตว์ขนาดใหญ่ของ บริษัท และมีผู้ใช้หลายร้อยล้านคน ดังนั้นการปรับปรุงใด ๆ อาจมีผลกระทบอย่างใหญ่หลวงต่อผลประกอบการในหลาย ๆ ด้านของหน่วยธุรกิจต่างๆ ฉันคิดว่ามีการตัดสินใจมากกว่าความเร็วเพียงอย่างเดียวและพวกเขาไม่ยอมให้เราทำเช่นนั้น แต่นั่นเป็นเพียงความคิดเห็นของฉัน อย่างไรก็ตามฉันไม่ได้ลดกระดูกสันหลังและคู่แข่ง แอพเหล่านี้ใช้งานได้ดีและสะอาดมากและตอบสนองได้ดี (ส่วนใหญ่)

ตัวเลือกที่สามมีเสน่ห์ที่ถูกต้องเช่นกัน นี่คือที่ที่ฉันทำตามหลักการ Pareto (80/20 กฎ) และมี 20% ของมาร์กอัปหลักของคุณ (หรือกลับกัน) ที่แสดงผลบนเซิร์ฟเวอร์แล้วมีลูกค้า JS ที่ดี (แบ็คโบน / ฯลฯ ) เรียกใช้ส่วนที่เหลือของมัน . คุณอาจไม่ได้สื่อสาร 100% กับ REST api ผ่านทางไคลเอนต์ JS แต่คุณจะทำงานบางอย่างหากจำเป็นเพื่อให้ประสบการณ์ที่ดีขึ้น

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

ฉันกำลังแปลง CMS ขนาดใหญ่จากตัวเลือก 1 เป็นตัวเลือก 3 และมันก็ใช้ได้ดี เราเลือกที่จะแสดงผลด้านเซิร์ฟเวอร์มาร์กอัปเพราะ SEO เป็นเรื่องใหญ่สำหรับเราและเราต้องการให้เว็บไซต์ทำงานได้ดีบนโทรศัพท์มือถือ

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

• แสดงถึงรากฐานของแอป
  (https://github.com/visionmedia/express)
• ขอให้ดึงข้อมูล
  (https://github.com/mikeal/request)
• ขีดเส้นใต้เทมเพลตที่ทำให้ฝั่งเซิร์ฟเวอร์แสดงผล ฉันนำสิ่งเหล่านี้กลับมาใช้กับลูกค้า
  (https://github.com/documentcloud/underscore)
• UTML ล้อมรอบแม่แบบที่ขีดเส้นใต้เพื่อให้ทำงานกับ Express ได้
  (https://github.com/mikefrey/utml)
• รวบรวมแม่แบบล่วงหน้าและให้คุณเลือกว่าจะส่งให้ลูกค้าแบบใด
  (https://github.com/mrDarcyMurphy/upfront)
• Express Expose ส่งผ่านข้อมูลที่ดึงมาโมดูลบางส่วนและเทมเพลตไปยังส่วนหน้า
  (https://github.com/visionmedia/express-expose)
• Backbone สร้างแบบจำลองและมุมมองที่ส่วนหน้าหลังจากกลืนข้อมูลที่ผ่านไปแล้ว
  (https://github.com/documentcloud/backbone)

นั่นคือแกนกลางของสแต็ค โมดูลอื่น ๆ ที่ฉันพบมีประโยชน์:

• fleck (https // github.com / trek / fleck)
• ช่วงเวลา (https // github.com / timrwood / ช่วงเวลา)
• สไตลัส (https // github.com / LearnBoost / สไตลัส)
• smoosh (https // github.com / fat / smoosh)
  …แม้ว่าฉันจะดูเป็นคนเสี้ยงฮึดฮัด (https // github.com / โคบาล / grunt)
• การติดตามคอนโซล (//github.com/LearnBoost/console-trace)

ไม่ฉันไม่ได้ใช้ coffeescript

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

(ขออภัยสำหรับลิงก์แปลก ๆ ฉันมี n00b มากเกินไปสำหรับการโอเวอร์โฟลว์ของสแต็กเพื่อให้ฉันโพสต์จำนวนมาก)

เราใช้ตัวแปร # 3 ต่อไปนี้: สร้างเซิร์ฟเวอร์ REST API ของ JSON เท่านั้น สร้างเซิร์ฟเวอร์เว็บไซต์ HTML เว็บเซิร์ฟเวอร์ HTML ไม่เหมือนกับไคลเอ็นต์ในเซิร์ฟเวอร์ REST API แต่ทั้งสองเป็นเพื่อน ไม่ไกลจากพื้นผิวมี API ภายในที่ให้ฟังก์ชันการทำงานที่เซิร์ฟเวอร์ทั้งสองต้องการ

เราไม่ทราบถึงแบบอย่างใด ๆ ดังนั้นจึงเป็นการทดลอง จนถึงตอนนี้ (กำลังจะเข้าสู่เบต้า) มันได้ผลค่อนข้างดี

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

ฉันได้นำเสนอเกี่ยวกับวิธีการนี้ในวันRubyDay.itล่าสุด: http://www.slideshare.net/matteocollina/enter-the-app-era-with-ruby-on-rails-rubyday

สำหรับตัวเลือกที่สามเพื่อรับการตอบสนองของตัวที่สองคุณอาจต้องการลองชุดนอนแบบที่ Github ทำ

ฉันใช้เวลาประมาณ 2 เดือนในโครงการ 3 เดือนซึ่งใช้แนวทางที่สองที่คุณได้อธิบายไว้ที่นี่ เราใช้ RESTful API ฝั่งเซิร์ฟเวอร์กับ backbone.js ด้านหน้า Handlebars.js จัดการเทมเพลตและ jQuery จัดการการจัดการ AJAX และ DOM สำหรับเบราว์เซอร์รุ่นเก่าและสไปเดอร์การค้นหาเราได้กลับไปใช้การเรนเดอร์ฝั่งเซิร์ฟเวอร์ แต่เราใช้เทมเพลต HTML เดียวกับส่วนหน้าของแฮนด์บาร์โดยใช้ Mozilla Rhino

เราเลือกวิธีการนี้ด้วยเหตุผลที่แตกต่างกัน แต่ทราบว่ามันมีความเสี่ยงเล็กน้อยเนื่องจากยังไม่ได้รับการพิสูจน์ในวงกว้าง เหมือนกันทุกอย่างกำลังดำเนินไปอย่างราบรื่น

จนถึงตอนนี้เราเพิ่งทำงานกับหนึ่ง API แต่ในระยะต่อไปของโครงการเราจะทำงานร่วมกับ API ที่สอง สิ่งแรกคือข้อมูลจำนวนมากและสิ่งที่สองทำหน้าที่คล้ายกับ CMS ผ่าน API มากขึ้น

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

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

ขอให้โชคดีกับการเลือกของคุณที่นี่ กระตือรือร้นที่จะเห็นสิ่งที่คนอื่นแบ่งปันเช่นกัน

ฉันชอบ # 3 เมื่อเว็บไซต์ของฉันไม่ได้ใช้งาน CRUD 100% สำหรับข้อมูลของฉัน ซึ่งยังไม่เกิดขึ้น

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

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

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

https://github.com/dusty/multi-rack-app-app

บางคำตอบที่ดีที่นี่แล้ว - ฉันขอแนะนำ # 2 หรือ # 3 - แยกเป็นแนวคิดที่ดี แต่ในทางปฏิบัติ

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

ระหว่าง # 2 # 3 ขึ้นอยู่กับเป้าหมายของคุณ - ฉันยอมรับว่า # 2 น่าจะเป็นอนาคตของ webapps - แต่บางทีคุณอาจต้องการบางสิ่งที่ตรงไปตรงมามากขึ้นถ้าช่องนั้นจะเป็นหนึ่งในหลาย ๆ !

สำหรับ atyourservice.com.cy เราใช้เทมเพลตที่สร้างการแสดงผลด้านเซิร์ฟเวอร์สำหรับหน้าโดยเฉพาะเพื่อครอบคลุมส่วน และใช้ API สำหรับการโต้ตอบหลังจากโหลดหน้าเว็บ เนื่องจากเฟรมเวิร์กของเราคือ MVC ฟังก์ชันคอนโทรลเลอร์ทั้งหมดจะทำซ้ำกับเอาต์พุต json และเอาต์พุต html เทมเพลตสะอาดและรับเพียงวัตถุ สามารถแปลงเป็นเทมเพลต js ได้ในไม่กี่วินาที เราบำรุงรักษาเทมเพลตเซิร์ฟเวอร์เสมอและเพิ่งเปลี่ยนเป็น js ตามคำขอ

การเรนเดอร์ isomorphic และการเพิ่มประสิทธิภาพแบบก้าวหน้า ซึ่งเป็นสิ่งที่ฉันคิดว่าคุณกำลังมุ่งหน้าไปในตัวเลือกที่สาม

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

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

ใช่แน่นอนเขียน json api แบบสแตนด์อโลนสำหรับฟังก์ชันการทำงานของแอพนี้ แต่อย่าไปจนคุณเขียน json api สำหรับสิ่งที่ทำงานได้ดีเป็นเอกสาร html คงที่

เซิร์ฟเวอร์ REST + ไคลเอนต์ที่ใช้ JavaScript หนักคือหลักการที่ฉันได้ติดตามในงานล่าสุดของฉัน

เซิร์ฟเวอร์ REST ถูกนำมาใช้ในnode.js + Express + MongoDB (ประสิทธิภาพการเขียนที่ดีมาก) + Mongoose ODM (ยอดเยี่ยมสำหรับการสร้างแบบจำลองข้อมูลการตรวจสอบรวม) + CoffeeScript (ฉันจะไป ES2015 แทน) ซึ่งทำงานได้ดีสำหรับฉัน Node.js อาจค่อนข้างเล็กเมื่อเทียบกับเทคโนโลยีฝั่งเซิร์ฟเวอร์อื่น ๆ ที่เป็นไปได้ แต่มันทำให้ฉันสามารถเขียน API ที่มั่นคงด้วยการชำระเงินแบบรวม

ฉันใช้Ember.jsเป็นเฟรมเวิร์ก JavaScript และตรรกะส่วนใหญ่ของแอปพลิเคชันได้รับการดำเนินการในเบราว์เซอร์ ฉันใช้SASS (SCSS โดยเฉพาะ) สำหรับการประมวลผลล่วงหน้าของ CSS

Ember เป็นเฟรมเวิร์กที่ได้รับการสนับสนุนโดยชุมชนที่เข้มแข็ง มันเป็นเฟรมเวิร์กที่ทรงพลังมากเมื่อไม่นานมานี้มีงานจำนวนมากที่มุ่งเน้นไปที่ประสิทธิภาพเช่นเครื่องมือการแสดงผล Glimmer ใหม่ล่าสุด (ได้รับแรงบันดาลใจจาก React)

ทีม Ember Core อยู่ในระหว่างการพัฒนาFastBootซึ่งให้คุณเรียกใช้งาน JavaScript Ember logic บนฝั่งเซิร์ฟเวอร์ (โดยเฉพาะ node.js) และส่ง HTML ที่แสดงผลล่วงหน้าของแอปพลิเคชันของคุณ (ซึ่งโดยปกติจะเรียกใช้ในเบราว์เซอร์) เป็นการดีสำหรับ SEO และประสบการณ์ผู้ใช้เนื่องจากเขาไม่รอนานที่จะแสดงหน้าเว็บ

Ember CLIเป็นเครื่องมือที่ยอดเยี่ยมที่ช่วยให้คุณสามารถจัดระเบียบโค้ดของคุณได้ Ember มีระบบนิเวศ addon ของตัวเองและคุณสามารถเลือกจากEmber Addons ที่หลากหลาย คุณสามารถคว้า Bootstrap (ในกรณีของฉัน) หรือมูลนิธิและเพิ่มลงในแอปของคุณ

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

upstream app_appName.com {
  # replace 0.0.0.0 with your IP address and 1000 with your port of node HTTP server
  server 0.0.0.0:1000;
  keepalive 8;
}

server {
  listen 80 default_server;
  listen [::]:80 default_server ipv6only=on;

  client_max_body_size 32M;

  access_log  /var/log/nginx/appName.access.log;
  error_log  /var/log/nginx/appName.error.log;

  server_name appName.com appName;

  location / {
     # frontend assets path
     root /var/www/html;
     index index.html;

     # to handle Ember routing
     try_files $uri $uri/ /index.html?/$request_uri;
  }

  location /i/ {
    alias /var/i/img/;
  }

  location /api/v1/ {
    proxy_pass  http://app_appName.com;

    proxy_next_upstream error timeout invalid_header http_500 http_502
http_503 http_504;
    proxy_redirect off;
    proxy_buffering off;
    proxy_set_header        Host            $host;
    proxy_set_header        X-Real-IP       $remote_addr;
    proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
  }
}

Pro: ฉันชอบการแยก API และไคลเอนต์ คนฉลาดบอกว่านี่เป็นวิธีที่จะไป ยิ่งใหญ่ในทางทฤษฎี ดูเหมือนทันสมัยและน่าตื่นเต้น

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

คอนดิชั่น: แบบอย่างไม่มากนัก มีตัวอย่างไม่มากที่ทำได้ดี ตัวอย่างสาธารณะ (twitter.com) รู้สึกซบเซาและเปลี่ยนไปจากแนวทางนี้

ตอนนี้ทุกอย่างดูแตกต่าง มีตัวอย่างมากมายในการทำ REST API + ลูกค้าจำนวนมากที่บริโภคมัน

ฉันตัดสินใจเลือกสถาปัตยกรรมของตัวเลือก # 2 สำหรับInfiniformsเนื่องจากเป็นวิธีที่ยอดเยี่ยมในการแยก UI ออกจากตรรกะทางธุรกิจ

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

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

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

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

module WebAndAPICommon
    module Products

        def index
            @products = # do some logic here that will set @products variable
        end

    end
end


class ProductsController < ApplicationController
    # default products controlelr, for rendering HMTL pages 
    include WebAndAPICommon

    def index
        super
    end

end



module API
    class ProductsController
        include WebAndAPICommon

        def index
            super
            render json: @products
        end

    end
end

ฉันใช้วิธีไฮบริดซึ่งเราใช้ซินาตร้าเป็นฐาน, ActiveRecord / Postgress ฯลฯ เพื่อแสดงเส้นทางของหน้าเว็บ (เทมเพลตที่บาง) เผยให้เห็น REST API ที่เว็บแอปสามารถใช้ ในการพัฒนาสิ่งต่าง ๆ เช่นการเลือกตัวเลือกการเติมข้อมูลจะทำผ่านผู้ช่วยที่แสดงผลในเทมเพลตที่บาง แต่เมื่อเราเข้าใกล้การผลิตสิ่งนี้จะถูกเปลี่ยนไปสำหรับการโทร AJAX ไปยัง REST API เนื่องจากเราเริ่มสนใจความเร็วหน้าโหลดมากขึ้น

สิ่งที่ง่ายต่อการแสดงผลใน Slim ได้รับการจัดการด้วยวิธีการและสิ่งต่างๆ (การเติมแบบฟอร์มการรับข้อมูล POST จาก jQuery.Validation submitHandlerเป็นต้นเป็น AJAX อย่างเห็นได้ชัด)

การทดสอบเป็นปัญหา ตอนนี้ฉันนิ่งงันพยายามที่จะส่งผ่านข้อมูล JSON เพื่อชั้น :: ทดสอบทดสอบ

ฉันชอบตัวเลือก (3) เป็นวิธีแก้ปัญหา มันใช้ในเว็บไซต์เกือบทุกแห่งที่นายจ้างของฉันเคยมี (ชื่อครัวเรือน) หมายความว่าคุณสามารถรับส่วนหน้าของผู้ที่รู้เกี่ยวกับ Javascript, นิสัยใจคอของเบราว์เซอร์และอะไรที่จะเขียนโค้ดส่วนหน้าของคุณ พวกเขาเพียงแค่ต้องรู้ว่า "curl xyz และคุณจะได้รับ json" และปิดพวกเขาไป

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

ตัวเลือก 3 มอบสถาปัตยกรรมสามชั้นที่ดีและแข็งแกร่ง มันหมายความว่าสิ่งที่คุณถ่มน้ำลายจากเบื้องหน้านั้นเป็นมิตรกับ SEO สามารถทำงานกับเบราว์เซอร์เก่าหรือใหม่ (และผู้ที่ปิด JS) และอาจเป็นเทมเพลตฝั่งไคลเอ็นต์ของ Javascript ถ้าคุณต้องการ ทำสิ่งต่าง ๆ เช่นจัดการเบราว์เซอร์เก่า / googlebot ด้วย HTML แบบคงที่ แต่ส่งประสบการณ์แบบไดนามิกที่ JS สร้างขึ้นให้ผู้ใช้เบราว์เซอร์ Chrome ล่าสุดหรืออะไรก็ตาม)

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

FWIW, $ current_employer สามารถทำกับตัวเลือก 3 ในสถานที่สำคัญสองแห่ง ฉันกำลังมองหากรอบทับทิมที่ดีในการสร้างบางสิ่งบางอย่าง ฉันแน่ใจว่าฉันสามารถรวมอัญมณีจำนวนหนึ่งเข้าด้วยกันได้ แต่ฉันต้องการผลิตภัณฑ์ชิ้นเดียวที่มีเทมเพลต 'การดัดผม' การรับรองความถูกต้องที่เป็นตัวเลือกตัวเลือกการเชื่อมต่อแคชแคช memcache / nosql ที่เป็นตัวเลือก มีฉันล้มเหลวในการค้นหาสิ่งที่สอดคล้องกัน :-(

การสร้าง JSON API ใน Rails เป็นเฟิร์สคลาส, JSONAPI :: Gem gem ช่วยยกระดับหนักสำหรับhttp://jsonapi.org spec'd API