Google App Engine'de Java ve Python Seçimi


161

Google App Engine şu anda hem Python hem de Java'yı desteklemektedir. Java desteği daha az gelişmiştir. Bununla birlikte, Java'nın daha uzun bir kütüphane listesine sahip olduğu ve özellikle bu kodu yazmak için kullanılan dillerden bağımsız olarak Java bayt kodunu desteklediği görülüyor. Hangi dil daha iyi performans ve daha fazla güç verecek? Tavsiye lütfen. Teşekkür ederim!

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

Düzenleme: "Güç" ile daha iyi genişletilebilirlik ve çerçeve dışında kullanılabilir kütüphanelerin dahil edilmesi demek. Python sadece saf Python kütüphanelerine izin verir.


şimdi Google App Engine Go (deneysel) özelliğini destekliyor . Bununla ilgili düşüncelerin neler?
Benjamin Crouzier

@pinouchon Go kullanmaya başladım ve bunu GAE üzerinde üretime yerleştirdim. GO, GAE'de çok iyi çalışır, birkaç saniye içinde derler. Akıllıca web çerçeve seçin :-)
Michele Giuseppe Fadda

Yanıtlar:


123

Önyargılıyım (bir Python uzmanı olmakla birlikte Java'da oldukça paslı), ancak GAE'nin Python çalışma zamanının şu anda Java çalışma zamanından daha gelişmiş ve daha gelişmiş olduğunu düşünüyorum - eski, sonuçta geliştirmek ve olgunlaşmak için bir yıl daha geçirdi. .

İlerlemenin nasıl devam edeceği elbette tahmin etmek zordur - Java tarafında talep muhtemelen daha güçlüdür (özellikle sadece Java ile ilgili değil, aynı zamanda JVM'nin üzerine yerleştirilmiş diğer diller de, bu yüzden örneğin PHP'yi çalıştırmanın yolu veya App Engine'de Ruby kodu); Python App Engine ekibi, Python'un mucidi ve inanılmaz derecede güçlü bir mühendis olan Guido van Rossum'da yer almanın avantajına sahip.

Esneklik açısından, Java motoru, daha önce de belirtildiği gibi, çok büyük bir pozitif olan çok dilli bir dükkandaysanız, sadece Java tarafından değil, farklı diller tarafından yapılan JVM bayt kodunu çalıştırma imkanı sunar. Bunun tersine, Javascript'ten nefret ediyorsanız ancak kullanıcının tarayıcısında bir kod yürütmeniz gerekiyorsa, Java'nın GWT'si (Java düzeyindeki kodlamanızdan sizin için Javascript'i oluşturmak) Python tarafındaki alternatiflerden çok daha zengin ve daha gelişmiş (pratikte, Python, bu amaç için kendinize bazı JS yazacaksınız, Java seçerseniz JS yazarken nefret ediyorsanız kullanılabilir bir alternatiftir).

Kütüphaneler açısından bu bir yıkamadır - JVM, mevcut Python'dan basit olarak yeniden kullanılmasını engellemek için yeterince kısıtlanmıştır (iş parçacığı, özel sınıf yükleyici yok, JNI yok, ilişkisel DB yok). kütüphaneler benzer şekilde Python çalışma zamanındaki benzer kısıtlamalarla engellenir.

Performans açısından, bunun bir yıkama olduğunu düşünüyorum, ancak kendi görevlerinizi karşılaştırmalısınız - büyük başlangıç ​​zamanlarını ve bellek ayak izlerini azaltan yüksek düzeyde optimize edilmiş JIT tabanlı JVM uygulamalarının performansına güvenmeyin, çünkü uygulama motoru ortam çok farklıdır (uygulamanızın örnekleri başlatıldığından, durdurulduğundan, farklı ana bilgisayarlara taşındığından vb. başlangıç ​​maliyetleri sık sık ödenecektir - bu tür olaylar genellikle Python çalışma zamanı ortamlarında JVM'lerden daha ucuzdur).

XPath / XSLT durumu (euphemistik olmak için ...) her iki tarafta tam olarak mükemmel değil, iç çek, ama JVM'de biraz daha az kötü olabileceğini düşünüyorum (görünüşe göre, Saxon'un önemli alt kümelerinin çalıştırılabileceği düşünülüyor) , biraz dikkatle). Bence XPath ve XSLT ile Appengine Sorunları başlıklarında sorunları açmaya değer - şu anda sadece belirli kütüphaneleri isteyen sorunlar var ve bu miyop: Gerçekten iyi bir XPath / XSLT'nin nasıl uygulandığını umursamıyorum, Python ve / veya Java için kullanıyorum. (Belirli kütüphaneler mevcut kodun taşınmasını kolaylaştırabilir, ancak bu, "XSLT dönüşümünü hızlı bir şekilde uygulayın" gibi görevleri BAZI şekilde gerçekleştirmekten daha az önemlidir! -). İyi ifade edilmiş olsaydı (özellikle dilden bağımsız bir şekilde) böyle bir konuya yıldız koyacağımı biliyorum.

Son fakat en önemlisi: uygulamanızın, bazıları Python çalışma zamanı, bazıları Java çalışma zamanı ile uygulanan farklı sürümlerine sahip olabileceğinizi ve "varsayılan / etkin" "açık URL'lere sahip bir tane. Her iki Python olabilir Yani ve kullanım (uygulama farklı versiyonları), Java kodu ve olsa (size daha fazla esneklik verilmesi, aynı veri deposunu değiştirmek sadece tek bir foobar.appspot.com olarak "güzel" URL olacak - ki bu sadece tarayıcılarda etkileşimli kullanıcıların erişimi için önemli, sanırım ;-).


9
GWT öncelikle bir istemci tarafı teknolojisidir - arka ucunuzun python veya java olmasına bakılmaksızın kullanabilirsiniz. RPC'de yerleşik GWT yerine JSON üzerinden rpc yapmak zorunda kalarak biraz sözdizimsel şeker kaybedersiniz, ancak JS'den nefret edip python yaparsanız hala bir göz atmaya değer :)
Peter Recore

9
GWT'ye Pythonic alternatifi olarak Pijamalar ( pyjs.org ) vardır - PWhon kodunu alır ve GWT'nin Java kodu için yaptığı gibi Javascript'e derler.
Dave Kirby

7
Sadece "5 yıl sonra" perspektifi vermek. Bir Java Geliştiricisi olarak GAE'nin eski bir yığın çalıştırdığını hissediyorum. Java 8 desteği bulamazsınız ( Java 6 ve Servlet API 2.5 ile eski Jetty 6 kapsayıcısı çalıştırıyorlar ), GAE'deki tüm Java Desteği 2010'da hala takılı kalıyor. GAE basitliğini ve Google Güçlü Hizmetleri'ni sevdiğim halde, Yığını yükseltinceye kadar Java için GAE tavsiye edemez.
Anthony Accioly

72

Python ve Java performansındaki değişiklikler için bu uygulamayı izleyin:

http://gaejava.appspot.com/ (değiştir: özür dilerim, bağlantı şimdi kesildi. Ama son çalıştığını gördüğümde aşağıdaki para hala uygulandı)

Şu anda, bu basit test için Python ve Java'da düşük seviyeli API kullanımı Java'daki JDO'dan daha hızlıdır . En azından altta yatan motor değişirse, bu uygulama performans değişikliklerini yansıtmalıdır.


5
Tüm saygımla, bu testi anlamsız olacak kadar basit buluyorum. Değer için ... Java / GAE kullanıyorsanız, Düşük düzey API'yi kullanmanızı ve JDO'dan veya başka bir çerçeveden kaçınmanızı öneririm. Daha da önemlisi, JDO size 'yanıltıcı' olabilen ilişkisel bir veritabanı ile çalıştığınız 'hissini' verir.
Mo'in Creemers

1
JDO'dan kaçınmayı, kısmen belirttiğiniz nedenden dolayı değil, aynı zamanda düşük seviyeden daha yavaş olduğu için de katılıyorum. (Testin genellikle gösterdiği gibi.) Sadece performans farklılıkları olduğunu ima eder, bu nedenle ya JDO kullanmayın ya da özel göreviniz için test yapmayın. Kendi kodumu JDO'dan ve düşük seviye API'dan Objectify'a taşıdım. Ve her durumda, Python'un kesinlikle GAE'deki performansın kötü kuzeni olmadığını da gösteriyor.
Richard Watson

1
Uygulamanız Dahili Sunucu Hatası veriyor.
tomdemuyt

1
Teşekkürler Tom. Ne yazık ki benim app değil. Bağlantı kurulabilecek birini postayla göndermiş olabilirsiniz.
Richard Watson

1
objektifleştirmenin bu testte nasıl karşılaştırıldığını görmek istiyorum
Moshe Shaham

18

Bu VM'leri diğer platformlarda çalıştırma deneyimine dayanarak, Java'dan muhtemelen Python'dan daha fazla ham performans elde edeceğinizi söyleyebilirim. Bununla birlikte, Python'un satış noktalarını hafife almayın: Python dili kod satırları açısından çok daha üretken - genel anlaşma, Python'un eşdeğer bir Java programının kodunun üçte birini gerektirmesine rağmen okunabilir olarak kalmasıdır. Bu avantaj, açık bir derleme adımı olmadan hemen kod çalıştırma yeteneği ile çarpılır.

Kullanılabilir kitaplıklarla ilgili olarak, kapsamlı Python çalışma zamanı kitaplığının çoğunun kutuda çalıştığını göreceksiniz (Java gibi). Popüler Django Web çerçevesi ( http://www.djangoproject.com/ ) AppEngine'de de desteklenmektedir.

'Güç' ile ilgili olarak, ne demek istediğinizi bilmek zordur, ancak Python birçok farklı alanda, özellikle Web'de kullanılır: YouTube, Python'da, Sourceforge'da (geçen hafta itibariyle) yazılmıştır.


Teşekkürler Judy2K! Güç ile demek istediğim daha fazla şey yapabilir ve kolayca genişletilebilir.
Vietnam

15

Haziran 2013: Bu video bir google mühendisi tarafından çok iyi bir cevap:

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

TLDR; dır-dir:

  • Sizin ve ekibinizin en üretken olduğu dili seçin
  • Üretim için bir şeyler oluşturmak istiyorsanız: Java veya Python (Go değil)
  • Büyük bir ekibiniz ve karmaşık bir kod tabanınız varsa: Java (statik kod analizi ve yeniden düzenleme nedeniyle)
  • Hızlı yinelenen küçük takımlar: Python (Java da iyi olsa da)

9

Python ve Java arasında karar verirken göz önünde bulundurulması gereken önemli bir soru , veri deposunu her dilde nasıl kullanacağınızdır (ve orijinal sorunun diğer açılarının çoğu bu konuda zaten iyi bir şekilde ele alınmıştır).

Java için standart yöntem JDO veya JPA kullanmaktır. Bunlar taşınabilirlik için mükemmeldir ancak veri deposuna çok uygun değildir.

Düşük düzeyli bir API kullanılabilir, ancak bu günlük kullanım için çok düşük bir düzeydir - 3. taraf kitaplıkları oluşturmak için daha uygundur.

Python için, uygulamalara veri deposuna kolay ancak güçlü erişim sağlamak için özel olarak tasarlanmış bir API vardır. Taşınabilir olması dışında harika, bu yüzden sizi GAE'ye kilitler.

Neyse ki, her iki dil için de listelenen zayıflıklar için çözümler geliştirilmektedir.

Java için , düşük düzeyli API, veri deposuna ve ardından JDO / JPA'ya (IMO) çok daha uygun olan kalıcılık kitaplıkları geliştirmek için kullanılmaktadır. Örnekler arasında Siena projesi ve Objectify sayılabilir .

Yakın zamanda Objectify'ı kullanmaya başladım ve kullanımı çok kolay ve veri deposuna çok uygun buluyorum ve artan popülaritesi iyi desteğe dönüştü. Örneğin, Objectify Google'ın yeni Cloud Endpoints hizmeti tarafından resmi olarak desteklenmektedir. Öte yandan, Objectify sadece veri deposuyla çalışır, Siena ise veri deposundan 'ilham alır', ancak çeşitli SQL veritabanları ve NoSQL veri depolarıyla çalışmak üzere tasarlanmıştır.

Python için , Python GAE veri deposu API'sının GAE dışında kullanılmasına izin vermek için çaba sarf edilmektedir. Bir örnek, Google'ın SDK ile kullanım için serbest bıraktığı SQLite arka ucudur, ancak bunun hazır bir şeye dönüşmesi niyetinde olduklarından şüpheliyim. TyphoonAE projesi muhtemelen daha potansiyel var ama (hatam varsa doğru ben) henüz iki üretim hazır olduğunu sanmıyorum.

Herkes bu alternatiflerden herhangi biri ile deneyimliyse veya başkalarını biliyorsa, lütfen bir yorumda ekleyin. Şahsen, GAE veri deposunu gerçekten çok seviyorum - AWS SimpleDB üzerinde önemli bir gelişme olarak görüyorum - bu yüzden bu sorunların bazılarını hafifletme çabalarının başarılı olmasını diliyorum.


7

GAE için Java'yı şiddetle tavsiye ediyorum ve işte nedeni:

  1. Performans: Java potansiyel olarak Python'dan daha hızlıdır.
  2. Python gelişimi, üçüncü taraf kütüphanelerinin eksikliğinin baskısı altındadır. Örneğin, Python / GAE için hiç XSLT yoktur. Hemen hemen tüm Python kütüphaneleri C bağlarıdır (ve GAE tarafından desteklenmez).
  3. Memcache API'sı: Java SDK, Python SDK'dan daha ilginç yeteneklere sahiptir.
  4. Veri Deposu API'sı: JDO çok yavaş, ancak yerel Java veri deposu API'sı çok hızlı ve kolaydır.

Şu anda geliştirme aşamasında Java / GAE kullanıyorum.


1
@Paul - JDO gitmek için bir yol değilse, GAE'de Java kullanarak kalıcılığı ele almanın en iyi yolunu önerebilir misiniz (veya bağlantı verebilir misiniz)?
Mark

1
@ Mark, gecikme için özür dilerim. Kod.google.com/p/objectify-appengine şimdilik en iyi seçim olduğunu düşünüyorum .
Paul

7
# 2 ve # 3'teki açık yanlışlıklar için ve # 4 için hiçbir anlam ifade etmiyor.
Triptych

@Triptych, python / GAE için XSLT işlemcinin adı nedir? Ve memcache / python / GAE için CAS (putIfUntouched) işleminin eşdeğeri nedir?
Paul

1
@ Paul, bu şeyleri cevabınızın bir parçası olarak düşünmemi istiyorsanız, bunları cevabınıza dahil etmelisiniz. Bunun yerine, bir dizi yarım gerçeği dahil ettiniz. Kimse şu anda yaklaştığınız köşe vakalarına dayanarak bir dil seçmiyor.
Triptych

6

Tanımladığınız gibi, JVM kullanmak sizi Java dilini kullanmakla sınırlamaz. JVM dillerinin ve bağlantılarının bir listesini burada bulabilirsiniz . Bununla birlikte , Google App Engine, normal Java SE setinden kullanabileceğiniz sınıf setini kısıtlar ve bu uygulamalardan herhangi birinin uygulama motorunda kullanılıp kullanılamayacağını araştırmak istersiniz.

EDIT: Böyle bir liste bulduğunuzu görüyorum

Python'un performansı hakkında yorum yapamam. Bununla birlikte, JVM, çalışma süresi boyunca kodu dinamik olarak derleme ve optimize etme yeteneği düşünüldüğünde performans açısından çok güçlü bir platformdur.

Sonuçta performans, uygulamanızın ne yaptığına ve nasıl kodladığınıza bağlıdır. Daha fazla bilgi olmadığında, bu alanda daha fazla işaretçi vermenin mümkün olmadığını düşünüyorum.


Hemen cevap verdiğin için teşekkürler, Brian. Uygulama url getirme ve XML ayrıştırma ve XSLT işleme odaklanmak niyetinde. Tarayıcılara HTTP içeriği sunma daha az olacaktır.
Viet

6

Python / Django SDK'nın ne kadar temiz, anlaşılır ve problemsiz olduğuna hayran kaldım. Ancak daha fazla JavaScript yapmaya başlamam gereken durumlarda çalışmaya başladım ve GWT ve diğer Java yardımcı programlarından yararlanmak isteyebileceğimi düşündüm. Ben GAE Java öğretici ile sadece yarı yoldan aldım ve birbiri ardına bir sorun yaşadım: Tutulma yapılandırma sorunları, JRE versionitis, Java zihin-uyuşuk karmaşıklığı ve kafa karıştırıcı ve muhtemelen kırık öğretici. Bu siteye ve buradan bağlantılı diğer sitelere göz atmak bu siteyi benim için taklit etti. Python'a geri dönüyorum ve JavaScript zorluklarımda yardımcı olması için Pijama'ya bakacağım.


5

Konuşmaya biraz geç kaldım, ama işte iki sentim. Her iki dilde de bilgili olduğum için Python ve Java arasında seçim yapmakta gerçekten zorlandım. Hepimizin bildiği gibi, her ikisi için de avantajlar ve dezavantajlar vardır ve gereksinimlerinizi ve projeniz için en uygun çerçeveleri dikkate almanız gerekir.

Genellikle bu tür ikilemlerde yaptığım gibi, kararımı destekleyecek sayılar ararım. Birçok nedenden dolayı Python ile gitmeye karar verdim, ancak benim durumumda, devrilme noktası olan bir arsa vardı. Eylül 2014 itibarıyla GitHub'da "Google App Engine" i ararsanız , aşağıdaki rakamı bulacaksınız:

GAE Dil İstatistikleri

Bu sayılarda çok fazla önyargı olabilir, ancak genel olarak, GAE Java depolarından üç kat daha fazla GAE Python deposu vardır. Sadece bu değil, aynı zamanda projeleri "yıldız sayısına" göre listelerseniz, Python projelerinin çoğunun en üstte göründüğünü göreceksiniz (Python'un daha uzun süredir var olduğunu dikkate almanız gerekir). Benim için bu, Python için güçlü bir durum oluşturuyor çünkü toplumun benimsenmesi ve desteklenmesi, dokümantasyon ve açık kaynak projelerinin kullanılabilirliğini dikkate alıyorum.


3

Bu iyi bir soru ve sanırım cevapların çoğu çitin her iki tarafında artıları ve eksileri iyi bir bakış açısı verdi. Hem Python hem de JVM tabanlı AppEngine denedim (benim durumumda , AppEngine için yapılmış bir Groovy uygulama çerçevesi olan Gaelyk kullanıyordum ). Platformdaki performans söz konusu olduğunda, yüzüme bakana kadar düşünmediğim bir şey, çitin Java tarafında meydana gelen "Yükleme İstekleri" nin sonucudur. Groovy kullanırken bu yükleme istekleri bir katildir.

Konuyla ilgili bir gönderi koydum ( http://distractable.net/coding/google-appengine-java-vs-python-performance-comparison/ ) ve bu soruna geçici bir çözüm bulmayı umuyorum, ancak değilse, soğuk başlatma java istekleri daha az etkisi olana kadar bir Python + Django kombinasyonu için gidiyorum düşünüyorum.


3

Java kullanıcılarının Python kullanıcılarına kıyasla AppEngine'den şikayet ettiklerini duyunca, Python'un kullanımı çok daha az stresli olduğunu söyleyebilirim.


7
Ford sahiplerinin arabaları hakkında Koenigsegg sahiplerinden çok daha fazla şikayet ettiklerini duydum. Neden olabilir?
Axarydax

2

Ayrıca , Google'a ait değilse, görünüşe göre Google tarafından finanse edilen Unladen Swallow projesi de var . Python 2.6.1 bayt kodu için LLVM tabanlı bir arka uç uygulamaya çalışıyorlar, böylece bir JIT ve çeşitli güzel yerel kod / GC / çok çekirdekli optimizasyonlar kullanabilirler. (Güzel bir alıntı: "Son 30 yıllık araştırmayı olabildiğince çok kullanmak yerine, orijinal bir çalışma yapmayı düşünmüyoruz.") CPython'a 5 kat hız arıyorlar.

Tabii ki bu acil sorunuza cevap vermiyor, ancak gelecekte (eğer varsa) "boşluğun kapanmasına" (umarız) işaret ediyor.


1
Unladen Swallow artık ölü bir proje ve son taahhüt bir yıldan daha eski .
tshepang

2

Bugünlerde python'un güzelliği, diğer dillerle ne kadar iyi iletişim kurduğudur. Örneğin, Jython ile aynı tabloda hem python hem de java olabilir. Tabii ki jython tamamen java kütüphanelerini desteklese de tamamen python kütüphanelerini desteklemez. Ancak Java Kütüphaneleri ile uğraşmak istiyorsanız ideal bir çözümdür. Ekstra kodlama olmadan Java kodu ile karıştırmanıza bile izin verir.

Ancak python'un kendisi bile bazı adımlar attı. Ctypes'e bakınız, örneğin C hızına yakın, python kodlama rahatlığını bırakmadan tüm bunları C kütüphanelerine yönlendirir. Cython bir adım daha ileri giderek, c kodunu python koduyla kolayca karıştırmanıza izin verir veya c veya c ++ ile uğraşmak istemeseniz bile, yine de python'da kod yazabilirsiniz, ancak python programlarınızı C uygulamaları kadar hızlı hale getiren statik tip değişkenleri kullanabilirsiniz . Cython bu arada hem google tarafından kullanılıyor hem de destekleniyor.

Dün hatta Python'un satır içi C hatta Meclis'e bile araçları buldum (bkz. CorePy), bundan daha güçlü olamazsınız.

Python kesinlikle çok olgun bir dildir, sadece kendi başına ayakta kalmakla kalmaz, aynı zamanda diğer dillerle de kolay bir şekilde işbirliği yapabilir. Bence çok gelişmiş ve zorlu senaryolarda bile python'u ideal bir çözüm yapan şey budur.

Python ile neredeyse sıfır ek kodlamaya sahip C / C ++, Java, .NET ve diğer birçok kütüphaneye erişim sağlayabilirsiniz, ayrıca kodlamayı en aza indiren, basitleştiren ve güzelleştiren bir dil sağlar. Çok cazip bir dil.


Soru, GAE'de java vs python ile ilgili, çok fazla kısıtlama var. Bu nedenle, argümanlarınız uygulanamaz.
Daniyar

@Daniyar'a katılıyorum, bu cevabın ritmden biraz (veya belki de tamamen) olduğu, ancak cevabı beğendim ve bu aradığım bir şeydi. Kilon'a bu bilgiyi paylaştığı için teşekkürler. Belki de burası yanlış bir yerdi, ama kesinlikle bilgi paylaşımı yaptınız. +1 ve bunun için kudos.
zeFree

1

GWT, geliştirdiğim bir uygulama için mükemmel bir eşleşme gibi görünse de Python ile gitti. JPA, GAE'de oldukça karışıktır (örn. @Embeddable ve diğer belirsiz dokümante edilmemiş sınırlamalar yoktur). Bir hafta geçirdikten sonra, Java'nın şu anda GAE'de doğru hissetmediğini söyleyebilirim.


1

Dikkate alınması gereken bir nokta, kullanmayı düşündüğünüz çerçevelerdir. Java tarafındaki tüm çerçeveler, geleneksel Java uygulama sunucularından biraz farklı olan App Engine'de çalışan uygulamalar için uygun değildir.

Dikkate alınması gereken bir şey, uygulamanın başlangıç ​​zamanıdır. Geleneksel Java web uygulamaları ile bunu düşünmeniz gerekmez. Uygulama başlar ve sonra çalışır. Başlangıç ​​işleminin 5 saniye veya birkaç dakika sürmesi gerçekten önemli değil. App Engine ile uygulamanın yalnızca bir istek geldiğinde başlatıldığı bir durumla karşılaşabilirsiniz. Bu, uygulamanız açılırken kullanıcının beklediği anlamına gelir. Ayrılmış örnekler gibi yeni GAE özellikleri burada yardımcı olur, ancak önce kontrol edin.

Başka bir şey, GAE'nin Java üzerindeki farklı sınırlamalarıdır. Tüm çerçeveler, hangi sınıfları kullanabileceğiniz veya iş parçacıklarına izin verilmemesi veya yerel dosya sistemine erişememenizle ilgili kısıtlamalardan memnun değildir. Bu sorunların yalnızca GAE uyumluluğu hakkında bilgi edinerek öğrenmesi kolaydır.

Bazı insanların modern UI çerçevelerinde (Wicket, yani oturum boyutu ile ilgili sorunlar hakkında şikayet ettiklerini de gördüm). Genel olarak bu çerçeveler, gelişimi eğlenceli, hızlı ve kolay hale getirmek için belirli ödünleşimler yapma eğilimindedir. Bazen bu, App Engine sınırlamalarıyla çakışmaya neden olabilir.

Başlangıçta Java ile GAE üzerinde çalışmaya başladım, ancak bu nedenlerle Python'a geçtim. Benim kişisel duygu Python App Engine gelişimi için daha iyi bir seçim olmasıdır. Sanırım Java, Amazon'un Elastik Beanstalk'ında daha "evde".

AMA App Engine ile işler çok hızlı değişiyor. GAE kendini değiştiriyor ve daha popüler hale geldikçe, çerçeveler de sınırlarını aşmak için değişiyor.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.