Memilih Java vs Python di Google App Engine


161

Saat ini Google App Engine mendukung Python & Java. Dukungan Java kurang matang. Namun, Java tampaknya memiliki daftar perpustakaan yang lebih panjang dan khususnya dukungan untuk bytecode Java terlepas dari bahasa yang digunakan untuk menulis kode itu. Bahasa mana yang akan memberikan kinerja yang lebih baik dan lebih banyak kekuatan? Mohon saran. Terima kasih!

Edit: http://groups.google.com/group/google-appengine-java/web/will-it-play-in-app-engine?pli=1

Sunting: Dengan "kekuatan" yang saya maksud adalah pengembangan yang lebih baik dan penyertaan perpustakaan yang tersedia di luar kerangka kerja. Python hanya mengizinkan pustaka Python murni.


sekarang Google App Engine mendukung Go (percobaan). Apa kesulitan Anda tentang itu?
Benjamin Crouzier

@ pinouchon Saya sudah mulai menggunakan Go, dan menyebarkannya dalam produksi di GAE. GO bekerja dengan sangat baik pada GAE, kompilasi dalam beberapa detik. Pilih kerangka kerja web Anda dengan bijak :-)
Michele Giuseppe Fadda

Jawaban:


123

Saya bias (menjadi ahli Python tetapi cukup berkarat di Jawa) tapi saya pikir runtime Python dari GAE saat ini lebih maju dan lebih berkembang daripada runtime Java - yang pertama memiliki satu tahun ekstra untuk berkembang dan matang, setelah semua .

Bagaimana hal-hal akan berjalan maju tentu saja sulit untuk diprediksi - permintaan mungkin lebih kuat di sisi Jawa (terutama karena itu bukan hanya tentang Jawa, tetapi bahasa lain juga bertengger di atas JVM, jadi itu adalah cara untuk menjalankan misalnya PHP atau kode Ruby di App Engine); Namun tim Mesin App Python memang memiliki keuntungan memiliki Guido van Rossum, penemu Python dan insinyur yang luar biasa kuat.

Dalam hal fleksibilitas, mesin Java, seperti yang telah disebutkan, memang menawarkan kemungkinan menjalankan bytecode JVM yang dibuat oleh berbagai bahasa, bukan hanya Java - jika Anda berada di toko multi-bahasa yang positif cukup besar. Begitu juga sebaliknya, jika Anda membenci Javascript tetapi harus menjalankan beberapa kode di peramban pengguna, Java GWT (menghasilkan Javascript untuk Anda dari pengkodean tingkat Java) jauh lebih kaya dan lebih maju daripada alternatif sisi Python (dalam praktiknya, jika Anda memilih Python, Anda akan menulis sendiri beberapa JS untuk tujuan ini, sementara jika Anda memilih Java GWT adalah alternatif yang dapat digunakan jika Anda tidak suka menulis JS).

Dalam hal perpustakaan, ini cukup mudah - JVM cukup terbatas (tidak ada utas, tidak ada pemuat kelas khusus, tidak ada JNI, tidak ada DB relasional) untuk menghambat penggunaan kembali yang sederhana dari perpustakaan Java yang ada sebanyak, atau lebih, daripada Python yang ada perpustakaan sama-sama terhambat oleh pembatasan serupa pada runtime Python.

Dalam hal kinerja, saya pikir ini adalah pekerjaan biasa, meskipun Anda harus melakukan tolok ukur pada tugas Anda sendiri - jangan mengandalkan kinerja implementasi JVM berbasis JIT yang sangat dioptimalkan dengan diskon waktu startup dan jejak kaki memori yang besar, karena mesin aplikasi lingkungan sangat berbeda (biaya awal akan sering dibayar, karena instance aplikasi Anda dimulai, dihentikan, dipindahkan ke host yang berbeda, dll, semua benar-benar untuk Anda - peristiwa seperti itu biasanya jauh lebih murah dengan lingkungan runtime Python daripada dengan JVM).

Situasi XPath / XSLT (menjadi eufemistik ...) tidak sepenuhnya sempurna di kedua sisi, huh, meskipun saya pikir ini mungkin tidak terlalu buruk di JVM (di mana, tampaknya, subset besar dari Saxon dapat dibuat untuk dijalankan , dengan hati-hati). Saya pikir itu layak membuka masalah pada halaman Appengine Issues dengan XPath dan XSLT dalam judul mereka - saat ini hanya ada masalah meminta perpustakaan tertentu, dan itu rabun: Saya tidak begitu peduli BAGAIMANA XPath / XSLT yang baik diimplementasikan, untuk Python dan / atau untuk Java, selama saya bisa menggunakannya. (Perpustakaan tertentu dapat memudahkan migrasi kode yang ada, tapi itu kurang penting daripada mampu melakukan tugas-tugas seperti "cepat menerapkan transformasi XSLT" dengan BEBERAPA cara! -). Saya tahu saya akan membintangi masalah seperti itu jika diutarakan dengan baik (terutama dengan cara yang mandiri dalam bahasa).

Last but not least: ingat bahwa Anda dapat memiliki versi aplikasi yang berbeda (menggunakan datastore yang sama) beberapa di antaranya diimplementasikan dengan runtime Python, beberapa dengan runtime Java, dan Anda dapat mengakses versi yang berbeda dari "default / aktif "satu dengan URL eksplisit. Jadi Anda bisa menggunakan kode Python dan Java (dalam versi berbeda dari aplikasi Anda) menggunakan dan memodifikasi penyimpanan data yang sama, memberi Anda lebih banyak fleksibilitas (walaupun hanya satu yang akan memiliki URL "bagus" seperti foobar.appspot.com - yang mungkin penting hanya untuk diakses oleh pengguna interaktif di browser, saya kira ;-).


9
GWT terutama merupakan teknologi sisi klien - Anda dapat menggunakannya terlepas dari apakah back end Anda adalah python atau java. Anda kehilangan sedikit gula sintaksis dengan memiliki untuk melakukan rpc lebih JSON daripada GWT dibangun di RPC, tetapi jika Anda benci JS dan melakukan python itu masih layak lihat :)
Peter Recore

9
Ada Pyjamas ( pyjs.org ) sebagai alternatif Pythonic untuk GWT - itu akan mengambil kode Python dan mengkompilasinya ke Javascript, seperti halnya GWT untuk kode Java.
Dave Kirby

7
Hanya untuk memberikan perspektif "5 tahun kemudian". Sebagai Pengembang Java, saya merasa GAE menjalankan tumpukan yang sudah usang. Anda tidak akan menemukan dukungan Java 8 , ( mereka menjalankan Java 6 serta wadah Jetty 6 legacy dengan Servlet API 2.5 ), semuanya Dukungan Java di GAE masih macet di 2010. Sementara saya suka kesederhanaan GAE dan Layanan Google Powerful, Saya tidak bisa merekomendasikan GAE untuk Java sampai mereka meningkatkan tumpukannya.
Anthony Accioly

72

Tonton aplikasi ini untuk perubahan kinerja Python dan Java:

http://gaejava.appspot.com/ (sunting: permintaan maaf, tautan rusak sekarang. Tetapi para yang masih berlaku saat saya melihatnya berjalan terakhir)

Saat ini, Python dan menggunakan API tingkat rendah di Jawa lebih cepat daripada JDO di Jawa, untuk pengujian sederhana ini . Setidaknya jika mesin yang mendasarinya berubah, aplikasi itu harus mencerminkan perubahan kinerja.


5
Dengan segala hormat, saya menemukan tes ini cukup sederhana untuk menjadi tidak berarti. Untuk apa itu layak ... Jika Anda menggunakan Java / GAE, saya sarankan menggunakan API tingkat rendah dan menghindari JDO atau kerangka kerja lainnya. Lebih penting lagi, JDO memberi Anda 'perasaan' Anda bekerja dengan database relasional, yang bisa 'menyesatkan'.
Mo'in Creemers

1
Saya setuju tentang menghindari JDO, sebagian karena alasan yang Anda sebutkan tetapi juga karena lebih lambat daripada tingkat rendah. (Yang ditunjukkan oleh tes pada umumnya.) Ini hanya mengisyaratkan bahwa ada perbedaan kinerja, jadi jangan gunakan JDO atau tes untuk tugas spesifik Anda. Saya telah memindahkan semua kode saya sendiri dari JDO dan API tingkat rendah ke Objectify. Dan dalam hal apapun, itu juga menunjukkan bahwa Python tentu saja bukan sepupu miskin kinerja pada GAE.
Richard Watson

1
Aplikasi Anda, itu melempar Kesalahan Server Internal.
tomdemuyt

1
Terima kasih tom. Bukan aplikasi saya, sayangnya. Telah mengirim seseorang yang mungkin ditautkan.
Richard Watson

1
Saya ingin melihat bagaimana objektivitas membandingkan dalam tes ini
Moshe Shaham

18

Berdasarkan pengalaman menjalankan VMs ini pada platform lain, saya akan mengatakan bahwa Anda mungkin akan mendapatkan lebih banyak kinerja mentah dari Jawa daripada Python. Namun, jangan meremehkan nilai jual Python: Bahasa Python jauh lebih produktif dalam hal baris kode - kesepakatan umum adalah bahwa Python membutuhkan sepertiga kode program Java yang setara, sambil tetap sebagai atau lebih mudah dibaca. Manfaat ini dikalikan dengan kemampuan untuk menjalankan kode segera tanpa langkah kompilasi yang eksplisit.

Sehubungan dengan perpustakaan yang tersedia, Anda akan menemukan bahwa banyak perpustakaan runtime Python yang luas bekerja di luar kotak (seperti halnya Java). Kerangka kerja Django Web yang populer ( http://www.djangoproject.com/ ) juga didukung di AppEngine.

Mengenai 'kekuatan', sulit untuk mengetahui apa yang Anda maksud, tetapi Python digunakan dalam banyak domain berbeda, terutama Web: YouTube ditulis dalam Python, seperti halnya Sourceforge (pada minggu lalu).


Judy2K terima kasih! Dengan kekuatan yang saya maksud bisa melakukan lebih banyak hal dan mudah diperluas.
Viet

15

Juni 2013: Video ini adalah jawaban yang sangat bagus oleh seorang insinyur google:

http://www.youtube.com/watch?v=tLriM2krw2E

TLDR; adalah:

  • Pilih bahasa yang Anda dan tim Anda paling produktif dengannya
  • Jika Anda ingin membangun sesuatu untuk produksi: Java atau Python (not Go)
  • Jika Anda memiliki tim besar dan basis kode yang kompleks: Java (karena analisis kode statis dan refactoring)
  • Tim kecil yang beralih dengan cepat: Python (walaupun Java juga oke)

9

Sebuah pertanyaan penting untuk dipertimbangkan dalam memutuskan antara Python dan Java adalah bagaimana Anda akan menggunakan datastore dalam setiap bahasa (dan sebagian besar sudut lain terhadap pertanyaan asli telah dibahas dengan cukup baik dalam topik ini).

Untuk Java , metode standar adalah menggunakan JDO atau JPA. Ini bagus untuk portabilitas tetapi tidak terlalu cocok untuk datastore.

API tingkat rendah tersedia tetapi ini terlalu rendah untuk penggunaan sehari-hari - lebih cocok untuk membangun perpustakaan pihak ketiga.

Untuk Python ada API yang dirancang khusus untuk menyediakan aplikasi dengan akses yang mudah namun kuat ke datastore. Ini bagus kecuali bahwa itu tidak portabel sehingga mengunci Anda ke GAE.

Untungnya, ada solusi yang dikembangkan untuk kelemahan yang terdaftar untuk kedua bahasa.

Untuk Java , API tingkat rendah sedang digunakan untuk mengembangkan perpustakaan persistensi yang jauh lebih cocok untuk datastore daripada JDO / JPA (IMO). Contohnya termasuk proyek Siena , dan Objectify .

Saya baru-baru ini mulai menggunakan Objectify dan menemukannya sangat mudah digunakan dan cocok untuk datastore, dan popularitasnya yang semakin meningkat telah diterjemahkan ke dalam dukungan yang baik. Misalnya, Objectify secara resmi didukung oleh layanan Cloud Endpoints baru Google. Di sisi lain, Objectify hanya berfungsi dengan datastore, sementara Siena 'terinspirasi' oleh datastore tetapi dirancang untuk bekerja dengan berbagai database SQL dan datastore NoSQL.

Untuk Python , ada upaya yang dilakukan untuk memungkinkan penggunaan API datastore Python GAE dari GAE. Salah satu contoh adalah backend SQLite yang dirilis Google untuk digunakan dengan SDK, tapi saya ragu mereka bermaksud ini untuk tumbuh menjadi sesuatu yang siap produksi. Proyek TyphoonAE mungkin memiliki lebih banyak potensi, tetapi saya juga berpikir itu belum siap untuk produksi (koreksi saya jika saya salah).

Jika ada yang punya pengalaman dengan salah satu dari alternatif ini atau mengetahui orang lain, silakan tambahkan mereka dalam komentar. Secara pribadi, saya benar-benar menyukai datastore GAE - Saya merasa ini merupakan peningkatan yang cukup besar atas AWS SimpleDB - jadi saya berharap atas keberhasilan upaya ini untuk meringankan beberapa masalah dalam menggunakannya.


7

Saya sangat merekomendasikan Java untuk GAE dan inilah alasannya:

  1. Kinerja: Java berpotensi lebih cepat daripada Python.
  2. Pengembangan python berada di bawah tekanan kurangnya perpustakaan pihak ketiga. Misalnya, tidak ada XSLT untuk Python / GAE sama sekali. Hampir semua pustaka Python adalah binding C (dan itu tidak didukung oleh GAE).
  3. API Memcache: Java SDK memiliki kemampuan lebih menarik daripada Python SDK.
  4. API Datastore: JDO sangat lambat, tetapi API Java datastore asli sangat cepat dan mudah.

Saya menggunakan Java / GAE dalam pengembangan sekarang.


1
@ Paul - bisakah Anda merekomendasikan (atau memberikan tautan ke) cara terbaik untuk menangani ketekunan menggunakan Java pada GAE jika JDO bukan cara untuk melakukannya?
Tandai

1
@Mark, saya minta maaf atas keterlambatan. Saya pikir code.google.com/p/objectify-appengine adalah pilihan terbaik untuk saat ini.
Paul

7
-1 untuk kepalsuan langsung dalam poin # 2 dan # 3 dan untuk # 4 tidak masuk akal.
Triptych

@ Triptych, beri tahu saya apa nama prosesor XSLT untuk python / GAE? Dan apa yang setara dengan operasi CAS (putIfUntouched) untuk memcache / python / GAE?
Paul

1
@ Paul jika Anda ingin saya mempertimbangkan hal-hal itu sebagai bagian dari jawaban Anda, Anda harus memasukkannya dalam jawaban Anda. Sebaliknya, Anda memasukkan serangkaian kebenaran setengah. Tidak ada yang memilih bahasa berdasarkan kasus sudut Anda datang dengan sekarang.
Triptych

6

Seperti yang telah Anda identifikasi, menggunakan JVM tidak membatasi Anda untuk menggunakan bahasa Java. Daftar bahasa dan tautan JVM dapat ditemukan di sini . Namun , Google App Engine memang membatasi set kelas yang dapat Anda gunakan dari set Java SE normal, dan Anda akan ingin menyelidiki jika salah satu dari implementasi ini dapat digunakan pada engine app.

EDIT: Saya melihat Anda telah menemukan daftar seperti itu

Saya tidak dapat mengomentari kinerja Python. Namun, JVM adalah platform yang sangat kuat untuk kinerja-bijaksana, mengingat kemampuannya untuk secara dinamis mengkompilasi dan mengoptimalkan kode selama waktu berjalan.

Pada akhirnya kinerja akan tergantung pada apa yang aplikasi Anda lakukan, dan bagaimana Anda mengkodekannya. Dengan tidak adanya info lebih lanjut, saya pikir tidak mungkin untuk memberikan petunjuk lagi di area ini.


Terima kasih atas balasan secepatnya, Brian. Saya bermaksud memfokuskan aplikasi pada url fetching dan pemrosesan XML parsing & XSLT. Akan lebih sedikit menyajikan konten HTTP ke browser.
Viet

6

Saya kagum dengan betapa bersih, mudah, dan masalah membebaskan Python / Django SDK. Namun saya mulai mengalami situasi di mana saya perlu mulai melakukan lebih banyak JavaScript dan berpikir saya mungkin ingin mengambil keuntungan dari GWT dan utilitas Java lainnya. Saya baru mendapatkan setengah dari tutorial Java GAE, dan memiliki satu masalah setelah yang lain: masalah konfigurasi Eclipse, versiRE JRE, kompleksitas Java yang mematikan pikiran, dan tutorial yang membingungkan dan mungkin rusak. Memeriksa situs ini dan orang lain yang terhubung dari sini meraihnya untuk saya. Saya akan kembali ke Python, dan saya akan melihat ke Piyama untuk membantu dengan tantangan JavaScript saya.


5

Saya sedikit terlambat untuk percakapan, tapi ini dua sen saya. Saya benar-benar kesulitan memilih antara Python dan Java, karena saya fasih dalam kedua bahasa. Seperti yang kita semua tahu, ada kelebihan dan kekurangan untuk keduanya, dan Anda harus memperhitungkan persyaratan Anda dan kerangka kerja yang paling cocok untuk proyek Anda.

Seperti yang biasanya saya lakukan dalam dilema jenis ini, saya mencari angka untuk mendukung keputusan saya. Saya memutuskan untuk menggunakan Python karena berbagai alasan, tetapi dalam kasus saya, ada satu plot yang merupakan titik kritis. Jika Anda mencari "Google App Engine" di GitHub pada September 2014 , Anda akan menemukan gambar berikut:

Statistik Bahasa GAE

Mungkin ada banyak bias dalam angka-angka ini, tetapi secara keseluruhan, ada tiga kali lebih banyak repositori GAE Python daripada repositori Java GAE. Tidak hanya itu, tetapi jika Anda mendaftar proyek dengan "jumlah bintang" Anda akan melihat bahwa sebagian besar proyek Python muncul di bagian atas (Anda harus memperhitungkan bahwa Python telah ada lebih lama). Bagi saya, ini menjadi alasan kuat bagi Python karena saya memperhitungkan adopsi komunitas & dukungan, dokumentasi, dan ketersediaan proyek sumber terbuka.


3

Ini adalah pertanyaan yang bagus, dan saya pikir banyak tanggapan telah memberikan pandangan yang baik tentang pro dan kontra di kedua sisi pagar. Saya sudah mencoba AppEngine berbasis Python dan JVM (dalam kasus saya saya menggunakan Gaelyk yang merupakan kerangka kerja aplikasi Groovy yang dibangun untuk AppEngine). Ketika datang ke kinerja pada platform, satu hal yang saya tidak mempertimbangkan sampai menatap saya di muka adalah implikasi dari "Permintaan Muatan" yang terjadi di sisi Jawa pagar. Saat menggunakan Groovy, permintaan pemuatan ini adalah pembunuh.

Saya menempatkan posting bersama pada topik ( http://distractable.net/coding/google-appengine-java-vs-python-performance-comparison/ ) dan saya berharap menemukan cara untuk mengatasi masalah tersebut, tetapi jika tidak saya pikir saya akan kembali ke kombinasi Python + Django sampai dingin mulai permintaan java memiliki dampak yang lebih kecil.


3

Berdasarkan seberapa banyak saya mendengar orang Jawa mengeluh tentang AppEngine dibandingkan dengan pengguna Python, saya akan mengatakan Python jauh lebih sedikit stres untuk digunakan.


7
Saya mendengar bahwa pemilik Ford mengeluh tentang mobil mereka jauh lebih banyak daripada pemilik Koenigsegg. Kenapa bisa begitu?
Axarydax

2

Ada juga proyek Unladen Swallow , yang tampaknya didanai Google jika bukan milik Google. Mereka mencoba mengimplementasikan backend berbasis LLVM untuk bytecode Python 2.6.1, sehingga mereka dapat menggunakan JIT dan berbagai optimisasi kode asli / GC / multi-core yang bagus. (Kutipan yang bagus: "Kami bercita-cita untuk tidak melakukan karya asli, alih-alih menggunakan sebanyak 30 tahun terakhir dari penelitian mungkin.") Mereka mencari 5x mempercepat untuk CPython.

Tentu saja ini tidak menjawab pertanyaan langsung Anda, tetapi mengarah ke "penutupan kesenjangan" (jika ada) di masa depan (mudah-mudahan).


1
Unladen Swallow sekarang merupakan proyek mati dan komit terakhir berusia lebih dari satu tahun .
tshepang

2

Keindahan python saat ini adalah seberapa baik berkomunikasi dengan bahasa lain. Misalnya Anda dapat memiliki kedua python dan java di tabel yang sama dengan Jython. Tentu saja jython meskipun sepenuhnya mendukung perpustakaan java itu tidak sepenuhnya mendukung perpustakaan python. Tapi ini solusi ideal jika Anda ingin mengacaukan Java Libraries. Bahkan memungkinkan Anda untuk mencampurnya dengan kode Java tanpa kode tambahan.

Tetapi bahkan python sendiri telah membuat beberapa langkah untuk diwaspadai. Lihat ctypes misalnya, di dekat kecepatan C, akses langsung ke perpustakaan C semua ini tanpa meninggalkan kenyamanan pengkodean python. Cython selangkah lebih maju, memungkinkan untuk mencampur kode c dengan kode python dengan mudah, atau bahkan jika Anda tidak ingin mengacaukan dengan c atau c ++, Anda masih dapat kode dalam python tetapi menggunakan variabel tipe statis membuat program python Anda secepat C apps . Cython digunakan dan didukung oleh Google.

Kemarin saya bahkan menemukan alat untuk python ke inline C atau bahkan Assembly (lihat CorePy), Anda tidak bisa mendapatkan yang lebih kuat dari itu.

Python jelas merupakan bahasa yang sangat matang, tidak hanya berdiri sendiri, tetapi mampu bekerja sama dengan bahasa lain dengan mudah. Saya pikir itulah yang membuat python solusi ideal bahkan dalam skenario yang sangat maju dan berat.

Dengan python Anda dapat memiliki akses ke C / C ++, Java, .NET dan banyak perpustakaan lainnya dengan hampir nol pengkodean tambahan memberi Anda juga bahasa yang meminimalkan, menyederhanakan dan memperindah pengkodean. Ini bahasa yang sangat menggoda.


Pertanyaannya adalah tentang java vs python di GAE, yang memiliki banyak batasan. Karenanya, argumen Anda tidak dapat diterapkan.
Daniyar

Saya setuju dengan @Dyaryar, bahwa jawaban ini sedikit (atau mungkin sama sekali) off the beat, tapi saya suka jawabannya dan ini adalah sesuatu yang saya cari. Terima kasih Kilon untuk berbagi pengetahuan ini. Mungkin ini adalah tempat yang salah, tetapi Anda tentu saja berbagi pengetahuan. +1 dan pujian untuk itu.
zeFree

1

Pergi dengan Python meskipun GWT tampaknya sangat cocok untuk jenis aplikasi yang saya kembangkan. JPA sangat kacau di GAE (mis. Tidak ada @Embeddable dan batasan tidak terdokumentasi yang tidak jelas lainnya). Setelah menghabiskan satu minggu, saya dapat mengatakan bahwa Java tidak merasa tepat pada GAE saat ini.


1

Satu pemikiran untuk dipertimbangkan adalah kerangka kerja yang ingin Anda gunakan. Tidak semua kerangka kerja di sisi Java sangat cocok untuk aplikasi yang berjalan di App Engine, yang agak berbeda dari server aplikasi Java tradisional.

Satu hal yang perlu dipertimbangkan adalah waktu startup aplikasi. Dengan aplikasi web Java tradisional, Anda tidak perlu memikirkan hal ini. Aplikasi dimulai dan kemudian dijalankan. Tidak masalah jika startup membutuhkan waktu 5 detik atau beberapa menit. Dengan App Engine Anda mungkin berakhir dalam situasi di mana aplikasi hanya dimulai ketika permintaan masuk. Ini berarti pengguna sedang menunggu saat aplikasi Anda boot. Fitur GAE baru seperti instance yang dipesan membantu di sini, tetapi periksa dulu.

Hal lain adalah berbagai perbedaan GAE psoes di Jawa. Tidak semua kerangka kerja senang dengan batasan pada kelas apa yang dapat Anda gunakan atau fakta bahwa utas tidak diizinkan atau bahwa Anda tidak dapat mengakses sistem file lokal. Masalah-masalah ini mungkin mudah diketahui dengan hanya mencari Google tentang kompatibilitas GAE.

Saya juga melihat beberapa orang mengeluh tentang masalah dengan ukuran sesi pada kerangka UI modern (yaitu, Wicket). Secara umum kerangka kerja ini cenderung melakukan trade-off tertentu untuk membuat pembangunan menyenangkan, cepat dan mudah. Terkadang ini dapat menyebabkan konflik dengan keterbatasan App Engine.

Saya awalnya mulai mengembangkan bekerja pada GAE dengan Java, tetapi kemudian beralih ke Python karena alasan ini. Perasaan pribadi saya adalah bahwa Python adalah pilihan yang lebih baik untuk pengembangan App Engine. Saya pikir Java lebih "di rumah" misalnya di Elastic Beanstalk Amazon.

TETAPI dengan App Engine segalanya berubah sangat cepat. GAE berubah dengan sendirinya dan semakin populer, kerangka kerja juga berubah untuk mengatasi keterbatasannya.

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.