Mengapa menggunakan Django di Google App Engine?


88

Saat meneliti Google App Engine (GAE), jelas bahwa menggunakan Django sangat populer untuk pengembangan Python di GAE. Saya telah menjelajahi web untuk mencari informasi tentang biaya dan keuntungan menggunakan Django, untuk mencari tahu mengapa itu begitu populer. Meskipun saya dapat menemukan berbagai macam sumber tentang bagaimana menjalankan Django pada GAE dan berbagai metode melakukannya, saya belum menemukan analisis komparatif tentang mengapa Django lebih disukai menggunakan kerangka webapp yang disediakan oleh Google.

Agar jelas, itu segera terlihat mengapa menggunakan Django pada GAE berguna untuk pengembang dengan keahlian yang ada di Django (mayoritas pengembang web Python, tidak diragukan lagi) atau kode yang ada di Django (di mana menggunakan GAE lebih merupakan latihan porting). Namun, tim saya sedang mengevaluasi GAE untuk digunakan pada proyek yang semuanya baru dan pengalaman kami yang ada adalah dengan TurboGears, bukan Django.

Sudah cukup sulit untuk menentukan mengapa Django bermanfaat bagi tim pengembangan ketika pustaka BigTable telah menggantikan ORM Django, sesi dan otentikasi perlu diubah, dan templat Django (jika diinginkan) tersedia tanpa menggunakan seluruh susunan Django.

Terakhir, jelas bahwa menggunakan Django memang memiliki keuntungan dalam menyediakan "strategi keluar" jika nanti kita ingin menjauh dari GAE dan membutuhkan platform untuk menargetkan eksodus.

Saya akan sangat menghargai bantuan dalam menunjukkan mengapa menggunakan Django lebih baik daripada menggunakan aplikasi web di GAE. Saya juga sama sekali tidak berpengalaman dengan Django, jadi elaborasi pada fitur dan / atau kemudahan yang lebih kecil yang bekerja pada GAE juga berharga bagi saya.


suci omong kosong terry bradshaw menulis kode?
Woot4Moo

4
Django bermanfaat karena mengagumkan. Benar-benar itu. :)
jathanism

Saya juga baru mengenal mesin aplikasi Google dan ini adalah pertanyaan yang dibentuk dengan sangat baik bahkan untuk 2018 (meskipun Django ORM tampaknya jauh lebih baik didukung di GAE sekarang). :)
Divij Sehgal

Jawaban:


19

Kami menggunakan django pada instance appengine kami sebagian besar ketika kami harus menyajikan situs web yang sebenarnya kepada pengguna. Ia memiliki mesin template yang bagus, perutean url dan semua permintaan / respon / penanganan kesalahan yang ada di dalamnya. Jadi meskipun kita tidak dapat menggunakan hal-hal orm / admin ajaib itu memiliki banyak hal yang terjadi.

Untuk layanan api, kami membuat sesuatu yang sangat sederhana di atasnya webob. Ini jauh lebih ringan karena tidak membutuhkan semua yang ditawarkan django, dan oleh karena itu sedikit lebih cepat dalam beberapa situasi.


1
Terima kasih Koen. Bagian dari kebingungan saya mengenai daya tarik Django berasal dari gagasan bahwa perutean url dan penanganan permintaan / tanggapan / kesalahan juga merupakan fitur dari aplikasi web yang disediakan dan bahwa mesin templat dapat digunakan tanpa Django juga dengan aplikasi web. Apakah saya salah Apakah Django menyediakan layanan ini lebih baik daripada kerangka webapp?
Travis Bradshaw

Menurut saya, mereka lebih luas dan fleksibel dalam Django. Jadi lebih baik jika Anda benar-benar membutuhkannya :-)
Koen Bok

2
Saya rasa inilah jawaban yang saya cari! Django itu sebagian besar berlebihan untuk aplikasi web, tetapi dalam fungsionalitas yang mereka bagikan Django dengan cara yang lebih fleksibel dan kuat. Sepertinya itu pasti keputusan "di pinggir," tapi saya pikir semua saran lain, ditambah saran Anda, membuat jawaban yang menarik. Terima kasih.
Travis Bradshaw

1
Modul Python yang ditulis dalam C juga tidak didukung.
Ryu_hayabusa

51

Django mungkin bukan pilihan yang tepat untuk Anda, jika Anda yakin bahwa GAE tepat untuk Anda. Kekuatan dari dua teknologi tidak selaras dengan baik - Anda benar-benar kehilangan banyak orm indah Django di GAE, dan jika Anda menggunakannya, Anda menulis kode yang tidak benar-benar cocok secara langsung ke bigtable dan cara kerja GAE.

Hal tentang GAE adalah ia mendapatkan skalabilitas yang hebat dengan memaksa Anda untuk menulis kode yang diskalakan dengan mudah dari bawah ke atas. Anda hanya tidak dapat melakukan beberapa hal dengan skala yang buruk (tentu saja, Anda masih dapat menulis kode penskalaan yang buruk, tetapi Anda menghindari beberapa jebakan). Imbalannya adalah Anda benar-benar akhirnya membuat kode di sekitar kerangka kerja, jika Anda menggunakan sesuatu seperti Django yang dirancang untuk lingkungan yang berbeda.

Jika Anda melihat diri Anda keluar dari GAE karena alasan apa pun, berinvestasi di infrastruktur ada masalah bagi Anda. Pengkodean untuk bigtable berarti akan lebih sulit untuk pindah ke arsitektur yang berbeda (meskipun proyek apache bekerja untuk menyelesaikannya untuk Anda dengan komponen HBase dari proyek Hadoop). Masih banyak pekerjaan untuk beralih dari GAE.

Apa motivasi pendorong di balik penggunaan GAE, selain menjadi produk Google, dan kata kunci yang keren? Apakah ada alasan bahwa penskalaan menggunakan sesuatu seperti penawaran mediatemple tidak mungkin bekerja dengan baik untuk Anda? Apakah Anda yakin bahwa skala GAE tepat untuk aplikasi Anda? Bagaimana biayanya dibandingkan dengan server khusus, jika Anda mengharapkan untuk mencapai bidang kinerja itu? Dapatkah Anda menyelesaikan masalah Anda dengan baik menggunakan alat yang disediakan GAE, dibandingkan dengan penyiapan server dengan beban seimbang yang lebih tradisional?

Semua ini mengatakan, kecuali jika Anda benar-benar benar-benar membutuhkan penskalaan batas-konyol yang ditawarkan GAE, saya pribadi menyarankan untuk tidak membiarkan layanan tertentu itu menyusun kerangka pilihan Anda. Saya suka Django, jadi menurut saya Anda harus menggunakannya, tetapi tidak pada GAE.

Sunting (Juni 2010): Sebagai pembaruan untuk komentar ini beberapa waktu kemudian: Google telah mengumumkan kemampuan sql-like untuk GAE yang tidak gratis, tetapi akan membiarkan Anda dengan mudah melakukan hal-hal seperti menjalankan perintah gaya SQL untuk menghasilkan laporan pada data Anda.

Selain itu, ada perubahan yang akan datang pada bahasa kueri GAE yang akan memungkinkan kueri kompleks dengan cara yang jauh lebih mudah. Lihat video dari Google I / O 2010.

Lebih lanjut, ada pekerjaan yang sedang dilakukan selama proyek Summer of Code 2010 yang seharusnya membawa dukungan no-sql ke django core, dan dengan ekstensi, membuat bekerja dengan GAE jauh lebih mudah.

GAE menjadi lebih menarik sebagai platform hosting.

Edit (Agustus 2011):

Dan Google baru saja menaikkan biaya untuk sebagian besar pengguna platform secara signifikan dengan mengubah struktur harga. Masalah lockin menjadi lebih baik (jika aplikasi Anda cukup besar, Anda dapat menerapkan alternatif apache), tetapi untuk sebagian besar aplikasi, menjalankan server atau penerapan VPS lebih murah.

Sangat sedikit orang yang benar-benar memiliki masalah data besar. "Oh, startup saya mungkin berkembang suatu hari nanti" bukanlah masalah data besar. Buat barang sekarang dan keluarkan menggunakan alat standar.


Terima kasih atas tanggapan yang bijaksana, Paul. Kami mengevaluasi GAE terutama karena model biaya sesuai dengan rencana bisnis yang kami usulkan dengan baik. Kemampuan untuk memulai secara gratis dan kemudian menskalakan secara bertahap dengan model biaya yang sangat terperinci sangat menarik. Selain itu, kami tidak berharap untuk pindah atau bermigrasi dari GAE di masa mendatang dan penguncian platform untuk proyek ini dapat diterima. Saya menyertakan komentar "strategi keluar" dalam pertanyaan saya terutama dalam upaya untuk menjadi cukup komprehensif dalam apa yang telah saya pelajari melalui membaca dan penelitian sebelum memposting pertanyaan ini. Terima kasih lagi!
Travis Bradshaw

Bagaimana Anda menilai biaya waktu pengembangan? Salah satu hal menyenangkan tentang Django adalah Anda menghabiskan lebih sedikit waktu untuk mencemaskan tentang mendefinisikan model data Anda daripada yang Anda lakukan dengan Bigtable. Bigtable memaksa Anda untuk lebih memahami tentang penggunaan Anda sebelum dapat menggunakannya sama sekali. Kueri tertentu jauh lebih mudah dengan sql "normal".
Paul McMillan

3
Berhati-hatilah untuk tidak menjepit uang secara berlebihan. Gratis memang bagus, tetapi layanan dengan cepat memerlukan uang sungguhan. Jika Anda meluncur di tingkat layanan "gratis", simpan di beberapa server / hosting lain yang sudah Anda bayar. Jika Anda masuk ke tingkat layanan non-gratis, $ 20 / bln untuk VPS yang dapat Anda skala nanti dengan mudah berada dalam kebisingan sejauh biayanya.
Paul McMillan

11
tbradshaw, jangan lupa untuk mempertimbangkan seberapa sering Anda akan membutuhkan laporan ad-hoc yang dijalankan pada kumpulan data Anda. Saya terlibat dalam aplikasi sosial yang berkembang dan GAE menjadi ... Saya tidak akan mengatakan mimpi buruk, tetapi sangat intensif sumber daya untuk memperoleh pengetahuan dari data kami. Antara Google membersihkan log lama dan panjang ekstrim yang diperlukan untuk menyapu semua data, itu membuat cara pelaporan, jauh lebih mahal daripada SQL db. Itu adalah biaya yang tidak saya pertimbangkan saat memulai. Kedua, jika Anda benar-benar tumbuh dan mulai menghasilkan uang, kendali yang hilang terkait pencadangan adalah salah satu faktornya.
JasonSmith

2
Untuk masalah lock-in, lihat AppScale, yang merupakan tiruan Google App Engine. Kami telah mengerjakan platform ini sejak GAE pertama kali keluar dan memiliki banyak pengguna untuk aplikasi python dan java produksi mereka. Anda memiliki akses langsung ke mesin yang menjalankannya sehingga Anda memiliki kontrol lebih pada infrastruktur. github.com/AppScale/appscale.git
Chohan

16

Saya telah melakukan banyak proyek di GAE. Beberapa di django, beberapa dalam kerangka normalnya.

Untuk hal-hal kecil, saya biasanya menggunakan kerangka normalnya untuk kesederhanaan dan kecepatan. Seperti http://stdicon.com , http://yaml-online-parser.appspot.com/ , atau http://text-twist.appspot.com/ .

Untuk hal-hal besar, saya menggunakan django untuk memanfaatkan semua middleware dan plugin yang bagus. Seperti http://metaward.com .

Pada dasarnya tes lakmus saya adalah Apakah ini membutuhkan waktu lebih dari 2 minggu untuk menulis dan menjadi proyek perangkat lunak NYATA ? Jika demikian, gunakan django untuk addons.

Ini memiliki manfaat tambahan, jika proyek Anda tidak cocok untuk BigTable maka Anda dengan cepat melakukan port off (seperti yang saya lakukan Apakah BigTable lambat atau apakah saya bodoh? )


+1, bigtable tidak baik untuk beberapa jenis proyek dan kueri. Itu bagus untuk apa yang Google lakukan, dan mungkin buruk untuk apa yang ingin Anda lakukan.
Paul McMillan

Terima kasih Paul! Dapatkah Anda menghubungkan saya ke sumber apapun yang menjelaskan middleware Django dan plugin yang bekerja pada GAE? Jika ada add-on yang berguna untuk proyek kami, itu pasti akan menjadi alasan untuk menggunakan Django daripada webapp. Yang lebih jelas berguna (seperti sesi dan otentikasi) tampaknya mempunyai ketergantungan Django ORM yang jelas.
Travis Bradshaw

2
Pada dasarnya semua addon yang tidak memiliki models.py akan bekerja dengan sempurna. Dan jika mereka memiliki models.py Anda mungkin dapat melakukan konversi 1-ke-1 ke bigtable dan tetap menggunakannya jika Anda mau. Beberapa yang saya gunakan adalah django_annoying, django_debug_toolbar, dan dari bagian contrib csrf, humanize, dan tentunya admin.
Paul Tarjan

11

Saya pikir semua jawaban ini agak usang.

Sekarang Anda bisa menggunakan Google Cloud SQL

Django adalah kerangka web Python pihak ketiga yang populer. Jika digabungkan dengan Google Cloud SQL, semua fungsinya dapat didukung sepenuhnya oleh aplikasi yang berjalan di App Engine . Dukungan untuk menggunakan Google Cloud SQL dengan Django disediakan oleh backend basis data Django khusus yang membungkus backend MySQL Django.

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

satu lagi berita baru adalah, bahwa ada dukungan BETA untuk PostgreSQL


3

Saya memiliki pengalaman menggunakan Django dan bukan GAE. Dari pengalaman saya dengan Django itu adalah pengaturan yang sangat sederhana dan proses penyebaran sangat mudah dalam hal proyek web. Memang saya harus belajar Python untuk benar-benar menguasai banyak hal, tetapi pada akhirnya saya akan menggunakannya lagi dalam sebuah proyek. Ini hampir 2 tahun yang lalu sebelum mencapai 1.0 jadi saya pengetahuan saya agak ketinggalan jaman.

Jika Anda khawatir tentang mengubah platform, maka ini akan menjadi pilihan yang lebih baik.


1
Terima kasih atas tanggapan cepat Anda! Meskipun saya setuju bahwa Django adalah kerangka kerja yang cepat untuk dimulai, itu tidak terlalu menjadi perhatian kami. Kami memiliki empat pengembang Python yang cukup berpengalaman dengan latar belakang pengembangan web, jadi memulai dengan kerangka kerja apa pun akan menjadi cepat dan mudah. Tetapi pertanyaannya tetap, ketika memilih antara Django dan webapp pada GAE, mana pilihan yang lebih baik dan mengapa ?
Travis Bradshaw

@ Woot4Moo jika tidak ada pengalaman dengan GAE apakah Anda menerapkannya ke, saya baru mengenal GAE tetapi harganya cukup membingungkan saya, biaya hughe acak, saya berpikir pythonanywhere, dapatkah Anda memberikan saya beberapa rekomendasi?
Manza

0

Saya tidak bisa menjawab pertanyaan itu tetapi Anda mungkin ingin melihat web2py. Ini mirip dengan Django dalam banyak hal tetapi lapisan abstraksi basis datanya bekerja pada GAE dan mendukung sebagian besar fungsionalitas GAE (tidak semua tetapi kami mencoba mengejar ketinggalan). Dengan cara ini jika GAE bekerja untuk Anda dengan baik, jika tidak, Anda dapat memindahkan kode Anda ke db yang berbeda (SQLite, MySQL, PostgreSQL, Oracle, MSSQL, FireBird, DB2, Informix, Ingres, dan - soon - Sybase dan MongoDB ).


0

Jika Anda memutuskan untuk menjalankan aplikasi Anda di luar GAE, Anda masih dapat menggunakan Django. Anda tidak akan terlalu beruntung dengan aplikasi web GAE


Terima kasih, meskipun saya menyebutkan dengan tepat dalam pertanyaan awal: "Akhirnya, jelas bahwa menggunakan Django memang memiliki keuntungan dalam menyediakan" strategi keluar "jika nanti kita ingin menjauh dari GAE dan membutuhkan platform untuk menargetkan eksodus. "
Travis Bradshaw

0

Saya masih sangat baru dalam pengembangan mesin Google App, tetapi antarmuka yang disediakan Django memang tampak jauh lebih bagus daripada default. Manfaat akan bergantung pada apa yang Anda gunakan untuk menjalankan Django pada mesin aplikasi. Pembantu Mesin Aplikasi Google untuk Django memungkinkan Anda menggunakan kekuatan penuh Mesin Aplikasi Google dengan beberapa fungsi Django di sampingnya.

Django non-rel mencoba menyediakan kekuatan Django sebanyak mungkin, tetapi berjalan pada mesin-aplikasi untuk kemungkinan skalabilitas ekstra. Khususnya, ini menyertakan model Django (salah satu fitur inti Django), tetapi ini adalah abstraksi yang bocor karena perbedaan antara basis data relasional dan tabel besar. Kemungkinan besar akan ada pengorbanan dalam fungsionalitas dan efisiensi, serta peningkatan jumlah bug dan kebiasaan. Tentu saja, ini mungkin sepadan dalam keadaan seperti yang dijelaskan dalam pertanyaan, tetapi sebaliknya akan sangat merekomendasikan menggunakan helper di awal karena kemudian Anda memiliki opsi untuk berpindah ke mesin aplikasi murni atau Django non-rel nanti. Juga, jika anda beralih ke Django non-rel,

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.