Pourquoi utiliser Django sur Google App Engine?

Lors de la recherche de 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 été à récurer le web pour trouver de l'information sur les coûts et les avantages de l'utilisation de Django, à savoir pourquoi il est si populaire. Alors que j'ai été en mesure de trouver une grande variété de sources sur comment pour exécuter Django à la FGA et les différentes méthodes pour le faire, je n'ai pas trouvé d'analyse comparative sur pourquoi Django est préférable à l'utilisation de la webapp cadre fourni par Google.

Pour être clair, il est immédiatement évident que l'utilisation de Django à la FGA est utile pour les développeurs avec un niveau de compétences dans Django (une majorité de Python développeurs web, sans aucun doute) ou code existant dans Django (où à l'aide de GAE est plus un portage de l'exercice). Mon équipe, cependant, est l'évaluation GAE pour une utilisation sur un tout nouveau projet et de notre expérience est à TurboGears, pas de Django.

Il est assez difficile de déterminer pourquoi Django est bénéfique pour une équipe de développement lors de la BigTable bibliothèques ont remplacé l'ORM de Django, des séances et l'authentification sont nécessairement changé, et Django template (si cela est souhaitable) est disponible sans l'aide de l'ensemble de Django pile.

Enfin, il est clair que l'utilisation de Django n'ont l'avantage de fournir une "stratégie de sortie" si plus tard, nous avons voulu éloigner de la FGA et de la nécessité d'une plate-forme de la cible de l'exode.

Je serais extrêmement reconnaissante de l'aide en pointant pourquoi à l'aide de Django est mieux que d'utiliser la webapp sur GAE. Je suis aussi totalement inexpérimentés avec Django, donc l'élaboration d'entités plus petites et/ou des convenances que le travail sur GAE sont également précieuses pour moi.

  • holy crap terry bradshaw écrit le code?
  • Django est bénéfique, car il est génial. C'est vraiment elle. 🙂
  • Je suis nouveau sur le Google app engine aussi bien et c'est très bien formé question, même pour 2018(bien que l'ORM de Django, il semble beaucoup mieux pris en charge sur GAE maintenant). 🙂
InformationsquelleAutor Travis Bradshaw | 2009-12-20
  1. 19

    Nous utilisons django sur notre appengine cas la plupart du temps quand nous avons de servir réel les sites web de l'utilisateur. Il a un grand moteur de template, le routage d'url et tous les de requête/réponse/gestion des erreurs construit en. Donc, même si nous ne pouvons pas utiliser la magie orm/admin choses, il a beaucoup de choses pour elle.

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

    • Merci Koen. Une partie de ma confusion quant à l'appel de Django découle de l'idée que le routage d'url et de demande/réponse/gestion des erreurs ont été également des fonctionnalités de l'application web et le moteur de template peut être utilisé sans Django aussi bien avec de la webapp. Suis-je trompé? N'Django fournir ces services de mieux que la webapp cadre?
    • Ils sont plus large et plus souple dans django, je dirais. Il est donc préférable si vous avez réellement besoin 🙂
    • Je pense que c'est la réponse que je cherche! Que Django est largement redondante à webapp, mais dans les fonctionnalités qu'ils partagent Django ne plus souple et robuste. Il semble que c'est sûrement une décision "sur la marge", mais je pense que toutes les autres suggestions, en plus de la vôtre, en fait une réponse convaincante. Merci.
    • Les modules Python écrit en C ne sont pas pris en charge.
    InformationsquelleAutor Koen Bok
  2. 51

    Django n'est probablement pas le bon choix pour vous, si vous êtes sûr que GAE est bon pour vous. Les points forts de ces deux technologies ne s'alignent pas très bien qui vous fait perdre beaucoup de Django est merveilleux orm sur GAE, et si vous ne l'utilisez, vous écrivez du code qui n'est pas vraiment directement adapté de bigtable et la façon GAE œuvres.

    La chose à propos de GAE est que c'est de la grande évolutivité en vous forçant à écrire du code qui s'adapte facilement à partir de la base. Vous ne pouvez pas faire un certain nombre de choses que l'échelle de mal (bien sûr, vous pouvez toujours écrire mal de mise à l'échelle de code, mais vous éviter quelques pièges). Le compromis est que vous avez vraiment en fin de codage dans le cadre, si vous utilisez quelque chose comme Django, qui est conçu pour un environnement différent.

    Si vous voyez-vous jamais quitter GAE pour une raison quelconque, devenant investi dans les infrastructures, il est un problème pour vous. Le codage de bigtable signifie qu'il sera plus difficile de passer à une architecture différente (bien que le projet apache travaille à résoudre pour vous avec la HBase composante du projet Hadoop). Il serait encore beaucoup de travail à la transition hors de la FGA.

    Ce qui est de la conduite de motivation derrière l'utilisation de GAE, en plus d'être un produit de Google, et un bon mot à la mode? Est-il une raison que mise à l'échelle en utilisant quelque chose comme mediatemple l'offre est peu probable de travailler bien pour vous? Êtes-vous sûr que les moyens que GAE échelles sont les plus appropriés pour votre application? Quel est le coût de comparer sur des serveurs dédiés, si vous attendez pour obtenir des performances royaume? Pouvez-vous résoudre votre problème à l'aide des outils GAE offre, par rapport à une approche plus traditionnelle à charge équilibrée de configuration du serveur d'?

    Tout cela dit, sauf si vous avez absolument, positivement besoin de la ligne de démarcation-ridicule mise à l'échelle de GAE offre, je serais personnellement vous conseillons de ne pas laisser ce service en particulier de la structure de votre choix de cadre. J'aime Django, donc je dirais que vous devriez l'utiliser, mais pas sur GAE.

    Édition (Juin 2010):
    Une mise à jour de ce commentaire un peu plus tard:
    Google a annoncé sql-like capabilitys de GAE qui ne sont pas gratuit, mais vous pouvez facilement faire des choses comme de l'exécution de SQL commandes de style pour générer des rapports sur vos données.

    En outre, il y a des changements à venir à la FGA langage de requête qui permettra de requêtes complexes dans une beaucoup plus facile de mode. Regardez les vidéos de Google I/O 2010.

    En outre, il y a du travail fait au cours de la Summer of Code 2010 projet qui devrait apporter pas-sql soutien à django de base, et, par extension, de rendre le travail avec GAE nettement plus facile.

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

    Édition (Août 2011):

    Et Google vient de soulever le coût de la plupart des utilisateurs de la plate-forme de manière significative par la modification de la structure de prix. Les faire adopter problème s'est mieux (si votre demande est assez grande, vous pouvez déployer l'apache alternatives), mais pour la plupart des applications, de serveurs ou de VPS déploiements est moins cher.

    Très peu de gens ont vraiment bigdata problèmes. "Oh mon démarrage pourrait échelle d'un jour" n'est pas un bigdata problème. Construire des trucs maintenant et obtenez la porte en utilisant les outils standard.

    • Merci pour la réponse réfléchie, Paul. Nous évaluons en FGA en grande partie parce que le modèle de coût correspond à notre proposition de plan d'affaires bien. La possibilité de démarrer gratuit échelle et puis progressivement avec une très granulaire modèle de coût est très attrayant. En outre, nous n'avons aucun espoir d'avoir besoin de déplacer ou de migrer loin de GAE dans l'avenir et de la plate-forme de blocage de ce projet est acceptable. J'ai inclus la "stratégie de sortie" commentaire dans ma question principalement dans un effort pour être assez complet de ce que j'ai appris au travers de la lecture et de la recherche avant de poster cette question. Merci encore!
    • Comment évaluez-vous le coût de temps de développement? Une des belles choses au sujet de Django, c'est que vous passez moins de temps à se préoccuper de la définition de vos modèles de données que vous le feriez avec Bigtable. Bigtable vous oblige à être beaucoup plus clair au sujet de vos usages avant de pouvoir l'utiliser du tout. Certaines requêtes sont beaucoup plus facile à la "normale" sql.
    • Veillez à ne pas pincer pennies trop. Gratuit est agréable, mais le service rapide coûte de l'argent réel. Si vous êtes en roue libre dans le "libre" niveau de service, de l'héberger sur un autre serveur/hébergement, vous payez déjà pour. Si vous êtes d'entrer dans le niveau de service, le montant de 20 $/mois pour un VPS que vous pouvez facilement ajuster plus tard est dans le bruit des coûts.
    • Merci encore pour le suivi. Nous sommes en considérant les temps de développement associés à un BigTable modèle de style plutôt que d'une approche plus traditionnelle de l'ORM basé sur le modèle relationnel. Nous sommes tous d'énormes défenseurs et les utilisateurs de SQLAlchemy et la transition vers une colonne de base de données est une partie importante de notre évaluation. Nous avons également examiné le rapport coûts/bénéfices de GAE par rapport à d'autres options d'hébergement, mais ne sont pas satisfaits de la performance et du coût de modèle pour les VPS sur nos autres projets et que vous souhaitez déplacer à l'écart de cela. Encore de superbes commentaires et notre équipe vous lire et d'en discuter!
    • tbradshaw, ne pas oublier de tenir compte de combien de fois vous aurez besoin de rapports ad-hoc de l'exécuter sur votre ensemble de données. Je suis impliqué dans une demande sociale croissante et de la FGA est en train de devenir... je ne dirai pas un cauchemar, mais il est extrêmement gourmande en ressources pour dériver des connaissances à partir de nos données. Entre Google purge de vieux journaux et de l'extrême à la longueur requise pour balayer toutes les données, il rend la déclaration façon, de manière plus cher qu'un SQL db. C'est un coût, je n'ai pas à considérer lors de la mise en route. Deuxièmement, si vous avez vraiment le faire grandir et commencer à gagner de l'argent, vous perdez le contrôle concernant les sauvegardes est, ainsi, un facteur.
    • Pour le verrouillage des préoccupations découvrez AppScale, qui est un Google App Engine clone. Nous avons travaillé sur la plate-forme depuis GAE sortis pour la première fois et ont de nombreux utilisateurs pour leur production de python et des applications java. Vous avez un accès direct à la machine, il fonctionne sur de sorte que vous avez plus de contrôle sur l'infrastructure. github.com/AppScale/appscale.git

    InformationsquelleAutor Paul McMillan
  3. 16

    J'ai fait beaucoup de projets sur GAE. Certains dans django, certains dans leur cadre normal.

    Pour les petites choses, j'ai l'habitude d'utiliser 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 grandes choses, je aller avec django pour profiter de toutes les belles middleware et les plugins. Comme http://metaward.com.

    Fondamentalement, mon test décisif est Sera-ce de me prendre plus de 2 semaines pour écrire et être un RÉEL projet de logiciel? Si oui, allez-y avec django pour les addons.

    Il a l'avantage d', si votre projet est mal adaptée pour BigTable, alors vous rapidement de port off (comme je l'ai fait Est BigTable lente 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 Google fait, et peut être terrible pour ce que vous voulez faire.
    • Merci Paul! Pourriez-vous me lier à toutes les ressources qui décrivent le Django middleware et les plugins qui fonctionnent sur GAE? Si il y a des add-ons utiles à notre projet, ce serait certainement une raison pour aller avec Django, plutôt que d'une webapp. Le plus évidemment ceux qui sont utiles (comme la session et l'authentification) semblent avoir clairement ORM de Django dépendances.
    • Fondamentalement, toute addon qui n'ont pas de models.py fonctionne parfaitement. Et si elles ont un models.py vous pouvez probablement faire la 1-to-1 conversion de bigtable et toujours l'utiliser si vous le souhaitez. Certains que j'utilise sont django_annoying, django_debug_toolbar, et à partir de la section contrib csrf, humaniser, et bien sûr de l'admin.
    InformationsquelleAutor Paul Tarjan
  4. 11

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

    Maintenant, vous pouvez utiliser Google Cloud SQL

    Django est un tiers populaire framework web Python. , Lorsqu'il est couplé
    avec Google Cloud SQL, l'ensemble de ses fonctionnalités peuvent être entièrement pris en charge
    par les applications en cours d'exécution sur App Engine    . La prise en charge de Google Cloud
    SQL avec Django est fourni par un Django principale base de données qui
    roulés de Django reinhardt, MySQL backend.

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

    un plus fraîche nouvelle, c'est qu'il y est une version BÊTA de soutien pour PostgreSQL

    InformationsquelleAutor andilabs
  5. 3

    J'ai de l'expérience à l'aide de Django et de ne pas GAE. De mes expériences avec Django, il a été un des plus simplistes, la configuration et le processus de déploiement a été incroyablement facile en termes de projets web. Certes, j'ai dû apprendre Python pour vraiment avoir une bonne tenue sur les choses, mais à la fin de la journée, je l'utiliserais à nouveau sur un projet. C'était presque 2 ans avant d'atteindre 1.0 j'ai donc mes connaissances sont un peu dépassées.

    Si vous êtes inquiet au sujet de la modification des plates-formes, alors ce serait un meilleur choix, je suppose.

    • Merci pour votre réponse rapide! Alors que je suis d'accord que Django est un framework qui est rapide pour commencer, ce n'est pas vraiment une préoccupation pour nous. Nous avons quatre assez connu Python aux développeurs web de développement des formations, et donc la prise en main du cadre va être rapide et indolore. Mais la question demeure, au moment de choisir entre Django et webapp sur GAE, qui est le meilleur choix, et pourquoi?
    • si pas d'expérience avec GAE ont été faites-vous de le déployer pour, je suis nouveau sur GAE, mais le prix est source de confusion, me beaucoup, aléatoire hughe frais, je pense pythonanywhere, pourriez-vous me passer quelques recommandations?
    InformationsquelleAutor Woot4Moo
  6. 0

    Je ne peux pas répondre à la question, mais vous voudrez peut-être chercher dans web2py. Il est semblable à Django à de nombreux égards, mais sa couche d'abstraction de base de travaux sur GAE et prend en charge la plupart de la GAE fonctionnalités (pas tous, mais nous essayons de rattraper). De cette façon, si GAE fonctionne pour vous beaucoup, si elle n'est pas, vous pouvez déplacer votre code à une autre db (SQLite, MySQL, PostgreSQL, Oracle, MSSQL, FireBird, DB2, Informix, Ingres, et - bientôt - Sybase et MongoDB).

    InformationsquelleAutor mdipierro
  7. 0

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

    • Merci, si je mentionner exactement que, dans la question de départ: "Enfin, il est clair que l'utilisation de Django n'ont l'avantage de fournir une "stratégie de sortie" si plus tard, nous avons voulu éloigner de la FGA et de la nécessité d'une plate-forme de la cible de l'exode."
    InformationsquelleAutor George Godik
  8. 0

    Je suis encore très nouveau pour Google App engine développement, mais les interfaces Django fournit à faire apparaître beaucoup plus agréable que celui par défaut. Les avantages dépendra de ce que vous utilisez pour exécuter Django sur l'app engine. Le Google App Engine aide pour Django vous permet d'utiliser toute la puissance de Google App Engine avec certains Django fonctionnalité sur le côté.

    Django non-rel efforce de fournir autant de Django est possible, mais en cours d'exécution sur l'app-moteur pour d'éventuels extra évolutivité. En particulier, il comprend Django modèles (l'un de Django fonctionnalités de base), mais c'est une abstraction qui fuit en raison des différences entre les bases de données relationnelles et bigtable. Il y aura probablement des différences de fonctionnalité et d'efficacité, ainsi qu'une augmentation du nombre de bugs et de bizarreries. Bien sûr, cela pourrait être utile dans des circonstances telles que celles décrites dans la question, mais sinon recommandons fortement d'utiliser l'aide au début, car ensuite, vous avez la possibilité d'aller en direction soit de la pure app-moteur ou Django non-rel plus tard. Aussi, si vous ne passer à Django non-rel, votre augmentation de la connaissance de la façon dont app engine œuvres seront utiles si l'Django abstraction jamais de pauses - certainement beaucoup plus utile que la connaissance des bizarreries/solutions de contournement pour Django non-rel si vous permutez l'autre sens.

    InformationsquelleAutor Casebash