Penso che ciò che mi infastidisce di questa domanda è che l'hai formulata e caricata di "fatti" nel tentativo di raccogliere un no definitivo.
La verità è che potresti sviluppare un'app App Engine che replica le funzionalità di Facebook, Twitter o Tumblr. E supponendo che l'app fosse ben scritta, si ridimensionerebbe per supportare centinaia di milioni di utenti. Il motivo principale per cui non vorresti (che non sembra essere una considerazione per te) è il costo della gestione di un servizio di quelle dimensioni su App Engine.
Inoltre, non riesco a vedere come una delle restrizioni che hai elencato ti impedirebbe di sviluppare una tale app.
Richiesta / risposta HTTP
- Dimensione massima richiesta: 10 MB - errata, elevata a 32 MB.
- Dimensione massima della risposta: 10 MB - errata, elevata a 32 MB.
- se stai sviluppando un'app social che spesso deve pubblicare pagine di dimensioni superiori a 10 MB, probabilmente stai sbagliando. Inoltre, se è necessario distribuire contenuti di dimensioni superiori a 32 MB, è possibile utilizzare il blobstore per file fino a 2 GB.
- Non è possibile accedere al file system. (dimentica di salvare i caricamenti nel filesystem) - sbagliato. È possibile leggere dal file system locale e caricare e leggere / scrivere file nel blobstore.
- Non è possibile che Facebook, Twitter o Tumblr stiano semplicemente caricando i caricamenti degli utenti e li copino in una cartella. Non un problema.
- Tutte le richieste devono rispondere entro 10 minuti, altrimenti GAE genererà DeadlineExceededException - errato. Sono in realtà 30 secondi.
- Se hai bisogno di più di 30 secondi per consegnare i risultati alla richiesta di un utente, probabilmente stai sbagliando.
- Ogni cron job deve essere eseguito entro 30 secondi - sbagliato, sono 10 minuti.
- Se non riesci a dividere un'attività lunga in blocchi di 10 minuti, A: probabilmente stai sbagliando e B: ora puoi spostare l'attività in un'istanza di Backend, che non ha un limite di tempo per le richieste.
I lavori Cron non possono utilizzare la riduzione della mappa - mai usata la riduzione della mappa, ma penso che ciò richieda una citazione.
Ogni GET o POST su un altro sito viene interrotto dopo 5 secondi. È possibile configurarlo per attendere fino a 10 secondi max. (i server intermedi sarebbero necessari per funzionare più volte con Twitter e Facebook) - Vero.
- Se una richiesta rivolta all'utente a un'API esterna impiega più di 10 secondi, è probabilmente una buona idea dire all'utente di riprovare comunque. Se non è una richiesta rivolta all'utente, puoi ritentare automaticamente l'attività fino a quando l'API non risponde.
- Il client non può connettersi a GAE tramite FTP (solo HTTP e HTTPS). - Vero
-- Perchè questo è un problema? Pensi che qualsiasi azienda su larga scala distribuisca le modifiche tramite FTP?
- Nessun https per domini personalizzati. Solo per i domini your-app-id.appspot.com. - Vero.
- È sulla tabella di marcia però.
- Se ricevi un afflusso di utenti, ricevi l'errore "Over quota" - Half true.
- Se hai pianificato correttamente l'app, non vedrai mai un errore di quota eccessiva. Il sito Royal Wedding è stato ospitato su App Engine e ha ricevuto 32.000 richieste al secondo. Nessun errore di quota eccessiva. Inoltre, hai mai visto la balena fallita su Twitter o l'errore di sovraccapacità su Tumblr? Questo è essenzialmente il loro errore di quota eccessiva.
Banca dati
- Il comportamento del database non è lo stesso nello sviluppo locale rispetto ai server effettivi. - Falso
- Se intendi eseguire l'archivio dati sul tuo laptop è più lento di eseguirlo sul cluster di App Engine, allora vero, altrimenti non è affatto vero.
- GQL. Nient'altro. - Falso
- La maggior parte degli sviluppatori utilizza i filtri db per interrogare l'archivio dati. Inoltre, potresti anche dire che MySQL consente "SQL. Nient'altro".
- Nessuna query può recuperare più di 1000 record (fa schifo seriamente se si desidera consentire al client di avere un pulsante con un clic-go-offline-now) - Falso.
- Il limite dei 1000 record è stato revocato molto tempo fa. Inoltre, mostrami qualsiasi pagina rivolta agli utenti su Facebook, Twitter o Tumblr che richiede più di 1000 record per il rendering.
- Se hai bisogno di un accesso lineare a una quantità enorme di record per eseguire un'operazione, sei sfortunato (i sistemi di Google sono raggruppati in modo massiccio)
- Non sono nemmeno sicuro di cosa stai arrivando qui. Molte persone considerano la velocità dell'enorme cluster di Google come un enorme vantaggio del sistema.
La dimensione massima dei valori di Memcache è 10 MB. - In realtà è 1 MB per voce memcache, lo stesso di ogni altra implementazione memcache.
Impossibile eseguire una semplice ricerca di testo - Vero.
- È una caratteristica sul ponte. La maggior parte dei siti di grandi dimensioni non esegue la propria indicizzazione della ricerca di testo.
- Non puoi unirti a 2 tavoli. - Vero.
- Gli sviluppatori di App Engine devono adattare il loro pensiero da una singola enorme query SQL multi-join a diverse singole query più piccole o denormalizzare i dati in modo che i join non siano necessari.
- Lento (devi leggere come separare le tabelle usando l'ereditarietà in modo da poter cercare in una tabella, ottenere la chiave e quindi ottenere il suo genitore per evitare le prestazioni di deserializzazione) - ???
- richiesta traduzione / citazione.
- Eccezione di runtime "Troppi indici" - Vero
- Esiste un limite al numero di indici in una singola app. Ho visto solo applicazioni di ricerca accademica colpire però.
- Un'entità può al massimo avere 5000 valori di proprietà in un indice - Vero
- Quindi, se qualcuno ha più di 5000 amici, avrebbero bisogno di due entità nel gruppo di amici.
- I nomi chiave del modulo
__*__(inizio e fine con due trattini bassi) sono riservati e non devono essere utilizzati dall'applicazione. - Vero
- E allora?
- I nomi delle chiavi sono limitati a 500 byte (codificato UTF-8, immagino) - Vero
- Ancora una volta, e allora? I nomi chiave non sono per l'archiviazione di novelle, ma per l'identificazione univoca di un'entità.
linguaggio
- python o java o Go (qualsiasi altra cosa dovrebbe essere tradotta in queste lingue) - Mezzo vero
- In realtà è anche possibile eseguire qualsiasi lingua eseguita su JVM, inclusi PHP e JRuby. Non so perché sia un problema, Python e Java sono due potenti linguaggi con molti strumenti disponibili, tutorial e programmatori esperti.
Problemi del server
- Nessun IP statico (problemi di limitazione e quota che chiamano API di terze parti) - Half true
- La maggior parte delle API di terze parti è a conoscenza di App Engine e / o ha una relazione con Google. Alcune volte Twitter ha bloccato accidentalmente App Engine e si risolve in poche ore.
- Ogni applicazione è limitata a 3000 file - Half true
- Se hai davvero bisogno di più di 3000 file di codice per la tua applicazione web, puoi usare l'importazione zip (potresti anche sbagliare).
- Nessun controllo del sistema operativo o dell'hardware che esegue l'app Web - Vero
- App Engine è una piattaforma come servizio . Non doversi preoccupare della manutenzione del sistema operativo o dell'hardware è ciò per cui le persone pagano. Questo è il vantaggio chiave di App Engine, non una limitazione.