Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
which one are you using on google app engine?
what were the reasons behind your decision?
Tipfy
It's developed as an extension to webapp, so it's just one abstracted layer.
That abstracted layer is very minimal. Methods have the same or similar names to their webapp counterparts, but with useful extras that you'd probably end up coding yourself.
Simple routing; if you're familiar with Django or web2py, tipfy's routing is a huge step forward.
Finally, tipfy has an excellent support community. Rodrigo Moraes is especially helpful and engaging. Questions are answered very quickly, and courteously.
Although I mainly work with Django for larger work related projects (hosted elsewhere) I've tended to use webapp for things on App Engine. App Engine to me is best suited for small webservices that you then link together into a full app, and webapp suits that usecase pretty well. Small hacks as well I always use webapp just for simplicity and speed of development. Examples imified-demo.appspot.com, gitbug.appspot.com and github.com/garethr/appengine-image-host
Downside is tool support, you probably have to hack together little things to make your life easier that already exist in the Django world (eg. a test runner http://github.com/garethr/appengine-testrunner)
Anecdotal evidence from a previous project made me feel like Django was a little slow on App Engine for my liking.
Tipfy sounds a good idea, hopefully a case of App Engine maturing as a platform, although I have no personal experience with it at this stage.
All things considered it depends. A big project with multiple developers should probably opt for Django. It's standard ways of doing things will make life easier for everyone. For one off projects I personally prefer webapp or similar. But set aside some time for building your own tools as well as writing your application.
Imho..
Django - the only part that's relevant is the templating and maybe the no rel..
Webapp - never tried it after
Tipfy - is what I'm using, seems to be more "pylons" like, has a basic apps/modules structure and lots of "helpers" which quite frankly should be in the google.appengine.api
Easy to implement templates and routing is nice. Your pretty much left on your own on how to use tipfy and how to structure the application.
I'm still investigating, but I think webapp and tipfy will be a lighter framework than django. Right now, I am using just webapp and the cold start times are already too long. I want to use tipfy for sessions and keep everything else in webapp.
What are you trying to optimize for? Speed of development? Easy of programming? Obscure middleware?
I would still prefer Django for its structure and a high support available over internet for it and for the following reasons:
Webapp offcourse is light weight, but
Django comes with a nice structure
which saves a lots of time while
working on a large application.
Google app engine does provide a good
document for working with Webapp but Django has
a large community of programmers and
thus proves to be a better choice for
implementing some complex
applications.
Django provides a default admin
panel, which otherwise would need to
be created in Webapp, though Google
app provides an admin interface but
that is not equivalent of a full
fledged customizable admin panel.
Webapp itself follows Django for its templates.
I use webapp2 which is a derivative of tipfy (in fact the functions and docs are in many cases identical) and takes ideas from other frameworks too. I recommend taking a look at some boilerplates if you are starting a new project and want to get a quick feel for the framework. Take a look at this boilerplate i've been working on with coto if you are interested in webapp2: http://github.com/coto/gae-boilerplate
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
In order to make an web application with RESTful capabilities I have read and watched tons of articles and videos and I still do not get a complete picture of how it works. And which I should chose. Every other answer is the not helpful ”it depends”. I have boiled it down to a first choice between Django and Node. But nowhere I find the whole ”picture” of how the pieces works together and which modules are needed. Therefore I have tried to put all into a rough illustration. Note that I am a complete newbie on this.
I develop an ERP application with accounting modules. Basically it is mainly about CRUD besides viewing diagrams, printing and storing documents. So this is the ”it depends”
The only thing I have managed to make decisions about is to use nginx, Postgresql and Debian 8 as tools/os. These are the fixed stars.
My questions are not really the common Django vs Node.js and it is not just an opinion I want:
Is the picture below correct? Any comments?
Is there any further components that will be needed? To get started?
You have a lot of questions - and on StackOverflow there should be one question that can be answered without generating a lot of debate or have opinions rather than facts.
As such, I think your question might be closed as "too broad"; however I think it deserves an answer.
I am not going to say "it depends", although that's really all it boils down to - but here is my attempt to explain it.
nodejs is a runtime. It is an environment which allows you to develop code on the server using javascript. In order to do anything useful with nodejs, beyond "hello world"; you'll need to use a framework, and there are tons of those around and various stacks have been developed by the community to tie in all the components together. An example of such a stack is MEAN, which is MongoDB for the database, Express for the framework, Angular to assist with the front-end, and Node to run it all.
django is a framework - it is not a runtime. This means that it is one step removed from the node world. The runtime for django is Python. django also is not a "stack" like MEAN, you can develop your own stack on top of it - but since django is a "batteries included" framework, you only really need to add a database to it - it includes everything else you need.
REST is just a way of designing web-services. Its not a language, or a platform or a library. Its a set of rules that describe a way to design APIs such that they take advantage of the semantic verbs of HTTP.
You can use any library and programming language to develop a RESTful service. All you really need is two things [a] a library to communicate over HTTP [b] a way to serialize data, preferably in JSON (but even that's not a requirement).
nginx is just a very fast webserver and a reverse proxy. The reason it is mentioned often - is because it is very expensive for a framework to serve static media. All requests to a framework (either in django world, or in nodejs world) have to go through a large chain of components that help decode the HTTP request and create a data structure that is easy for developers to use. This chain of components is often called middleware. Since each and every request has to go through this middleware, it is better for performance reasons that requests that don't need the "power" of the application to execute (like a request for an image, a stylesheet, a video file) be handled by something else. This is what nginx is used for, since its a very fast webserver.
Now that those are explained, you need to see what stack works best for your application. To do that, you need to know a bit about the philosophy/justification or problem that each stack is trying to solve.
For django - this is easy. Django was created by a team working on multiple newspapers to help them manage content that was published on different sites. As such, it is designed so that the management of content is of primary concern. That is why it has a very robust administration console as a standard component; and a built-in quite robust ORM and its own templating engine. Django leaves it up to you to figure out how best to actually run and deploy it; although they do provide a lot of suggestions and examples - but in the end, its upto you to decide which database to use, which web server to use, and how to deploy the application.
In the nodejs world - the primary focus is nonblocking I/O and speed of response. Nodejs excels at being able to serve a lot of simultaneous requests on limited resources. Therefore, it provides you a very powerful foundation to develop applications that need to quickly respond to requests ... and that's it. When you program in node or any other specialized lower-level library, you need to make sure your code is taking complete advantage of the library. So, if you start writing blocking code in node, you'll find that the performance that you expect hasn't been achieved.
nodejs doesn't care what the application actually does. Think of it like a very fast, very powerful tool. You can build anything with it, but you need to know what the tool is designed to do best in order to know when to use it.
nodejs has you working at a lower level - which is why there are a lot of packages that help you do all sorts of things with node; and multiple ways you can take components and create your own stack - depending on what you are building on top of node. Think of it like Lego building blocks.
nodejs and django are not mutually exclusive. You can utilize both in your application and exploit their strengths and take advantage of what each does best.
As far as your specific questions:
Did I get the picture? Any comments?
I don't know. Did you?
Is there any further components that will be needed? To get started?
The answer to this is yes, because you don't want to build everything from scratch. Each stack has its own libraries components for developing services. For django, there is django rest framework (DRF).
Which framework are best for CRUD?
Which framework are best for RESTful? Any other module needed?
Best report generator for printing?
Best diagram tools?
There is nothing that is "best" for anything. This question is just asking for opinions. Its like asking, what is the best fruit juice?
Which framework are fastest and most reliable for CRUD using Postgresql
People have developed many robust applications on top of postgresql; however as nodejs is bound to javascript - there is still a lot of work being done in this area.
Can I lock the library (trade secrets) in both environments?
Yes.
Is there better tools for creating ERP/Accounting?
ERP and accounting are two very different things. There are tons of accounting packages/applications written in Python. There are very few ERP systems written in Python.
You cannot combine the two and lump it together.
What is the benefits using Angular on top of Node.js?
The same benefit of using Angular on top of _____ (insert your favorite backend). Angular is just a front end library.
An anecdotal benefit is that both Angular and Node use the same programming language.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I have 4 days off and I will use this time to rewrite our RoR (Ruby on Rails) Application in a python web framework just for fun ;-] (and why not make the switch, RoR is great but keep changing all the time, can be exhausting.)
I don't know the python web framework very well, I've glad web.py, django, cherry.py, pylons/pyramid and few others. Our requirements are (put everything can be irrelevant) :
MVC (Strict or not)
Small Team (2-3 people included one designer)
Fun to use
REST support
Multilevel caching (DB query, page cache)
Nginx Support (X-Accel-Redirect File Download)
Heavy traffic (1,200,000 ~ views)
Urls rewrting (Multi-domains support not only subdomain)
Not a problem if it's not hype
Not a problem if there is no plugins
Either SQL or NOSQL (can be fun to try NOSQL)
So what you would advise ?
I think most of the big frameworks will fit your requirements so maybe you might look at it from the perspective of the app you are writing. How much do you want to work "out of the box". Will you need user management? Will you need an admin panel etc.
I use Django and it's great when you don't want to rewrite a lot of boilerplate. It can be a bit tedious at times trying to bend it to do what you want, but once you get your head around it's intricacies , you can get things done very quickly.
With Django anyway:
MVC (Strict or not)
Not MVC, but similar > http://www.djangobook.com/en/2.0/chapter05/#cn16
Small Team (2-3 people included one designer)
not sure how the framework will effect this, but yes, it's quick to develop on your own or with a team via version control
Fun to use
well there's a lot of great documentation, so less time is spent pulling your hair out, and you can get going very quickly which is nice
REST support
Yes, as a library: > https://bitbucket.org/jesperndjjango-piston/wiki/Home
Multilevel caching (DB query, page cache)
Yep > https://docs.djangoproject.com/en/dev/topics/cache/?from=olddocs
Nginx Support (X-Accel-Redirect File Download)
Again, not sure this is relevant, but yes. I use nginx with UWSGI and it's very quick
Heavy traffic (1,200,000 ~ views)
Yes > Does Django scale?
Urls rewriting (Multi-domains support not only subdomain)
Not sure about this
Not a problem if it's not hype
It's no node-js, but again, lots of really good documentation
Not a problem if there is no plugins
There are .... my god there are
Either SQL or NOSQL (can be fun to try NOSQL)
SQL out of the box, but NOSQL is supported > http://www.allbuttonspressed.com/projects/django-nonrel
In addition to the other frameworks mentioned (which are all good options), you should check out web2py. It's a feature-packed, full-stack framework that's very easy to set up, learn, and use. It was originally inspired by Ruby on Rails, so if you're rewriting an RoR application, you may find it more comfortable than some of the other Python frameworks. Here are some details regarding your requirements:
MVC:
http://web2py.com/book/default/chapter/01#Model-View-Controller
REST support:
http://vimeo.com/21133657
https://groups.google.com/d/msg/web2py/gcqEcXIo7RI/I8BhkK0G_XUJ
Multilevel caching (DB query, page cache):
http://web2py.com/book/default/chapter/04#cache
http://web2py.com/book/default/chapter/06#Caching-Selects
Nginx Support:
http://code.google.com/p/web2py/source/browse/scripts/setup-web2py-nginx-uwsgi-ubuntu.sh
Urls rewriting:
http://web2py.com/book/default/chapter/04#URL-Rewrite
Not a problem if there is no plugins
Plugin documentation
plugin_wiki
Plugins
More plugins
Appliances
Slices
Either SQL or NOSQL (can be fun to try NOSQL)
SQL support: SQLite, PostgreSQL, MySQL, Oracle, MSSQL, FireBird, DB2, Informix, Ingres, Cubrid.
NoSQL support: Google App Engine, CouchDB (partial), MongoDB (partial)
Easy to add additional database adapters (SQL or NoSQL).
The framework is under very active development (new releases every 2-4 weeks), yet is committed to maintaining backward compatibility, so existing apps won't break upon upgrade. If you have any questions, you'll get lots of help from the friendly and responsive mailing list.
I would recommend DJANGO or TurboGears.
I don't think you can go wrong with any of the major web frameworks. Personally I've used Django the most and would lean that way, the ORM is really great and it's philosophies/design are closely aligned with my own personal preference. However, if you wanted to go a different route, bottle is a really fun lightweight microframework, I've found it a pleasure to develop with. If you want to go the NoSQL route, MongoDB has great Python support. PyMongo is excellent (and the recommended way to use MongoDB from Python), MongoEngine is a nice little ORM (if you care for that sort of thing).
Of the frameworks you've mentioned, Django has the most momentum and is most likely to fit your ideals of a framework, coming from a Rails background. By this I mean it has helpers that allow you to generate your forms quickly, though no scaffolding. (In fact, Django's way is a little better than scaffolding in Rails because you can use all or just pieces of it)
It has a good ORM with lots of helper methods and, one of the best features, it has a fully functional admin interface once you define your models. You can start porting data even while the site is being developed.
It also provides excellent user support, including permissions, access control, groups, user profiles.
It's easy (and fun) to create your own middleware and context processors that let you abstract out often reused pieces as plugins to the framework.
The only feature Django doesn't have that you specified above is the NoSQL support. And this is only half true. If you want to use a non relational database for some parts of your app, such as session storage, you can. If you want to use it as your exclusive backend you'll lose some of Django's awesome features unless you patch Django with django-nonrel.
I've used turbo gears which is a combination of several of the other options you mentioned. That community has some great people in it but they're currently experiencing a major architecture revamp and honestly, they're just not getting as much developer attention as Django.
I plan to develop a rather database heavy (~100 tables) web application in python. The focus is on providing a nice and task-optimized interface for people that edit or navigate through the data. Other focuses are:
Handle lots of data and complex queries.
Internationalization (translation, timezones, currencies)
Mailings (bulk emailing as well as notifications)
Easy integration into other websites (pull data from or push data to the application)
A role based authentication scheme. (ideally enforcing one role at a time)
It should be easy and fast (for python programmers) to create custom forms and workflows to work with the data.
I've read a lot about django, turbogears, pyramid, webcore, … but I'm still having a hard time to figure out where to start.
My current evaluation would suggest that turbogears is the way to go. Pyramid seems too much to learn about. Django seems to be too publishing focused. WebCore seems a bit to immature to base such a project on it.
Am I overlooking something? Are there other more suitable python frameworks? Is my information about some of them plain wrong? Which framework would you choose for this project, and why?
Imo the only part of django that might be "too" publishing orientated is the admin, but I have seen plenty of django applications doing stuff neatly.
Django has plenty of apps available covering what you want to do, but the only road block you might find is the part of: handle lots of data and complex queries. You will probably move out of django ORM land, but you might even move out of SQLAlchemy land too. Most of these projects use ORM's, so I would look into SQLAlchemy first, and evaluate how to use it for your needs.
Second, I would just go through the tutorials of the following projects, reading about them is good, but a small little tutorial/project (or mini prototype) is the only way to see if the project fits your programming style: pyramid, turbogears, and django. They have afaik the largest communities. The best tool will be the one you feel more confortable with. They all have good, excellent documentation, good supportive communities, and are mature enough for solid projects, and for very subtle differences, you probably can use any of them for your needs.
I have to agree with you: if you already have a database model, Django is not potentially the best way to go.
As of database binding, SQL Alchemy is definitely worth checking out, regardless of which framework you choose.
Some additions to your list:
Web.py - A little low-level, but a nice, mature framework (for SQLAlchemy usage, see cookbook on SQLAlchemy)
Tornado - Very good performance, supports Websockets which could be of a concern for some applications.
Edit: nowadays I would recommended Flask instead of Web.py. Tornado works really nicely with it as well.
The number of tables is not relevant for speeds etc. and not relevant for the choice of the framework. Recommendation: use SQLAlchemy as ORM between database and application. Go for Pyramid as web framework. Pyramid is easy, well-documented, test and very flexible in all aspects. Forms etc. can be easily created using "colander" + "deform" add-ons.
My gut says you want to use SQLAlchemy as the ORM. Turbogears does this out of the box, and probably is the largest player in the "not Django" space.
There was some work on pulling in SQLAlchemy for (or in addition to!) Django's ORM, but I don't know how current that work is (a quick google search found articles from 2008-2009 as the top hits)
I have no background in web applications, but have a fairly experience background in C++, and a quick learner.
I have spent some time learning Python and reading through SQLAlchemy. I kind of like the idea of coding in pure Python OO, and then use a nice SQLAlchemy mapper to persist everything. I like this decoupled approach (using pure Python classes along a mapper function to talk to DB) better than the ActiveRecord idea of Rails. I think eventually I would have more control over connecting the DB to the app. (I need to work with a DB that is updated by a background process. Something like a web crawler that fills the DB.)
At the same time, some stuff makes me think again about Rails. Like streamlined Email and Ajax handling in Rails.
Am I thinking the right way, that Rails is less flexible for Form Validation Manipulations, and working with DB? And is it harder in Pylons to handle Email (notifications), RSS, Ajax?
What would you suggest?
Thanks
Have a look at Django. It sounds like this exactely what you are looking for :-).
Have a look at these Python frameworks:
Django: Probably the single most popular Python framework, but for better (and worse) is very-much a full-stack solution.
Pylons: As reaction to the Django One Way of working, Pylons, for better (and worse), uses a much looser binding of the modules that make up your framework.
TurboGears: As an attempt at a happy medium between Django and Pylons, TurboGears is based on Pylons, but comes ready made with certain component choices, and the glue to hold it together.
Zope: Zope is more of an application server and framework than a "web framework". It just happens to be web based.
The first three are all inspired by Ruby on Rails, but each has it's own ideas for improvement. Zope predates Rails, and is it's own world.
I've used TurboGears to develop a few small apps. Kinda nice. At the time, their docs were kinda bad. I hope that's changed.
I've also directly used Python Paste a few times. Paste is the HTTP server base upon which Pylons, and in turn TurboGears, is based. Again very nice.
Also: When given the choice, I've always used SQLAlchemy as an ORM. It's truly an impressive piece of software that I've used for even non-web projects.
Hope this helps. Let us know what path you take. :-)
Rails is written in Ruby, not Python. If you have your heart set on Python, then go with Django. But please give Rails a fair shake; ActiveRecord is not the only ORM available either. I use DataMapper for some apps too. I may be biased, but I'm inclined to think the Rails ecosystem is bigger than that of Django too.
If you are looking for a project similar to rails, you should check out Masonite, A modern and developer-centric web framework in Python
You should also checkout web2py instead of Django. Just an alternative you might consider.
Here's two "A vs. B" articles and discussions regarding the two:
Django vs. web2py
Reddit.com community discussion
I wrote a few websites in Pylons over the years and I like it a lot. The great things about Pylons is that it consists mostly of third party libraries. That means that you're learning many useful libraries that can be used in you other projects, for example SQLAlchemy, WebOb, FormEncode, Beaker, Mako and so on ... Especially SQLAlchemy and Beaker are extremely useful in pretty much any context.
You could also have a look to Nagare, another full stack framework.
Some of Nagare based projects already in production can be found on the Nagare web site.
I used Web2Py for many small projects, including many goodies such as the "Workers" & Scheduler concepts, some event-driven updates in web page through the short tornado example in websocket_messaging.py. If you're looking for a small but powerful development framework that includes a small DB and display tables, it's just amazing. You even do not need to write a single HTML line. I do not see any competitor in this area. In my opinion it's far easier and faster than django, but django might provide much freedom in complex apps.
When researching Google App Engine (GAE), it's clear that using Django is wildly popular for developing in Python on GAE. I've been scouring the web to find information on the costs and benefits of using Django, to find out why it's so popular. While I've been able to find a wide variety of sources on how to run Django on GAE and the various methods of doing so, I haven't found any comparative analysis on why Django is preferable to using the webapp framework provided by Google.
To be clear, it's immediately apparent why using Django on GAE is useful for developers with an existing skillset in Django (a majority of Python web developers, no doubt) or existing code in Django (where using GAE is more of a porting exercise). My team, however, is evaluating GAE for use on an all-new project and our existing experience is with TurboGears, not Django.
It's been quite difficult to determine why Django is beneficial to a development team when the BigTable libraries have replaced Django's ORM, sessions and authentication are necessarily changed, and Django's templating (if desirable) is available without using the entire Django stack.
Finally, it's clear that using Django does have the advantage of providing an "exit strategy" if we later wanted to move away from GAE and need a platform to target for the exodus.
I'd be extremely appreciative for help in pointing out why using Django is better than using webapp on GAE. I'm also completely inexperienced with Django, so elaboration on smaller features and/or conveniences that work on GAE are also valuable to me.
Django probably isn't the right choice for you, if you're sure that GAE is right for you. The strengths of the two technologies don't align very well - you completely lose a lot of Django's wonderful orm on GAE, and if you do use it, you write code that isn't really directly suitable to bigtable and the way GAE works.
The thing about GAE is that it gets the great scalability by forcing you to write code that scales easily from the ground up. You just can't do a number of things that scale poorly (of course, you can still write poorly scaling code, but you avoid some pitfalls). The tradeoff is that you really end up coding around the framework, if you use something like Django which is designed for a different environment.
If you see yourself ever leaving GAE for any reason, becoming invested in the infrastructure there is a problem for you. Coding for bigtable means that it will be harder to move to a different architecture (though the apache project is working to solve this for you with the HBase component of the Hadoop project). It would still be a lot of work to transition off of GAE.
What's the driving motivator behind using GAE, besides being a Google product, and a cool buzzword? Is there a reason that scaling using something like mediatemple's offering is unlikely to work well for you? Are you sure that the ways that GAE scales are right for your application? How does the cost compare to dedicated servers, if you're expecting to get to that performance realm? Can you solve your problem well using the tools GAE provides, as compared to a more traditional load-balanced server setup?
All this said, unless you absolutely positively need the borderline-ridiculous scaling that GAE offers, I'd personally suggest not letting that particular service structure your choice of framework. I like Django, so I'd say you should use it, but not on GAE.
Edit (June 2010):
As an update to this comment sometime later:
Google has announced sql-like capabilitys for GAE that aren't free, but will let you easily do things like run SQL-style commands to generate reports on your data.
Additionally, there are upcoming changes to the GAE query language which will allow complex queries in a far easier fashion. Look at the videos from Google I/O 2010.
Furthermore, there is work being done during the Summer of Code 2010 project which should bring no-sql support to django core, and by extension, make working with GAE significantly easier.
GAE is becoming more attractive as a hosting platform.
Edit (August 2011):
And Google just raised the cost to most users of the platform significantly by changing the pricing structure. The lockin problem has gotten better (if your application is big enough you can deploy the apache alternatives), but for most applications, running servers or VPS deployments is cheaper.
Very few people really have bigdata problems. "Oh my startup might scale someday" isn't a bigdata problem. Build stuff now and get it out the door using the standard tools.
We use django on our appengine instances mostly when we have to serve actual websites to the user. It has a great template engine, url routing and all the request/response/error handling built in. So even while we can't use the magic orm/admin stuff it has a lot going for it.
For api services we built something very simple on top of webob. It's far more lightweight because it doesn't need everything that django offers, and therefore a little quicker in some situations.
I've done lots of projects on GAE. Some in django, some in their normal framework.
For small things, I usually use their normal framework for simplicity and quickness. Like http://stdicon.com, http://yaml-online-parser.appspot.com/, or http://text-twist.appspot.com/.
For large things, I go with django to take advantage of all the nice middleware and plugins. Like http://metaward.com.
Basically my litmus test is Will this take me more than 2 weeks to write and be a REAL software project? If so, go with django for the addons.
It has the added benefit of, if your project is badly suited for BigTable then you quickly port off (like I did Is BigTable slow or am I dumb?)
I think all this answers are a bit obsolete.
Now you can use Google Cloud SQL
Django is a popular third-party Python web framework. When coupled
with Google Cloud SQL, all of its functionality can be fully supported
by applications running on App Engine. Support for using Google Cloud
SQL with Django is provided by a custom Django database backend which
wraps Django's MySQL backend.
https://cloud.google.com/python/django/appengine
one more fresh news is, that there is BETA support for PostgreSQL
I have experience using Django and not GAE. From my experiences with Django it was a very simplistic setup and the deployment process was incredibly easy in terms of web projects. Granted I had to learn Python to really get a good hold on things, but at the end of the day I would use it again on a project. This was almost 2 years ago before it reached 1.0 so I my knowledge is a bit outdated.
If you are worried about changing platforms, then this would be a better choice I suppose.
I cannot answer the question but you may want to look into web2py. It is similar to Django in many respects but its database abstraction layer works on GAE and supports most of the GAE functionality (not all but we try to catch up). In this way if GAE works for you great, if it does not, you can move your code to a different db (SQLite, MySQL, PostgreSQL, Oracle, MSSQL, FireBird, DB2, Informix, Ingres, and - soon - Sybase and MongoDB).
If you decide to run you app outside of GAE, you can still use Django. You won't really have that much luck with the GAE webapp
I am still very new to Google App engine development, but the interfaces Django provides do appear much nicer than the default. The benefits will depend on what you are using to run Django on the app engine. The Google App Engine Helper for Django allows you to use the full power of the Google App Engine with some Django functionality on the side.
Django non-rel attempts to provide as much of Django's power as possible, but running on the app-engine for possible extra scalability. In particular, it includes Django models (one of Django's core features), but this is a leaky abstraction due to the differences between relational databases and bigtable. There will most likely be tradeoffs in functionality and efficiency, as well as an increased number of bugs and quirks. Of course, this might be worth it in circumstances like those described in the question, but otherwise would strongly recommend using the helper at the start as then you have the option of moving towards either pure app-engine or Django non-rel later. Also, if you do switch to Django non-rel, your increased knowledge of how app engine works will be useful if the Django abstraction ever breaks - certainly much more useful than knowledge of the quirks/workarounds for Django non-rel if you swap the other way.