Ultimamente tenho evangelizado a Plataforma como Serviço (do inglês PaaS – Plataform as a Service) Google App Engine (GAE), utilizando a linguagem Python. Uma pergunta me é feita de forma recorrente: “Renzo, é possível rodar Django no App Engine? Funciona bem?”. Isso era de se esperar, visto que Django é o framework web full-stack mais famoso dessa linguagem.

Versão curta:

Sim, é possível utilizar o Django no GAE com o porte não oficial. Contudo, você encontrará várias limitações.

Na prática, você vive no pior dos dois mundos: não consegue utilizar nem o Django nem o GAE 100%, ficando com uma solução capenga. Então não use o Django no GAE!

Se você quiser usar o Django, use em um stack padrão para ele. Seja Heroku, Amazon ou Digital Ocean.

Se quer usar App Engine, use com suas APIs. Apesar do medo do “vendor-lock-in”, em quatro anos nunca sofri com isso. Se for para portar para outro host, o melhor é usar o Appscale do que Django. Use um framework full-stack feito exclusivamente para a plataforma.

Versão longa:

Django é um framework feito com SQL em mente. Suas apps, painel de administração, ORM e scaffolding dependem fundamentalmente desse tipo de banco para funcionar 100%. Assim, querer portá-lo para NoSQL me lembra a célebre frase “para quem só conhece martelo, tudo é prego”.

Um dos grandes atrativos para iniciantes é o painel de administração. Aliado ao scaffold, é possível prototipar rapidamente aplicações web. Contudo, ao tentar rodar o Django-Admin no GAE, as limitações do Datastore não permitem o uso integral do painel. Além disso, a plataforma em si já provê um painel de administração próprio, mesmo que mais rústico.

Mas as limitações desse banco existem por uma razão: escalabilidade. Elas estão lá para permitir que sua aplicação escale sem haver necessidade de alterar o código. E o fato é que depois de conversar com engenheiro de grandes sites, como Facebook e Globo.com, conclui que mesmo trabalhando com SQL, várias dessas limitações impostas acabam sendo necessárias nesse tipo de banco para se atingir uma grande escala. Como exemplo, a eliminação de joins para facilitar o cache:

Outra grande vantagem do Django é seu ecossistemas de apps (módulos). Elas resolvem problemas recorrentes apenas com a instalação de uma biblioteca. Para exemplificar, procurei no Google: “app django voting” e consegui uma para resolver votações online. Contudo, uma vez que se baseiam em Django + SQL, elas também não funcionarão 100% no GAE. Basta a app precisar de um simples join e sua funcionalidade não irá funcionar.

Tendo, então, comprometidas as duas grande vantagens, sobra ainda uma outra muito interessante: geração e validação automática de formulários a partir dos modelos. Isso é extremamente útil, evitando replicação de código e reduzindo sua complexidade. Porém, para utilizar os formulários, pelo menos o ModelForm, é necessário utilizar os modelos do Django.

Ao utilizar o ORM do Django, e algumas outras APIs, você irá perder uma grande vantagem do ndb: chamadas assíncronas. Com elas é possível paralelizar as diversas buscas que devem ser feitas em banco de dados durante uma requisição. Assim é otimizado o uso de seus recursos gerando economia para seu bolso, uma vez que o modelo de cobrança é proporcional ao tempo de uso. Logo, mais uma vez um recurso não será utilizado 100%.

Ok, se te convenci nesse ponto de que usar Django no GAE é “martelar parafuso”, então a pergunta lógica a ser feita é: “o que uso para desenvolver?”

Quando comecei a usar a plataforma, o projeto Django-nonrel não existia. Da mesma maneira, o micro framework Flask também não. Mas o que percebi, acompanhando discussões Flask versus Django na comunidade Python, é que microframeworks, como o primeiro, são preferidos por devs mais experientes pela liberdade de escolha que proporcionam. Mas para devs iniciantes, um framework full-stack é mais adequado. E a razão disso é muito simples: para um dev iniciante é melhor contar com as decisões feitas por profissionais mais experientes dentro do framework do que bater cabeça tentando criar suas soluções.

Essa conclusão então me chamou a atenção para a pergunta recorrente do início do post, que aqui repito: “Renzo, é possível rodar Django no App Engine? Funciona bem?”. Acabei meditando melhor, deixando meu preconceito contra frameworks full-stack de lado, tentando entender o que realmente essa pergunta queria dizer. Como fruto desse pensamento, acabei traduzindo a pergunta para “Existe uma forma de automatizar o código no GAE da mesma forma que faço com o Django?”. E a reposta é sim.

A solução então foi adaptar minha biblioteca, o Tekton. Ele foi construído em cima do framework padrão da documentação do App Engine, o webapp2. Sua versão inicial tinha a mesma filosofia do Flask. E por conta do que comentei sobre esse tipo de framework, essa é uma opção não familiar para devs iniciantes ou aqueles que conhecem as facilidades do Django.

Passei, então, a analisar os pontos fortes do Django e também do Rails. Minhas conclusões:

1. Seria legal ter scaffold para prototipação;
2. Seria legal ter validação automática de formulários a partir de modelos;
3. Seria legal ter a criação de código HTML a partir de modelos;
4. Seria legal ter um ecossistema de apps mínimas para começar e ir acrescentando outra com o tempo;
5. Seria legal fornecer uma arquitetura para permitir o uso das API’s assíncronas do Google, ao mesmo tempo em que se construa apps isoladas como as do Django;
6. Seria legal documentar todas ferramentas;
7. Seria legal criar uma comunidade em volta desse framewok;

Para as primeiras 4 questões, segue o vídeo:

Para as demais:

Apps:

Até agora escrevi 5 apps:

1. GAEBusiness: Arquitetura para camada de negócio que permite separar apps e ainda sim executar código utilizando as vantagens da API assíncrona;
2. GAEGraph: Lib que permite modelagem de dados no banco como um grafo. Prove várias features interessantes, como recuperação de nós, salvamento entre outras. Isso utilizando memcache para aumentar performance e reduzir custos;
3. GAECookie: App de segurança de cookie para validação de sessão e para evitar ataques CSRF;
4. GAEPermission: Plataforma de login com Google, Facebook e Passwordless. Também prove camada de segurança por lista branca (white-list) para controlar permissões em alto nível;
5. GAEPagseguro: Plataforma de integração com pagseguro.

Todas essas features podem ser conferidas neste link e também neste aqui.

Quanto a documentação, vou reescrever todo o livro https://leanpub.com/appengine para conter essa nova abordagem. Após isso, vou documentar todas apps no Github.

Por fim, fica a criação da comunidade. É isso que começo fazer agora! Assim, se você quiser participar desse projeto ou tirar dúvidas, fica o endereço do fórum para você se filiar: https://groups.google.com/forum/#!forum/tekton-web

Até o próximo artigo!