Márcio, On Tue, Mar 12, 2013, at 02:24 AM, Thiago Rondon wrote: > Como diria Phil Karlton. Há apenas duas coisas difíceis em ciências da > computação, invalidação de cache ou dar nome as coisas.
São duas, as coisas difíceis: dar nome, invalidar cache e acertar nos índices ao iterar sobre listas! ;) > Na minha opinião, se você esta utilizando a arquitetura REST e quer > efetuar cache na aplicação é um tiro no pé, uma hora isto vai te dar dor > de cabeça. Digo isto, pois a maior parte do desenvolvimento e evolução > dos frameworks, servidores web, proxy e navegadores nos últimos anos > foram na direção contraria. O cache deve ser local (cliente) ou > compartilhado (intermediadores). O cache no servidor é válido também, bastante indicado quando é mais caro computar a representação do recurso em cada request, ao invés de gerá-la novamente, é onde etag e last-modified funcionam muito bem! :) > Para efetuar cache baseado no header, verifique se as próprias opções do > HTTP não te resolvem, principalmente com as estratégias disponíveis para > isto. Utilizando as diretivas dentro de Cache-Controle, Expire, .. Ou > recomendando a interação com teu backend baseado com perguntas baseado ao > Etag ou Last-Modified. Então, se você tem o request e vai respeitar as especificações, me pareceu artificial a restrição de não ter um proxy reverso com cache na frente da sua app. Inclusive, até bem recentemente, esses caras eram mais conhecidos pelo nome "web application accelerator" veja https://en.wikipedia.org/wiki/Web_accelerator#Web_server_accelerator Se você faz questão de trabalhar dentro da sua app, veja a turma CHI::* e coisas como https://metacpan.org/module/Memoize::Memcached Abraço, Nuba -- Nuba R. Princigalli n...@pauleira.com http://pauleira.com @nprincigalli Discipline is not an end in itself, just a means to an end. - King Crimson _______________________________________________ Rio-pm mailing list Rio-pm@pm.org http://mail.pm.org/mailman/listinfo/rio-pm