Flask vs webapp2 untuk Google App Engine

116

Saya memulai aplikasi Google App Engine baru dan saat ini sedang mempertimbangkan dua kerangka kerja: Flask dan webapp2 . Saya agak puas dengan kerangka webapp bawaan yang telah saya gunakan untuk aplikasi App Engine saya sebelumnya, jadi saya pikir webapp2 akan menjadi lebih baik dan saya tidak akan memiliki masalah dengan itu.

Namun, ada banyak review bagus tentang Flask, saya sangat suka pendekatannya dan semua hal yang telah saya baca sejauh ini dalam dokumentasi dan saya ingin mencobanya. Tapi saya agak khawatir tentang batasan yang bisa saya hadapi dengan Flask.

Jadi, pertanyaannya adalah - apakah Anda mengetahui masalah, masalah kinerja, batasan (misalnya sistem perutean, mekanisme otorisasi bawaan, dll.) Yang dapat dibawa oleh Flask ke aplikasi Google App Engine? Yang saya maksud dengan "masalah" adalah sesuatu yang tidak dapat saya atasi dalam beberapa baris kode (atau kode dan upaya yang masuk akal) atau sesuatu yang sama sekali tidak mungkin.

Dan sebagai pertanyaan lanjutan: apakah ada fitur mematikan di Flask yang menurut Anda dapat membuat saya terpesona dan membuat saya menggunakannya meskipun ada masalah yang mungkin saya hadapi?

— Anton Moiseev
sumber

Saya tidak tahu banyak tentang webapp2, tapi saya telah menggunakan Flask selama beberapa bulan dan saya menyukainya. Saya menemukan plugin flask yang sangat membantu saya, seperti flask-babeluntuk dukungan berbagai bahasa, dan flask-seasurfuntuk dukungan CSRF untuk mengamankan formulir saya.

— ThePloki

138

Penafian: Saya adalah penulis tipfy dan webapp2.

Keuntungan besar tetap menggunakan webapp (atau evolusi alaminya, webapp2) adalah Anda tidak perlu membuat versi Anda sendiri untuk penangan SDK yang ada untuk kerangka kerja pilihan Anda.

Misalnya, deferred menggunakan penangan webapp. Untuk menggunakannya dalam tampilan Flask murni, gunakan werkzeug.Request dan werkzeug.Response, Anda harus mengimplementasikan deferred untuk itu (seperti yang saya lakukan di sini untuk tipfy).

Hal yang sama terjadi untuk penangan lain: blobstore (Werkzeug masih tidak mendukung permintaan jangkauan, jadi Anda harus menggunakan WebOb bahkan jika Anda membuat penangan Anda sendiri - lihat tipfy.appengine.blobstore ), mail, XMPP dan seterusnya, atau orang lain yang disertakan dalam SDK di masa mendatang.

Dan hal yang sama terjadi untuk library yang dibuat dengan App Engine, seperti ProtoRPC , yang didasarkan pada webapp dan akan membutuhkan port atau adaptor untuk bekerja dengan framework lain, jika Anda tidak ingin mencampur webapp dan your-framework-of- penangan pilihan di aplikasi yang sama.

Jadi, meskipun Anda memilih kerangka kerja yang berbeda, Anda akan mengakhiri a) menggunakan webapp dalam beberapa kasus khusus atau b) harus membuat dan memelihara versi Anda untuk penangan atau fitur SDK tertentu, jika Anda akan menggunakannya.

Saya lebih memilih Werkzeug daripada WebOb, tetapi setelah lebih dari satu tahun mem-porting dan memelihara versi penangan SDK yang bekerja secara asli dengan tipfy, saya menyadari bahwa ini adalah penyebab yang hilang - untuk mendukung GAE untuk jangka panjang, yang terbaik adalah tetap dekat dengan webapp / WebOb. Itu membuat dukungan untuk pustaka SDK menjadi mudah, pemeliharaan menjadi jauh lebih mudah, lebih tahan masa depan karena pustaka baru dan fitur SDK akan berfungsi di luar kotak dan ada manfaat dari komunitas besar yang bekerja di sekitar alat App Engine yang sama.

Pertahanan webapp2 tertentu dirangkum di sini . Selain itu, webapp2 dapat digunakan di luar App Engine dan mudah disesuaikan agar terlihat seperti kerangka kerja mikro yang populer dan Anda memiliki serangkaian alasan kuat untuk melakukannya. Selain itu, webapp2 memiliki peluang besar untuk disertakan dalam rilis SDK di masa mendatang (ini ekstra-resmi, jangan mengutip saya :-) yang akan mendorongnya ke depan dan membawa pengembang dan kontribusi baru.

Meskipun demikian, saya penggemar berat Werkzeug dan orang-orang Pocoo dan meminjam banyak dari Flask dan lainnya (web.py, Tornado), tetapi - dan, Anda tahu, saya bias - manfaat webapp2 di atas seharusnya diperhitungkan.

— moraes
sumber

10

Terima kasih, @moraes! Cukup padat. Saya pikir hal-hal seperti blobstore, mail (dan mungkin ProtoRPC) adalah bagian yang cukup penting untuk proyek itu, dan saya ingin bekerja dengannya semulus mungkin. Juga, saya pikir untuk mencampur kerangka kerja yang berbeda bukanlah ide terbaik jika Anda dapat dengan mudah menghindarinya. Selain itu, meskipun saya bersimpati dengan Flask, saya sangat terkesan dengan webapp2 dan membuat tangan saya gatal untuk mencobanya. Terima kasih atas jawabannya dan untuk webapp2!

— Anton Moiseev

3

@Sundar Dapat berjalan di server web yang mendukung WSGI. Untuk Apache ada code.google.com/p/modwsgi dan lainnya.

— moraes

4

@moraes: Apakah jawaban ini sudah usang sekarang? Saya dapat melihat bahwa GAE SDK mendukung Flask. Apakah webapp2 masih pilihan yang lebih baik?

— nish

1

@nish, sebutkan bahwa GAE SDK mendukung Flask secara resmi?

— enkash

15

Sekadar catatan, meskipun ini adalah jawaban yang diterima sebelumnya, pengembangan webapp2 sudah mati. Saya akan mengatakan Flask adalah cara yang tepat.

— Jesse

13

Pertanyaan Anda sangat luas, tetapi tampaknya tidak ada masalah besar dalam menggunakan Flask di Google App Engine.

Utas milis ini tertaut ke beberapa templat:

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

Dan berikut adalah tutorial khusus untuk kombinasi Flask / App Engine:

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

Selain itu, lihat App Engine - Kesulitan Mengakses Data Twitter - Flask , pesan Flask yang berkedip gagal saat pengalihan , dan Bagaimana cara mengelola pustaka Python pihak ketiga dengan Google App Engine? (virtualenv? pip?) untuk masalah yang dialami orang-orang dengan Flask dan Google App Engine.

— agf
sumber

7

Terima kasih, @agf. Saya telah melihat sebagian besar posting ini sebelumnya, tetapi saya pikir saya lebih tertarik pada pengalaman pribadi. Saya tidak berpikir bahwa pertanyaannya terlalu luas, karena saya tidak tertarik dengan diskusi komprehensif atau informasi terperinci tentang suatu masalah, tunjukkan saja bahwa ini dan ini akan sulit atau tidak mungkin untuk diterapkan.

— Anton Moiseev

2

@ Anton, Meminta pengalaman pribadi subjektif cukup dekat dengan pedoman SO untuk pertanyaan yang tidak diajukan .

— Yakobus

9

@ James - Jangan setuju. Saya tidak bertanya tentang tebakan, asumsi, atau perasaan subjektif Anda. Saya bertanya tentang pengalaman Anda, yaitu tentang fakta yang Anda ketahui dengan percaya diri. Bukan posting usang, atau masalah yang dihadapi orang lain selama kustomisasi berat, hanya fakta. Tidak setuju - oke, tandai saja.

— Anton Moiseev

3

Bagi saya keputusan untuk webapp2 mudah ketika saya menemukan bahwa flask bukanlah kerangka kerja berorientasi objek (dari awal), sedangkan webapp2 adalah kerangka kerja berorientasi objek murni. webapp2 menggunakan Pengiriman Berbasis Metode sebagai standar untuk semua RequestHandler (sebagaimana dokumentasi flask memanggilnya dan mengimplementasikannya sejak V0.7 di MethodView). Sementara di flask MethodView adalah add-on, ini adalah prinsip desain inti untuk webapp2. Jadi desain perangkat lunak Anda akan terlihat berbeda menggunakan kedua kerangka kerja tersebut. Kedua framework saat ini menggunakan template jinja2 dan memiliki fitur yang cukup identik.

Saya lebih suka menambahkan pemeriksaan keamanan ke RequestHandler kelas dasar dan mewarisinya. Ini juga bagus untuk fungsi utilitas, dll. Seperti yang Anda lihat misalnya pada tautan [3], Anda dapat mengganti metode untuk mencegah pengiriman permintaan.

Jika Anda adalah OO-person, atau jika Anda perlu merancang server REST, saya akan merekomendasikan webapp2 untuk Anda. Jika Anda lebih suka fungsi sederhana dengan dekorator sebagai penangan untuk beberapa tipe permintaan, atau Anda tidak nyaman dengan pewarisan OO, maka pilih flask. Saya pikir kedua kerangka menghindari kompleksitas dan ketergantungan kerangka kerja yang jauh lebih besar seperti piramida.

— kucing
sumber

itu saja, dukungan OOP memenangkan saya. Saya awalnya menggunakan web.py tetapi webapp2 tampaknya memiliki struktur yang rapi tanpa solusi yang saya lakukan di web.py. flask mungkin mudah untuk memulai, tetapi Anda membutuhkan lebih dari itu jika Anda berencana untuk membuat aplikasi yang lebih besar

— Ahmad Muzakki

2

Saya pikir mesin aplikasi google secara resmi mendukung kerangka kerja flask. Ada kode contoh dan tutorial di sini -> https://console.developers.google.com/start/appengine?_ga=1.36257892.596387946.1427891855

— Anup
sumber

bagi saya, ini bukan dukungan resmi, ini hanya contoh "Anda juga dapat melakukannya dengan Flask" -gaya. Untuk webapp2, masih ada manual terperinci dengan item khusus GAE ditambahkan di sana-sini.

— silpol

2

Saya tidak mencoba webapp2 dan menemukan bahwa tipfy agak sulit digunakan karena memerlukan skrip pengaturan dan build yang mengkonfigurasi instalasi python Anda ke selain default. Untuk alasan ini dan lainnya, saya belum membuat proyek terbesar saya bergantung pada kerangka kerja dan saya menggunakan aplikasi web biasa sebagai gantinya, tambahkan pustaka yang disebut beaker untuk mendapatkan kemampuan sesi dan django sudah memiliki terjemahan bawaan untuk kata-kata yang umum bagi banyak kasus penggunaan jadi ketika membangun sebuah aplikasi lokalisasi django adalah pilihan yang tepat untuk proyek terbesar saya. 2 kerangka kerja lain yang sebenarnya saya gunakan dengan proyek ke lingkungan produksi adalah GAEframework.com dan web2py dan umumnya tampaknya menambahkan kerangka kerja yang mengubah mesin templatnya dapat menyebabkan ketidaksesuaian antara versi lama dan baru.

Jadi pengalaman saya adalah bahwa saya enggan menambahkan kerangka kerja ke proyek saya kecuali mereka menyelesaikan kasus penggunaan yang lebih maju (unggahan file, multi auth, admin ui adalah 3 contoh kasus penggunaan lanjutan yang tidak ada kerangka untuk gae saat ini menangani dengan baik.

— Niklas R.
sumber