Microframework contra “Baterias Incluídas”

Python é uma linguagem de programação que tem a fama existir mais frameworks web que palavras reservadas, isso se reflete em uma diversidade de opções para os mais diversos gostos. Talvez isso seja um reflexo da diversidade de pessoas que utilizam o Python para as mais diversas finalidades.

Quando iniciei no desenvolvimento web, comecei com PHP, da forma mais simples possível, montando cada página em arquivos separados com alguns includes para não repetir muito o código. Quando migrei para Python, o primeiro impacto foi ter que utilizar algum framework e não seguir a forma de cada página num arquivo, até poderia manter os arquivos utilizando CGI, mas não teria desempenho, ou escrever o WSGI diretamente, mas acabaria criando outro framework para facilitar o processo.

Comecei a aprender o Django, achei legal, porém foi complicado por ser muito diferente do que eu estava acostumado e passava mais tempo consultando a documentação que programando efetivamente. Com a filosofia de “baterias incluídas”, o Django tem incorporado bibliotecas para as funcionalidades mais comuns de uma página ou aplicação web pode precisar, como formulário, acesso a banco de dados relacionais, paginação, internacionalização…

Outra opção que temos é utilizar um microframework, que auxilie apenas no WSGI e utilizar outras bibliotecas para montar a base da aplicação, como no caso do Flask. Ele vem por padrão com outras bibliotecas, como o Jinja 2 para auxiliar a escrever o html das páginas e caso precise de banco de dados ou formulários, basta instalar alguma biblioteca como o SQLAlchemy e o WTForms.

A primeira coisa que pode ser notada ao comparar esses dois modelos é a complexidade, com certeza um microframework é mais simples e fácil de aprender, uma vez que você está focado apenas em como interagir com o servidor ou protocolo HTTP, não tem que se preocupar com banco de dados por exemplo.

O primeiro ponto contra o microframework é a necessidade do programador conheçer ou procurar outras bibliotecas para partes específicas da aplicação, como persistência de dados. Muitas vezes isso pode levar ao desenvolvimento de algo que já está pronto e disponível por desconhecimento. Porém o programador não fica restrito ao que o framework suporta, podendo adotar qualquer tipo de biblioteca, diferente do Django que por exemplo não suporta oficialmente nenhum banco NoSQL, é possível utilizá-los, porém você não conseguirá integrá-los nativamente com os models e forms. Além de que utilizar algum framework específico pode aproveitar melhor as funcionalidades de um banco de dados, em vez de funções genéricas suportada por todos.

Por outro lado, uma vantagem de você ter um framework que define as bibliotecas é a possibilidade de integração das mesmas, como no caso do Django, com um model escrito, é extremamente fácil criar um form baseado no mesmo, com validação, ou fazer a migração do esquema da tabela no banco sem precisar escrever tudo na mão ou duplicar o código e lógicas. Também não é necessário sair procurando bibliotecas na internet, e você terá tudo em apenas uma documentação, que na hora de buscar ajuda evita respostas do tipo com a biblioteca tal funciona ou ter que conhecer mais de uma biblioteca que fazem a mesma tarefa para decidir qual das duas utilizar.

Microframeworks e “baterias incluídas” são abordagens opostas, cada uma pode se sair melhor que a outra de acordo com o caso. Se você tiver que desenvolver um sistema que necessite de bibliotecas que o Django oferece e se encaixe na forma dele de resolver os problemas, com certeza é uma ótima opção, uma vez que você terá as bibliotecas integradas e tudo pronto para utilizar. Caso o sistema seja mais simples, não necessitando de todas as bibliotecas oferecidas pelo Django, ou tenha necessidades mais específicas, o Flask começa a ganhar vantagens, uma vez que o fato de ser reduzido pode deixá-lo mais leve ou até ter uma configuração inicial mais rápida.

Com certeza tem o conhecimento das duas abordagens é importante na hora da decisão do framework, nada pior que durante o desenvolvimento o framework ficar atrapalhando, por ele não ter foco para um determinado fim, ou ser tornar burocrático demais para coisas simples. Para quem estiver conhecendo um framework como o Django e acha que algumas coisas seriam mais práticas fazer na mão, tente visualizar todo o processo, que em algum ponto será facilitado por ser desta forma ou mais prático, porém vai necessitar de algum tempo para acostumar.

Anúncios

MX Reverse e escolhas de frameworks

Se alguém deu uma olhada recentemente no meu GitHub, pode ter visto um repositório chamado mxreverse, que é um site que desenvolvi para validar o DNS reverso de servidores de e-mail. Apesar do código ser simples, tomei algumas decisões que gostaria de compartilhar.

Primeiramente a linguagem escolhida foi Python principalmente por ser a qual tenho mais domínio e facilidade, também achei uma biblioteca para fazer as pesquisas do DNS, possibilitando o desenvolvimento. Inicialmente pensei em criar uma função para fazer a validação com algumas funções auxiliares, que depois de alguns testes e tempo de desenvolvimento estava pronta.

Agora até aqui foi algo bem normal do qualquer projeto. Porém como disponibilizar esta função? Como utilizei uma biblioteca externa, além do meu código seria necessário também instalá-la para executar local, ou poderia disponibilizar um webservice, que possibilitaria reutilizá-lo com linguagens também. Como o código é Python, a forma mais simples, e provavelmente a mais recomendada é usar a especificação do WSGI, sendo uma única página, com apenas um parâmetro (o domínio a ser verificado), retornando um JSON, não tive necessidade de utilizar outros frameworks. Apesar de conhecer e gostar de Django e Bottle, o projeto não teria vantagens ao utilizar qualquer um dos dois, além de possibilitar fazer algo mais otimizado e simples sem um framework no caminho.

Com a API definida e funcional, era necessário um cliente que consuma a API e mostre as informações, caso contrário perderia a praticidade que gostaria, exigindo que cada um desenvolvesse seu código. Com as atuais aplicações em JavaScript no navegador, interessei me pela ideia de fazer uma página estática, utilizar AJAX para comunicar com a API e JavaScript para mostrar a resposta. Um framework JavaScript que tinha vontade de testar a algum tempo e aproveitei para fazê-lo neste projeto é o AngularJS. A principal ideia é atualizar um template HTML a partir de variáveis do JavaScript, ou seja, bastava ler o JSON e guardá-lo numa variável que o resultado seria mostrado na página.

O mais importante deste projeto é que mesmo que você conheça e goste de algum framework, ele pode não ser o melhor para a aplicação que está sendo desenvolvida. Abandonei a montagem do HTML em Python, passando para o JavaScript, deixei o código no servidor muito mais simples e aproveitei para conhecer outra forma de desenvolver aplicações, que poderei reutilizar em outros projetos onde ela se adapte melhor.

Resumo saia de sua zona de conforto, conhecer outros frameworks, por mais que superficialmente, pode ajudar na hora de montar uma aplicação, escolhendo uma arquitetura mais adequada.

Aprendendo JavaScript com exercícios TDD e críticas a esse modelo

Com as novas tecnologias, principalmente cloud e busca por sistemas que consumam menos recursos, estou interessado em tecnologias de API REST e consumi-la no navegador. Quando se fala em navegador sempre temos o JavaScript, no MongoDB temos documentos JSON e um terminal, que se não for JavaScript, tem várias semelhanças, além do Node.js no lado do servidor. Com todas essas tecnologias a única que não tenho conhecimento para identificar se ela pode ser aplicada com vantagens e quais seriam é o Node.js, então andei pesquisando para aprender.

Achei um link no site oficial muito bom do nodeschool.io. O tutorial presente no site segue um esquema TDD, ou seja, você tem um exercício para fazer e para validar o mesmo, basta rodar o teste, isso tudo via Node.js e npm. Pode ser um pouco complicado para quem não tem contato nenhum, porém não é muito complicado instalar essas duas dependências e para iniciar o tutorial basta seguir os comandos do site.

Como eu já conheço programação em JavaScript no navegador, esse tutorial a primeira vista pareceu muito interessante, e bem legal a forma de aprender. Porém eu já sabia JavaScript e conheço algumas de suas características, como uso de callbacks e prototype. Também temos um curso específico de JavaScript, infelizmente ainda não tive tempo para dar uma conferida no mesmo para falar sobre o mesmo.

Olhando esse modelo de aprendizado, com textos curtos e um exercício estilo TDD para resolver, lembrei do Codeacademy e que outros sites oferecem conteúdo desta forma. As vantagens são obviamente a rapidez para quem inicia, todo seu aprendizado já vai ser em cima da linguagem, já é possível iniciar uma filosofia de TDD, além da resposta muito mais rápida se o código funciona ou não. Porém não sei se quem tem um mínimo conhecimento de JavaScript, com pouco ou nenhum domínio de callbacks e outras características da linguagem teria o mesmo aproveitamento do material.

Com certeza “cursos TDDs” não irão substituir o material escrito, ainda prefiro um texto explicativo que um exercício para aprender novos conceitos, pelo menos acho que o conhecimento que consigo obter seria maior. Recentemente li o livro Padrões JavaScript e mesmo sem ter feito nenhum exercício aprendi várias boas práticas e formas de escrever um código melhor, obviamente apliquei depois nos códigos para fixar o aprendizado. Só lembrando que essa foi minha forma de aprender.

Recentemente também estive querendo dar uma olhada em Ruby, porém não achei um bom material, que com certeza existem, porém não quero algo que me ensine a fazer uma condição, laço de repetição simples ou o básico de orientação a objetos, tenho esse conhecimento de outras linguagens, gostaria de algo que me ensinasse Ruby e sua forma de resolver os problemas (filosofia), provavelmente o ideal seria algo mostrando um projeto ou parte dele, que possa utilizar como referência. Porém após o fim do mesmo ficaria perdido novamente, somado aos açucares sintéticos que levam a várias formas de escrever exatamente o mesmo código.

Achei no site do Ruby um link de Ruby a partir de outras linguagens (https://www.ruby-lang.org/pt/documentation/ruby-from-other-languages/), li o de Python, aprendi algumas diferenças, porém não sabia fazer uma linha sequer e não consegui ler nenhum código mais específico de Ruby, que simplesmente não entendia a sintaxe do que eram certas partes.

Não tive esse problema com Python, pois quando aprendi fazia algum tempo que não programava, servindo como revisão, além do tutorial presente na documentação ser bem objetivo. Porém acredito que isso irá acontecer com qualquer linguagem, e principalmente a dificuldade de perder o “sotaque”. Gostaria de saber se mais alguém passou por isso e o que fizeram, também seriam interessantes links de material classificados para os diferentes níveis de conhecimento para se aprender alguma linguagem. Deixem nos comentários, depois posso organizar em uma página separada, ou se souberem algum lugar que já tenha isso, melhor ainda.