Pourquoi utiliser Django sur Google App Engine ?

Question

Lorsque l'on fait des recherches sur Google App Engine (GAE), il est clair que l'utilisation de Django est très populaire pour développer 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, afin de découvrir pourquoi c'est si populaire. Alors que j'ai été en mesure de trouver une grande variété de sources sur comment pour exécuter Django sur GAE et les différentes méthodes pour le faire, je n'ai pas trouvé d'analyse comparée sur pourquoi Il est préférable d'utiliser Django plutôt que le framework webapp fourni par Google.

Pour être clair, on voit immédiatement pourquoi l'utilisation de Django sur GAE est utile pour les développeurs ayant déjà des compétences en Django (la majorité des développeurs Web Python, sans aucun doute) ou un code existant en Django (où l'utilisation de GAE est plus un exercice de portage). Mon équipe, cependant, est en train d'évaluer GAE pour l'utiliser sur un tout nouveau projet et notre expérience existante est avec TurboGears, pas Django.

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

Enfin, il est clair que l'utilisation de Django présente l'avantage de fournir une "stratégie de sortie" si nous voulions plus tard nous éloigner de GAE et avoir besoin d'une plateforme à cibler pour cet exode.

J'apprécierais énormément que l'on m'aide à indiquer pourquoi L'utilisation de Django est meilleure que l'utilisation de webapp sur GAE. Je suis également totalement inexpérimenté avec Django, donc des précisions sur les petites fonctionnalités et/ou les commodités qui fonctionnent sur GAE sont également précieuses pour moi.

Answer 1

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

L'avantage de GAE est qu'il obtient une grande évolutivité en vous obligeant à écrire un code qui évolue facilement dès le départ. Vous ne pouvez tout simplement pas faire un certain nombre de choses qui s'échelonnent mal (bien sûr, vous pouvez toujours écrire du code qui s'échelonne mal, mais vous évitez certains pièges). La contrepartie 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 un jour les GAE pour quelque raison que ce soit, le fait de vous investir dans l'infrastructure est un problème pour vous. Coder pour bigtable signifie qu'il sera plus difficile de passer à une architecture différente (bien que le projet Apache travaille à résoudre ce problème pour vous avec le composant HBase du projet Hadoop). La transition à partir de GAE demanderait encore beaucoup de travail.

Qu'est-ce qui motive l'utilisation de GAE, à part le fait qu'il s'agisse d'un produit Google et d'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 a peu de chances de fonctionner correctement pour vous ? Êtes-vous sûr que les méthodes de mise à l'échelle de GAE sont adaptées à votre application ? Comment le coût se compare-t-il à celui des serveurs dédiés, si vous comptez atteindre ce niveau de performance ? Pouvez-vous bien résoudre votre problème en utilisant les outils fournis par GAE, par rapport à une configuration de serveur à équilibrage de charge plus traditionnelle ?

Cela dit, à moins que vous n'ayez absolument besoin de la mise à l'échelle limite-ridicule qu'offre GAE, je vous suggère personnellement de ne pas laisser ce service particulier structurer votre choix de framework. J'aime Django, donc je dirais que vous devriez l'utiliser, mais pas sur GAE.

Edit (juin 2010) : Comme une 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 type SQL pour générer des rapports sur vos données.

En outre, des modifications seront bientôt apportées au langage de requête GAE, ce qui permettra d'effectuer des requêtes complexes de manière beaucoup plus simple. Regardez les vidéos de la Google I/O 2010.

En outre, des travaux sont en cours dans le cadre du projet Summer of Code 2010. Ils devraient permettre d'intégrer la prise en charge de la fonction no-sql au noyau de django et, par extension, de faciliter considérablement le travail avec GAE.

GAE devient de plus en plus attrayant en tant que plate-forme d'hébergement.

Edit (août 2011) :

Et Google vient d'augmenter considérablement le coût pour la plupart des utilisateurs de la plateforme en modifiant la structure tarifaire. Le problème du verrouillage s'est amélioré (si votre application est suffisamment importante, vous pouvez déployer les alternatives d'Apache), mais pour la plupart des applications, il est moins coûteux de faire tourner des serveurs ou des déploiements VPS.

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

Answer 2

Nous utilisons django sur nos instances appengine principalement lorsque nous devons servir des sites web réels à l'utilisateur. Il dispose d'un excellent moteur de modèles, d'un routage d'url et de toute la gestion des requêtes/réponses/erreurs intégrée. Ainsi, même si nous ne pouvons pas utiliser les fonctions magiques d'orm/admin, il a beaucoup d'avantages.

Pour les services api, nous avons construit quelque chose de très simple au dessus de 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.

Answer 3

J'ai réalisé de nombreux projets sur GAE. Certains dans Django, d'autres dans leur framework normal.

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

Pour les gros projets, j'utilise django pour profiter de tous les intergiciels et plugins. Comme http://metaward.com .

En gros, mon test décisif est Est-ce que cela me prendra plus de 2 semaines pour écrire et être une REAL projet de logiciel ? Si c'est le cas, optez pour django pour les modules complémentaires.

Si votre projet n'est pas adapté à BigTable, vous pouvez rapidement le transférer (comme je l'ai fait). BigTable est-il lent ou suis-je stupide ? )

Answer 4

J'ai de l'expérience avec Django et non avec GAE. D'après mon expérience avec Django, la configuration était très simpliste et le processus de déploiement était incroyablement facile en termes de projets Web. Il est vrai que j'ai dû apprendre Python pour bien maîtriser les choses, mais en fin de compte, je l'utiliserais à nouveau pour un projet. C'était il y a presque deux ans, avant la version 1.0, donc mes connaissances sont un peu dépassées.

Si vous êtes inquiet à l'idée de changer de plateforme, je suppose que ce serait un meilleur choix.

Answer 5

Je ne peux pas répondre à votre question mais vous pouvez vous intéresser à 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 de GAE (pas toutes mais nous essayons de rattraper le retard). De cette façon, si GAE fonctionne pour vous, c'est génial, sinon, 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).