3 ms·

Two reasons come to mind about using micro frameworks: 1- You're working on a very customized architecture so having a large but powerful framework is a hindra

by znt 16y ago

Two reasons come to mind about using micro frameworks: 1- You're working on a very customized architecture so having a large but powerful framework is a hindrance rather than an advantage. 2- You're starting to learn web programming on a particular language and you want to be closer to how things work, "inventing" or duct taping extensions on the go. I've used django-nonrel on GAE, which has an ORM that works with GAE but now I'm reading Programming on Google App Engine and realized that learning the low level basics is a must as App Engine differs a lot from a regular database. PS: Transactions does not work on django-nonrel, one more reason to go native python.

StavrosK 16y ago
Learning the low-level basics of GAE was important to me too, that's why I went with Flask, but having created the app structure and written 50 lines of code I think I know all the low-level stuff now (they aren't really that many). With transactions not working, there might be one reason to go native, but there are a million others to use Django (all its batteries). I'm more worried about the lack of migrations et al, but you have to do those by hand anyway, so it's not that big a difference. One of the reasons I heard against Django is the slow startup, which can kill you if your app isn't very popular. I wonder how valid that is.
- wkornewald 16y ago
  1. You can still use transactions with Django-nonrel. Just use App Engine's run_in_transaction() function in combination with Django models. No problem. 2. The slow startup problem doesn't really matter, anymore, because App Engine provides reserved instances and warmup requests. It only matters to those who don't want to pay a few $ for reserved instances (but even without reserved instances there are ways around that ;).
  - StavrosK 16y ago
    That's what I thought too. I wonder if this means that Django is (or will be, when it's mature enough) a very good alternative for GAE. A memcache caching module would be especially useful, as it would enable the entire Django caching infrastructure to work on GAE.
    - wkornewald 16y ago
      Caching is already pre-configured (in default settings) to use GAE's memcache in djangoappengine/Django-nonrel. The session app is also pre-configured to use cache+db. Django's mail API also is pre-configured to use GAE's mail API via a special backend. Even file uploads work with FileField if you use django-filetransfers. A large part of Django already works out-of-the-box and it's easy to write fully portable code. With django-dbindexer you can even use QuerySet features which are not natively supported by App Engine. At some point django-dbindexer will even support JOINs via automatic denormalization (or via in-memory filtering where desired) and maybe also simple aggregates and scalable counters (via QuerySet.update()). This will simplify complex DB code a lot (compared to App Engine's model API) and by reusing Django's ORM as the abstraction for common NoSQL patterns you can not only move between NoSQL DBs, but also between SQL and NoSQL (at least to a certain extent; the goal is to provide a better high-level NoSQL API and only implement scalable features, not build a SQL emulation layer that wouldn't scale).
wkornewald 16y ago
Transactions via run_in_transaction() do work (it's even mentioned in the docs).

by znt 16y ago

StavrosK 16y ago

Learning the low-level basics of GAE was important to me too, that's why I went with Flask, but having created the app structure and written 50 lines of code I think I know all the low-level stuff now (they aren't really that many). With transactions not working, there might be one reason to go native, but there are a million others to use Django (all its batteries). I'm more worried about the lack of migrations et al, but you have to do those by hand anyway, so it's not that big a difference. One of the reasons I heard against Django is the slow startup, which can kill you if your app isn't very popular. I wonder how valid that is.

wkornewald 16y ago
1. You can still use transactions with Django-nonrel. Just use App Engine's run_in_transaction() function in combination with Django models. No problem. 2. The slow startup problem doesn't really matter, anymore, because App Engine provides reserved instances and warmup requests. It only matters to those who don't want to pay a few $ for reserved instances (but even without reserved instances there are ways around that ;).
- StavrosK 16y ago
  That's what I thought too. I wonder if this means that Django is (or will be, when it's mature enough) a very good alternative for GAE. A memcache caching module would be especially useful, as it would enable the entire Django caching infrastructure to work on GAE.
  - wkornewald 16y ago
    Caching is already pre-configured (in default settings) to use GAE's memcache in djangoappengine/Django-nonrel. The session app is also pre-configured to use cache+db. Django's mail API also is pre-configured to use GAE's mail API via a special backend. Even file uploads work with FileField if you use django-filetransfers. A large part of Django already works out-of-the-box and it's easy to write fully portable code. With django-dbindexer you can even use QuerySet features which are not natively supported by App Engine. At some point django-dbindexer will even support JOINs via automatic denormalization (or via in-memory filtering where desired) and maybe also simple aggregates and scalable counters (via QuerySet.update()). This will simplify complex DB code a lot (compared to App Engine's model API) and by reusing Django's ORM as the abstraction for common NoSQL patterns you can not only move between NoSQL DBs, but also between SQL and NoSQL (at least to a certain extent; the goal is to provide a better high-level NoSQL API and only implement scalable features, not build a SQL emulation layer that wouldn't scale).

wkornewald 16y ago

Transactions via run_in_transaction() do work (it's even mentioned in the docs).