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:
- Seria legal ter scaffold para prototipação
- Seria legal ter validação automática de formulários a partir de modelos
- Seria legal ter a criação de código html a partir de modelos
- Seria legal ter um ecossistema de apps mínimas para começar, e ir acrescentando outra com o tempo
- 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
- Seria legal documentar todas ferramentas
- 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:- GAEBusiness. Arquitetura para camada de negócio que permite separar apps e ainda sim executar código utilizando as vantagens da API assíncrona;
- 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;
- GAECookie. App de segurança de cookie para validação de sessão e para evitar ataques CSRF;
- 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;
- 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!
Nenhum comentário:
Postar um comentário