View Original Text

Hide Table of Contents

"I choose to code it in BASH.... I choose to code it in BASH and other things in one week, not because it is easy, but because it is HARD!!!"

#lisíadas #DevOpLife
(modesto, eu, não?)

Páginas HTML (Client Side)

Não tem tanta firula, é HTML5+CSS3+JS . A página faz um request para o W/S, recebe um JSONP, "parseia" e monta a View. A parte bacana é que não usei AJAX nem JQUERY, dependência mínima. Funciona apenas em browsers modernos por conta disso.

Autocomplete com Awesomplete. Cache local dos metadados do servidor (tanto para poupá-lo como para agilizar o client-side que estiver usando conexão limitada, como 3G). Há margem para otimizações, não me preocupei muito em economizar memória (eu podia criar uma única lista de autocomplete e compartilhar entre os campos de texto...)

Uso do localStorage para cache dos metadados do Server. Cache vence por mudança de versão do serviço e por tempo.

Ficou pesada num celular.... =/

Hackear a página é simples: aquilo roda até na sua máquina local sem alterações - salve tudo na sua máquina local e saia brincando. :-)

Interesting issues solved

localStorage

O RPi tende à ficar sobrecarregado. Ainda mais, o objetivo é que estes serviços sejam prestados por pequenos dispositivos espalhados pelo mundo, sabe Deus em que condições de largura de banda.

Adicionalmente, testes empíricos demonstram que são os list das entidades são as chamadas que mais ferram a vida do serviço. E estar ocupando 85% da memória do dispositivo só com este serviço não tá ajudando muito: o aftermath é que as chamadas secundárias são simplesmente as mais lentas (algumas chegando a 30 segundos!), enquanto a working horse do sistema faz o trabalho dela em 1/10 de segundo. A escassez de memória dá a dica de que estamos sofrendo com as limitações do PyPy, uma vez que são exatamente estas chamadas as que fazem uso pesado de Strings (o ponto fraco do PyPy!), que gera muito lixo e obriga o GC do PyPy (uma carroça de bois mancos) à trabalhar constantemente.

Então as páginas de demonstração fizeram um uso bem agressivo de cache - no startup carregam todas as entidades (menos files) e armazenam num cache local (localStorage) durante uma semana ou até mudar a identificação do servidor (normalmente, versão).

Só que com a inclusão de novos datasources, topei com uma situação inesperada: eu estourei a quota do localStorage!!

Pesquisas se revelaram infrutíferas - parece que ninguém sabe ao certo qual o tamanho da quota. Li sobre limites que variam de 10 megabytes até o espaço disponível em disco, ao passo que um código para pesquisar e solicitar mais espaço me informa que o limite corrente é de 2Giga. Mas este mesmo código me dizia que estava ocupando menos de 1K... Sei não. :-)

Tentei atacar a situação com bibliotecas de persistência, todas as opções se revelaram pior que o problema. Não me solucionavam o estouro que eu recebia ao tentar persistir o cache dos datasources maiores, e ainda era mais uma coisa para aprender (e ainda ter que confiar no cara). Até que topei com alguém na StackOverflow comentando que havia um limite de 10 Megabytes por item. Hummm.... Agora começa a fazer sentido.

Passei a compactar (usado o lz-string) os dados antes de armazenar do localStorage, e o problema foi resolvido no curto prazo. Todo o localStorage agora está usando pouco mais de 2 megabytes (chequei no filesystem, uma vez que o maldito DevTools do Chrome tá travando quando tento analisar o localStorage por ele - belo pedaço de *).

Pra os curiosos, no MacOS o Local Storage do Google está em ~/Library/Application Support/Google/Chrome/Default/Local Storage .

CORS

TODO