Perché utilizzare Django su Google App Engine?

Quando si effettua una ricerca su Google App Engine (GAE), è chiaro che l'utilizzo di Django è molto popolare per lo sviluppo in Python su GAE. Ho setacciato il web per trovare informazioni sui costi e sui vantaggi dell'utilizzo di Django, per scoprire perché è così popolare. Sebbene sia stato in grado di trovare un'ampia varietà di fonti su come eseguire Django su GAE e sui vari metodi per farlo, non ho trovato alcuna analisi comparativa sul perché Django sia preferibile all'utilizzo del framework webapp fornito da Google.

Per essere chiari, è immediatamente evidente perché l'utilizzo di Django su GAE è utile per gli sviluppatori con uno skillset esistente in Django (la maggior parte degli sviluppatori web Python, senza dubbio) o il codice esistente in Django (dove l'uso di GAE è più un esercizio di porting). Il mio team, tuttavia, sta valutando GAE per l'uso su un progetto completamente nuovo e la nostra esperienza esistente è con TurboGears, non con Django.

È stato abbastanza difficile determinare perché Django sia vantaggioso per un team di sviluppo quando le librerie BigTable hanno sostituito l'ORM di Django, le sessioni e l'autenticazione sono necessariamente cambiate e il modello di Django (se desiderabile) è disponibile senza utilizzare l'intero stack Django.

Infine, è chiaro che l'utilizzo di Django ha il vantaggio di fornire una "strategia di uscita" se in seguito volessimo allontanarci da GAE e avessimo bisogno di una piattaforma su cui mirare all'esodo.

Sarei estremamente grato per l'aiuto nel sottolineare perché usare Django è meglio che usare webapp su GAE. Sono anche completamente inesperto con Django, quindi anche l'elaborazione di funzionalità più piccole e / o comodità che funzionano su GAE sono preziose per me.

Usiamo django sulle nostre istanze di appengine principalmente quando dobbiamo servire siti web reali all'utente. Ha un ottimo motore di template, instradamento degli URL e tutta la gestione di richieste / risposte / errori incorporata. Quindi, anche se non possiamo usare le cose magiche / admin, ha molto da offrire.

Per i servizi api abbiamo creato qualcosa di molto semplice sopra webob. È molto più leggero perché non ha bisogno di tutto ciò che offre django e quindi un po 'più veloce in alcune situazioni.

Django probabilmente non è la scelta giusta per te, se sei sicuro che GAE sia giusto per te. I punti di forza delle due tecnologie non si allineano molto bene: perdi completamente gran parte del meraviglioso orm di Django su GAE e, se lo usi, scrivi codice che non è direttamente adatto a bigtable e al modo in cui funziona GAE.

La cosa su GAE è che ottiene la grande scalabilità costringendoti a scrivere codice che si ridimensiona facilmente da zero. Non puoi semplicemente fare una serie di cose che scalano male (ovviamente, puoi ancora scrivere codice che ridimensiona male, ma eviti alcune insidie). Il compromesso è che finisci davvero per scrivere codice intorno al framework, se usi qualcosa come Django, progettato per un ambiente diverso.

Se ti vedi mai lasciare GAE per qualsiasi motivo, investire nell'infrastruttura è un problema per te. Codificare per bigtable significa che sarà più difficile passare a un'architettura diversa (sebbene il progetto apache stia lavorando per risolverlo per te con il componente HBase del progetto Hadoop). Sarebbe ancora molto faticoso abbandonare GAE.

Qual è la motivazione che sta dietro all'utilizzo di GAE, oltre ad essere un prodotto Google e una bella parola d'ordine? C'è una ragione per cui è improbabile che il ridimensionamento utilizzando qualcosa come l'offerta di mediatemple funzioni bene per te? Sei sicuro che i modi in cui le bilance GAE siano adatte alla tua applicazione? Come si confronta il costo con i server dedicati, se ti aspetti di arrivare a quel regno delle prestazioni? Riesci a risolvere bene il tuo problema utilizzando gli strumenti forniti da GAE, rispetto a una più tradizionale configurazione del server con bilanciamento del carico?

Detto questo, a meno che tu non abbia assolutamente bisogno del ridicolo ridicolo ridimensionamento che offre GAE, personalmente suggerirei di non lasciare che quel particolare servizio strutturi la tua scelta del framework. Mi piace Django, quindi direi che dovresti usarlo, ma non su GAE.

Modifica (giugno 2010): come aggiornamento di questo commento qualche tempo dopo: Google ha annunciato funzionalità simili a sql per GAE che non sono gratuite, ma che ti consentiranno di eseguire facilmente operazioni come eseguire comandi in stile SQL per generare rapporti sui tuoi dati.

Inoltre, sono in arrivo modifiche al linguaggio di query GAE che consentiranno query complesse in modo molto più semplice. Guarda i video di Google I / O 2010.

Inoltre, è in corso del lavoro durante il progetto Summer of Code 2010 che dovrebbe portare il supporto no-sql a django core e, per estensione, rendere il lavoro con GAE notevolmente più semplice.

GAE sta diventando più attraente come piattaforma di hosting.

Modifica (agosto 2011):

E Google ha appena aumentato significativamente il costo per la maggior parte degli utenti della piattaforma modificando la struttura dei prezzi. Il problema del lock-in è migliorato (se la tua applicazione è abbastanza grande puoi distribuire le alternative apache), ma per la maggior parte delle applicazioni, l'esecuzione di server o implementazioni VPS è più economica.

Pochissime persone hanno davvero problemi con i bigdata. "Oh, la mia startup potrebbe scalare un giorno" non è un grosso problema di dati. Costruisci le cose ora e tirale fuori dalla porta usando gli strumenti standard.

Ho realizzato molti progetti su GAE. Alcuni in Django, altri nella loro struttura normale.

Per le piccole cose, di solito uso il loro normale framework per semplicità e rapidità. Come http://stdicon.com , http://yaml-online-parser.appspot.com/ o http://text-twist.appspot.com/ .

Per grandi cose, vado con django per sfruttare tutti i bei middleware e plugin. Come http://metaward.com .

Fondamentalmente la mia cartina di tornasole è Mi ci vorranno più di 2 settimane per scrivere ed essere un VERO progetto software? Se è così, vai con django per gli addons.

Ha l'ulteriore vantaggio di, se il tuo progetto non è adatto per BigTable, allora lo porti rapidamente fuori (come ho fatto io è BigTable lento o sono stupido? )

Penso che tutte queste risposte siano un po 'obsolete.

Ora puoi usare Google Cloud SQL

Django è un popolare framework web Python di terze parti. Se abbinato a Google Cloud SQL, tutte le sue funzionalità possono essere completamente supportate dalle applicazioni in esecuzione su App Engine . Il supporto per l'utilizzo di Google Cloud SQL con Django è fornito da un database backend Django personalizzato che avvolge il backend MySQL di Django.

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

un'altra novità è che esiste il supporto BETA per PostgreSQL

Ho esperienza nell'uso di Django e non di GAE. Dalle mie esperienze con Django è stata una configurazione molto semplicistica e il processo di distribuzione è stato incredibilmente facile in termini di progetti web. Certo, ho dovuto imparare Python per avere davvero una buona presa sulle cose, ma alla fine della giornata lo userei di nuovo su un progetto. Questo è stato quasi 2 anni fa prima che raggiungesse 1.0, quindi la mia conoscenza è un po 'obsoleta.

Se sei preoccupato di cambiare piattaforma, suppongo che questa sarebbe una scelta migliore.

Non posso rispondere alla domanda ma potresti voler esaminare web2py. È simile a Django per molti aspetti, ma il suo livello di astrazione del database funziona su GAE e supporta la maggior parte delle funzionalità GAE (non tutte, ma cerchiamo di recuperare). In questo modo se GAE funziona alla grande, se non funziona, puoi spostare il tuo codice su un db diverso (SQLite, MySQL, PostgreSQL, Oracle, MSSQL, FireBird, DB2, Informix, Ingres e - presto - Sybase e MongoDB ).

Se decidi di eseguire la tua app al di fuori di GAE, puoi comunque utilizzare Django. Non avrai molta fortuna con la webapp GAE

Sono ancora molto nuovo nello sviluppo del motore di Google App, ma le interfacce fornite da Django sembrano molto più belle di quelle predefinite. I vantaggi dipenderanno da ciò che utilizzi per eseguire Django sul motore dell'app. Google App Engine Helper per Django ti consente di utilizzare tutta la potenza di Google App Engine con alcune funzionalità Django sul lato.

Django non-rel tenta di fornire quanta più potenza possibile di Django, ma in esecuzione sul motore dell'app per una possibile scalabilità aggiuntiva. In particolare, include i modelli Django (una delle caratteristiche principali di Django), ma questa è un'astrazione che perde a causa delle differenze tra database relazionali e bigtable. Molto probabilmente ci saranno compromessi in termini di funzionalità ed efficienza, oltre a un numero maggiore di bug e stranezze. Ovviamente, potrebbe valerne la pena in circostanze come quelle descritte nella domanda, ma per il resto consigliamo vivamente di utilizzare l'helper all'inizio poiché in seguito hai la possibilità di passare al puro app-engine o Django non-rel. Inoltre, se passi a Django non-rel,