Cinco meses atrás eu iniciei um projeto de NodeJS que veio a ser chamado de Ateliês. O projeto, devido aos seus ideais, tinha que ser Open Source, então coloquei ele no Github. O projeto é voluntario e tem um foco social, a ideia é oferecer a artesãos um canal onde eles possam vender seus produtos sem intermediários no menor custo possível (que hoje, do tamanho que ele está, é zero).

Isso quer dizer que cinco meses atrás eu assumi meu primeiro projeto de verdade com o Node. Eu já tinha feito diversas brincadeiras com ele, eu já tinha palestrado sobre ele, já tinha feito mini projetos, mas nunca tinha colocado nada em produção. E eu estava adorando o que estava vendo, estava sendo muito divertido brincar com o Node. Além disso, o CoffeeScript e o TypeScript são feitos pra rodar primeiramente via Node, é lá seu ambiente nativo. E Node é uma das maneiras mais fáceis de levar ferramental interoperável para linha de comando para Windows, Linux e Mac (como faz o Azure, por exemplo), porque é JavaScript, e porque tem uma API muito interessante e com acesso a arquivos, rede, etc. Quando surgiu a ideia de montar esse projeto, naturalmente pensei em Node.

Então agora o projeto está no ar. O site está em produção em soft-opening, ou seja, está no ar mas é beta em com melhorias a serem feitas (e se vocês notarem no histórico verão que ele conta com quase 700 commits e eu comito quase todo dia, inclusive sábados e domingos). Eu aprendi muito nesses meses e hoje me sinto plenamente habilitado a conduzir um projeto de Node. Conheço suas limitações, o ferramental, os frameworks e componentes, e os seus problemas e oportunidades. Troquei diversas vezes de ferramenta, de paradigma, de abordagem. Esse post é o primeiro de muitos que pretendo fazer pra contar o que eu tenho visto, pra trazer minha experiência pra vocês. Vai ser mais leve que os outros, onde pretendo pegar mais pesado.

Uma das coisas que quero iniciar contando pra vocês é que estou muito surpreso, positivamente, com o que encontrei. Um ecossistema já bastante maduro, com muito apoio da comunidade de desenvolvimento. O ecossistema está maduro o suficiente no ponto em que tudo que quis fazer foi amparado por algum componente que já existia e tornava minha vida mais fácil. Quer logar via Facebook? Fácil. Quer comunicar com o Mongo? Tranquilo. Quer dirigir um navegador durante os testes? Sem problemas. Quer um framework poderosíssimo de testes, ou um que ao rodar mostra gatinhos na linha de comando? Eles tem um pra você. Está precisando se comunicar com um backend de nuvem, qualquer que seja ele? Os caras já tem ferramentas de Node. A stack que usei está detalhada na página de tecnologia do Ateliês. Você vai ver muita coisa legal lá. Depois vou entrar a fundo em muitos dos itens que estão lá.

Algumas vezes eu encontrei problemas. Entrei em contato com os desenvolvedores, fiz correções, submeti pull requests para projetos de tamanho razoável ou não, e foram todos aceitos. As discussões, geralmente feitas nos issues do Github foram muito interessantes e informativas. Isso mostra uma comunidade sem estrelinhas, sem caras que estão se achando rockstars só porque escreveram um componente que deu sorte de ficar conhecido, como tanto acontece por aí.

O código todo foi escrito no VIM, no Linux. Aprendi a usar o VIM quando comecei a codar com Ruby, e adorei. Não sinto a menor falta de nenhum adicional que talvez uma IDE possa proporcionar, ou esses editores mais hipsters por aí, como um TextMate ou Sublime. Isso porque todo o trabalho que esses editores poderiam fazer, como compilar, testar, etc, são feitos via terminais que deixo em workspaces diferentes no Linux. Mantenho 12 workspaces. Tenho um pro VIM, bem no meio à esquerda, outro pra rodar testes de integração e comitar, outro pra acessar a console do Mongo já conectado, outro onde a tarefa de compilação e autotest ficam rodando, fora os outros onde de vez enquanto verifico os módulos do node ou verifico um arquivo compilado. Sou extremamente produtivo com essa configuração. E como estou no VIM e na console o tempo todo nunca pego no mouse pra desenvolver. Nunca.

Todo o código foi feito em CoffeeScript. Eu amo CoffeeScript e sou mais produtivo com ele do que com JavaScript, e ainda mais quando posso focar em EcmaScript 5, como é o caso quando falamos do Node 0.10.x, que é o que estou rodando.

Uma coisa muito interessante que você precisa conhecer, então vou apresentar nesse primeiro post é o Grunt. O Grunt é um automatizador de tarefas. No meu caso ele compila o CoffeeScript, sobe o servidor de Node, roda os testes quando algum arquivo é alterado e reinicia o sevidor se for necessário, otimiza o Requirejs, instala dependências, entre outras atividades. Basicamente eu preciso digitar “grunt” em uma janela de terminal e já posso desenvolver, debugar, rodar testes. Ferramente essencial ao desenvolvedor de Node.

O Node tem um gestor de pacotes, ao estilo Nuget/RubyGems, chamado NPM (Node Package Manager). O NPM é excelente e toda semana eu tenho atualização em algum pacote importante. Tudo anda muito rápido. Só que ele só cuida do JavaScript que está no server. Pra cuidar dos pacotes que rodam no browser há o Bower. O Bower é um NPM que instala pra você o jQuery, o Backbone, o Requirejs, e praticamente tudo o que você quiser. Esse é fundamental se você for um desenvolvedor de frontend. Mesmo se você usa Java, C#, Ruby, deveria gerenciar suas dependências de frontend com Bower.

A aplicação é uma SPA (Single Page Application). Estou usando Backbone pra isso. Isso também dá muito pano pra manga. Temos falado muito sobre esse assunto aqui nesse blog.

E pra terminar você pode rodar sua aplicação Node de graça no Azure, na AWS ou no Heroku. No Azure e no Heroku ela é gratuita forever, no AWS só por um ano. Tenho muito a falar dessas 3 opções, e só a comparação desses três serviços dá no mínimo um post.

Vou terminando por aqui porque a ideia é não fazer posts muitos compridos. Se você se interessou veja os outros posts aqui no blog com a tag nodejs pra ter uma ideia, e veja o post do Elemar onde ele dá um pouco a visão dele. O assunto no meu lado aqui no blog da Lambda3 vai ser só esse nos próximos meses, com poucas exceções.

E se quiser saber mais do porquê do Ateliês, visite o site, dê uma passeada por lá e veja o vídeo do Youtube gravado durante um Conversa Rápida onde explico melhor:

http://www.youtube.com/watch?v=NBRjS4794gg

Até breve.

Giovanni Bassi

Arquiteto e desenvolvedor, agilista, escalador, provocador. É fundador e CSA da Lambda3. Programa porque gosta. Acredita que pessoas autogerenciadas funcionam melhor e por acreditar que heterarquia é mais eficiente que hierarquia. Foi reconhecido Microsoft MVP há mais de dez anos, dos mais de vinte que atua no mercado. Já palestrou sobre .NET, Rust, microsserviços, JavaScript, TypeScript, Ruby, Node.js, Frontend e Backend, Agile, etc, no Brasil, e no exterior. Liderou grupos de usuários em assuntos como arquitetura de software, Docker, e .NET.