A principal vantagem de se utilizar um microframework para criar um sistema web é a pouca quantidade de “regras” que se precisa seguir no desenvolvimento. O que quero dizer é que se ganha liberdade para escolher o que e como utilizar as facilidades que o framework provém.
Com o advento da liberdade vem a pergunta: qual é o melhor jeito de fazer?
Como de costume, assim que comecei a utilizar o microframework Flask, escrito em Python, segui diversos tutoriais que encontrei na internet para dar os primeiros passos. Fiz alguns sistemas pequenos para aprender e logo vieram as dúvidas. Pesquisando mais e mais percebi que existem diversas maneiras de se estruturar uma aplicação com ele.
E a lição mais interessante que tirei com tudo isso é que deve-se criar seu próprio jeito de fazer as coisas. De acordo com seu background e com seu conhecimento anterior o desenvolvedor vai naturalmente criando seu “estilo” de estruturar seu código e seus sistemas como um todo.
Criando pequenos sistemas não se tem dificuldades com a estrutura, mas a partir do momento que o sistema cresce a coisa muda de figura. Quase todos os tutoriais estilo “hello world” em Flask tem o mesmo formato: um arquivo único que possui todas as chamadas e roda o sistema, como no exemplo abaixo.
from flask import Flask
app = Flask(__name__)
@app.route('/')
def hello_world():
return 'Hello World!'
if __name__ == '__main__':
app.run()
É claro que para criar um sistema mais complexo colocar tudo em um arquivo único é uma péssima ideia. Mas esse tipo de exemplo serve para dar a noção de como o framework é simples.
Mas como estruturar um sistema maior? Nesse caso se cria o arquivo que contém as rotas e suas funções, um arquivo que carrega o aplicativo e um arquivo com o mapeamento do banco de dados. Uma estrutura de diretórios mais ou menos como no exemplo abaixo.
/app
__init__.py
models.py
views.py
/run.py
Até aí tudo bem, ainda se tem uma aplicação bem simples. Adicionamos os diretórios de templates, de arquivos estáticos e o arquivo com as configurações e teremos a estrutura padrão de um sistema simples em Flask.
/app
/static
/templates
__init__.py
models.py
views.py
/config.py
/run.py
Ficou um pouquinho mais complexo, mas ainda segue o padrão de tutoriais básicos de utilização do Flask.
Nesse caso, todas as rotas que o sistema terá ficarão em apenas um único arquivo. Pode-se imaginar que isso não é uma boa ideia no caso de sistemas mais complexos, correto?
Basta imaginar a quantidade de linhas que o arquivo views.py pode atingir… a manutenção e o entendimento dele ficarão mais difíceis. Sabe-se que, principalmente para scripts Python, isso não é a melhor opção, pois a ideia é que o código seja simples e legível.
É aí que entram os Blueprints.
Blueprints
Existem diversas formas de utilizar Blueprints no Flask, mas eu basicamente tenho utilizado como aprendi com um vídeo de Miguel Grinberg para a PyCon 2014 (se não me engano): uma forma de separar e modularizar as rotas do aplicativo.
Funciona da seguinte maneira. Em vez de termos um arquivo para todas as rotas do sistema, modularizamos as rotas utilizando arquivos separados e registrando Blueprints para cada um deles.
Em uma tradução livre da documentação do Flask:
Um Blueprint funciona de forma parecida com o objeto de aplicação do Flask, mas não é a mesma coisa. Poderiam ser criadas várias aplicações separadas, mas elas não compartilhariam as mesmas configurações e seriam tratadas na camada WSGI e não na camada do Flask. Já os Blueprints compartilham as mesmas configurações e são uma forma de separar funções dentro da mesma aplicação.
Como eu uso os Blueprints
Para cada módulo que defino no sistema eu crio um arquivo e registro seu Blueprint, como no exemplo abaixo, que simula o arquivo meumodulo.py.
from flask import Blueprint, render_template
meumodulo = Blueprint('meumodulo', __name__, template_folder='templates')
@meumodulo.route('/')
def index(page):
return render_template('index.html')
Dessa maneira eu crio todas as rotas desse “módulo” específico. Para registrar o Blueprint é preciso adicionar a linha abaixo no arquivo __init__.py, depois de inicializar o objeto app do Flask.
from .meumodulo import meumodulo
app.register_blueprint(meumodulo)
Se quiser que o novo módulo tenha um prefixo para todas as suas rotas, basta adicionar url_prefixao registro do Blueprint.
app.register_blueprint(meumodulo, url_prefix='/modulo')
Já começamos a deixar tudo mais organizado, pelo menos no que diz respeito às rotas. E com isso podemos ter a seguinte estrutura de diretórios.
/app
/static
/templates
__init__.py
meumodulo.py
models.py
outromodulo.py
/config.py
/run.py
Evitando dependências circulares
Para evitar dependências circulares, podemos criar uma função que registre os Blueprints e a chamamos ao final do arquivo __init__.py, como mostra o exemplo abaixo.
def register_blueprints(app):
from .meumodulo import meumodulo
from .outromodulo import outromodulo
app.register_blueprint(meumodulo, url_prefix='/modulo')
app.register_blueprint(outromodulo, url_prefix='/outromodulo')
register_blueprints(app)
Conclusão
Depois de tudo isso, ainda utilizo uma extensão do Flask chamada Flask-Script para criar um arquivo manager.py no lugar do arquivo run.py. Mas vou explicar melhor sobre isso em uma post futuro.
Essas são apenas algumas dicas que mostram como eu tenho utilizado o microframework Flask para alguns dos meus projetos. Sou relativamente novo com Python e com Flask e por isso tenho certeza de que no futuro terei descoberto novas formas de estruturar os sistemas maiores que farei, mas por enquanto essas são as dicas que tenho para dar para quem se encontra na mesma situação de estudante que eu. Espero poder ter ajudado.
Qualquer dúvida ou sugestão, por favor deixe seu comentário abaixo que responderei sempre que possível.
Atá a próxima.
