Primeiro, vamos com calma

Antes de tudo, vamos com calma. Sei que esse tipo de afirmação pode gerar problemas de entendimento e até certo favoritismo em relação a tecnologias. Entretanto, precisamos ter em mente as necessidades que nossas ferramentas suprem e por que devemos usá-las.

Nos primórdios, veio o MVC...

Nos primórdios do desenvolvimento web, quando queríamos conectar e criar ferramentas, não existiam conceitos como micro-frontends, SaaS, microservices ou nada parecido. O mais próximo disso eram aplicações monolíticas, desenvolvidas com stacks que seguiam arquiteturas “quadradas” e bem estabelecidas. Um exemplo clássico é a infame stack LAMP:

• Linux
• Apache
• MySQL
• PHP

Nessa época, era comum seguir a arquitetura MVC (Model-View-Controller), onde:

• A View apresentava os dados e recebia as entradas dos usuários;
• O Model era responsável por manipular e armazenar os dados no banco de dados;
• O Controller fazia o meio de campo entre a visualização e a lógica de negócio.

Com o avanço das aplicações e das necessidades da web moderna, surgiram outros modelos e paradigmas que possibilitaram o desenvolvimento de ferramentas mais complexas. Eles mudaram a forma como processamos dados, renderizamos interfaces e integramos diferentes sistemas.

Mas aqui vai um ponto importante:

Só porque o MVC é uma arquitetura antiga, não significa que está defasada.

Muito pelo contrário — a maioria dos sistemas microempresariais ou de escopo pessoal não precisa de soluções super complexas, que envolvam escalabilidade em tempo real, uso de Docker, pipelines no Jenkins ou alertas de sobrecarga enviados via Resend.

Nesses casos, um bom "feijão com arroz" feito com frameworks como Django, Flask, Ruby on Rails ou até mesmo Laravel já atende muito bem às necessidades. E melhor ainda: com mais simplicidade, produtividade e menos dor de cabeça.

Mas no final, por que Flask?

Apesar da afirmação que inicia este post, e do que foi apresentado até agora, pode parecer óbvio que vou "supostamente" apresentar argumentos embasados e bem direcionados sobre o porquê de um framework ser mais qualificado que outro para determinadas ações e necessidades. No entanto, proponho justamente o contrário.

Começando pelo Django e indo para o Flask, depois passando pelo Spring, desviando para o Express, voltando ao Spring e mantendo um flerte com o Flask, observei como — diferente das outras ferramentas que citei anteriormente — ele apresenta, propositalmente, uma curva de aprendizado muito menor para quem está começando. E essa curva cresce conforme as necessidades do sistema vão aparecendo, sem exigir a adoção imediata de padrões organizacionais rígidos, como no Django; padrões fixos de construção, como no Spring; ou até o uso constante de arrow functions e a quantidade avassaladora de decisões possíveis no Express.

No Flask, você pode construir desde aplicações completas com apenas um único arquivo de código, até sistemas grandes e organizados, que crescem de forma robusta e segura em várias camadas, utilizando padrões de projeto conhecidos e elementos independentes que se integram conforme necessário.

E o castelo de Lego vai se montando...

Temos dentro do Flask, além do conceito arquitetural do MVC, o conceito da possibilidade de criar elementos e usá-los por meio de extensões. Isso é um pensamento muito forte dentro da comunidade do framework e dentro dele mesmo, em que podemos resumir a:

Se não necessito dentro do meu projeto, não necessito instalar ele

Com isso, o framework vem com o mínimo necessário para ser construída uma aplicação Web, e conforme as necessidades vão surgindo, vamos adicionando extensões responsáveis por suprir essas necessidades, e integrar diretamente com nossa aplicação por meio da sua extensibilidade.

Um exemplo disso é que as extensões mais famosas são justamente extensões responsáveis por solucionar problemas simples, mas fundamentais na maioria dos projetos, como, por exemplo:

• Flask-SQLAlchemy: Modelagem de dados e de entidades dentro do código
• Flask-Login: Autenticação e Autorização
• Flask-WTForms: Segurança, construção e responsabilidade com formulários
• Flask-Bootstrap: Bootstrap de forma nativa dentro do Flask
• Flask-SocketIO: Uso de WebSockets fácil e direto
• Flask-Mail: Envio de e-mails do lado do servidor de forma automática e organizada

Com isso, pode vir um questionamento muito importante de ser falado:

Tá, mas os outros frameworks também possuem essas ferramentas e você não é obrigado a implantá-las logo de cara. Por que o Flask seria mais recomendado?

O fato do framework nem sequer possuir essas ferramentas, e não possuir uma estrutura necessária, faz com que cada elemento possa ser aprendido separadamente e de forma independente, sem que precisem ser feitas ressalvas, e sem que seja, a todo momento, instigada a necessidade de usar aquela determinada ferramenta no projeto com a ideia de "Ah... já tem, então vou aproveitar e implementar", e aquilo que era pra ser um CRUD simples virou um e-commerce com marketplace de camiseta do Vasco, até bitcoin do Paraguai.

E caso haja mais dúvidas da sua simplicidade de construção, é possível construir uma rota que retorna uma mensagem, com apenas 7 linhas (tendo em vista algumas necessidades que foram incluídas apenas para manter organização e qualidade).

from flask import Flask 

app = Flask(__name__)

@app.route("/")
def index():
    return "Hello world!"

if __name__ == "__main__":
    app.run()

Quem sabe no futuro...

Inclusive, penso que até mesmo aqui dentro do Tabnews, é possível aprender o Flask, somente por meio dos posts e dos textos -- e caso seja a vontade de vocês, irei fazer isso. Portanto, se você anseia em aprender Flask, ou ver essa saga tendo algum rumo, se expresse abaixo, e inclusive, peço que se expresse para concordar, e PRINCIPALMENTE discordar de mim...