Recentemente desenvolvi uma aplicação que depende muito do cache para funcionar bem. O Rapid Mockup, um software para desenvolvimento de mockups em 3D, que roda diretamente no navegador. Lancei o Beta 1, rodou tudo bonito.
Aí chegou a vez de lançar o Beta 2, e surge um problema: como as pessoas vão receber as atualizações se a maior parte da aplicação fica em cache? Fui estudar as alternativas:
Essa alternativa eu simplesmente descartei por ser inviável. Isso representava baixar toda a aplicação do servidor sempre que o usuária acessasse. O Rapid Mockup é uma aplicação pesada, e mesmo que fosse mais leve, não poderia correr o risco de desperdiçar os benefícios do cache, que permitem carregar a aplicação de maneira muito rápida.
Essa é uma boa alternativa, em partes. Eu poderia colocar um tempo de expiração de uma semana, por exemplo, e após uma semana, sempre atualizar a minha aplicação. Mas isso forçaria a recarga completa da aplicação toda semana, e muitas vezes, eu alterei apenas um arquivo pequeno. Além disso, se fiz um update, quero que os usuários tenham acesso agora, e não daqui dois, cinco, sete dias.
Essa opção funciona, é um pequeno "hack" utilizado para resolver essa questão. O parâmetro na frente do script ("v=1.2") é apenas uma forma de modificar a URL de carregamento, e que faz com que o arquivo seja carregado novamente. No entanto, alguns proxies como o Squid não funcionam com essa opção, fazendo com que o script seja sempre recarregado, mesmo que não tenhamos modificado o parâmetro.
Essa é a melhor opção, pois também funciona com proxies como o Squid e outros. No entanto, tem um preço à se pagar por isso: o controle de diversos arquivos no seu sistema de versão.
Bom, depois de pesquisar e ler alguns artigos como este, acabei me decidindo por utilizar a quarta opção, versionando os arquivos separadamente. Não é a mais simples e intuitiva, mas é a que funciona melhor. E qualidade é o que desejamos entregar, não?
Se você souber de uma solução melhor, ou tiver alguma carta na manga, por favor comente abaixo. Afinal, estou aqui pra aprender e trocar experiências.
Sucesso e Abraços!!!
Imagem do Rapid Mockup
Aí chegou a vez de lançar o Beta 2, e surge um problema: como as pessoas vão receber as atualizações se a maior parte da aplicação fica em cache? Fui estudar as alternativas:
Limpeza total do cache
Sempre que abrir a aplicação, limpar todo o cache realizando um location.reload(true), o que força a página a ser carregada diretamente do servidor.Essa alternativa eu simplesmente descartei por ser inviável. Isso representava baixar toda a aplicação do servidor sempre que o usuária acessasse. O Rapid Mockup é uma aplicação pesada, e mesmo que fosse mais leve, não poderia correr o risco de desperdiçar os benefícios do cache, que permitem carregar a aplicação de maneira muito rápida.
Tempo de Expiração
Configurar um tempo de expiração curto para o cache dos meus recursos no servidor.Essa é uma boa alternativa, em partes. Eu poderia colocar um tempo de expiração de uma semana, por exemplo, e após uma semana, sempre atualizar a minha aplicação. Mas isso forçaria a recarga completa da aplicação toda semana, e muitas vezes, eu alterei apenas um arquivo pequeno. Além disso, se fiz um update, quero que os usuários tenham acesso agora, e não daqui dois, cinco, sete dias.
Utilizando "Query Params"
Utilizar versionamento usando um "query param". Ex: <script src="./scripts/script.js?v=1.2">Essa opção funciona, é um pequeno "hack" utilizado para resolver essa questão. O parâmetro na frente do script ("v=1.2") é apenas uma forma de modificar a URL de carregamento, e que faz com que o arquivo seja carregado novamente. No entanto, alguns proxies como o Squid não funcionam com essa opção, fazendo com que o script seja sempre recarregado, mesmo que não tenhamos modificado o parâmetro.
Versionamento no nome do arquivo
Utilizar versionamento no nome do arquivo. Ex: <script src="./scripts/script-1.2.js">Essa é a melhor opção, pois também funciona com proxies como o Squid e outros. No entanto, tem um preço à se pagar por isso: o controle de diversos arquivos no seu sistema de versão.
Bom, depois de pesquisar e ler alguns artigos como este, acabei me decidindo por utilizar a quarta opção, versionando os arquivos separadamente. Não é a mais simples e intuitiva, mas é a que funciona melhor. E qualidade é o que desejamos entregar, não?
Se você souber de uma solução melhor, ou tiver alguma carta na manga, por favor comente abaixo. Afinal, estou aqui pra aprender e trocar experiências.
Sucesso e Abraços!!!