Flask vs webapp2 สำหรับ Google App Engine

ฉันเริ่มที่แอพลิเคชันใหม่ของ Google App Engine และกำลังพิจารณาสองกรอบ: ขวดและwebapp2 ฉันค่อนข้างพอใจกับเฟรมเวิร์ก webapp ในตัวที่ฉันเคยใช้กับแอปพลิเคชัน App Engine ก่อนหน้านี้ดังนั้นฉันคิดว่า webapp2 จะดียิ่งขึ้นและฉันจะไม่มีปัญหากับมัน

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

คำถามคือ - คุณทราบปัญหาใด ๆ ปัญหาด้านประสิทธิภาพข้อ จำกัด (เช่นระบบการกำหนดเส้นทางกลไกการอนุญาตในตัว ฯลฯ ) ที่ Flask สามารถนำเข้าสู่แอปพลิเคชัน Google App Engine ได้หรือไม่ โดย "ปัญหา" ฉันหมายถึงสิ่งที่ฉันไม่สามารถแก้ไขได้ในหลายบรรทัดของโค้ด (หรือโค้ดและความพยายามในจำนวนที่สมเหตุสมผล) หรือสิ่งที่เป็นไปไม่ได้เลย

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

Disclaimer:ฉันเป็นผู้เขียน tipfy และ webapp2

ข้อได้เปรียบอย่างมากของการใช้ webapp (หรือวิวัฒนาการตามธรรมชาติ webapp2) คือคุณไม่จำเป็นต้องสร้างเวอร์ชันของคุณเองสำหรับตัวจัดการ SDK ที่มีอยู่สำหรับกรอบงานที่คุณเลือก

ตัวอย่างเช่นการเลื่อนเวลาใช้ตัวจัดการเว็บแอป ในการใช้งานในมุมมองขวดที่บริสุทธิ์โดยใช้ werkzeug.Request และ werkzeug การตอบสนองคุณจะต้องดำเนินการรอการตัดบัญชี (เช่นที่ฉันทำที่นี่เพื่อ tipfy)

สิ่งเดียวกันนี้เกิดขึ้นกับตัวจัดการอื่น ๆ : blobstore (Werkzeug ยังไม่รองรับคำขอช่วงดังนั้นคุณจะต้องใช้ WebOb แม้ว่าคุณจะสร้างตัวจัดการของคุณเองก็ตาม - ดูtipfy.appengine.blobstore ), เมล, XMPP และอื่น ๆ หรืออื่น ๆ ที่รวมอยู่ใน SDK ในอนาคต

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

ดังนั้นแม้ว่าคุณจะเลือกเฟรมเวิร์กที่แตกต่างกันคุณจะต้อง a) การใช้ webapp ในกรณีพิเศษบางอย่างหรือ b) ต้องสร้างและดูแลเวอร์ชันของคุณสำหรับตัวจัดการ SDK หรือคุณสมบัติเฉพาะหากคุณจะใช้

ฉันชอบ Werkzeug มากกว่า WebOb แต่หลังจากผ่านไปกว่าหนึ่งปีในการย้ายและบำรุงรักษาเวอร์ชันของตัวจัดการ SDK ที่ทำงานได้ดีโดยกำเนิดฉันตระหนักว่านี่เป็นสาเหตุที่หายไป - เพื่อรองรับ GAE ในระยะยาวที่ดีที่สุดคืออยู่ใกล้ ๆ webapp / WebOb ช่วยให้การสนับสนุนไลบรารี SDK เป็นเรื่องง่ายการบำรุงรักษาง่ายขึ้นมากเป็นการพิสูจน์อนาคตมากขึ้นเนื่องจากไลบรารีใหม่และฟีเจอร์ SDK จะทำงานนอกกรอบและมีประโยชน์จากชุมชนขนาดใหญ่ที่ทำงานกับเครื่องมือ App Engine เดียวกัน

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

ที่กล่าวว่าฉันเป็นแฟนตัวยงของ Werkzeug และพวก Pocoo และยืมมากจาก Flask และอื่น ๆ (web.py, Tornado) แต่ - และคุณก็รู้ว่าฉันลำเอียง - ประโยชน์ของ webapp2 ข้างต้นควร ถูกนำมาพิจารณา

คำถามของคุณกว้างมาก แต่ดูเหมือนจะไม่มีปัญหาใหญ่ในการใช้ Flask บน Google App Engine

เธรดรายชื่ออีเมลนี้เชื่อมโยงไปยังเทมเพลตต่างๆ:

http://flask.pocoo.org/mailinglist/archive/2011/3/27/google-app-engine/#4f95bab1627a24922c60ad1d0a0a8e44

และนี่คือบทช่วยสอนเฉพาะสำหรับชุดเครื่องมือ Flask / App Engine:

http://www.franciscosouza.com/2010/08/flying-with-flask-on-google-app-engine/

ยังดูApp Engine - ปัญหาในการเข้าถึงทวิตเตอร์ข้อมูล - กระติกน้ำ , กระติกน้ำกระพริบข้อความล้มเหลวในการเปลี่ยนเส้นทางข้ามและฉันจะจัดการบุคคลที่สามห้องสมุดหลามกับ Google App Engine ได้อย่างไร? (Virtualenv? pip?)สำหรับปัญหาที่ผู้คนเคยมีกับ Flask และ Google App Engine

สำหรับฉันการตัดสินใจสำหรับ webapp2 นั้นง่ายมากเมื่อฉันพบว่า flask ไม่ใช่เฟรมเวิร์กเชิงวัตถุ (ตั้งแต่เริ่มต้น) ในขณะที่ webapp2 เป็นเฟรมเวิร์กเชิงวัตถุบริสุทธิ์ webapp2 ใช้ Method Based Dispatching เป็นมาตรฐานสำหรับ RequestHandlers ทั้งหมด (ตามที่เอกสารของขวดเรียกมันและใช้งานตั้งแต่ V0.7 ใน MethodViews) ในขณะที่อยู่ในขวด MethodViews เป็นส่วนเสริม แต่เป็นหลักการออกแบบหลักสำหรับ webapp2 ดังนั้นการออกแบบซอฟต์แวร์ของคุณจะดูแตกต่างกันโดยใช้ทั้งสองเฟรมเวิร์ก เฟรมเวิร์กทั้งสองใช้เทมเพลต jinja2 ในปัจจุบันและมีคุณสมบัติเหมือนกัน

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

หากคุณเป็น OO-person หรือหากคุณต้องการออกแบบ REST-server ฉันขอแนะนำ webapp2 สำหรับคุณ หากคุณชอบฟังก์ชั่นที่เรียบง่ายโดยมีมัณฑนากรเป็นตัวจัดการสำหรับคำขอหลายประเภทหรือคุณไม่สบายใจกับการสืบทอด OO ให้เลือกขวด ฉันคิดว่าทั้งสองกรอบหลีกเลี่ยงความซับซ้อนและการพึ่งพาของกรอบที่ใหญ่กว่าอย่างปิรามิด

1. http://flask.pocoo.org/docs/0.10/views/#method-based-dispatching
2. https://webapp-improved.appspot.com/guide/handlers.html
3. https://webapp-improved.appspot.com/guide/handlers.html#overriding-dispatch

ฉันคิดว่าเอ็นจิ้นแอพ google รองรับเฟรมเวิร์กขวดอย่างเป็นทางการ มีโค้ดตัวอย่างและบทช่วยสอนที่นี่ -> https://console.developers.google.com/start/appengine?_ga=1.36257892.596387946.1427891855

ฉันไม่ได้ลองใช้ webapp2 และพบว่า tipfy ใช้งานยากเล็กน้อยเนื่องจากต้องใช้สคริปต์การตั้งค่าและบิลด์ที่กำหนดค่าการติดตั้ง python ของคุณเป็นค่าอื่นที่ไม่ใช่ค่าเริ่มต้น ด้วยเหตุผลเหล่านี้และเหตุผลอื่น ๆ ที่ฉันไม่ได้สร้างโปรเจ็กต์ที่ใหญ่ที่สุดของฉันขึ้นอยู่กับเฟรมเวิร์กและฉันใช้เว็บแอพธรรมดาแทนเพิ่มไลบรารีที่เรียกว่าบีกเกอร์เพื่อรับความสามารถของเซสชันและ django ได้มีการแปลในตัวสำหรับคำทั่วไปสำหรับผู้ใช้จำนวนมากดังนั้นเมื่อสร้าง แอปพลิเคชันที่แปลเป็นภาษาท้องถิ่น django เป็นตัวเลือกที่เหมาะสมสำหรับโครงการที่ใหญ่ที่สุดของฉัน อีก 2 เฟรมเวิร์กที่ฉันปรับใช้กับโปรเจ็กต์ในสภาพแวดล้อมการใช้งานจริงคือ GAEframework.com และ web2py และโดยทั่วไปแล้วดูเหมือนว่าการเพิ่มเฟรมเวิร์กที่เปลี่ยนแปลงเอ็นจินเทมเพลตอาจทำให้เกิดความไม่ลงรอยกันระหว่างเวอร์ชันเก่าและเวอร์ชันใหม่

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