quarta-feira, 23 de julho de 2014

App Engine e Django: No! hell!


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 4 anos nunca sofri com isso. Se for para portar para outro host, melhor é usar o Appscale (http://www.appscale.com/) do que Django. Use um framework full-stack feito exclusivamente para a plataforma:

https://github.com/renzon/tekton

Versão Longa:

DJango é um framework feito com SQL em mente. Suas apps, painel de adminstração, ORM e scaffolding dependem fundalmentalmente 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 adminstraçã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 (https://developers.google.com/appengine/docs/python/ndb/) não permitem o uso integral do painel. Além disso, a plataforma em si já provê um painel de adminstraçã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 exemplifcar, procurei no Google: “app django voting” e consegui uma para resolver votações online: https://code.google.com/p/django-voting/. 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 (https://developers.google.com/appengine/docs/python/ndb/async). 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 àqueles 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 em https://pt-dot-tekton-fullstack.appspot.com/ e também em http://adm.python.pro.br/

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:


Até o próximo post!
Postar um comentário