

Djangae – Run Django on Google App Engine - jasoncartwright
https://p.ota.to/blog/2014/10/announcing-djangae/

======
beagle3
There is not much love in the Django community towards web2py (to put it
lightly), but if you are interested in Django on GAE it might be interesting
to give web2py (for which GAE is a native backend) a look.

The main complaints against web2py are that it is "un pythonic" because it
automatically imports some things for you (from Jacob Moss Kaplan / django),
and that it re-executes scripts leading to some unavoidable memory leaks in
some (arguably, non-idiomatic, easy to avoid and extremely rare) situations
(from Armin Ronacher / flask). I hope I have properly summarized and not
misrepresented the core arguments - apologies in advance if I did.

Having used both django and web2py for commercial uses, and helping newbies on
the web2py list, I would say that these complaints have no practical
significance. In my opinion, web2py is simpler and easier to use; and if you
need GAE support, it's there.

------
madfarmer
This has actually been done many years ago. [http://django-
nonrel.org](http://django-nonrel.org) . Don't know how it differs from this
one, but it has many of the same features. Used it for a project 4 years ago.

How is performance compared to using cloud sql ?

~~~
kazade
Yeah, we used Django-nonrel and Djangoappengine for a long time, and Djangae
is heavily inspired by it. However the advantage that Djangae has is that it
works with normal Django - it doesn't require a patched fork like
djangoappengine.

As for performance, it depends what you are doing. Obviously the datastore is
non-relational so it scales much better with a lot of data, and you don't have
to deal with things like migrations or connection limits. But then you can't
do complex queries and aggregates etc. the good thing about using Djangae is
you can make use of Django's multiple database connections to store your data
in whichever form makes sense (datastore or CloudSQL).

------
superflit
that is a nice development and google should give some support or contribution
for that.

It does reduce the barrier to use Django in AppEngine and does remove the need
for the cloudsql db instance(mysql)

------
davis_m
Is there any benefit to using the Datastore, as opposed to CloudSQL?

~~~
kazade
There are many benefits, depending on your situation. If your website is
expected to get a high QPS, or you have a lot of data (e.g. millions of rows)
then using the datastore can be much more suitable (you don't have to deal
with schema migrations or connection limits etc.)

You, of course, have to put much more thought into the model design on the
datastore and your design should play to the strengths of a non-relational
store but once you have that right your site will seamlessly scale.

But CloudSQL is also more suitable in many situations, there are no aggregates
or joins on the datastore. You need to to pick and choose the right technology
for what you are doing.

Djangae is awesome here, because you use a consistent API for both CloudSQL
and the Datastore, which makes switching between the two much easier.

------
kevinschumacher
I haven't used either approach, but how does using this project compare to
just using NDB directly with the Django middleware?

[https://cloud.google.com/appengine/docs/python/ndb/#integrat...](https://cloud.google.com/appengine/docs/python/ndb/#integration)

~~~
mattdoughty
Djangae lets you use the Django ORM with the Datastore, meaning you don't have
to use NDB. It also has lots of other helpers for things like deferred tasks.

The Django NDB middleware written by Google, as far as I can work out, just
makes sure that writes are flushed. You still have to define and query your
models using NDB syntax.

------
jsmeaton
What django version is this based on? Some of the other nonrel projects that
I'm aware of are based on the LTS 1.4 (LTS until next year), and haven't
really progressed from there.

~~~
kazade
1.6 is supported in the alpha, we're aiming for 1.7 support before beta. From
that point on we intend to support the two most recent stable Django releases.

We structured the Djangae database connector to be as de-coupled from Django
as possible (everything happens at the cursor level) so hopefully keeping up
with Django releases should be fairly easy (hopefully!).

------
anhtran
As Django developer for over 6 years, sorry guys I don't see the benefits of
hacking the framework in this case. I know so many people love django out
there and try to apply it as much as they can. When you think you go with the-
easy-thing, you're going to make it harder.

BTW, depending on the purpose, I will go with another frameworks, even another
languages.

------
maybeiambatman
I'm just disappointed this isn't called "Djangoogle"

~~~
stucox
I tried very hard to persuade them to call it “Djappango”, but no dice.

------
webmdee
Anybody else read this as "Djan-gay?"

~~~
stucox
I believe the official pronunciation is /ˈdʒæŋɡiː/ (“djan-gee”).

