เหตุใดจึงต้องใช้ Django บน Google App Engine

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

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

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

สุดท้ายเป็นที่ชัดเจนว่าการใช้ Django มีประโยชน์ในการให้ "กลยุทธ์การออก" หากเราต้องการย้ายออกจาก GAE ในภายหลังและต้องการแพลตฟอร์มเพื่อกำหนดเป้าหมายสำหรับการอพยพ

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

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

สำหรับการให้บริการ API webobเราสร้างสิ่งที่ง่ายมากที่ด้านบนของ มีน้ำหนักเบากว่ามากเนื่องจากไม่ต้องการทุกสิ่งที่ django นำเสนอดังนั้นจึงเร็วกว่าเล็กน้อยในบางสถานการณ์

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

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

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

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

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

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

นอกจากนี้ยังมีการเปลี่ยนแปลงที่จะเกิดขึ้นกับภาษาข้อความค้นหา GAE ซึ่งจะช่วยให้การสืบค้นที่ซับซ้อนทำได้ง่ายขึ้น ดูวิดีโอจาก Google I / O 2010

นอกจากนี้ยังมีงานที่กำลังดำเนินการในระหว่างโครงการ Summer of Code 2010 ซึ่งควรนำการสนับสนุนแบบ no-sql มาใช้กับ django core และด้วยการขยายทำให้การทำงานกับ GAE ง่ายขึ้นอย่างมาก

GAE น่าสนใจยิ่งขึ้นในฐานะแพลตฟอร์มโฮสติ้ง

แก้ไข (สิงหาคม 2554):

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

น้อยคนนักที่จะมีปัญหา bigdata "สักวันการเริ่มต้นของฉันอาจขยายขนาด" ไม่ใช่ปัญหาข้อมูลขนาดใหญ่ สร้างสิ่งต่างๆตอนนี้และนำมันออกไปจากประตูโดยใช้เครื่องมือมาตรฐาน

ฉันได้ทำโครงการมากมายเกี่ยวกับ GAE บางคนใน django บางคนอยู่ในกรอบปกติ

สำหรับเรื่องเล็ก ๆ ฉันมักจะใช้กรอบการทำงานปกติเพื่อความเรียบง่ายและรวดเร็ว เช่นเดียวกับhttp://stdicon.com , http://yaml-online-parser.appspot.com/หรือhttp://text-twist.appspot.com/

สำหรับเรื่องใหญ่ฉันใช้ django เพื่อใช้ประโยชน์จากมิดเดิลแวร์และปลั๊กอินที่ดีทั้งหมด เช่นเดียวกับhttp://metaward.com

โดยทั่วไปการทดสอบกระดาษลิตมัสของฉันจะใช้เวลามากกว่า 2 สัปดาห์ในการเขียนและเป็นโครงการซอฟต์แวร์จริงหรือไม่? ถ้าเป็นเช่นนั้นไปกับ django สำหรับส่วนเสริม

มีประโยชน์เพิ่มเติมคือถ้าโครงการของคุณไม่เหมาะกับ BigTable คุณก็จะย้ายออกอย่างรวดเร็ว (เช่นฉันทำBigTable ช้าหรือฉันเป็นใบ้? )

ฉันคิดว่าคำตอบทั้งหมดนี้ล้าสมัยไปหน่อย

ตอนนี้คุณสามารถใช้ Google Cloud SQL

Django เป็นเว็บเฟรมเวิร์ก Python ของบุคคลที่สามยอดนิยม เมื่อคู่กับ Google Cloud SQL, ทั้งหมดของการทำงานของมันสามารถอย่างเต็มที่รับการสนับสนุนโดยการประยุกต์ใช้บน App Engine รองรับการใช้ Google Cloud SQL กับ Django โดยแบ็กเอนด์ฐานข้อมูล Django ที่กำหนดเองซึ่งรวมแบ็กเอนด์ MySQL ของ Django

https://cloud.google.com/python/django/appengine

อีกหนึ่งข่าวสดคือมีการรองรับ BETA สำหรับ PostgreSQL

ฉันมีประสบการณ์ในการใช้ Django ไม่ใช่ GAE จากประสบการณ์ของฉันกับ Django มันเป็นการตั้งค่าที่ง่ายมากและขั้นตอนการปรับใช้นั้นง่ายมากในแง่ของโครงการเว็บ จริงอยู่ที่ฉันต้องเรียนรู้ Python เพื่อให้ได้สิ่งต่าง ๆ ที่ดี แต่ในตอนท้ายของวันฉันจะใช้มันอีกครั้งในโครงการ นี่เป็นเวลาเกือบ 2 ปีที่แล้วก่อนที่จะถึง 1.0 ดังนั้นความรู้ของฉันจึงล้าสมัยไปหน่อย

หากคุณกังวลเกี่ยวกับการเปลี่ยนแพลตฟอร์มนี่เป็นทางเลือกที่ดีกว่าที่ฉันคิด

ฉันไม่สามารถตอบคำถามได้ แต่คุณอาจต้องการดูใน web2py มันคล้ายกับ Django ในหลาย ๆ ด้าน แต่เลเยอร์นามธรรมของฐานข้อมูลทำงานบน GAE และรองรับฟังก์ชัน GAE ส่วนใหญ่ (ไม่ใช่ทั้งหมด แต่เราพยายามตาม) ด้วยวิธีนี้หาก GAE ใช้งานได้ดีสำหรับคุณหากไม่เป็นเช่นนั้นคุณสามารถย้ายรหัสของคุณไปยังฐานข้อมูลอื่น (SQLite, MySQL, PostgreSQL, Oracle, MSSQL, FireBird, DB2, Informix, Ingres และ - เร็ว ๆ นี้ - Sybase และ MongoDB ).

หากคุณตัดสินใจที่จะเรียกใช้แอปนอก GAE คุณยังสามารถใช้ Django ได้ คุณจะไม่มีโชคมากนักกับเว็บแอป GAE

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

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