Pourquoi utiliser Django sur Google App Engine?


88

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.


Holy Crap Terry Bradshaw écrit le code?
Woot4Moo

4
Django est bénéfique car c'est génial. C'est vraiment ça. :)
jathanism

Je suis également nouveau sur le moteur d'application Google et c'est une question terriblement bien formulée même pour 2018 (bien que Django ORM semble être beaucoup mieux pris en charge sur GAE maintenant). :)
Divij Sehgal

Réponses:


19

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.


1
Merci Koen. Une partie de ma confusion quant à l'attrait de Django provenait de l'idée que le routage d'url et la gestion des requêtes / réponses / erreurs étaient également des fonctionnalités de la webapp fournie et que le moteur de template peut être utilisé sans Django aussi bien avec webapp. Est-ce que je me trompe? Django fournit-il mieux ces services que le framework webapp?
Travis Bradshaw

Ils sont plus étendus et flexibles dans django, je dirais. Donc c'est mieux si vous en avez réellement besoin :-)
Koen Bok

2
Je pense que c'est la réponse que je recherche! Ce Django est largement redondant avec les applications Web, mais dans les fonctionnalités qu'ils partagent, Django le fait d'une manière plus flexible et plus robuste. Il semble que ce soit sûrement une décision «à la marge», mais je pense que toutes les autres suggestions, plus la vôtre, constituent une réponse convaincante. Merci.
Travis Bradshaw

1
Les modules Python écrits en C ne sont pas non plus pris en charge.
Ryu_hayabusa

51

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.


Merci pour la réponse réfléchie, Paul. Nous évaluons GAE en grande partie parce que le modèle de coût correspond bien à notre plan d'affaires proposé. La possibilité de démarrer gratuitement, puis d'évoluer progressivement avec un modèle de coût très granulaire est très intéressante. De plus, nous ne prévoyons pas de devoir quitter ou migrer loin de GAE à l'avenir et le verrouillage de la plate-forme pour ce projet est acceptable. J'ai inclus le commentaire «stratégie de sortie» dans ma question principalement dans un effort pour être assez complet dans ce que j'ai appris par la lecture et la recherche avant de publier cette question. Merci encore!
Travis Bradshaw

Comment évaluez-vous le coût du temps de développement? L'un des avantages de Django est que vous passez moins de temps à vous soucier de la définition de vos modèles de données qu'avec Bigtable. Bigtable vous oblige à être beaucoup plus clair sur vos usages avant de pouvoir l'utiliser du tout. Certaines requêtes sont beaucoup plus faciles avec SQL "normal".
Paul McMillan

3
Veillez à ne pas trop pincer les centimes. Gratuit, c'est bien, mais le service coûte rapidement de l'argent réel. Si vous optez pour le niveau de service «gratuit», hébergez-le sur un autre serveur / hébergement pour lequel vous payez déjà. Si vous entrez dans le niveau de service non gratuit, les 20 $ / mois pour un VPS que vous pouvez facilement mettre à l'échelle plus tard sont dans le bruit en ce qui concerne le coût.
Paul McMillan

11
tbradshaw, n'oubliez pas de prendre en compte la fréquence à laquelle vous aurez besoin de rapports ad hoc exécutés sur votre ensemble de données. Je suis impliqué dans une application sociale en pleine croissance et GAE devient ... Je ne dirai pas un cauchemar, mais il est extrêmement gourmand en ressources de tirer des connaissances de nos données. Entre Google purgeant les anciens journaux et les longueurs extrêmes nécessaires pour balayer toutes les données, cela rend la création de rapports beaucoup plus coûteuse qu'une base de données SQL. C'est un coût que je n'ai pas pris en compte lors du démarrage. Deuxièmement, si vous vous développez vraiment et commencez à gagner de l'argent, le contrôle que vous perdez sur les sauvegardes est, eh bien, un facteur.
JasonSmith

2
Pour les problèmes de verrouillage, consultez AppScale, qui est un clone de Google App Engine. Nous travaillons sur la plate-forme depuis la sortie de GAE et avons de nombreux utilisateurs dessus pour leurs applications de production python et java. Vous avez un accès direct aux machines sur lesquelles il s'exécute afin d'avoir plus de contrôle sur l'infrastructure. github.com/AppScale/appscale.git
Navraj Chohan

16

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? )


+1, bigtable est tout simplement mauvais pour certains types de projets et de requêtes. C'est génial pour ce que fait Google et peut être terrible pour ce que vous voulez faire.
Paul McMillan

Merci Paul! Pourriez-vous me relier à des ressources décrivant le middleware et les plugins Django qui fonctionnent sur GAE? S'il y a des add-ons utiles à notre projet, ce serait certainement une raison pour aller avec Django plutôt que webapp. Les plus évidemment utiles (comme la session et l'authentification) semblent avoir des dépendances claires de Django ORM.
Travis Bradshaw

2
En gros, tout addon qui n'a pas de models.py fonctionnera parfaitement. Et s'ils ont un models.py, vous pouvez probablement effectuer la conversion 1-en-1 en bigtable et continuer à l'utiliser si vous le souhaitez. Certains que j'utilise sont django_annoying, django_debug_toolbar, et de la section contrib csrf, humanize, et bien sûr admin.
Paul Tarjan

11

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


3

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.


1
Merci pour votre réponse rapide! Bien que je convienne que Django est un framework qui démarre rapidement, ce n'est pas vraiment un problème pour nous. Nous avons quatre développeurs Python assez expérimentés avec des antécédents en développement Web, donc démarrer avec n'importe quel framework sera rapide et sans douleur. Mais la question demeure, lors du choix entre Django et webapp sur GAE, quel est le meilleur choix et pourquoi ?
Travis Bradshaw

@ Woot4Moo si aucune expérience avec GAE ne l'avez-vous déployé, je suis nouveau sur GAE mais le prix me déroute beaucoup, des frais énormes aléatoires, je pense à pythonanywhere, pourriez-vous me donner quelques recommandations?
Manza

0

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 ).


0

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


Merci, bien que je mentionne exactement cela dans la question initiale: "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. "
Travis Bradshaw

0

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,

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.