Memcached.JS /ou: Sanidade não era pré-requisito

Posted: 1 de mar de 2011 | . David Lojudice Sobrinho | tags: , , , ,

Idéia
Eu acho que pra aprender uma nova linguagem, engine, etc., é bom ter um projeto com um propósito prático. Afinal é na prática que você vai sentir as verdadeiras dores.

Estava interessado em aprender Node.JS, principalmente seu modelo de non-blocking I/O e JavaScript no server-side utilizando o V8. Ao pensar num projeto pra implementar essas idéia, event loop (de I/O) e memória (GC), a primeira coisa me veio a cabeça foi o Memcached.

Mas implementar o Memcached em JavaScript? Ninguém falou que seria fácil! Aqui compartilho alguns desafios que encontrei, alguns vindos do problema proposto em si (cache distribuído em memória) e outros vindos pela solução dada (Node.JS, V8, etc.)

Prefácio: Memcached Server em JavaScript?
Quando comecei, a idéia parecia meio maluca, mas a intenção era aprender e, logo, sanidade não era pré-requisito. Se eu conseguisse implementar os principais comandos e um algoritmo de complexidade O(1) de cache, como no projeto original, eu já estava feliz. Depois era só perseguir uma performance parecida.
Depois de conseguir atingir alguns desses objetivos, o Memcached.JS agora me parece uma alternativa em alguns cenários. Exemplos que me vem a mente:

- Não tenho acesso a um Memcached mas uso um serviço de cloud para Node.JS. Se performance não é seu requisito mais forte, você poderia ter uma instância do Memcached.JS sem problemas (e, alias, não é que a performance do Memcached.JS é ruim, ela só não é tão boa quanto o projeto original).

- Alterar o comportamento do server. Entre se perder em 7500 linhas de código em C do projeto original, basta brincar com 750 LOC em JS. Simples.

Tenho certeza que pessoas mais criativas que eu vão achar usos mais interessantes, mas esses acima já me fazem olhar para o projeto de uma forma diferente. Sim, é uma idéia meio maluca, mas talvez tenha sua utilidade.

JavaScript mostra sua idade
A primeira dificuldade que se encontra ao programar em JS em server side é que existem um mundo de informações sobre JavaScript, mas a maioria é "how to" para desenvolvimento front-end, onde informações de DOM e JS se misturam. Além disso, a maioria dos links é da idade da pedra da internet. Ex.: procure "js string concatenation"

Encontrar bom material sobre JavaScript, sem detalhes de browser e além disso atual, com técnicas avançadas do uso da linguagem (a parte funcional, por exemplo) leva um tempo. Bom, vou facilitar seu lado: http://neversaw.us/2011/1/16/not-your-fathers-javascript/

Orientação (quase) a Objeto
Pode-se argumentar se existe ou não OO em JS, mas a verdade é que se ela existe, não é "out-of-box". Você se pega desbravando por prototypes, problemas com this e o obscuro bind. E tudo que você queria era um método numa superclasse. Depois desse perrengue, hoje eu acho super legítima a idéia do CoffeScript.

V8: Uma VM para server-side?
Uma discussão que apareceu quando estava desenvolvendo o projeto foi se o V8 era uma VM preparada para server-side, já que o principal mantenedor, o Google, tinha interesse exclusivo no front-end. Interessante, certo?
Meus testes, no meu domínio de problema, mostraram que o V8 se comportou muito bem. Para um cache, que trabalha com objetos em memória, eu não vi grandes penalizações.
O que eu vejo como melhoria, especificamente para o Memcached.JS, é que o Buffer faça parte do V8, assim como String, e não parte da lib do Node.JS. Isso provavelmente iria fazer o Buffer ser gerenciado tão rápido quanto a String é hoje.
Ai vem a pergunta: isso vai fazer diferença no front-end (aka Chrome)? Não. E por isso, provavelmente, não veremos essa alteração tão cedo.

Se você precisa entender como a VM está trabalhando ou fazer profile do seu código em JS, recomendo aqui algumas libs e tools muito boas para fazer isso:
- https://github.com/dannycoates/v8-profiler
- https://github.com/dannycoates/node-inspector
- http://code.google.com/p/v8/wiki/V8Profiler

E a parte boa?
Concorrência! Coisa linda de ver. Quão simples pode ser um código que não precisa se preocupar em bloquear recursos compartilhados em um ambiente altamente concorrente? Simples o suficiente. E isso é muito bom! Foi possível desenvolver um cache acessado por várias conexões simultâneas sem um nenhum "lock". Cool!

Ah! Eu falei da velocidade do código? V8 shines!

Eu sei que o Memcached.JS não é o típico exemplo de uso do Node.JS, mas valeu o aprendizado. E reforçou que eu devo ficar de olho no Node.JS e JavaScript!

3 comentários:

  1. Edmar Wiggers (Macrovita) disse...
  2. Show de bola David! Parabéns pela idéia, e mais ainda pelo post compartilhando!!

  3. Edmar Wiggers (Macrovita) disse...
  4. Show de bola David! Parabéns pela iédia, e mais ainda pelo post compartilhando!!

  5. BRAGA, Bruno disse...
  6. Muito legal!