[SP-pm] Vaga catalyst

[Thiago Rondon]

On Fri, Oct 07, 2011 at 06:17:09PM -0300, Tiago Peczenyj wrote:
>    Nao querendo sair do assunto mais ja saindo.
>    Nao sei comec,ar um projeto com catalyst. Vejo o cookbook, acho maneiro,
>    mas parece que nao da liga no cerebro. Pode ser questao de tempo, talvez.
>    Mas o ciclo de vida de um request no catalyst ainda nao entendi, por
>    exemplo.

Tiago,

Acredito que tua dúvida é muito pertinente. 

E pensando nisto, em 2009 eu escrevi este tutorial em pt_BR sobre o Catalyst:

https://github.com/maluco/catalyst-tutorial-ptbr/blob/master/catalyst.pod

Ela contempla o uso do Catalyst, com um exemplo simples de um aplicativo de 
agenda telefonica.

Bonus: Este exemplo ainda funciona.

E sobre a requisição, é interessante dizer que a filosofia do Catalyst esta
direcionado em oferecer uma flexibilidade grande para o desenvolvedor, facilitar
o "plug" de várias "coisas" de forma simples. Resumindo: o que visualizo é que 
outros frameworks são mais simples de começar, porém tornam a vida do desenvolvedor
extremamente dificeis depois do "ponto" que você começa a necessitar de 
funcionalidades diferentes, seja ela direcionado para escalar sua aplicação,
se comunicar com um servidor web de forma diferente, ou até mesmo interagir
com outros módulos já existentes.

Bonus: Você não fica "amarrado", tirar seu aplicativo do Catalyst é tão
simples, pois na realidade ele trata tudo de forma "orgânica", e você
acaba depois de um determinado tempo, entendendo que isto faz muito sentido.

ATENÇÃO: Isto não é uma defesa ao Catalyst, e sim a sua filosofia. É da mesma
forma que eu defendo módulos do namespace "Cache::", "AnyEvent::" e etc.

Muitos de nós, acabamos desenvolvendo na fase inicial do "relacionamento" com
o framework, baseado apenas na simplicidade de uma sintaxe, e esquecendo que 
além de desenvolver um aplicativo web, precisamos testar, precisamos manter, 
tornar a vida de quem for manter simples. Isto significa, que na minha opinião
"dividir" as tarefas sempre que possível, ou seja, o que é de responsabilidade
do framework seja bem definido, o que é de responsabilidade do banco de dados é 
do ORM XPTO, o que é de responsabilidade por serializar as coisas são de modulos
determinados, o que é de responsabilidade por efetuar cache, são dos módulos
no namespace Cache::, enfim...

Bonus: Na minha opinião, a arquitetura de desenvolvimento do Catalyst é tão
"simples" e orientado ao objetivo de ser exatamente um framework web, que 
em muitos casos, alguns frameworks dizem que esta filosofia é limitada, ou
seja, um framework poderia fazer mais, ele poderia até serializar seus dados,
ele poderia até acessar o teu banco de dados, ele poderia até executar testes
automaticamente, enfim...

CONTRA: Dificulta o acesso por muitos desenvolvedores a tecnologia, pois 
exige uma curva de aprendizado maior, e além do aprendizado no framework, de
vários outros aplicativos que estão ao redor do framework, e que vão completar
ele. Um framework que oferece sintaxe simples, que faz muito mais do que ele
se propõe, oferece uma maneira muito mais rápida no primeiro contato para
resolver teus problemas de forma geral.

PRÓ: Liberdade para o desenvolvedor, o framework web, sendo apenas um
framework web, e nada mais do que isto, na prática significada de forma
prática estabilidade e flexibilidade no mundo de "software-livre", ou seja 
'plugue' com o que você quiser, e há muito menos código para aprimorar.

Bonus: É melhor testar 'tudo' junto, ou tudo separado ? Ou os dois ? O
interessante do Catalyst, que você é orientado de certa forma a resolver
seu problema fora do framework web, e isto vai te ajudar muito, quando 
você começar a elaborar testes, ou mesmo quiser trocar de framework web. ;-)

Mas, depois de tudo isto, fica uma outra pergunta, o que significa ser
melhor ? O que significa visualizar 'liga' no framework que vou utilizar ?

Acredito que o Catalyst é uma boa escolha, quando você procura simplesmente
um framework web.

Se você procura um framework web, que faça mais do que a proposta dele, e
que isto vai te oferecer facilidades iniciais para o teu desenvolvimento,
o Catalyst pode ser para alguns, uma escolha 'dificil', devida a curva
de aprendizado.

E por isto, que em alguns tutoriais normalmente que descrevem, 'vejam
qual o ciclo de requisição no meu framework':

    sub respondendo_requisicao: URL('/') {
        my $resposta = shift;
        return $resposta->html("Olá mundo, veja como sou simples") if $parametro eq 'html';
        return $resposta->json( mundo => 'sou simples') if $parametro eq 'json';
    }

Teoricamente, isto é possivel de se fazer em qualquer framework, basta você
efetuar o teu setup para isto, e aí o que muda o setup 'default' ou mesmo
o esforço que foi realizado para simplificar a sintaxe.

Atenção: Eu acredito que a sintaxe do Catalyst poderia ser melhor, como 
usuário do framework. Eu gostaria de ver um projeto "em cima" do Catalyst
oferecendo uma sintaxe mais simples no geral.

Porém, qual é o meu real ganho com isto ? O meu ganho é sintaxe, mas eu
preciso saber o que o framework esta fazendo 'debaixo' dos panos. Eu posso
ter problemas logo ali, que se eu não entender bem, o que ele esta fazendo
é complicado, vou ter que estudar mais para debugar algo e etc. O interessante
é que este framework já consuma tecnologias que uso em outros cenários, e 
não apenas para o meu framework, isto gera uma curva de aprendizado 
"pós-inicio de relacionamento" muito menor.

Bonus: Aplicações web, estão cada vez mais complexas, cada vez mais extendendo
ferramentas diversas, tecnologias distintas, ou seja, saber que minha
solução faz só uma tarefa e trabalha bem em conjunto com outros, é baita
duma vantagem.

Veja, minha indagação, não é nem sintaxe agora, e sim o que o framework faz
no 'ciclo de vida da requisição'. Pois bem, eu ainda não encontrei nenhum
framework web que faça isto melhor que o Catalyst, pq ? Ele simplesmente
não quer saber de nada, ele simplesmente quer 'rotear' as requisições entre
a minha aplicação, os módulos já existentes para suas respectivas tarefas e
o servidor web. 

Ou seja, o 'ciclo de vida da requisição' no Catalyst é tão simples de ser
explicado, que dificulta na comparação com outros frameworks. Pois, ele 
não faz mais nada além do que dizer 'você vai para cá, você vai para lá', 
agora o que você vai fazer lá, ou cá, é de responsabilidade tua.

O setup 'default' do Catalyst é o MVC, que ele cria uma estrutura de 
diretórios para oferecer esta arquitetura, que é um consenso na grande
maioria dos desenvolvedores web, ou seja, quem 'responde' a requisição é
o "Controller".

No "Controller" nada mais temos do que :

1. sub root : Args(0) PathPart('') ... {
2.    my ($self, $c) = @_;
3.    warn $c->request->user_agent; 
4.    $c->response->headers->header( 'X-Foo' = 'Bar') 
5. }

1. Estou declarando o "cá" ou o "lá".
3. Estou buscando a informação da requisição já efetuada, o user agent.
4. Estou setando um cabeçalho HTTP para resposta.

Ou seja, nestas poucas linhas, eu estou setando quem responde por este
"código", estou mostrando informações da requisição, e estou preparando
a resposta.

Veja uma coisa, tanto a requisição, como a resposta, são baseado nos
módulos do namespace "HTTP::" para oferecer compatibilidade com diversos
outros módulos que trabalhem com HTTP.

Qual o papel além de um framework do que este ?

Esta pergunta, pode levar você para um framework ou outro. Quem vai 
definir, são suas necessidades, se você quer uma sintaxe por exemplo
que retorne JSON diretamente como resposta, você pode ter um cenário
para distinguir dois frameworks:

    use JSON;
    sub foo { 
        return JSON->encode(foo => 'bar');
    }

Ou, ter:

    sub foo {
        return json(foo => 'bar');
    }

O que é mais simples ? O segundo, claro. Mas, antes de falar de sintaxe
precisamos saber o que é feito por baixo dos panos, e é por saber o que
o Catalyst faz e não faz, que opto por ele, e hoje o entendimento da
"vida requisição" dele é até 'muito simples' e me deixa muito confortavel
e seguro de saber que ele utiliza módulos com a mesma filosofia que ele,
ou seja, o próprio módulo JSON que esta disponível não só para este
framework, assim para tantas outras soluções.

Eu acredito que estes frameworks mais novos, que estão oferecendo uma
vida mais simples, podem ensinar muito para o Catalyst em relação a
"tração" de usuários-desenvolvedores. Assim como o Catalyst pode 
ensinar muito, em como "manter tudo" de forma mais estável e elegante
em relação ao ecosistema da comunidade Perl, no caso em especifico.

Enfim, não tenho a menor intenção de gerar um flame war em cima desta
resposta, e sim de levantar questões que eu ainda não vi sendo debatidas
aqui. Na minha opinião pessoal, precisamos valorizar projetos que 
estão fazendo bem para todos, e não só para ele. Afinal, como comentei
aplicações web estão cada vez mais complexas, e cada vez mais vamos
"tirar proveito" de ecosistemas paralelos de desenvolvimento.

O tempo é cada vez mais precioso, e eu hoje quero saber sim o que 
esta "por traz" dos desenvolvimetos de projetos em geral, até por
que isto me dá uma baita segurança como profissional, saber que as
coisas dificilmente vão ser descontinuadas de uma hora para outra
e eu ter uma porção de código que não será mais compativel com nada.

Desculpe o e-mail longo. Se tiver alguma dúvida mais pontual, por 
favor envie.

Abs,
-Thiago Rondon