Choosing Java VS Python on Google App Engine

Choosing Java vs Python on Google App Engine

I'm biased (being a Python expert but pretty rusty in Java) but I think the Python runtime of GAE is currently more advanced and better developed than the Java runtime -- the former has had one extra year to develop and mature, after all.

How things will proceed going forward is of course hard to predict -- demand is probably stronger on the Java side (especially since it's not just about Java, but other languages perched on top of the JVM too, so it's THE way to run e.g. PHP or Ruby code on App Engine); the Python App Engine team however does have the advantage of having on board Guido van Rossum, the inventor of Python and an amazingly strong engineer.

In terms of flexibility, the Java engine, as already mentioned, does offer the possibility of running JVM bytecode made by different languages, not just Java -- if you're in a multi-language shop that's a pretty large positive. Vice versa, if you loathe Javascript but must execute some code in the user's browser, Java's GWT (generating the Javascript for you from your Java-level coding) is far richer and more advanced than Python-side alternatives (in practice, if you choose Python, you'll be writing some JS yourself for this purpose, while if you choose Java GWT is a usable alternative if you loathe writing JS).

In terms of libraries it's pretty much a wash -- the JVM is restricted enough (no threads, no custom class loaders, no JNI, no relational DB) to hamper the simple reuse of existing Java libraries as much, or more, than existing Python libraries are similarly hampered by the similar restrictions on the Python runtime.

In terms of performance, I think it's a wash, though you should benchmark on tasks of your own -- don't rely on the performance of highly optimized JIT-based JVM implementations discounting their large startup times and memory footprints, because the app engine environment is very different (startup costs will be paid often, as instances of your app are started, stopped, moved to different hosts, etc, all trasparently to you -- such events are typically much cheaper with Python runtime environments than with JVMs).

The XPath/XSLT situation (to be euphemistic...) is not exactly perfect on either side, sigh, though I think it may be a tad less bad in the JVM (where, apparently, substantial subsets of Saxon can be made to run, with some care). I think it's worth opening issues on the Appengine Issues page with XPath and XSLT in their titles -- right now there are only issues asking for specific libraries, and that's myopic: I don't really care HOW a good XPath/XSLT is implemented, for Python and/or for Java, as long as I get to use it. (Specific libraries may ease migration of existing code, but that's less important than being able to perform such tasks as "rapidly apply XSLT transformation" in SOME way!-). I know I'd star such an issue if well phrased (especially in a language-independent way).

Last but not least: remember that you can have different version of your app (using the same datastore) some of which are implemented with the Python runtime, some with the Java runtime, and you can access versions that differ from the "default/active" one with explicit URLs. So you could have both Python and Java code (in different versions of your app) use and modify the same data store, granting you even more flexibility (though only one will have the "nice" URL such as foobar.appspot.com -- which is probably important only for access by interactive users on browsers, I imagine;-).

Google App Engine - Go vs. Python recommendations?

The recently-released Go runtime for App Engine is labelled experimental for a reason: Both Go and Go-on-appengine are new and in a state of change.

If you want to experiment with Go and running Go apps in the cloud, go for it. If you want to write a production app on App Engine, use Python or Java.

Google App Engine -- Java or Python?

By this time, both implementations are reasonably mature and solid, and their functionality is pretty similar (I don't think it's quite 100% equal yet, but, moving in that direction). So, if you already know only one of the two languages, I'd say "just go for it". If you already know both, you don't need my advice;-).

If you know neither, but are rarin' to try some of the non-Java languages that are (more or less;-) supported on the JVM side of GAE (I believe this includes Scala, server-side Javascript, JRuby, etc), then it's worth trying. If you know neither, and don't want to risk a "not-first-class-supported language", I'd definitely agree with your observation that Python's faster to learn (but of course I'm biased in favor of Python;-).

How to choose between Google Cloud Functions and Google App Engine?

Update:
As of June 12, 2018, Node.js 8.x is supported in Google App
Engine Standard environment along with the Flexible Environment.

Short answer: It depends upon your need.

Long answer: Here's the checklist

Runtime
Cloud Functions supports only Node.js at the moment and there aren't any plans, as far as I know, to introduce new runtimes there. If you're good with that, you can put Cloud Functions in your options.

App Engine does support Node.js, although it's only available in the Flexible environment. App Engine Standard Environment supports Python 2.7, Java 8, Java 7, PHP 5.5, Go 1.8 and 1.6, while App Engine Flexible Environment supports Python, Java, Node.js, Go, Ruby, PHP, or .NET. You can also provide your own runtime using a dockerfile in Flexible environment. So if you want to develop your application in anything other than Node.js, App Engine is the better option there.

Serverless Architecture
Are you looking for a serverless architecture? Are you frustrated with managing instances and having them scale up or down? Do you want to spend no time to manage your server? Go for Cloud functions if you answer yes to all of these questions.

Are you looking for fine grain control on no. of instances and billing of those. Do you want to have separate versions and want better control of those. Look for App Engine in this case.

Microservice
Can you break your code into smaller independant functions? Go for Cloud Functions.

App Engine do support Microservice architecture using same code base, but different yaml files to split the services, but it's upto you if you want to break them into services or not. We are running all our code into one monolithic application for last few years and it's still working good on App Engine.

Database
Is your app data stored in Firebase? Then Cloud functions can be used easily there. If not, App Engine is the better alternative. App Engine can connect to Firebase too, in case you're wondering.

There're other things to consider too, such as pricing and if you're looking to migrate existing application or if you're writing things from scratch. You can in fact, use both of the options. We are using App Engine (Python) Standard Environment for our application, but we have recently migrated few of our long running tasks on Cloud functions and they are working amazingly.

In my opinion App Engine is the answer to most of the things, where as Cloud Functions are made for specific requirements.

Google Appengine: Java or Python

I gave the accepted answer to the question a comment claims is "very similar" -- but that was nearly a year ago. I'm still biased the same way (still expert on Python, rusty in Java), but in the intervening year I would say the Java runtime has just about caught up to the Python one -- or, if not quite that yet, it has made serious strides (as have both runtimes "in parallel", of course;-). Most of my general considerations in that answer remain roughly valid.

So the main consideration today is, I think, how familiar is the team with Python, and how familiar with Java -- if very familiar with one and not at all with the other, go with what you already know, as the time needed to "catch up" on the other is a cost that's probably larger than the advantages you could get one way or another (to a hobbyist wanting a "mind expanding" experience I'd recommend the reverse: take the opportunity to learn what you don't yet know -- but in terms of immediate productivity, staying with what you know increases it;-).

If there's some "killer library" that you've ascertained runs well with one of the runtimes and that you're really keen to use in your apps, that could be the decisive factor, if differences of familiarity with the two languages are not decisive in your case.

How to integrate Python and Java together for an app in Google Cloud Platform

Yep, you can use two programming languages in an GAE app using GAE services.

If you want the services to communicate then it would be possible through http requests, task queues. If you want a folder to be available in both the services then create that folder on the project's root directory and do sym-linking inside necessary services.

Reference

Deploying different languages services to the same Application [Google App Engine]

The naming of the resulting app on appspot.com will be a bit different than what you mentioned, because of the url routing rules. From Routing via URL:

Sends a request to an available instance of the default version of the
named service:

https://service-dot-app-id.appspot.com
http://service.my-custom-domain.com

So, assuming your services are named python and java and you app is named app then your appspot.com URLs woulds be:

python-dot-app.appspot.com
java-dot-app.appspot.com

But you can map them them however you want with custom domains.

As for building such app:

  • keep in mind that one of the services needs to me named default (or remain unnamed)

  • create app sub-directories for each service (following what used to be recommended multi-service app structure picture no longer found in the docs, but captured in Can a default service/module in a Google App Engine app be a sibling of a non-default one in terms of folder structure?)

  • copy the entire content of each service code into the respective subdir

  • identify the app-level configuration files (cron.yaml, dispatch.yaml, queue.yaml and index.yaml or their java equivalents) you have and move them one level up, at the app level directory (you may need to merge them if such config files are present in both services). You may need to choose one language for these files, I'd choose python. Cron jobs would need to have targets configured (see target row in Cron job definitions).

    Remember that deploying one/all modules might not necessarily update these files as you may be used to, instead they might need to be explicitly deployed - check the respective service configuration docs. You should keep an eye out for potentially overwriting these configs when deploying the services, you may need to come up with a certain deployment sequence.

  • it's probably a good idea (potentially mandatory) to add a dispatch.yaml file and re-visit/adjust the request path namespaces of the services, to ensure that each request is properly directed to the respective service. Special attention for cron jobs, from the target row in Cron job definitions:

If you use a dispatch file, your job might be re-routed. For
example, given the following cron.yaml and dispatch.yaml
files, the job will run in module2, even though its target is
module1:

# cron.yaml
cron:
- description: "test dispatch vs target"
url: /tasks/hello_module2
schedule: every 1 mins
target: module1

# dispatch.yaml:
dispatch:
- url: '*/tasks/hello_module2'
module: module2

https://cloud.google.com/appengine/docs/python/config/cronref#cron_job_definitions

Java and Python Together in Single Google App Engine Project

It is possible to run Python and Java applications on different versions.

From:

Last but not least: remember that you can have different version of your app (using the same datastore) some of which are implemented with the Python runtime, some with the Java runtime, and you can access versions that differ from the "default/active" one with explicit URLs.

Google App Engine Standard and Flex in same project

Yes. Quote from the Google App Engine doc (emphasis added):

You can run your applications in App Engine using the flexible
environment or standard environment. You can also choose to
simultaneously use both environments
for your application and allow
your services to take advantage of each environment's individual
benefits.



Related Topics



Leave a reply



Submit