Google App Engine için Flask ve webapp2

Yeni Google App Engine uygulamasına başlıyorum ve şu anda iki çerçeve düşünüyorum: Flask ve webapp2 . Önceki App Engine uygulamam için kullandığım yerleşik web uygulaması çerçevesinden oldukça memnunum, bu yüzden webapp2'nin daha da iyi olacağını ve bununla ilgili herhangi bir sorun yaşamayacağımı düşünüyorum.

Bununla birlikte, Flask'ın birçok iyi yorumu var, yaklaşımını ve dokümantasyonda şimdiye kadar okuduğum her şeyi gerçekten seviyorum ve denemek istiyorum. Ancak, Flask ile yol boyunca karşılaşabileceğim sınırlamalar konusunda biraz endişeliyim.

Öyleyse, soru şu: Flask'ın Google App Engine uygulamasına getirebileceği herhangi bir sorun, performans sorunu, sınırlama (ör. Yönlendirme sistemi, yerleşik yetkilendirme mekanizması vb.) Biliyor musunuz? "Sorun" derken, birkaç satır kodda (veya makul miktarda kod ve çabada) çalışamayacağım veya tamamen imkansız olan bir şeyi kastediyorum.

Ve takip sorusu olarak: Flask'ta aklımı başımdan alabileceğini ve karşılaşabileceğim herhangi bir soruna rağmen onu kullanmamı sağlayacağını düşündüğünüz katil özellikler var mı?

Feragatname: tipfy ve webapp2'nin yazarıyım.

Web uygulamasına (veya onun doğal evrimi, webapp2'ye) bağlı kalmanın büyük bir avantajı, seçtiğiniz çerçeve için mevcut SDK işleyicileri için kendi sürümlerinizi oluşturmak zorunda olmamanızdır.

Örneğin, ertelenmiş bir web uygulaması işleyicisi kullanır. Bunu, werkzeug.Request ve werkzeug.Response kullanarak saf bir Flask görünümünde kullanmak için, bunun için ertelenmiş uygulamanız gerekir ( burada tipfy için yaptığım gibi).

Aynısı diğer işleyiciler için de geçerlidir: blobstore (Werkzeug hala aralık isteklerini desteklemiyor, bu nedenle kendi işleyicinizi oluştursanız bile WebOb'u kullanmanız gerekir - bkz. Tipfy.appengine.blobstore ), mail, XMPP vb. veya gelecekte SDK'ya dahil edilecek diğerleri.

Aynı şey, web uygulamasına dayalı olan ve web uygulaması ile çerçevenizi karıştırmak istemiyorsanız, diğer çerçevelerle çalışmak için bir bağlantı noktası veya adaptöre ihtiyaç duyan ProtoRPC gibi App Engine ile oluşturulan kitaplıklar için de geçerlidir. aynı uygulamada seçim işleyicileri.

Dolayısıyla, farklı bir çerçeve seçseniz bile, a) bazı özel durumlarda web uygulamasını kullanmak veya b) kullanıyorsanız, belirli SDK işleyicileri veya özellikleri için sürümlerinizi oluşturmak ve sürdürmek zorunda kalacaksınız.

Werkzeug'u WebOb'dan çok tercih ederim, ancak bir yıldan fazla bir süredir tipfy ile yerel olarak çalışan SDK işleyicilerinin sürümlerini taşıdıktan ve sürdürdükten sonra, bunun kayıp bir neden olduğunu fark ettim - GAE'yi uzun vadede desteklemek için, en iyisi yakın kalmaktır. webapp / WebOb. SDK kitaplıkları için desteği çocuk oyuncağı haline getirir, bakım çok daha kolay hale gelir, yeni kitaplıklar ve SDK özellikleri kutudan çıkar çıkmaz çalışacağından ve aynı App Engine araçları üzerinde çalışan büyük bir topluluğun avantajı olduğu için geleceğe daha dayanıklıdır.

Belirli bir webapp2 savunması burada özetlenmiştir . Webapp2'nin App Engine dışında kullanılabileceğini ve popüler mikro çerçeveler gibi görünmesi için kolayca özelleştirilebileceğini ve bunun için bir dizi çekici nedeniniz olduğunu ekleyin . Ayrıca, webapp2'nin gelecekteki bir SDK sürümüne dahil edilmek için büyük bir şansı var (bu ekstra resmidir, bana alıntı yapma :-) bu onu ileriye taşıyacak ve yeni geliştiriciler ve katkılar getirecektir.

Bununla birlikte, Werkzeug ve Pocoo adamlarının büyük bir hayranıyım ve Flask ve diğerlerinden (web.py, Tornado) çok ödünç aldım, ancak - ve biliyorsunuz, önyargılıyım - yukarıdaki webapp2 avantajları dikkate alınmalıdır.

Sorunuz son derece kapsamlı, ancak Google App Engine'de Flask'ı kullanırken büyük bir sorun görünmüyor.

Bu posta listesi dizisi birkaç şablona bağlanır:

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

Ve burada Flask / App Engine kombinasyonuna özel bir eğitici yer almaktadır:

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

Ayrıca, App Engine - Twitter Verilerine Erişmede Zorluk - Flask , Flask mesajı yeniden yönlendirmelerde başarısız oluyor ve Google App Engine ile üçüncü taraf Python kitaplıklarını nasıl yönetirim? (virtualenv? pip?) insanların Flask ve Google App Engine ile yaşadığı sorunlar için.

Benim için webapp2'nin kararı, flask'ın nesne yönelimli bir çerçeve olmadığını (en başından beri), webapp2'nin ise tamamen nesne yönelimli bir çerçeve olduğunu keşfettiğimde kolay oldu. webapp2, tüm RequestHandler'lar için standart olarak Method Based Dispatching kullanır (flask dokümantasyonu bunu çağırır ve MethodViews'ta V0.7'den beri uygular). Şişede MethodViews bir eklenti olsa da, webapp2 için temel bir tasarım ilkesidir. Dolayısıyla, yazılım tasarımınız her iki çerçeveyi kullanarak farklı görünecektir. Her iki çerçeve de günümüzde jinja2 şablonlarını kullanıyor ve oldukça aynı özelliklere sahip.

Temel sınıf bir RequestHandler'a güvenlik kontrolleri eklemeyi ve ondan devralmayı tercih ediyorum. Bu, yardımcı program işlevleri, vb. İçin de iyidir. Örneğin bağlantı [3] 'te görebileceğiniz gibi, bir istek gönderilmesini önlemek için yöntemleri geçersiz kılabilirsiniz.

Bir OO-kişiyseniz veya bir REST sunucusu tasarlamanız gerekiyorsa, sizin için webapp2'yi tavsiye ederim. Birden çok istek türü için işleyici olarak dekoratörlerin olduğu basit işlevleri tercih ediyorsanız veya OO kalıtımından rahatsızsanız, şişeyi seçin. Bence her iki çerçeve de piramit gibi çok daha büyük çerçevelerin karmaşıklığından ve bağımlılıklarından kaçınıyor.

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 uygulama motorunun flask çerçevesini resmi olarak desteklediğini düşünüyorum. Burada örnek bir kod ve öğretici var -> https://console.developers.google.com/start/appengine?_ga=1.36257892.596387946.1427891855

Webapp2'yi denemedim ve tipfy'nin python kurulumunuzu varsayılandan farklı bir şekilde yapılandıran kurulum komut dosyaları ve yapılar gerektirdiğinden kullanımının biraz zor olduğunu fark ettim. Bu ve diğer nedenlerden dolayı en büyük projemi bir çerçeveye bağımlı hale getirmedim ve bunun yerine düz web uygulamasını kullanıyorum, oturum yeteneği elde etmek için beher adlı kitaplığı ekledim ve django zaten birçok kullanım durumunda ortak olan sözcükler için yerleşik çevirilere sahiptir, bu nedenle bir yerelleştirilmiş uygulama django, en büyük projem için doğru seçimdi. Projelerle bir üretim ortamına yerleştirdiğim diğer 2 çerçeve GAEframework.com ve web2py idi ve genel olarak şablon motorunu değiştiren bir çerçeve eklemenin eski ve yeni sürümler arasında uyumsuzluklara yol açabileceği görülüyor.

Deneyimlerime göre, daha gelişmiş kullanım durumlarını çözmedikleri sürece projelerime bir çerçeve eklemek konusunda isteksiz davranıyorum (dosya yükleme, çoklu kimlik doğrulama, yönetici kullanıcı arayüzü, şu anda gae için çerçeve bulunmayan daha gelişmiş kullanım durumlarının 3 örneğidir. iyi idare eder.