Why we chose #NodeJS

[Versão Em Português]

First of all is important to understand that I was never a javascript fan to begin with. Always considered it to be a wonky incomprehensible language that is always trying to stab you in the back as soon as you begin to trust it.

Nor was I ever a fan of front-end programming, so any language that remotely reminds me of assembling a screen is like water and oil, so you can see that for this to work, the language REALLY had to get me excited for it to even being taken into consideration.

However, as soon as I was hired for the company I currently work for, it was given me the difficult task of defining a technology that would not only reduce development and operational costs, but it needed to bring together what was by that time two very separate teams of Java/Oracle SOA and .Net developers that, as it was presented to me, even though it did not take much to realize this assumption was not true, not only did not agree much, but were not extremely inclined on to learning new technologies.

I had never heard of #NodeJS before so I was not even sure on where to start. I had been working with Java before this job for about 18 years so you can imagine that my view deciding on Java or .Net would be highly biased, meaning that could not be an option. Some research was definitely on my horizon.

Many languages were considered and even though I still am keeping Python as my choice for the near future on our ML efforts, not a lot of languages really called my attention, until I decided, as one of the demands was also reducing costs, to search for cloud PAAS solutions and bumped into many cloud service providers offering really low cost hosting on javascript services, and the name #NodeJS first popped. How can it be, I thought to myself, javascript is not a enterprise solution language, one would have to be mad to choose such a thing!

Even still being very skeptical about this, I decided to approach all the developers on both very distinct groups so I could see how many of them had used or still use javascript on a daily basis and as you can imagine it was not hard to discover most of them had previous knowledge and some of them were even making their own #NodeJS experiences on their personal projects.

After a lot of coding to prove to myself that might actually be a good bet. With the help the book listed below as weel as a lot more documents and contributions the open source community constantly publishes, special mention here to Rising Stack, the group of directors decided it was worth trying our first project.

Obviously there were a lot of bumps on the road, a lot of lessons learned throughout, however, once the project was online, the solution’s performance was so impressive, the need of processing power so forgiving that it did not take long for other project managers try and reach our team so they could also use the solution on their own demands.

In coming weeks my plan is to send a lot more posts regarding the problems we had, the solutions we found using the power of the open-source community, the products we decided to use and how they performed in the real world.

Please follow me on Twitter at @vrsbrazil so you can see how the first project evolved and much more.

Thank You.

Vinícius Santos

Advertisements

Por que escolhemos #NodeJS

[English Version]

Primeiro de tudo é importante entender que eu nunca fui um fã de javascript. Sempre considerei uma linguagem incompreensível e vacilante que está sempre tentando apunhalá-lo pelas costas assim que você começa a confiar nela.

Também nunca fui fã de programação de front-end, então qualquer linguagem que remotamente me lembre de montar uma tela é como água e óleo, então você pode ver que para isso funcionar, a linguagem REALMENTE precisava me animar para ser levada em consideração.

No entanto, assim que fui contratado para a empresa para a qual trabalho atualmente, me foi dada a difícil tarefa de definir uma tecnologia que não só reduziria os custos operacionais e de desenvolvimento, como também precisaria reunir o que era na época, duas equipes bem separadas de desenvolvedores Java / Oracle SOA e .Net que, pelo que me foi dito na época, apesar de em pouco tempo perceber que essa era uma impressão muito errada, não apenas não concordavam muito, mas não estavam extremamente inclinados a aprender novas tecnologias.

Nunca tinha ouvido falar do #NodeJS antes, então eu nem sabia por onde começar. Trabalhei com Java antes deste trabalho por cerca de 18 anos, então você pode imaginar que a minha opinião sobre Java ou .Net seria altamente tendenciosa, o que significa que não poderia ser uma opção. Alguma pesquisa estava definitivamente no meu horizonte.

Muitas línguas foram consideradas e mesmo que eu ainda esteja mantendo Python como minha escolha para o futuro próximo em nossos esforços de ML, poucas línguas realmente chamaram minha atenção, até que decidi, como uma das demandas também era redução custos, buscar soluções PAAS em nuvem e acabei esbarrar em muitos provedores de serviços cloud que oferecem hospedagem de baixo custo em serviços de javascript, o nome #NodeJS apareceu pela primeira vez. Como pode ser, eu pensei comigo mesmo, o javascript não é uma linguagem de solução corporativa, seria preciso ser louco para escolher uma coisa dessas!

Mesmo ainda sendo muito cético sobre isso, decidi abordar todos os desenvolvedores em ambos os grupos distintos para que pudesse ver quantos deles tinham usado ou ainda usam o javascript diariamente, e, como você pode imaginar, não foi difícil descobrir muitos deles não só tinham conhecimento prévio mas alguns deles estavam até fazendo suas próprias experiências #NodeJS em seus projetos pessoais.

Depois de muita codificação para provar a mim mesmo que poderia realmente ser uma boa aposta. Com a ajuda do livro listado abaixo, além de mais documentos e contribuições que a comunidade de código aberto publica constantemente, é importante mencionar aqui o Rising Stack, o grupo de diretores decidiu que valeu a pena tentar o nosso primeiro projeto.

Obviamente, houveram muitos problemas na estrada, muitas lições aprendidas, mas, uma vez que o projeto estava online, o desempenho da solução foi tão impressionante, a necessidade de poder de processamento tão generoso que não demorou muito para outros gerentes de projeto entrarem em contato com nossa equipe para que eles também pudessem usar a solução em suas próprias demandas.

Nas próximas semanas, meu plano é enviar muito mais posts sobre os problemas que tivemos, as soluções que encontramos usando o poder da comunidade open source, os produtos que decidimos usar e como eles se comportaram no mundo real.

Por favor, siga-me no Twitter em @vrsbrazil para que você possa ver como o primeiro projeto evoluiu e muito mais.

Obrigado.

Vinícius Santos

Como definir um timeout para o listener do seu cliente Socket.io

Olá!

[English Version]

Então eu esbarrei em um problema com o módulo socket.io-client onde você não pode definir timeout para listeners, então se por exemplo você fez isso em seu código:


 socket_client.on ("my_event", (resposta) => {
   
    console.log ("Evento respondido");
   
});

Não há propriedades que você possa passar (até onde eu olhei, eu sei que há tickets abertos sobre isso) para timeout deste listener, então se você tiver um cliente de longo tempo conectado, ele experimentará um aumento de memória. Não é um vazamento de memória, os objetos estão realmente esperando para entrar em ação, mas pode haver uma situação em que um erro ocorreu e seu listener permanecerá lá para sempre até que você pare o processo.

Então, para atenuar isso, você poderia adicionar ao seu código esta função muito simples:


var addListener = (socket_client, eventName, 
                  callback, timeout)=>{

    // Adicionando o ouvinte de evento como
    // você normalmente faria

    socket_client.on(eventName,callback);

    // Se o ouvinte ainda não estiver limpo
    // após o tempo limite, isso fará o truque

    setTimeout(()=>{

      if(socket_client.hasListeners(eventName)){

        socket_client.removeListener(eventName, callback);

        console.log(eventName + " listener was cleaned");

      }

    }, timeout);

  }

Obrigado.