Google App Engine के लिए फ्लास्क बनाम webapp2

Question

मैं नया Google ऐप इंजन एप्लिकेशन शुरू कर रहा हूं और वर्तमान में दो चौखटों पर विचार कर रहा हूं: फ्लास्क और वेब 2 । मैं बिल्ट-इन वेबएप फ्रेमवर्क से संतुष्ट हूं, जिसका उपयोग मैंने अपने पिछले ऐप इंजन अनुप्रयोग के लिए किया है, इसलिए मुझे लगता है कि वेब 2 भी बेहतर होगा और मुझे इसमें कोई समस्या नहीं होगी।

हालाँकि, फ्लास्क के बहुत सारे अच्छे रिव्यू हैं, मैं वास्तव में इसके दृष्टिकोण और उन सभी चीजों को पसंद करता हूं जो मैंने अभी तक प्रलेखन में पढ़ी हैं और मैं इसे आज़माना चाहता हूं। लेकिन मैं सीमाओं के बारे में थोड़ा चिंतित हूं कि मैं फ्लास्क के साथ सड़क का सामना कर सकता हूं।

तो, सवाल यह है - क्या आप किसी भी समस्या, प्रदर्शन के मुद्दों, सीमाओं (जैसे मार्ग प्रणाली, अंतर्निहित प्राधिकरण तंत्र, आदि) को जानते हैं जो फ्लास्क Google ऐप इंजन अनुप्रयोग में ला सकता है? "समस्या" से मेरा मतलब है कि मैं कोड की कई लाइनों (या कोड और प्रयासों के किसी भी उचित मात्रा) या पूरी तरह से असंभव है कि आसपास काम नहीं कर सकता।

और एक अनुवर्ती सवाल के रूप में: क्या फ्लास्क में कोई हत्यारा-विशेषताएं हैं जो आपको लगता है कि मेरे दिमाग को उड़ा सकता है और मुझे किसी भी समस्या के बावजूद इसका उपयोग कर सकता है जो मैं सामना कर सकता हूं?

Comments

मैं webapp2 के बारे में ज्यादा नहीं जानता, लेकिन मैं कुछ महीनों से फ्लास्क का उपयोग कर रहा हूं और मुझे यह पसंद है। मुझे फ्लास्क प्लगइन्स मिले जिन्होंने वास्तव में मेरी मदद की, जैसे कि flask-babelकई भाषा समर्थन के लिए, और flask-seasurfसीएसआरएफ समर्थन के लिए मेरे रूपों को सुरक्षित करने के लिए।

— thePloki

Answer 1

डिस्क्लेमर: मैं टिपफी और वेबैप 2 का लेखक हूं।

Webapp (या इसके प्राकृतिक विकास, webapp2) के साथ चिपके रहने का एक बड़ा फायदा यह है कि आपको अपनी पसंद के ढांचे के लिए मौजूदा SDK संचालकों के लिए अपने स्वयं के संस्करण बनाने की आवश्यकता नहीं है।

उदाहरण के लिए, आस्थगित वेबएप हैंडलर का उपयोग करता है। शुद्ध फ्लास्क दृश्य में इसका उपयोग करने के लिए, werkzeug.Request और werkzeug.Response का उपयोग करके, आपको इसके लिए आस्थगित लागू करने की आवश्यकता होगी (जैसे मैंने यहां टिप्पी के लिए किया था )।

दूसरे हैंडलर के लिए भी ऐसा ही होता है: ब्लॉबस्टोर (वर्केजग अभी भी रेंज रिक्वेस्ट का समर्थन नहीं करता है, इसलिए आपको अपना हैंडलर बनाते समय भी WebOb का उपयोग करने की आवश्यकता होगी - टिपएफ़.आईपेंगाइन.ब्लोबस्टोर ), मेल, एक्सएमपीपी और इतने पर देखें। या अन्य जो भविष्य में एसडीके में शामिल हैं।

और ऐसा ही होता है ProtoRPC जैसे ऐप इंजन को ध्यान में रखकर बनाई गई लाइब्रेरियों के लिए , जो वेबएप पर आधारित होती है और आपको अन्य फ्रेमवर्क के साथ काम करने के लिए एक पोर्ट या अडैप्टर की जरूरत होगी, अगर आप वेबएप और अपने फ्रेमवर्क को नहीं मिलाना चाहते हैं- एक ही एप्लिकेशन में पसंद संचालकों।

इसलिए, यदि आप एक अलग फ्रेमवर्क चुनते हैं, तो आप कुछ विशेष मामलों में वेब का उपयोग करते हुए ए) समाप्त करेंगे या बी) विशिष्ट एसडीके हैंडलर या सुविधाओं के लिए अपने संस्करण बनाने और बनाए रखने के लिए, यदि आप उनका उपयोग करेंगे।

मैं WebOb पर वर्कर्ज़ग को बहुत पसंद करता हूं, लेकिन एक साल के बाद एसडीके हैंडलर्स के संस्करणों को पोर्ट करना और बनाए रखना जो मूल रूप से टिपफी के साथ काम करते हैं, मैंने महसूस किया कि यह एक खो गया कारण है - दीर्घकालिक के लिए जीएई का समर्थन करना, सबसे अच्छा है, पास रहना webapp / WebOb। यह एसडीके पुस्तकालयों के लिए एक हवा का समर्थन करता है, रखरखाव बहुत आसान हो जाता है, यह अधिक भविष्य का सबूत है क्योंकि नए पुस्तकालय और एसडीके विशेषताएं बॉक्स से बाहर काम करेंगे और एक ही ऐप इंजन टूल के आसपास काम करने वाले एक बड़े समुदाय का लाभ होगा।

एक विशिष्ट webapp2 रक्षा यहाँ संक्षेप में प्रस्तुत की गई है । उन लोगों को जोड़ें जिन्हें ऐप्प इंजन के बाहर इस्तेमाल किया जा सकता है और लोकप्रिय माइक्रो-फ्रेमवर्क की तरह दिखने के लिए अनुकूलित किया जाना आसान है और आपके पास इसके लिए जाने के लिए सम्मोहक कारणों का एक अच्छा सेट है। इसके अलावा, webapp2 के पास भविष्य के एसडीके रिलीज में शामिल होने का एक बड़ा मौका है (यह अतिरिक्त-आधिकारिक है, मुझे उद्धृत न करें :-) जो इसे आगे बढ़ाएगा और नए डेवलपर्स और योगदान लाएगा।

उस ने कहा, मैं Werkzeug और Pocoo लोगों का बहुत बड़ा प्रशंसक हूं और फ्लास्क और अन्य (web.py, Tornado) से बहुत अधिक उधार लेता हूं, लेकिन - और, आप जानते हैं, मैं पक्षपाती हूं - उपरोक्त webapp2 लाभ ध्यान में रखा जाना।

Comments

धन्यवाद, @moraes! ठोस पर्याप्त। मुझे लगता है कि ब्लॉबस्टोर, मेल (और शायद प्रोटो आरपीसी) जैसी चीजें उस परियोजना के लिए काफी महत्वपूर्ण टुकड़े हैं, और मैं उनके साथ यथासंभव सहजता से काम करना चाहता हूं। इसके अलावा, मुझे लगता है कि अगर आप आसानी से इससे बच सकते हैं तो विभिन्न रूपरेखाओं को मिलाना सबसे अच्छा विचार नहीं है। इसके अलावा, इस तथ्य के बावजूद कि मैं फ्लास्क के प्रति सहानुभूति रखता हूं, मैं वास्तव में वेब 2 से प्रभावित हूं और इसे आज़माने के लिए मेरे हाथों में खुजली है। उत्तर के लिए और webapp2 के लिए धन्यवाद!

— एंटोन मोइसेव

@Sundar यह किसी भी WSGI- अनुरूप वेब सर्वर पर चल सकता है। अपाचे के लिए code.google.com/p/modwsgi और अन्य हैं।

— मोरा

@ मोरेस: क्या यह उत्तर अब पुराना हो चुका है? मैं देख सकता हूं कि GAE SDK फ्लास्क का समर्थन करता है। क्या वेब 2 अभी भी बेहतर विकल्प है?

— निश

@ वार्निश, संदर्भ है कि जीएई एसडीके फ्लास्क को आधिकारिक रूप से समर्थन करता है?

— एनकैश

बस ध्यान दें, जबकि यह विरासत में स्वीकार किए गए उत्तर है, webapp2 विकास मृत है। मैं कहूंगा कि फ्लास्क जाने का रास्ता है।

— जेसी

Answer 2

आपका प्रश्न अत्यंत व्यापक है, लेकिन Google ऐप इंजन पर फ्लास्क का उपयोग करने में कोई बड़ी समस्या नहीं है।

यह मेलिंग सूची थ्रेड लिंक कई टेम्पलेट्स के लिए:

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

और यहाँ एक फ्लास्क / ऐप इंजन संयोजन के लिए विशिष्ट ट्यूटोरियल है:

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

इसके अलावा, ऐप इंजन देखें - ट्विटर डेटा तक पहुंचने में कठिनाई - फ्लास्क , फ्लास्क संदेश फ्लैशिंग पुनर्निर्देशन में विफल रहता है , और मैं Google ऐप इंजन के साथ तीसरे पक्ष के पायथन पुस्तकालयों का प्रबंधन कैसे करूं? (virtualenv? pip?) मुद्दों के लिए लोगों को फ्लास्क और गूगल ऐप इंजन के साथ पड़ा है।

Comments

धन्यवाद, @agf। मैंने इस पोस्ट को पहले देखा है, लेकिन मुझे लगता है कि मैं व्यक्तिगत अनुभव में अधिक रुचि रखता हूं। मुझे नहीं लगता कि यह प्रश्न व्यापक है, क्योंकि मैं व्यापक चर्चा या किसी समस्या के बारे में विस्तृत जानकारी में दिलचस्पी नहीं रखता हूं, बस मुझे यह इंगित करें कि यह और इसे लागू करना कठिन या असंभव होगा।

— एंटन मोइसेव

@ एटन, व्यक्तिपरक व्यक्तिगत अनुभव का अनुरोध करना, सवाल न पूछने के लिए एसओ दिशानिर्देशों के बहुत करीब है ।

— जेम्स

@ जेम्स - सहमत नहीं हैं। मैं आपसे आपके अनुमानों, मान्यताओं या व्यक्तिपरक भावनाओं के बारे में नहीं पूछता। मैं आपके अनुभव के बारे में पूछता हूं, अर्थात उन तथ्यों के बारे में जो आप आत्मविश्वास से जानते हैं। अप्रचलित पोस्ट नहीं, और न ही समस्याओं का सामना करना पड़ा जो अन्य लोगों ने भारी अनुकूलन के दौरान सामना किया है, बस तथ्य। सहमत मत हो - ठीक है, बस इसे ध्वजांकित करें।

— एंटोन मोइसेव

Answer 3

मेरे लिए webapp2 का निर्णय तब आसान था जब मुझे पता चला कि फ्लास्क ऑब्जेक्ट-ओरिएंटेड फ्रेमवर्क नहीं है (शुरुआत से), जबकि webapp2 एक शुद्ध ऑब्जेक्ट ओरिएंटेड फ्रेमवर्क है। webapp2 मेथड बेस्ड डिस्पैचिंग को सभी रिक्वेस्टहैंडलर के मानक के रूप में उपयोग करता है (जैसा कि फ्लास्क डॉक्यूमेंट इसे कहते हैं और मेथडव्यू में V0.7 के बाद से इसे लागू करता है)। फ्लास्क में जबकि MethodViews एक ऐड-ऑन हैं, यह webapp2 के लिए एक मुख्य डिजाइन सिद्धांत है। तो आपके सॉफ्टवेयर का डिज़ाइन दोनों रूपरेखाओं का उपयोग करके अलग दिखेगा। दोनों चौखटे आजकल jinja2 टेम्प्लेट का उपयोग करते हैं और काफी समान हैं।

मैं बेस-क्लास RequestHandler में सुरक्षा जांच जोड़ना पसंद करता हूं और इसे विरासत में लेता हूं। यह उपयोगिता कार्यों आदि के लिए भी अच्छा है, जैसा कि आप लिंक में उदाहरण के लिए देख सकते हैं [3] अनुरोध भेजने से रोकने के लिए आप तरीकों को ओवरराइड कर सकते हैं।

यदि आप एक OO- व्यक्ति हैं, या यदि आपको REST- सर्वर डिज़ाइन करने की आवश्यकता है, तो मैं आपके लिए webapp2 की सलाह दूंगा। यदि आप कई अनुरोध-प्रकारों के लिए हैंडलर्स के रूप में सज्जाकार के साथ सरल कार्य पसंद करते हैं, या आप ओओ-इनहेरिटेंस के साथ असहज हैं तो फ्लास्क चुनें। मुझे लगता है कि दोनों ढांचे पिरामिड की तरह बहुत बड़े ढांचे की जटिलता और निर्भरता से बचते हैं।

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

Comments

यह है, OOP समर्थन मुझे जीता। मैं मूल रूप से web.py का उपयोग करता हूं, लेकिन webapp2 को लगता है कि मैंने web.py पर काम नहीं किया है। फ्लास्क शुरू करना आसान हो सकता है, लेकिन आपको इससे ज्यादा की जरूरत है अगर आप बड़े ऐप बनाने की योजना बनाते हैं

— अहमद मुज़ाकी

Answer 4

मुझे लगता है कि Google ऐप इंजन आधिकारिक तौर पर फ्लास्क फ्रेमवर्क का समर्थन करता है। यहाँ एक नमूना कोड और ट्यूटोरियल है -> https://console.developers.google.com/start/appengine?_ga=1.36257892.596387946.1427891855

Comments

मेरे लिए, यह आधिकारिक समर्थन नहीं है, यह केवल उदाहरण है "आप इसे फ्लास्क के साथ भी कर सकते हैं" -स्टाइल। वेब 2 के लिए, अभी भी जीएई-विशिष्ट आइटमों के साथ यहां और वहां विस्तृत मैनुअल है।

— सिलपोल

Answer 5

मैंने webapp2 की कोशिश नहीं की और पाया कि टिपफी का उपयोग करना थोड़ा मुश्किल था क्योंकि इसे सेटअप स्क्रिप्ट की आवश्यकता होती है और यह तय करता है कि डिफ़ॉल्ट रूप से आपके अजगर स्थापना को कॉन्फ़िगर करें। इन और अन्य कारणों से मैंने अपनी सबसे बड़ी परियोजना को एक ढांचे पर निर्भर नहीं किया है और मैं इसके बजाय सादे वेबएप का उपयोग करता हूं, सत्र क्षमता प्राप्त करने के लिए बीकर नामक पुस्तकालय को जोड़ें और django में पहले से ही कई usecases के लिए आम शब्दों में बिल्ट अनुवाद हैं ताकि एक इमारत बनाते समय स्थानीय अनुप्रयोग django मेरे सबसे बड़े प्रोजेक्ट के लिए सही विकल्प था। 2 अन्य चौखटे, जिन्हें मैं वास्तव में एक उत्पादन वातावरण के लिए परियोजनाओं के साथ तैनात किया गया था, GAEframework.com और web2py थे और आम तौर पर ऐसा लगता है कि एक रूपरेखा को जोड़ने से इसका टेम्पलेट इंजन बदल जाता है जिससे पुराने और नए संस्करणों के बीच असंगति हो सकती है।

इसलिए मेरा अनुभव यह है कि मैं अपनी परियोजनाओं के लिए एक फ्रेमवर्क जोड़ने के लिए अनिच्छुक हो रहा हूं जब तक कि वे अधिक उन्नत उपयोग के मामलों को हल नहीं करते हैं (फ़ाइल अपलोड, मल्टी ऑर्टिकल, एडमिन यूआई अधिक उन्नत उपयोग मामलों के 3 उदाहरण हैं जो इस समय के लिए कोई रूपरेखा नहीं हैं अच्छी तरह से संभालता है।