Pourquoi utiliser Django sur Google App Engine?

Lors de la recherche sur Google App Engine (GAE), il est clair que l'utilisation de Django est très populaire pour le développement en Python sur GAE. J'ai parcouru le Web pour trouver des informations sur les coûts et les avantages de l'utilisation de Django, pour découvrir pourquoi il est si populaire. Bien que j'aie pu trouver une grande variété de sources sur la façon d'exécuter Django sur GAE et les différentes méthodes pour le faire, je n'ai trouvé aucune analyse comparative sur les raisons pour lesquelles Django est préférable à l'utilisation du cadre d'application Web fourni par Google.

Pour être clair, il est immédiatement évident pourquoi l'utilisation de Django sur GAE est utile pour les développeurs ayant des compétences existantes dans Django (une majorité de développeurs Web Python, sans aucun doute) ou du code existant dans Django (où l'utilisation de GAE est plus un exercice de portage). Mon équipe, cependant, évalue GAE pour une utilisation sur un tout nouveau projet et notre expérience actuelle est avec TurboGears, pas Django.

Il a été assez difficile de déterminer pourquoi Django est bénéfique pour une équipe de développement lorsque les bibliothèques BigTable ont remplacé l'ORM de Django, les sessions et l'authentification sont nécessairement modifiées et le modèle de Django (si souhaitable) est disponible sans utiliser toute la pile Django.

Enfin, il est clair que l'utilisation de Django a l'avantage de fournir une «stratégie de sortie» si nous voulions plus tard nous éloigner de GAE et avoir besoin d'une plate-forme pour cibler l'exode.

Je serais extrêmement reconnaissant de votre aide pour expliquer pourquoi l' utilisation de Django est préférable à l'utilisation de webapp sur GAE. Je suis également complètement inexpérimenté avec Django, donc l'élaboration de fonctionnalités plus petites et / ou de commodités qui fonctionnent sur GAE est également précieuse pour moi.

Nous utilisons django sur nos instances appengine principalement lorsque nous devons servir des sites Web réels à l'utilisateur. Il a un excellent moteur de template, un routage d'url et toute la gestion des requêtes / réponses / erreurs intégrées. Donc, même si nous ne pouvons pas utiliser le truc magique orm / admin, il a beaucoup à offrir.

Pour les services api, nous avons construit quelque chose de très simple en plus webob. Il est beaucoup plus léger car il n'a pas besoin de tout ce que propose django, et donc un peu plus rapide dans certaines situations.

Django n'est probablement pas le bon choix pour vous, si vous êtes sûr que GAE est fait pour vous. Les forces des deux technologies ne s'alignent pas très bien - vous perdez complètement une grande partie de la merveilleuse orm de Django sur GAE, et si vous l'utilisez, vous écrivez du code qui ne convient pas vraiment directement à bigtable et au fonctionnement de GAE.

Le problème avec GAE est qu'il obtient une grande évolutivité en vous obligeant à écrire du code qui évolue facilement à partir de zéro. Vous ne pouvez tout simplement pas faire un certain nombre de choses qui évoluent mal (bien sûr, vous pouvez toujours écrire du code dont la mise à l'échelle est médiocre, mais vous évitez certains pièges). Le compromis est que vous finissez vraiment par coder autour du framework, si vous utilisez quelque chose comme Django qui est conçu pour un environnement différent.

Si vous vous voyez quitter GAE pour quelque raison que ce soit, investir dans l'infrastructure pose un problème pour vous. Le codage pour bigtable signifie qu'il sera plus difficile de passer à une architecture différente (bien que le projet apache travaille à résoudre cela pour vous avec le composant HBase du projet Hadoop). La transition hors de GAE demanderait encore beaucoup de travail.

Quelle est la motivation motrice derrière l'utilisation de GAE, en plus d'être un produit Google et un mot à la mode? Y a-t-il une raison pour laquelle la mise à l'échelle à l'aide de quelque chose comme l'offre de mediatemple ne fonctionnera probablement pas bien pour vous? Êtes-vous sûr que les balances GAE sont adaptées à votre application? Comment le coût se compare-t-il à celui des serveurs dédiés, si vous prévoyez d'atteindre ce domaine de performances? Pouvez-vous bien résoudre votre problème en utilisant les outils fournis par GAE, par rapport à une configuration de serveur à charge équilibrée plus traditionnelle?

Cela dit, à moins que vous n'ayez absolument besoin de la mise à l'échelle ridicule et ridicule proposée par GAE, je suggérerais personnellement de ne pas laisser cette structure de service particulière votre choix de cadre. J'aime Django, donc je dirais que vous devriez l'utiliser, mais pas sur GAE.

Edit (juin 2010): comme mise à jour de ce commentaire un peu plus tard: Google a annoncé des fonctionnalités de type SQL pour GAE qui ne sont pas gratuites, mais qui vous permettront de faire facilement des choses comme exécuter des commandes de style SQL pour générer des rapports sur vos données.

De plus, il y a des changements à venir dans le langage de requête GAE qui permettront des requêtes complexes de manière beaucoup plus simple. Regardez les vidéos de Google I / O 2010.

De plus, des travaux sont en cours pendant le projet Summer of Code 2010 qui devraient apporter le support no-sql à django core et, par extension, faciliter considérablement le travail avec GAE.

GAE devient de plus en plus attrayante en tant que plateforme d'hébergement.

Edit (août 2011):

Et Google vient d'augmenter considérablement le coût pour la plupart des utilisateurs de la plate-forme en modifiant la structure de prix. Le problème de verrouillage s'est amélioré (si votre application est assez grande, vous pouvez déployer les alternatives apache), mais pour la plupart des applications, exécuter des serveurs ou des déploiements VPS est moins cher.

Très peu de gens ont vraiment des problèmes de bigdata. "Oh, ma startup pourrait évoluer un jour" n'est pas un problème de bigdata. Construisez des choses maintenant et sortez-les en utilisant les outils standard.

J'ai réalisé de nombreux projets sur GAE. Certains en django, certains dans leur cadre normal.

Pour les petites choses, j'utilise généralement leur cadre normal pour la simplicité et la rapidité. Comme http://stdicon.com , http://yaml-online-parser.appspot.com/ ou http://text-twist.appspot.com/ .

Pour les grandes choses, j'utilise django pour profiter de tous les bons middleware et plugins. Comme http://metaward.com .

Fondamentalement, mon test décisif est Est-ce que cela me prendra plus de 2 semaines pour écrire et devenir un VRAI projet logiciel? Si tel est le cas, utilisez django pour les addons.

Il a l'avantage supplémentaire de, si votre projet est mal adapté à BigTable, alors vous portez rapidement hors (comme je l'ai fait BigTable est-il lent ou suis-je stupide? )

Je pense que toutes ces réponses sont un peu obsolètes.

Vous pouvez maintenant utiliser Google Cloud SQL

Django est un framework Web Python tiers populaire. Lorsqu'elles sont associées à Google Cloud SQL, toutes ses fonctionnalités peuvent être entièrement prises en charge par les applications exécutées sur App Engine . La prise en charge de l'utilisation de Google Cloud SQL avec Django est fournie par un backend de base de données Django personnalisé qui encapsule le backend MySQL de Django.

https://cloud.google.com/python/django/appengine

une autre nouvelle nouvelle est qu'il existe un support BETA pour PostgreSQL

J'ai de l'expérience avec Django et non GAE. D'après mes expériences avec Django, la configuration était très simpliste et le processus de déploiement était incroyablement facile en termes de projets Web. Certes, je devais apprendre Python pour vraiment bien maîtriser les choses, mais à la fin de la journée, je l'utiliserais à nouveau sur un projet. C'était il y a presque 2 ans avant d'atteindre 1.0, donc mes connaissances sont un peu dépassées.

Si vous craignez de changer de plate-forme, ce serait un meilleur choix, je suppose.

Je ne peux pas répondre à la question, mais vous voudrez peut-être vous pencher sur web2py. Il est similaire à Django à bien des égards, mais sa couche d'abstraction de base de données fonctionne sur GAE et prend en charge la plupart des fonctionnalités GAE (pas toutes mais nous essayons de rattraper le retard). De cette façon, si GAE fonctionne très bien pour vous, si ce n'est pas le cas, vous pouvez déplacer votre code vers une autre base de données (SQLite, MySQL, PostgreSQL, Oracle, MSSQL, FireBird, DB2, Informix, Ingres et - bientôt - Sybase et MongoDB ).

Si vous décidez d'exécuter votre application en dehors de GAE, vous pouvez toujours utiliser Django. Vous n'aurez pas vraiment beaucoup de chance avec l'application Web GAE

Je suis encore très nouveau dans le développement du moteur Google App, mais les interfaces fournies par Django semblent beaucoup plus agréables que celles par défaut. Les avantages dépendront de ce que vous utilisez pour exécuter Django sur le moteur d'application. L'assistant Google App Engine pour Django vous permet d'utiliser toute la puissance de Google App Engine avec quelques fonctionnalités Django sur le côté.

Django non-rel tente de fournir autant de puissance que possible de Django, mais s'exécute sur le moteur d'application pour une éventuelle évolutivité supplémentaire. En particulier, il inclut les modèles Django (l'une des fonctionnalités principales de Django), mais il s'agit d'une abstraction qui fuit en raison des différences entre les bases de données relationnelles et bigtable. Il y aura très probablement des compromis en termes de fonctionnalité et d'efficacité, ainsi qu'un nombre accru de bogues et de bizarreries. Bien sûr, cela peut en valoir la peine dans des circonstances telles que celles décrites dans la question, mais sinon, je recommanderais fortement d'utiliser l'assistant au début, car vous avez alors la possibilité de passer au moteur d'application pur ou à Django non-rel plus tard. De plus, si vous passez à Django non-rel,