Eu e o Node.js<\/h2>\n
Talvez a melhor express\u00e3o para descrever meu relacionamento com Node.js at\u00e9 agora seja\u00a0“curiosidade distante”<\/em>. Meu primeiro contato com a plataforma foi quando surgiu: escrevi alguns mocks de webservices e APIs REST l\u00e1 pelos idos de 2009\/2010.<\/p>\n Se n\u00e3o me falha a mem\u00f3ria estes mocks foram escritos usando o m\u00f3dulo HTTP<\/a> mesmo. Na \u00e9poca fiquei muito impressionado pois com pouqu\u00edssimo\u00a0c\u00f3digo<\/strong> eu conseguia implementar aqueles servidores. Parecia fant\u00e1stico (e era).<\/p>\n Mas na \u00e9poca (e ainda hoje) a JVM dominava minha vida (estou nela desde o Java 1.1 1996\/97). Pra piorar, desde ent\u00e3o vi muitas hist\u00f3rias de terror envolvendo o mau uso: essencialmente a m\u00e1 compreens\u00e3o do modelo ass\u00edncrono, apresenta\u00e7\u00f5es muito ruins sobre o assunto (muito ruins mesmo), hype excessivo, fanboys… Tudo isto gerou uma p\u00e9ssima impress\u00e3o em mim, o que acabou me distanciando da plataforma.<\/p>\n (eu sei que devia focar minhas impress\u00f5es em aspectos objetivos, mas \u00e9 ineg\u00e1vel (e perigoso) o poder do subjetivo)<\/p>\n De l\u00e1 pra c\u00e1 meu uso do Node.js sempre foi indireto: ou tendo como base ferramentas como o Apache Cordova, Vue.js, at\u00e9 mesmo a escrita de pequenos scripts internos para resolver coisas pequenas do meu dia a dia (usava o comando Node como calculadora). Nada de avan\u00e7ado. Nunca fiz uma aplica\u00e7\u00e3o web real.<\/p>\n Al\u00e9m disto sou da gera\u00e7\u00e3o de programadores que n\u00e3o via o JavaScript com bons olhos. Me surpreende a popularidade da linguagem que, todos sabemos, n\u00e3o foi constru\u00edda sobre a melhor das bases. E esta primeira impress\u00e3o ainda exerce influencia sobre mim. Curiosamente mesmo assim JavaScript sempre foi uma das linguagens que mais dominei. Um sentimento do tipo: “sei que voc\u00ea tem muitos problemas, mas os ignoro e gosto de voc\u1ebd”<\/em>.<\/p>\n Navegando pelo Udemy topei com uma promo\u00e7\u00e3o envolvendo este curso:\u00a0The Complete Node.js Developer Course (2nd Edition)<\/em><\/a>. Custava R$ 20,00, os livros em portugu\u00eas que havia lido a respeito detestei (idem os cursos), vi a ementa, li muitos reviews positivos, tinha um fim de semana livre, o neg\u00f3cio era barato e me bateu aquela vontade de aprender Node.js. Comprei. (a prop\u00f3sito, o curso \u00e9 maravilhoso, recomendo)<\/p>\n De onde bateu esta vontade de aprender Node.js? Honesta e pura curiosidade e vontade de tirar a m\u00e1 impress\u00e3o que tinha da coisa. E dado que j\u00e1 estou h\u00e1 mais da metade da minha vida na JVM, que se tornou uma esp\u00e9cie de “ilha de Lost” pra mim, por que n\u00e3o tentar sair um pouquinho deste mundo e minimizar meu determinismo lingu\u00edstico<\/a>? De quebra eu ainda aprenderia um pouco mais sobre o ES6 e algumas ferramentas novas. Come\u00e7ava a expedi\u00e7\u00e3o.<\/p>\n (spoiler: ainda considero a JVM como a melhor plataforma de todos os tempos)<\/p>\n Mas este meu mergulho deveria ter um objetivo final: eu saberia se Node.js valeria \u00e0 pena se constru\u00edsse uma prova de conceito que o validasse enquanto tecnologia. Qual prova de conceito? Simples: reescrever parcialmente o \/dev\/All<\/a> em Node.js<\/strong> e descobrir se o neg\u00f3cio escala mesmo, assim como se o ferramental me fornece produtividade similar \u00e0 que tenho com Grails.<\/p>\n (o resultado foi muito interessante, aguarde e ver\u00e1)<\/p>\n O \/dev\/All tem dois componentes: o “Feed Hunter”, que \u00e9 o respons\u00e1vel por obter os links que aparecem no site (escrito em Java usando Spring, Apache Camel e outras cositas sobre as quais escreverei em breve por que v\u00eam surpresa a\u00ed) e o “Front-end”, feito inteiramente em Grails (3.1.9) e Vue.js.<\/p>\n Um dos nossos objetivos na evolu\u00e7\u00e3o do Front-end \u00e9 transform\u00e1-lo em um SPA<\/a>, desacoplando-o completamente do c\u00f3digo Grails (sim, eventualmente haver\u00e1 um app, no qual j\u00e1 estou trabalhando). J\u00e1 demos alguns passos nesta separa\u00e7\u00e3o, o que se manifesta na ado\u00e7\u00e3o do Vue.js: o c\u00f3digo Grails seria ent\u00e3o apenas uma API REST dali pra frente.<\/p>\n Apesar de todos os nossos esfor\u00e7os, ainda acho este componente pesado: ocupa no m\u00ednimo algo em torno de 300 a 400 Mb de RAM no servidor. A vida inteira escuto que Java devora mem\u00f3ria. Sendo assim decidi que minha prova de conceito seria a implementa\u00e7\u00e3o de uma API que j\u00e1 existe no \/dev\/All: aquela respons\u00e1vel por obter os posts apresentados na p\u00e1gina inicial. Este endpoint aqui<\/a>.<\/p>\n O modelo de desenvolvimento atual usa como base aquilo que o Grails nos prov\u00ea por padr\u00e3o: usamos o GORM como ORM e a pr\u00f3pria estrutura de controladores do framework para implementar estas APIs. \u00c9 not\u00f3rio portanto que h\u00e1 aqui um custo adicional de mem\u00f3ria\/desempenho relativo ao ORM, entretanto no que diz respeito \u00e0 produtividade, comparando o custo do desenvolvedor e do servidor, produtividade ganha e portanto o ORM fica.<\/p>\n O SGBD adotado \u00e9 o MySQL: e a\u00ed entra a primeira dificuldade em rela\u00e7\u00e3o ao material existente sobre o Node.js: 99% do que existe hoje usa o MongoDB como base de dados. Eu teria de aprender portanto como usar o MySQL com Node.js. Usei o m\u00f3dulo mysql<\/a> na vers\u00e3o 2.5.4 (e o aprendizado foi super r\u00e1pido).<\/p>\n No caso do Node.js n\u00e3o encontrei um m\u00f3dulo de ORM com bases relacionais e, sinceramente, desta vez quis evitar. Um dos meus objetivos foi tamb\u00e9m fugir um pouco do desenvolvimento estritamente orientado a objetos e partir para uma abordagem mais funcional (quem acompanha este blog sabe que tenho l\u00e1 meus problemas com OO<\/a>).<\/p>\n Foi uma excelente oportunidade para aprender de vez o ES6 e aqui aquela minha antiga impress\u00e3o a respeito da linguagem foi embora. Querendo ou n\u00e3o eu acabava escrevendo c\u00f3digo JavaScript tal como havia o conhecido l\u00e1 no in\u00edcio da minha carreira no final dos anos 90: de repente veio um upgrade gigantesco e muitas das coisas que n\u00e3o conseguia entender se tornaram claras.<\/p>\n J\u00e1 faz algum tempo que estava me dedicando ao estudo da linguagem, mas ainda n\u00e3o havia me debru\u00e7ado sobre o ES6. Foi sem sombra de d\u00favidas uma verdadeira reciclagem neste aspecto. Muitas coisas que n\u00e3o entendia agora fazem sentido:fun\u00e7\u00f5es arrow, a modularidade, e muitos aspectos envolvendo melhorias da pr\u00f3pria sintaxe.<\/p>\n Uma surpresa maravilhosa: tal como no Grails, tudo o que preciso para trabalhar \u00e9 da interface de linha de comando e um editor de textos. Mas mais do que isto, as ferramentas em si s\u00e3o bastante produtivas: nodemon para carregamento autom\u00e1tico das mudan\u00e7as que realizo no c\u00f3digo fonte, \u00a0as ferramentas de depura\u00e7\u00e3o nativas do Node, o pr\u00f3prio npm (que j\u00e1 conhecia e inclusive devemos lan\u00e7ar um guia esta semana)… Fant\u00e1stico pra dizer o m\u00ednimo.<\/p>\n O carregamento do c\u00f3digo e o tempo de execu\u00e7\u00e3o foram surpreendentes:\u00a0muito<\/strong> mais r\u00e1pido que o que eu esperava. Sobre isto vou inclusive falar mais \u00e0 frente.<\/p>\n Sempre que vou aprender algo novo os testes viram meu laborat\u00f3rio. At\u00e9 ent\u00e3o escrevia meus testes no navegador usando o Jasmine<\/a>. \u00c9 uma solu\u00e7\u00e3o legal, mas nesta expedi\u00e7\u00e3o acabei conhecendo o Mocha, que \u00e9 inclusive muito parecido. N\u00e3o houve grandes mudan\u00e7as para mim neste ponto portanto.<\/p>\n O interessante veio com o Expect<\/a>: ele tem uma funcionalidade muito interessante chamada “spy”. Essencialmente \u00e9 um “AOP para testes”, que te permite verificar se um m\u00e9todo foi ou n\u00e3o chamado.<\/p>\n O Supertest<\/a> tamb\u00e9m achei muito bacana: \u00e9 usado para escrever testes em cima de requisi\u00e7\u00f5es HTTP geradas pelo Express, ou seja, me permite escrever os testes funcionais de uma forma bastante simples.<\/p>\n O bacana \u00e9 que com o nodemon podemos ter os testes executando a cada altera\u00e7\u00e3o que fazemos no c\u00f3digo, isto se mostrou uma m\u00e3o na roda no meu laborat\u00f3rio interno.<\/p>\n Do lado JVM j\u00e1 temos alternativas que seguem a dire\u00e7\u00e3o do ExpressJS, como o Ratpack<\/a> (n\u00e3o conhece? devia!) e o Vert.x<\/a> (literalmente o Node na JVM). \u00c9 o modelo de desenvolvimento que considero ideal quando estamos escrevendo APIs: f\u00e1cil, direto, focado no que vamos fazer (a implementa\u00e7\u00e3o dos endpoints).<\/p>\n Confesso que apenas\u00a0amei<\/strong> o ExpressJS. A documenta\u00e7\u00e3o n\u00e3o \u00e9 t\u00e3o boa quanto a do Grails, mas te fornece o essencial para que voc\u00ea possa fazer praticamente tudo com ele, e de uma forma muito simples.<\/p>\n Nem tudo \u00e9 claro: o uso de sess\u00f5es, por exemplo, n\u00e3o \u00e9 t\u00e3o \u00f3bvio (mais a frente conto o por qu\u00ea das sess\u00f5es), idem no que diz respeito \u00e0 implementa\u00e7\u00e3o de coisas como o CORS. Entretanto, quando voc\u00ea conhece o conceito de middlewares (o equivalente aos filtros da API Servlet) a coisa deslancha.<\/p>\n Sobre os templates, sim: h\u00e1 a renderiza\u00e7\u00e3o de p\u00e1ginas tal como o JSP do Java EE ou o GSP do Grails. Para tal experimentei o Mustache<\/a>, Pug<\/a> e EJS<\/a>. Comparado ao que temos do lado Java s\u00e3o solu\u00e7\u00f5es muito primitivas: o GSP sem sombra de d\u00favidas est\u00e1 anos luz na frente. Mas \u00e9 natural isto: a pegada do Node.js sempre foi muito mais no desenvolvimento de aplica\u00e7\u00f5es que seguem o padr\u00e3o SPA, o que joga este tipo de solu\u00e7\u00e3o para o segundo plano. Acabei optando pelo hbs<\/a> (Handlebars) na minha prova de conceito.<\/p>\n No frigir dos ovos \u00e9 um framework extremamente produtivo. No meu caso, que s\u00f3 conhecia (e muito pouco) o m\u00f3dulo http, foi uma bela surpresa.<\/p>\n Quase tudo que vi no Node achei muito produtivo: e \u00e9 mesmo, mas apenas se voc\u00ea sabe o que est\u00e1 fazendo. Parece \u00f3bvio, n\u00e9? Mas n\u00e3o \u00e9: JavaScript ainda \u00e9 aquela linguagem que a maior parte das pessoas diz conhecer mas nunca estudou a respeito.<\/p>\n Lembra as hist\u00f3rias de terror que mencionei no in\u00edcio deste post? Pelo que pude ver sempre surgiram das mesmas causas:<\/p>\n A ferramenta \u00e9 realmente muito poderosa, \u00e9 \u00a0muito f\u00e1cil de usar e voc\u00ea de fato tem as coisas rodando num tempo muito menor. Mas quando ignora estes pontos acima a coisa fica feia, muito feia.<\/p>\n A armadilha surge no fato do Node ter uma \u00fanica thread (\u00e9 poss\u00edvel ter um servidor com mais de um processo, basta usar o m\u00f3dulo cluster<\/a>, mas n\u00e3o \u00e9 o padr\u00e3o). Qualquer opera\u00e7\u00e3o de I\/O que agarre, prende todas as requisi\u00e7\u00f5es que chegam no seu servidor: sendo assim voc\u00ea n\u00e3o “tem de pensar assincronamente”, voc\u00ea \u00e9\u00a0obrigado<\/strong>.<\/p>\n Mais do que pensar assincronamente, voc\u00ea precisa pensar\u00a0funcionalmente<\/strong>. Se o desenvolvedor n\u00e3o tiver bem fixados os conceitos do paradigma funcional \u00e9 quase certo que vai dar merda. E quer saber de uma coisa? Acho isto fant\u00e1stico, por que sair um pouco do OO foi uma experi\u00eancia quase terap\u00eautica para mim (j\u00e1 mencionei que n\u00e3o curto tanto OO<\/a>?).<\/p>\n Se n\u00e3o souber estas coisas, voc\u00ea n\u00e3o tem poder: tem a ilus\u00e3o de poder e a garantia de estar criando mais hist\u00f3rias tristes que se propagar\u00e3o por a\u00ed.\u00a0Rapadura \u00e9 doce, mas n\u00e3o \u00e9 mole n\u00e3o.<\/p>\n Bom, vamos aos resultados ent\u00e3o. Comecei pela implementa\u00e7\u00e3o de um \u00fanico endpoint: o respons\u00e1vel por realizar a busca por posts no \/dev\/All (este aqui<\/a>). Foi algo f\u00e1cil de fazer: este endpoint me retorna a lista de posts, e cada elemento no post tem uma estrutura similar \u00e0 seguinte:<\/p>\n H\u00e1 portanto tr\u00eas tabelas no banco de dados unidas por join: post, site e autor. Lembre: n\u00e3o estou usando MongoDB aqui, mas sim o MySQL. Ser\u00e1 que a coisa escala? Comecei a realizar ent\u00e3o alguns testes de desempenho e o resultado foi “apenas” assustador como mostrarei na sequ\u00eancia.<\/p>\n A chamada padr\u00e3o a este endpoint retorna os \u00faltimos 20 posts cadastrados no \/dev\/All. Em m\u00e9dia o tamanho da resposta \u00e9 20kb.<\/p>\nCome\u00e7a a expedi\u00e7\u00e3o ao redor do meu quarto<\/h2>\n
![\"\"](\"https:\/\/devkico.itexto.com.br\/wp-content\/uploads\/2017\/09\/viagem_redor_do_meu_quarto.jpg\")
<\/a>![\"\"](\"https:\/\/devkico.itexto.com.br\/wp-content\/uploads\/2017\/09\/banner_facebook.png\")
<\/a>\/dev\/All – Node.js ou Grails?<\/h2>\n
![\"\"](\"https:\/\/devkico.itexto.com.br\/wp-content\/uploads\/2010\/02\/grails_logo.png\"){kind=logo}
<\/p>\nUm pouco mais sobre o modelo de desenvolvimento atual e o da prova de conceito<\/h3>\n
As impress\u00f5es<\/h2>\n
JavaScript \u00a0– ES6<\/h3>\n
![\"\"](\"https:\/\/devkico.itexto.com.br\/wp-content\/uploads\/2017\/08\/logotipo.png\")
<\/p>\nFerramental do Node.js e tempo de execu\u00e7\u00e3o<\/h3>\n
Escrita de testes com Mocha, Expect e Supertest<\/h3>\n
O ExpressJS<\/a><\/h3>\n
O poder e a ilus\u00e3o de poder<\/h3>\n
\n
E a sua prova de conceito, como ficou?<\/h2>\n
\r\n\r\n{\r\n id:"id do post",\r\n titulo:"titulo do post",\r\n resumo:"o resumo do post",\r\n dataPublicacao:"a data em que o post foi publicado no post",\r\n dataInclusao:"a data em que o \/dev\/All encontrou o post e o incluiu no banco de dados",\r\n cliques:"quantos cliques recebeu o post",\r\n site:{\r\n id:"identificador do blog que cont\u00e9m o post",\r\n nome:"o nome do blog",\r\n url:"a URL do blog",\r\n autor:{\r\n id:"o identificador do autor do blog",\r\n nome:"O nome do autor do blog"\r\n }\r\n }\r\n}\r\n\r\n<\/pre>\nTeste de desempenho e escalabilidade<\/h3>\n