วิธีทำให้แอพพลิเคชั่นไร้สัญชาติ

97

นี่อาจเป็นคำถามที่ซับซ้อน แต่ฉันพยายามเข้าใจความไร้สัญชาติมากขึ้น

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

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

และจากคำถามที่เกี่ยวข้องเว็บไซต์หลัก (Amazon, Google, Facebook, Twitter และอื่น ๆ ) ไร้สัญชาติจริงๆหรือ? พวกเขาใช้โทเค็นหรือคุกกี้ (หรือทั้งสองอย่าง)?

web-applications state

38

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

— Mark Rogers

4

@ MarkRogers ทำไม การไร้สัญชาตินั้นไม่เกี่ยวกับความสามารถในการนำกลับมาใช้ใหม่ และการเป็นคนไร้สัญชาตินั้นไม่ได้นำไปสู่ความพยายามที่สูงขึ้น

— Paul Wasilewski

3

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

— Matthieu M.

6

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

— njzk2

20

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

— ปราณี

95

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

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

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

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

เว็บไซต์หลัก (Amazon, Google, Facebook, Twitter และอื่น ๆ ) ไร้สัญชาติจริงๆหรือ พวกเขาใช้โทเค็นหรือคุกกี้ (หรือทั้งสองอย่าง)?

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

— ฟิลิปป์
แหล่งที่มา

46

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

— Derek Elkins

16

"[... ] แต่จากนั้นคุณจะมีสถานะอีกครั้งเพียงแค่ไคลเอนต์แทนบนเซิร์ฟเวอร์" มันเกี่ยวกับการไม่มีสถานะทางฝั่งเซิร์ฟเวอร์เพื่อให้เกิดความยืดหยุ่นและความพร้อมใช้งานที่ดีขึ้น หากสถานะถูกเก็บไว้ในฝั่งไคลเอ็นต์ไม่สำคัญ

— Paul Wasilewski

5

@ njzk2 คุณสามารถทำอย่างละเอียดเพื่อที่จะไม่ฟังดูไร้สาระ? ผู้ใช้ไม่ไปที่ Amazon เพื่อซื้อชื่อเพิ่มเติม และหลังจากที่พวกเขาทำการสั่งซื้อบางสิ่งจะหายไปซึ่งมีอยู่ในขณะที่พวกเขากำลังช็อปปิ้ง หากสิ่งนั้นไม่ใช่ "สถานะของแอปพลิเคชัน" แสดงว่าเป็นอย่างไร หากแอปพลิเคชันไม่มีสถานะพวกเขามีอะไรบ้าง

3

@nocomprende: ฉันคิดว่าแก่นสารทั่วไปของ njzk2 คือเนื้อหาในรถเข็นของคุณเช่นชื่อเต็มของคุณคือข้อมูลที่ webapp ยังคงอยู่ในฝั่งเซิร์ฟเวอร์ เมื่อมีคนพูดว่า "webapps ควรไร้สัญชาติ" พวกเขามักจะหมายถึงบางสิ่งที่แตกต่างจาก "webapps ไม่ควรเข้าถึงฐานข้อมูลที่มีชื่อเต็มของคุณซึ่งเชื่อมโยงกับชื่อผู้ใช้ของคุณ" สิ่งที่พวกเขาทำอย่างถูกต้องโดย "ไร้สัญชาติ" อาจไม่ได้นิยามไว้เล็กน้อยเนื่องจากเมื่อคุณมีฐานข้อมูลนั้นมีเรื่องไร้สาระทุกประเภทที่คุณสามารถคงอยู่ในนั้นเพื่อสนับสนุนสถานะแอพที่ซับซ้อนเกินไป แต่ไม่ควร ;-)

— Steve Jessop

4

@nocomprende: ถอดรหัสไข่โดยการรีดกลับฐานข้อมูลนี้: ตั้งแต่ webapp ของเราคือการไร้สัญชาติก็สามารถกลับมาเป็นก่อน ;-)

— สตีฟเจสซอพ

56

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

นี่คือรูปแบบที่เรียบง่าย:

Web Browser (has state) <-> Web Server (stateless) <-> Database (has state)

ซึ่งอาจทำงานสำหรับวิศวกรรมซอฟต์แวร์ Stack แลกเปลี่ยน คำตอบที่ฉันพิมพ์นี้เป็นส่วนหนึ่งของสถานะเว็บเบราว์เซอร์ของฉัน ตราบใดที่มันเป็นที่เดียวที่ฉันไม่สามารถเข้าถึงใครได้นอกจากฉัน แต่ทันทีที่ฉันกดPost your Answerเบราว์เซอร์จะส่งไปยังเว็บเซิร์ฟเวอร์ เว็บเซิร์ฟเวอร์ประมวลผลโพสต์โดยไม่มีสถานะเป็นของตนเอง มันเรียนรู้ว่าฉันเป็นใครจากเบราว์เซอร์ของฉันและจากฐานข้อมูล เมื่อตรวจสอบโพสต์ของฉันเสร็จแล้วและเพิ่มลงในฐานข้อมูลเว็บเซิร์ฟเวอร์จะลืมฉันทันที

นั่นคือสิ่งที่ไร้สัญชาติหมายถึง เซิร์ฟเวอร์จะไม่รับผิดชอบในการจดจำสิ่งนี้ นั่นไม่ใช่งานของมัน

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

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

— candied_orange
แหล่งที่มา

8

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

7

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

— Derek Elkins

9

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

— Matthieu M.

6

"เป็นเรื่องจริงที่เว็บแอปพลิเคชั่นควรไร้สัญชาติ" ไม่นี่เป็นเรื่องไร้สาระที่สมบูรณ์

— svidgen

4

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

— Kat

30

เว็บแอปพลิเคชันควรไร้สัญชาติ

เรื่องไร้สาระ คำขอของเว็บควรไร้สัญชาติ หรืออย่างถูกต้องมากขึ้นคำขอของเว็บนั้นไร้สัญชาติ

แต่การบอกว่าการสมัครทั้งหมดควรไร้สัญชาตินั้นไร้สาระสมบูรณ์

คำขอแต่ละครั้งจะถือเป็นธุรกรรมที่เป็นอิสระ

ใช่ว่า หรือถูกต้องมากขึ้นใช่จำเป็น ผ่าน HTTP แต่ละคำร้องขอไม่ขึ้นอยู่กับคำร้องขออื่นทั้งหมด การเพิ่ม "statefulness" ลงใน HTTP ต้องให้คุณระบุจัดเก็บและดึงข้อมูล "state" สำหรับแต่ละคำขอ "stateful" อย่างชัดเจน และนั่นต้องใช้ความพยายามลดประสิทธิภาพและเพิ่มความซับซ้อน

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

ดังนั้นควรหลีกเลี่ยงเซสชันและคุกกี้ (เนื่องจากทั้งคู่มีสถานะเป็นของรัฐ) วิธีที่ดีกว่าคือใช้โทเค็น

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

นั่นหมายความว่าอย่างน้อยบางครั้งเซสชันและคุกกี้ก็เหมือนกับ "ดีกว่า" เหมือนกับโทเค็น!

[โทเค็น] ไร้สัญชาติเนื่องจากไม่มีสิ่งใดถูกเก็บไว้บนเซิร์ฟเวอร์

ก็แค่นั้นแหละ นั่นคือสิ่งที่เป็น "ความไร้สัญชาติ" ความเชื่อเป็นจริงเกี่ยวกับ แม้ว่าจะชัดเจนแล้วมันไม่เกี่ยวกับการจัดเก็บ "ไม่มีอะไร" บนเซิร์ฟเวอร์ แต่เกี่ยวกับการไม่เก็บสถานะเซสชันไว้บนเซิร์ฟเวอร์

ตัวอย่างกล่องจดหมาย Gmail ของฉันอยู่ในสถานะใช้งาน และมันน่ากลัวดีกว่าจะถูกเก็บไว้บนเซิร์ฟเวอร์! แต่ไม่ใช่สถานะเซสชัน

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

ทีนี้ถ้าสถานะนั้นมีขนาดเล็กอาจเป็นไปได้ ในบางกรณีมันดีมาก

และแน่นอนว่ามีบางสิ่งที่เราคาดหวังว่าจะเป็นของรัฐ ...

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

สองตัวเลือก ไม่ว่าคุณจะมีเซสชันหรือไม่ก็ปฏิเสธ!

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

สำหรับการใช้งานจริงอย่างจริงจัง: มีระดับใหญ่ที่ "statefulness" เป็นเพียงสิ่งที่เราเรียกว่าเมื่อตัวแทนการสื่อสารสองคนสามารถบริบทข้อความในการสนทนา และเซสชั่นตามธรรมเนียมเข้าใจเป็นเพียงสิ่งที่เรามักจะเรียกกลไกที่เกิดขึ้น

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

และจากคำถามที่เกี่ยวข้องเว็บไซต์หลัก (Amazon, Google, Facebook, Twitter และอื่น ๆ ) ไร้สัญชาติจริงๆหรือ? พวกเขาใช้โทเค็นหรือคุกกี้ (หรือทั้งสองอย่าง)?

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

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

— svidgen
แหล่งที่มา

3

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

@nocomprende FYI ฉันจะทำภาคผนวกในภายหลัง ฉันรู้สึกเหมือนว่าคำตอบของฉันไม่มีอยู่ในคำถามพื้นฐานของ OP เพราะมีเป็นความกังวลที่ legit ลอยอยู่เบื้องหลัง "โปรแกรมไร้สัญชาติ" ความคิด แต่คำตอบนั้นเป็นไปตามนั้นเมื่อผู้คนพูดว่า 'ไร้รัฐ' สิ่งที่พวกเขาหมายถึงคือ 'อาศัยช่วงเซิร์ฟเวอร์ฝั่งน้อยที่สุด'

— svidgen

4

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

— whatsisname

1

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

1

@nocomprende นี่คือการสนทนาที่น่าสนใจ แต่ฉันคิดว่าเราไม่ควรดำเนินการต่อที่นี่

— pabrams

14

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

การเป็นไร้สัญชาติ

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

สถานะบนเซิร์ฟเวอร์

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

สถานะบนไคลเอนต์

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

โทเค็น v. คุกกี้

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

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

แอปหน้าเดียวและสถานะลูกค้า

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

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

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

ตะกร้าสินค้าและไม่ชอบ

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

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

ขออภัยถ้าคำตอบนี้เบลอนิด ๆ หน่อย ๆ แต่ statefulness เป็นเรื่องที่ซับซ้อน

— โรเบิร์ตมันน์
แหล่งที่มา

6

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

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

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

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

— โคลอี้
แหล่งที่มา

5

โปรโตคอลเป็นไร้สัญชาติ

แต่จากนั้นไม่จำเป็นต้องติดตามแอปพลิเคชันที่ใช้โปรโตคอลควรเป็นแบบไร้รัฐ

StackOverflow ที่เกี่ยวข้องมีสองสามคำตอบที่อธิบายความแตกต่างได้ดี:

— sideshowbarker
แหล่งที่มา

5

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

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

วิธีที่ดีกว่าคือใช้โทเค็นซึ่งไร้สัญชาติเพราะไม่มีสิ่งใดถูกเก็บไว้บนเซิร์ฟเวอร์

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

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

เกี่ยวกับตัวอย่างตะกร้าสินค้า ไม่มีปัญหาในการจัดเก็บรายการรถเข็นทั้งหมดในฝั่งไคลเอ็นต์โดยไม่ต้องใช้เซสชันหรือคุกกี้ คุณสามารถหาตัวอย่างในsmashingmagazine.com แต่ก็เป็นไปได้ที่จะตระหนักถึงตะกร้าสินค้าไร้สัญชาติที่มีคุกกี้ (อย่างน้อยถ้าการจัดประเภทของคุณไม่ใหญ่มากและพื้นที่เก็บข้อมูลขนาด 4kb ก็เพียงพอสำหรับคุณแล้ว)

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

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

และจากคำถามที่เกี่ยวข้องเว็บไซต์หลัก (Amazon, Google, Facebook, Twitter และอื่น ๆ ) ไร้สัญชาติจริงๆหรือ? พวกเขาใช้โทเค็นหรือคุกกี้ (หรือทั้งสองอย่าง)?

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

— Paul Wasilewski
แหล่งที่มา

-2

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

เจตนาของกฎคือ "ไม่ถือฝั่งเซิร์ฟเวอร์สถานะต่อเซสชัน"

เช่นตัวแปรเซสชั่นในASPซึ่งมักใช้ทำสิ่งต่าง ๆ เช่นรายการในตะกร้า / ชื่อผู้ใช้ ฯลฯ

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

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

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

— Ewan
แหล่งที่มา

2

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

— Derek Elkins

อืม หากคุณมีข้อมูลผู้ใช้ต่อเซิร์ฟเวอร์แม้ว่าการเผยแพร่ของคุณจะยังคงมีปัญหาเรื่องความยืดหยุ่น

— Ewan

มีมากมายที่คุณสามารถทำได้ถ้าการดึงข้อมูลจากดิสก์เป็นคอขวดเช่นการแคช

— JeffO

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

— Ewan

1

การอภิปรายทั้งหมดเกี่ยวกับการพยายามหลีกเลี่ยงมันฝรั่งร้อนนี้ทำให้ฉันประหลาดใจจริงๆ ไม่ว่าอะไรจะเกิดขึ้นกับคำพูดเก่า ๆ "เจ้าชู้หยุดอยู่ที่นี่"? มีบางอย่างที่ต้องจัดการข้อมูลธนาคารของฉันไม่ต้องการให้ฉันเก็บข้อมูลธุรกรรมทางการเงินทั้งหมดไว้ในแล็ปท็อปของฉันเท่านั้น ทำไมทุกคนวิ่งหนีกรีดร้องจากข้อมูล? นี่คือเหตุผลที่เรามีคอมพิวเตอร์! บ้า.