Acho que o que me incomoda nessa questão é que você a formulou e carregou com "fatos" na tentativa de obter um não definitivo.
A verdade é que você pode desenvolver um aplicativo do Google App Engine que replique os recursos do Facebook, Twitter ou Tumblr. E, supondo que o aplicativo fosse bem escrito, ele seria dimensionado para suportar centenas de milhões de usuários. O principal motivo pelo qual você não gostaria (o que não parece ser uma consideração para você) é o custo da execução de um serviço desse tamanho no App Engine.
Além disso, não consigo ver como alguma das restrições listadas o impediria de desenvolver um aplicativo desse tipo.
Solicitação / resposta HTTP
- Tamanho máximo da solicitação: 10 MB - incorreto, aumentado para 32 MB.
- Tamanho máximo de resposta: 10 MB - incorreto, aumentado para 32 MB.
- se você estiver desenvolvendo um aplicativo social que frequentemente precisa entregar páginas maiores que 10 MB, provavelmente está fazendo algo errado. Além disso, se você precisar fornecer conteúdo maior que 32 MB, poderá usar o blobstore para arquivos de até 2 GB.
- Você não pode acessar o sistema de arquivos. (esqueça de salvar envios para o sistema de arquivos) - errado. Você pode ler do sistema de arquivos local e fazer upload e ler / gravar arquivos no blobstore.
- Não há como o Facebook, Twitter ou Tumblr apenas receber uploads do usuário e copiá-los para uma pasta. Não é um problema.
- Todas as solicitações devem responder dentro de 10 minutos, caso contrário, o GAE lançará DeadlineExceededException - errado. São 30 segundos, na verdade.
- Se você precisar de mais de 30 segundos para entregar resultados à solicitação de um usuário, provavelmente está fazendo algo errado.
- Cada tarefa cron deve ser executada em 30 segundos - errado, são 10 minutos.
- Se você não pode dividir uma tarefa longa em partes de 10 minutos, A: provavelmente está fazendo errado e B: agora você pode mover essa tarefa para uma instância de Back-end, que não tem limite de tempo para solicitações.
Trabalhos Cron não podem utilizar a redução de mapa - nunca a redução de mapa usada, mas acho que isso requer uma citação.
Todo GET ou POST para outro site é abortado após 5 segundos. Você pode configurá-lo para esperar até 10 segundos no máximo. (servidores intermediários seriam necessários para trabalhar com o Twitter e o Facebook várias vezes) - Verdade.
- Se uma solicitação voltada ao usuário para uma API externa estiver demorando mais de 10 segundos, provavelmente é uma boa ideia pedir ao usuário para tentar novamente de qualquer maneira. Se não for uma solicitação voltada ao usuário, você poderá tentar novamente a tarefa automaticamente até que a API responda.
- O cliente não pode se conectar ao GAE por FTP (apenas HTTP e HTTPS). - Verdade
-- Por que isso é um problema? Você acha que alguma empresa de grande escala implementa alterações via FTP?
- Não há https para domínios personalizados. Apenas para domínios your-app-id.appspot.com. - Verdade.
- Mas está no roteiro.
- Se você receber um fluxo de usuários, receberá um erro de "excesso de cota" - parcialmente verdadeiro.
- Se você planejar corretamente seu aplicativo, nunca verá um erro de excesso de cota. O site Royal Wedding foi hospedado no App Engine e recebeu 32.000 solicitações por segundo. Sem erros de excesso de cota. Além disso, já viu a baleia falhar no Twitter ou o erro de excesso de capacidade no Tumblr? Esse é essencialmente o erro de excesso de cota.
Base de dados
- O comportamento do banco de dados não é o mesmo no desenvolvimento local que nos servidores reais. - Falso
- Se você quer dizer que executar o armazenamento de dados no laptop é mais lento do que executá-lo no cluster do App Engine, é verdade, caso contrário, não é verdade.
- A maioria dos desenvolvedores usa filtros db para consultar o armazenamento de dados. Além disso, você também poderia dizer que o MySQL permite "SQL. Nada mais".
- Nenhuma consulta pode recuperar mais de 1000 registros (é muito ruim se você deseja permitir que seu cliente tenha um botão "clique para ficar offline agora") - Falso.
- O limite de 1000 registros foi levantado há muito tempo. Além disso, mostre-me qualquer página voltada para o usuário no Facebook, Twitter ou Tumblr que exija mais de 1000 registros para renderizar.
- Se você precisar de acesso linear a uma quantidade enorme de registros para executar uma operação, estará sem sorte (os sistemas do Google estão agrupados em massa)
- Eu nem tenho certeza do que você está recebendo aqui. A maioria das pessoas considera a velocidade do enorme cluster do Google como uma enorme vantagem do sistema.
O tamanho máximo dos valores de Memcache é 10 MB. - Na verdade, é 1 MB por entrada do memcache, o mesmo que qualquer outra implementação do memcache.
Não é possível fazer a pesquisa de texto simples - Verdadeiro.
- É um recurso que está no convés. A maioria dos sites grandes não faz sua própria indexação de pesquisa de texto.
- Você não pode participar de 2 mesas. - Verdade.
- Os desenvolvedores do App Engine precisam ajustar seus pensamentos de uma única consulta SQL de várias junções em massa para várias consultas individuais menores ou desnormalizar os dados para que as junções não sejam necessárias.
- Lento (você precisa ler sobre como separar tabelas usando herança para poder pesquisar em uma tabela, obter a chave e obter seu pai para evitar o desempenho da desserialização) - ???
- tradução / citação necessária.
- Exceção de tempo de execução "Muitos índices" - True
- Há um limite para o número de índices em um único aplicativo. Só vi aplicações de pesquisa acadêmica chegarem lá.
- Uma entidade pode ter no máximo 5000 valores de propriedades em um índice - True
- Portanto, se alguém tiver mais de 5000 amigos, precisará de duas entidades no grupo de amigos.
- Os nomes-chave do formulário
__*__(início e fim com dois sublinhados) são reservados e não devem ser usados pelo aplicativo. - Verdade
-- Mas e daí?
- Os nomes das chaves estão limitados a 500 bytes (acho que codificado em UTF-8) - True
- Novamente, e daí? Os nomes-chave não são para armazenar novelas, são para identificar exclusivamente uma entidade.
Língua
- python ou java ou Go (qualquer outra coisa teria que ser traduzida para esses idiomas) - Meia verdade
- Na verdade, você também pode executar qualquer linguagem que seja executada na JVM, incluindo PHP e JRuby. No entanto, não sei por que isso é um problema, Python e Java são duas linguagens poderosas, com muitas ferramentas disponíveis, tutoriais e programadores experientes.
Problemas do servidor
- Sem IP estático (problemas de limitação e cota ao chamar APIs de terceiros) - parcialmente verdadeiro
- A maioria das APIs de terceiros conhece o App Engine e / ou tem um relacionamento com o Google. Algumas vezes o Twitter bloqueou acidentalmente o App Engine e ele é corrigido em algumas horas.
- Cada aplicativo é limitado a 3000 arquivos - Meia verdade
- Se você realmente precisar de mais de 3000 arquivos de código para o seu aplicativo da Web, poderá usar as importações de zip (além disso, você pode estar fazendo errado).
- Nenhum controle do SO ou hardware executando o aplicativo Web - True
- O App Engine é uma plataforma como serviço . Não é preciso se preocupar com a manutenção do sistema operacional ou do hardware. Essa é a principal vantagem do App Engine, não uma limitação.