ฉันมีแอปพลิเคชันที่ฟังก์ชันหลักทำงานแบบเรียลไทม์ผ่านเว็บซ็อกเก็ตหรือการสำรวจความคิดเห็นแบบยาว
อย่างไรก็ตามเว็บไซต์ส่วนใหญ่เขียนในแนว RESTful ซึ่งเหมาะสำหรับแอปพลิเคชันและลูกค้ารายอื่น ๆ ในอนาคต อย่างไรก็ตามฉันกำลังคิดเกี่ยวกับการเปลี่ยนไปใช้ websocket API สำหรับฟังก์ชันไซต์ทั้งหมดโดยห่างจาก REST นั่นจะทำให้ง่ายขึ้นสำหรับฉันในการรวมคุณสมบัติเรียลไทม์เข้ากับทุกส่วนของไซต์ สิ่งนี้จะทำให้การสร้างแอปพลิเคชันหรือไคลเอนต์มือถือยากขึ้นหรือไม่?
ฉันพบว่าบางคนกำลังทำสิ่งนี้อยู่แล้ว: SocketStream
คำตอบ:
ไม่ต้องบอกว่าคำตอบอื่น ๆ ที่นี่ไม่ได้มีประโยชน์พวกเขาให้บางจุดที่ดี แต่ฉันจะต่อต้านฉันทามติทั่วไปและเห็นด้วยกับคุณว่าการย้ายไปยัง websockets เพื่อให้ได้มากกว่าคุณสมบัติเรียลไทม์นั้นน่าสนใจมาก
ฉันกำลังพิจารณาอย่างจริงจังในการย้ายแอปของฉันจากสถาปัตยกรรม RESTful ไปเป็นสไตล์ RPC เพิ่มเติมผ่าน websockets นี่ไม่ใช่ "แอปของเล่น" และฉันไม่ได้พูดถึงฟีเจอร์เรียลไทม์เท่านั้นดังนั้นฉันจึงต้องจอง แต่ฉันเห็นประโยชน์มากมายในการไปเส้นทางนี้และรู้สึกว่ามันอาจจะเป็นทางออกที่ยอดเยี่ยม
แผนของฉันคือการใช้DNode , SocketIOและกระดูกสันหลัง ด้วยเครื่องมือเหล่านี้โมเดลและคอลเลกชัน Backbone ของฉันสามารถส่งต่อจาก / ไปยังไคลเอนต์และเซิร์ฟเวอร์ได้โดยเพียงแค่เรียกฟังก์ชันแบบ RPC ไม่มีการจัดการปลายทาง REST อีกต่อไปการทำให้เป็นอนุกรม / การกำหนดค่าซีเรียลออบเจ็กต์และอื่น ๆ อีกต่อไป ฉันยังไม่ได้ทำงานกับซ็อกเก็ตสตรีม แต่มันก็คุ้มค่าที่จะลองดู
ฉันยังมีหนทางอีกไกลก่อนที่จะพูดได้อย่างชัดเจนว่านี่เป็นวิธีแก้ปัญหาที่ดีและฉันแน่ใจว่ามันไม่ใช่ทางออกที่ดีที่สุดสำหรับทุกแอปพลิเคชัน แต่ฉันเชื่อว่าชุดค่าผสมนี้จะมีประสิทธิภาพมาก ฉันยอมรับว่ามีข้อบกพร่องบางประการเช่นการสูญเสียความสามารถในการแคชทรัพยากร แต่ฉันรู้สึกว่าข้อดีจะมีมากกว่าพวกเขา
ฉันสนใจที่จะติดตามความคืบหน้าของคุณในการสำรวจโซลูชันประเภทนี้ หากคุณมีการทดลอง github โปรดชี้ให้ฉันทราบ ฉันยังไม่มี แต่หวังว่าจะเร็ว ๆ นี้
ด้านล่างนี้คือรายการลิงก์เพื่ออ่านภายหลังที่ฉันรวบรวมไว้ ฉันไม่สามารถรับรองได้ว่าพวกเขาทั้งหมดคุ้มค่าเพราะฉันได้อ่านหลายอย่างเท่านั้น แต่หวังว่าบางส่วนจะช่วยได้
บทช่วยสอนที่ยอดเยี่ยมเกี่ยวกับการใช้ Socket.IO กับ Express มันแสดงเซสชันด่วนไปยัง socket.io และกล่าวถึงวิธีการมีห้องต่างๆสำหรับผู้ใช้ที่ได้รับการพิสูจน์ตัวตนแต่ละคน
บทช่วยสอนเกี่ยวกับ node.js / socket.io / backbone.js / express / connect / jade / redis พร้อมการรับรองความถูกต้อง Joyent hosting ฯลฯ :
สอนการใช้ Pusher กับ Backbone.js (โดยใช้ Rails):
สร้างแอปพลิเคชันด้วย backbone.js บนไคลเอนต์และ node.js ด้วย express, socket.io, dnode บนเซิร์ฟเวอร์
การใช้ Backbone กับ DNode:
HTTP REST และ WebSockets แตกต่างกันมาก HTTP ไม่มีสถานะดังนั้นเว็บเซิร์ฟเวอร์จึงไม่จำเป็นต้องรู้อะไรเลยและคุณจะได้รับแคชในเว็บเบราว์เซอร์และในพร็อกซี หากคุณใช้ WebSockets เซิร์ฟเวอร์ของคุณกำลังกลายเป็นสถานะและคุณต้องมีการเชื่อมต่อกับไคลเอนต์บนเซิร์ฟเวอร์
ใช้ WebSockets เฉพาะเมื่อคุณต้องการPUSHข้อมูลจากเซิร์ฟเวอร์ไปยังไคลเอนต์รูปแบบการสื่อสารนั้นจะไม่รวมอยู่ใน HTTP (โดยวิธีแก้ปัญหาเท่านั้น) PUSH มีประโยชน์หากเหตุการณ์ที่สร้างโดยไคลเอนต์อื่นจำเป็นต้องพร้อมใช้งานสำหรับไคลเอนต์ที่เชื่อมต่ออื่น ๆ เช่นในเกมที่ผู้ใช้ควรดำเนินการกับพฤติกรรมของลูกค้ารายอื่น หรือหากเว็บไซต์ของคุณกำลังตรวจสอบบางสิ่งบางอย่างที่เซิร์ฟเวอร์ส่งข้อมูลไปยังลูกค้าตลอดเวลาเช่นตลาดหุ้น (สด)
หากคุณไม่ต้องการ PUSH ข้อมูลจากเซิร์ฟเวอร์โดยปกติแล้วการใช้เซิร์ฟเวอร์ HTTP REST แบบไม่ระบุสถานะจะง่ายกว่า HTTP ใช้รูปแบบการสื่อสารแบบคำขอตอบกลับอย่างง่าย
ฉันกำลังคิดเกี่ยวกับการเปลี่ยนไปใช้ WebSocket api สำหรับฟังก์ชันไซต์ทั้งหมด
ไม่คุณไม่ควรทำ ไม่มีอันตรายใด ๆ หากคุณรองรับทั้งสองรุ่น ใช้RESTสำหรับการสื่อสารทางเดียว / คำขอแบบง่ายและWebSocketสำหรับการสื่อสารสองทางโดยเฉพาะเมื่อเซิร์ฟเวอร์ต้องการส่งการแจ้งเตือนแบบเรียลไทม์
WebSocketเป็นโปรโตคอลที่มีประสิทธิภาพมากกว่าRESTful HTTPแต่ยังคงให้คะแนนRESTful HTTPมากกว่า WebSocket ในพื้นที่ด้านล่าง
สร้าง / อัปเดต / ลบทรัพยากรได้รับการกำหนดอย่างดีสำหรับ HTTP คุณต้องใช้การดำเนินการเหล่านี้ในระดับต่ำสำหรับ WebSockets
การเชื่อมต่อ WebSocket จะปรับขนาดในแนวตั้งบนเซิร์ฟเวอร์เดียวโดยที่การเชื่อมต่อ HTTP ปรับขนาดในแนวนอน มีโซลูชันที่ไม่เป็นไปตามมาตรฐานที่เป็นกรรมสิทธิ์สำหรับการปรับขนาดแนวนอนของ WebSocket
HTTP มาพร้อมกับคุณสมบัติที่ดีมากมายเช่นการแคชการกำหนดเส้นทางการมัลติเพล็กซ์การบีบอัดและอื่น ๆ สิ่งเหล่านี้ต้องสร้างขึ้นบน Websocket หากคุณเลือก Websocket
การเพิ่มประสิทธิภาพของเครื่องมือค้นหาทำงานได้ดีสำหรับ HTTP URL
พร็อกซี DNS ไฟร์วอลล์ทั้งหมดยังไม่ทราบถึงปริมาณการใช้งาน WebSocket อนุญาตให้ใช้พอร์ต 80 แต่อาจ จำกัด การรับส่งข้อมูลโดยการสอดแนมก่อน
การรักษาความปลอดภัยด้วย WebSocket เป็นวิธีการทั้งหมดหรือไม่มีเลย
ดูบทความนี้เพื่อดูรายละเอียดเพิ่มเติม
ปัญหาเดียวที่ฉันสามารถใช้ TCP (WebSockets) เป็นกลยุทธ์การจัดส่งเนื้อหาเว็บหลักของคุณคือมีข้อมูลการอ่านน้อยมากเกี่ยวกับวิธีการออกแบบสถาปัตยกรรมเว็บไซต์และโครงสร้างพื้นฐานโดยใช้ TCP
คุณจึงไม่สามารถเรียนรู้จากความผิดพลาดของคนอื่นได้และพัฒนาการจะช้าลง นอกจากนี้ยังไม่ใช่กลยุทธ์ "ทดลองและทดสอบ"
แน่นอนว่าคุณจะสูญเสียข้อดีทั้งหมดของ HTTP ไปด้วย (การไร้สัญชาติและการแคชเป็นข้อดีที่ใหญ่กว่า)
โปรดจำไว้ว่า HTTP เป็นนามธรรมสำหรับ TCP ที่ออกแบบมาเพื่อให้บริการเนื้อหาเว็บ
และอย่าลืมว่า SEO และเครื่องมือค้นหาไม่ได้ทำเว็บซ็อกเก็ต ดังนั้นคุณสามารถลืมเกี่ยวกับ SEO ไปได้เลย
โดยส่วนตัวแล้วฉันอยากจะแนะนำให้ต่อต้านสิ่งนี้เนื่องจากมีความเสี่ยงมากเกินไป
อย่าใช้ WS ในการให้บริการเว็บไซต์ใช้เพื่อให้บริการเว็บแอปพลิเคชัน
อย่างไรก็ตามหากคุณมีของเล่นหรือเว็บไซต์ส่วนตัวก็ไปหามัน ลองมันล้ำสมัย สำหรับธุรกิจหรือ บริษัท คุณไม่สามารถระบุความเสี่ยงในการทำเช่นนี้ได้
ฉันได้เรียนรู้บทเรียนเล็กน้อย (วิธีที่ยาก) ฉันสร้างแอพพลิเคชั่นที่ทำงานบนคลาวด์ Ubuntu AWS EC2 (ใช้ GPU ที่ทรงพลัง) และฉันต้องการสร้างส่วนหน้าเพื่อดูความคืบหน้าในแบบเรียลไทม์ เนื่องจากต้องการข้อมูลแบบเรียลไทม์จึงเห็นได้ชัดว่าฉันต้องการเว็บซ็อกเก็ตเพื่อผลักดันการอัปเดต
เริ่มต้นด้วยการพิสูจน์แนวคิดและใช้งานได้ดี แต่แล้วเมื่อเราต้องการเปิดให้ใช้งานต่อสาธารณะเราต้องเพิ่มเซสชันผู้ใช้ดังนั้นเราจึงต้องการคุณสมบัติการเข้าสู่ระบบ และไม่ว่าวิธีที่คุณมองไปที่มันไม่มี WebSocket มีที่จะทราบว่าผู้ใช้มันเกี่ยวข้องกับดังนั้นเราเอาทางลัดของการใช้ WebSockets ในการตรวจสอบผู้ใช้ เห็นได้ชัดและสะดวก
จริงๆแล้วเราต้องใช้เวลาเงียบ ๆ เพื่อให้การเชื่อมต่อเชื่อถือได้ เราเริ่มต้นด้วยบทช่วยสอน websocket ราคาถูก แต่พบว่าการใช้งานของเราไม่สามารถเชื่อมต่อใหม่โดยอัตโนมัติเมื่อการเชื่อมต่อขาด ทั้งหมดนี้ดีขึ้นเมื่อเราเปลี่ยนมาใช้ socket-io Socket-io เป็นสิ่งที่ต้องทำ!
พูดตามตรงฉันคิดว่าเราพลาดคุณสมบัติที่ยอดเยี่ยมของ socket-io ไป Socket-io มีข้อเสนออีกมากมายและฉันมั่นใจว่าถ้าคุณคำนึงถึงมันในการออกแบบครั้งแรกคุณจะได้รับประโยชน์มากขึ้น ในทางตรงกันข้ามเราเพิ่งเปลี่ยน websockets เก่าด้วยฟังก์ชัน websocket ของ socket-io และนั่นก็คือมัน (ไม่มีห้องไม่มีช่อง ... ) การออกแบบใหม่อาจทำให้ทุกอย่างมีประสิทธิภาพมากขึ้น แต่เราไม่มีเวลาสำหรับเรื่องนั้น นั่นคือสิ่งที่ต้องจำสำหรับโครงการต่อไปของเรา
ต่อไปเราเริ่มจัดเก็บข้อมูลมากขึ้นเรื่อย ๆ (ประวัติผู้ใช้ใบแจ้งหนี้ธุรกรรม ... ) เราเก็บข้อมูลทั้งหมดไว้ในฐานข้อมูล AWS dynamodb และอีกครั้งเราใช้ socket-io เพื่อสื่อสารการทำงานของ CRUD จากส่วนหน้าไปยังแบ็กเอนด์ ฉันคิดว่าเราเลี้ยวผิดที่นั่น มันเป็นความผิดพลาด.
ต้องบอกว่าทั้งหมดเราจะถ่ายทอดสดในสัปดาห์หน้า เราไปถึงทันเวลาทุกอย่างทำงานได้ และเร็ว แต่จะปรับขนาดได้หรือไม่?
ฉันจะพิจารณาใช้ทั้งสองอย่าง เทคโนโลยีแต่ละอย่างมีข้อดีและไม่มีขนาดเดียวที่เหมาะกับโซลูชันทั้งหมด
การแยกงานออกไปในลักษณะนี้:
WebSocketsเป็นวิธีการหลักของแอปพลิเคชันในการสื่อสารกับเซิร์ฟเวอร์ที่จำเป็นต้องมีเซสชัน ซึ่งจะช่วยกำจัดการแฮ็กจำนวนมากที่จำเป็นสำหรับเบราว์เซอร์รุ่นเก่า (ปัญหาคือการรองรับเบราว์เซอร์รุ่นเก่าซึ่งจะกำจัดสิ่งนี้)
RESTful APIใช้สำหรับการเรียก GET ที่ไม่เน้นเซสชัน (เช่นไม่จำเป็นต้องมีการตรวจสอบสิทธิ์) ที่ได้รับประโยชน์จากการแคชเบราว์เซอร์ ตัวอย่างที่ดีคือข้อมูลอ้างอิงสำหรับรายการแบบเลื่อนลงที่ใช้โดยเว็บแอปพลิเคชัน อย่างไรก็ตาม สามารถเปลี่ยนแปลงได้บ่อยกว่า ...
HTML และ Javascript สิ่งเหล่านี้ประกอบด้วย UI ของเว็บแอป โดยทั่วไปสิ่งเหล่านี้จะเป็นประโยชน์ต่อการวาง CDN
บริการเว็บที่ใช้WSDLยังคงเป็นวิธีที่ดีที่สุดในระดับองค์กรและการสื่อสารข้ามองค์กรเนื่องจากเป็นมาตรฐานที่กำหนดไว้อย่างดีสำหรับการส่งข้อความและข้อมูล โดยพื้นฐานแล้วคุณจะถ่ายโอนสิ่งนี้ไปยังอุปกรณ์ Datapower เพื่อพร็อกซีไปยังตัวจัดการบริการเว็บของคุณ
ทั้งหมดนี้เกิดขึ้นบนโปรโตคอล HTTP ซึ่งให้ใช้ซ็อกเก็ตที่ปลอดภัยผ่าน SSL อยู่แล้ว
สำหรับแอปพลิเคชันมือถือ websockets ไม่สามารถเชื่อมต่อกลับไปยังเซสชันที่ถูกตัดการเชื่อมต่ออีกครั้ง ( วิธีเชื่อมต่อกับ websocket ใหม่หลังจากการเชื่อมต่อปิด ) และการจัดการที่ไม่สำคัญ ดังนั้นสำหรับแอปบนอุปกรณ์เคลื่อนที่ฉันยังคงแนะนำ REST APIและการสำรวจ
อีกสิ่งหนึ่งที่ต้องระวังเมื่อใช้ WebSockets เทียบกับส่วนที่เหลือคือความยืดหยุ่น เซสชัน WebSocket ยังคงถูกจัดการโดยเซิร์ฟเวอร์ สงบ API เมื่อทำอย่างถูกต้องไร้สัญชาติ (ซึ่งหมายถึงไม่มีสถานะของเซิร์ฟเวอร์ที่ต้องมีการจัดการ) ดังนั้นความยืดหยุ่นสามารถเจริญเติบโตในแนวนอน (ซึ่งมีราคาถูกกว่า) ในแนวตั้ง
ฉันต้องการอัพเดตจากเซิร์ฟเวอร์หรือไม่?
ข้อเสียของ Socket.io คือ:
ฉันจะยังคงใช้ Socket.io ในโปรเจ็กต์ของฉัน แต่ไม่ใช่สำหรับเว็บฟอร์มพื้นฐานที่ REST จะทำอย่างดี
WebSockets (หรือ long polling) การขนส่งตามส่วนใหญ่ให้บริการสำหรับการสื่อสารแบบเรียลไทม์ (ใกล้) แบบเรียลไทม์ระหว่างเซิร์ฟเวอร์และไคลเอนต์ แม้ว่าจะมีหลายสถานการณ์ที่จำเป็นต้องใช้การขนส่งประเภทนี้เช่นการแชทหรือฟีดแบบเรียลไทม์หรือสิ่งอื่น ๆ แต่บางส่วนของเว็บแอปพลิเคชันไม่จำเป็นต้องเชื่อมต่อแบบสองทิศทางกับเซิร์ฟเวอร์
REST เป็นสถาปัตยกรรมที่ใช้ทรัพยากรซึ่งเป็นที่เข้าใจกันดีและให้ประโยชน์แก่ตนเองมากกว่าสถาปัตยกรรมอื่น ๆ WebSockets มีแนวโน้มที่จะสตรีม / ฟีดข้อมูลแบบเรียลไทม์มากขึ้นซึ่งคุณจะต้องสร้างลอจิกตามเซิร์ฟเวอร์เพื่อจัดลำดับความสำคัญหรือแยกความแตกต่างระหว่างทรัพยากรและฟีด (ในกรณีที่คุณไม่ต้องการใช้ REST)
ฉันคิดว่าในที่สุดจะมีเฟรมเวิร์กที่เป็นศูนย์กลางของ WebSockets มากขึ้นเช่นซ็อกเก็ตสตรีมในอนาคตเมื่อการขนส่งนี้จะแพร่หลายมากขึ้นและเข้าใจได้ดีขึ้น / จัดทำเป็นเอกสารในรูปแบบของการจัดส่งแบบไม่เชื่อเรื่องพระเจ้าชนิดข้อมูล / แบบฟอร์ม อย่างไรก็ตามฉันคิดว่านี่ไม่ได้หมายความว่าจะ / ควรแทนที่ REST เพียงเพราะมีฟังก์ชันการทำงานที่ไม่จำเป็นต้องใช้ในกรณีการใช้งานและสถานการณ์จำนวนมาก
ฉันต้องการชี้ให้เห็นว่าบล็อกโพสต์นี้เป็นคำตอบที่ดีที่สุดสำหรับคำถามนี้
ในระยะสั้นใช่
โพสต์มีแนวทางปฏิบัติที่ดีที่สุดทั้งหมดสำหรับ API ประเภทดังกล่าว
นั่นไม่ใช่ความคิดที่ดี มาตรฐานยังไม่ได้รับการสรุปการสนับสนุนจะแตกต่างกันไปในแต่ละเบราว์เซอร์ ฯลฯ หากคุณต้องการดำเนินการในตอนนี้คุณจะต้องใช้ทางเลือกอื่นเพื่อใช้แฟลชหรือโพลแบบยาวเป็นต้นในอนาคตอาจจะยังไม่ได้ มีความหมายมากเนื่องจากเซิร์ฟเวอร์ต้องรองรับการเปิดการเชื่อมต่อให้กับผู้ใช้ทุกคน เว็บเซิร์ฟเวอร์ส่วนใหญ่ได้รับการออกแบบมาเพื่อให้ตอบสนองต่อคำขอได้อย่างรวดเร็วและปิดโดยเร็วที่สุด Heck แม้แต่ระบบปฏิบัติการของคุณก็ต้องได้รับการปรับแต่งเพื่อจัดการกับการเชื่อมต่อพร้อมกันจำนวนมาก (การเชื่อมต่อแต่ละครั้งใช้พอร์ตและหน่วยความจำชั่วคราวมากขึ้น) ยึดติดกับการใช้ REST สำหรับไซต์ให้มากที่สุดเท่าที่จะทำได้