LuizTools

Tutorial de Workflow/BPM com Node.js (Camunda)

Este artigo considera que você já sabe o mínimo de Node.js e HTTP, é um tutorial intermediário em programação.

Desde 2017 que atuo em ambientes corporativos e uma coisa que aprendi a respeitar nesse mundo são os BPMS, ou Sistemas de Gestão de Processos de Negócio, os populares “workflows”. Dentre eles, o Camunda se demonstrou uma excelente ferramenta com esse propósito, o de orquestrar complexos processos como originação de contas digitais, automação de processos manuais simples e complexos e mesas de análise.

Além de possuir uma versão gratuita (community) e ter uma baixa curva de aprendizado, o Camunda permite a integração com web APIs Java, Node.js e REST em geral. E é essa conectividade com web APIs Node.js que vamos explorar no tutorial de hoje, criando um workflow simples que chama uma API Node quando chega na etapa correta.

Mas antes de começar, meu intuito com este tutorial é não apenas lhe ensinar como usar esse tipo de ferramenta, mas te motivar a conhecer esse mundo dos BMPS pois é muito promissor.

Vamos lá!

1 – Instalando o Camunda

O Camunda é feito em Java e por isso roda nos principais sistemas operacionais do mercado. Você pode baixar a versão gratuita e open-source, Community Platform, no site oficial.

O zip que você baixa e deve extrair em uma pasta à sua escolha possui o motor de processos, o recurso de Tasklist para processos manuais e o Cockpit, que é a parte de monitoramento.

Além do Community Platform, baixe o Open Source Modeler neste link, que é a ferramenta visual para criação dos fluxos de trabalho.

Ambos arquivos são bem leves de baixar e de rodar. Na própria página de download de cada um deles explica como executá-los no seu sistema operacional, sendo que você deve ter o Java 1.7+ instalado na sua máquina para que eles funcionem (JRE e/ou JDK), bem como as variáveis de ambiente JAVA_HOME (se instalou JDK) ou JRE_HOME (se instalou o JRE) configuradas (quem é programador Java certamente já fez isso antes).

Para executar o motor no Windows (Community Platform), basta executar o start-camunda.bat, enquanto que em sistemas Unix, rode o start-camunda.sh. Em ambos os casos, o terminal deve exibir que o motor está rodando e o navegador deve abrir uma página do Tomcat em localhost:8080, como abaixo.

A partir dessa tela é possível acessar as aplicações do servidor do Camunda para gestão e monitoramento.

Já o Camunda Modeler é ainda mais simples de usar, pois para Windows e Mac basta iniciar o executável da aplicação e no Linux é outro arquivo .sh.

2 – Modelando nosso primeiro processo

Quando ele iniciar, deve apresentar uma tela como abaixo, onde vamos iniciar nosso primeiro processo (BPMN Diagram). A título de curiosidade, BPMN é a notação padronizada e mundial para fluxos de trabalho, mantido pela OMG (a mesma instituição que mantém o UML).

Para aprender vamos criar um processo bem simples: dado que um usuário deseje se cadastrar no sistema, vamos salvar ele no banco e depois mandar um e-mail pra ele, de boas vindas. Esse processo curto e simples deve lhe ajudar a entender como funciona o Camunda e como a integração com o Node.js pode ser feita, inclusive simplificando sua arquitetura.

Como meu intuito aqui não é lhe ensinar BPMN ou a usar a ferramenta visual do Camunda (que é auto explicativa), modele um processo como abaixo e explicarei na sequência o que faz cada caixinha.

Basicamente o círculo representa o início do processo. Os retângulos, são atividades (Tasks), sendo que usei o ícone de ferramenta pra alterar o tipo para Service Task. O último círculo é o fim do processo.

Existem diferentes maneiras de executar Service Tasks com Camunda e aqui vou ensinar a que faz mais sentido para desenvolvedores Node.js que é usando o padrão External Task.

Clique no primeiro retângulo de Service Task e depois na aba Properties Panel à direita. Em Implementation selecione External e em Topic escreva o nome da fila desta atividade como “salvar-usuario-banco”, como na imagem abaixo.

Faça o mesmo procedimento para o segundo Service Task (enviar-email).

Agora vamos configurar nosso processo para execução. Para fazer isso é bem simples: clique em qualquer área branca do workflow e depois na aba Properties Panel para configurar um process id, process name e marcar que ele é executável, como abaixo.

Lembre-se desse process-id, vamos usá-lo mais tarde para inserir usuários no workflow pela API do Camunda.

Salve o arquivo de workflow em uma pasta que você ache depois.

3 – Programando o serviço externo

O próximo passo é criar o serviço externo que vai ficar olhando para o tópico ‘salvar-usuario-banco’ que definimos no Service Task de salvar o usuário no banco. Imagine este tópico como sendo uma fila que o Camunda vai adicionando usuários para serem salvos no banco. Precisaremos de um worker Node.js que vai ficar esperando chegar usuários nesta fila para serem cadastrados.

Para criar este worker, crie um novo projeto Node.js em sua máquina com o nome ‘salvar-usuario-banco-worker’ e rode um npm init nele.

mkdir salvar-usuario-banco-worker
cd salvar-usuario-banco-worker
npm init -y

mkdir salvar-usuario-banco-worker

cd salvar-usuario-banco-worker

npm init -y

Agora, vamos instalar a biblioteca do Camunda para clientes de serviços externos em Node.js, com o comando abaixo:

npm install -s camunda-external-task-client-js

1	npm install -s camunda-external-task-client-js

Agora, dentro da pasta do seu projeto Node.js crie um arquivo worker.js como abaixo, que vai fazer long polling na fila do Camunda com o tópico apropriado.

const { Client, logger } = require('camunda-external-task-client-js');

// configuration for the Client:
//  - 'baseUrl': url to the Process Engine
//  - 'logger': utility to automatically log important events
//  - 'asyncResponseTimeout': long polling timeout (then a new request will be issued)
const config = { baseUrl: 'http://localhost:8080/engine-rest', use: logger, asyncResponseTimeout: 10000 };

// create a Client instance with custom configuration
const client = new Client(config);

// susbscribe to the topic: 'salvar-usuario-banco'
client.subscribe('salvar-usuario-banco', async function({ task, taskService }) {
  // Put your business logic here

  // Get a process variable
  const username = task.variables.get('username');
  const email = task.variables.get('email');

  console.log(`Salvando o usuário ${username} com o email '${email}'...`);

  // Complete the task
  await taskService.complete(task);
});

const { Client, logger } = require('camunda-external-task-client-js');

// configuration for the Client:

// - 'baseUrl': url to the Process Engine

// - 'logger': utility to automatically log important events

// - 'asyncResponseTimeout': long polling timeout (then a new request will be issued)

const config = { baseUrl: 'http://localhost:8080/engine-rest', use: logger, asyncResponseTimeout: 10000 };

// create a Client instance with custom configuration

const client = new Client(config);

// susbscribe to the topic: 'salvar-usuario-banco'

client.subscribe('salvar-usuario-banco', async function({ task, taskService }) {

// Put your business logic here

// Get a process variable

const username = task.variables.get('username');

const email = task.variables.get('email');

console.log(`Salvando o usuário ${username} com o email '${email}'...`);

// Complete the task

await taskService.complete(task);

});

Atenção às variáveis da task que estou pegando, que são os inputs que definimos lá atrás, na Service Task. Também preste atenção na linha que faz o console.log, é ali que você colocaria a lógica de salvar no banco de verdade.

Coloque esse worker a rodar normalmente em Node e ele deve se conectar à sua instância do Camunda (ela precisa estar rodando como falei lá atrás).

4 – Implantando o processo

Agora que modelamos o processo e criamos o worker do Serviço Externo, é hora de publicarmos o nosso processo no Camunda, para que ele passe a funcionar.

No Camunda Modeler, o botão de deploy é o mais à direita no menu (parece um botão de upload) e ao clicar nele, a janela abaixo se abre para que você configure o deploy.

Caso tenha feito tudo corretamente, o deploy deve ser bem sucedido. Caso contrário, a aba inferior Logs vai se abrir explicando o que houve.

Para ver se seu processo está devidamente implantado no Camunda, você pode ir no navegador e usar o Cockpit em http://localhost:8080/camunda/app/cockpit (use usuário e senha demo)

Agora para testar se nosso processo está funcionando, você deve realizar uma chamada REST ao Camunda, o que recomendo que seja feito usando o POSTMAN.

Será um POST em http://localhost:8080/engine-rest/process-definition/key/cadastrar-usuario/start (note o nome do processo em negrito) com Content-Type application/json no header e o seguinte body (raw):

{
	"variables": {
		"username": {"value":"luiz"},
		"email": {"value":"contato@luiztools.com.br"}
	}
}

{

"variables": {

"username": {"value":"luiz"},

"email": {"value":"contato@luiztools.com.br"}

}

Se tudo der certo, ao você enviar essa requisição, terá retorno positivo no POSTMAN, como abaixo.

Olhando no terminal que está rodando o nosso worker Node.js, temos:

O que mostra que passou corretamente por onde deveria.

5 – Indo além

Mas e o que aconteceu quando o usuário chegou na etapa de envio de e-mail?

Dê uma olhada no Cockpit, acessando o nosso processo Cadastrar Usuário. Você vai ver que tem um número na Service Task de enviar email indicando que tem um usuário preso ali.

O processo chega nessa etapa e pára, pois não implementamos nada que consuma o tópico de envio de e-mail ainda. Esse é o funcionamento básico do workflow, ele vai ficar com o usuário preso até que ele seja consumido da sua fila por algum worker Node.js.

Se clicarmos no ID desse usuário, você consegue ver os seus dados e inclusve podemos editá-los.

Para podermos avançar, você terá de implementar um novo worker, para consumir o tópico de envio de e-mails. Faça isso usando o passo-a-passo que fizemos antes e coloque a rodar o seu novo worker que deve funcionar normalmente. Se quiser, use o que ensinei de Node Mailer para enviar e-mails de verdade usando Node.js, ou então o connector de envio de e-mails do Camunda.

Tão logo você suba um worker que consuma o tópico de envio de e-mails, a fila destrava e zera novamente.

Existem muitas outras coisas bacanas que dá para fazer com Camunda + Node, como colocar regras de negócio em DMNs, fazer transbordo de atividades para seres humanos, fornecer fronts para interagir com etapas do processo, postergar ações por tempo determinado, forks, syncs, startar tasks em paralelo e muito mais.

Espero ter despertado o seu interesse pelo assunto e no futuro pretendo escrever mais sobre ele conforme fizer sentido.

Em breve, mais conteúdo!

Curtiu o tutorial? Quer fazer com curso online de Node.js e MongoDB comigo? Clique no banner abaixo!

Métricas que todo Agile Coach deveria estar olhando

Tem algum tempo que escrevi um artigo falando sobre métricas ágeis para Scrum Masters ficarem de olho. Como William Deming sempre dizia, o que não se mede, não se gerencia e apesar do Scrum Master não ser um gerente, a sua posição de servo-líder lhe exige um olhar mais clínico da performance e saúde do time, o que facilita muito tendo métricas para se apoiar.

Mas enfim, e o Agile Coach?

O agilista a nível organizacional também precisa acompanhar métricas e elas podem inclusive serem compartilhadas com os Scrum Masters em um esforço coletivo de melhoria contínua, auxiliando na transformação da empresa como um todo. Quando estive quando estive quase dois anos à frente de uma grande transformação ágil em um banco gaúcho, eu usei de muitas métricas para acompanhar o progresso dos times e da transformação como um todo e a ideia deste artigo é compartilhar um pouco disso.

Roda Ágil

Essa ferramenta é muito interessante, tanto pro Scrum master quanto pro Agile Coach. A Roda Ágil é uma ferramenta criada por Ana G Soares, uma Agile Coach catarinense, que se inspirou na Roda da Vida do coaching profissional (uma das minhas dicas para se tornar um Agile Coach é fazer uma formação de coaching profissional).

Basicamente a roda é dividida em algumas seções e o coach aplicando a roda (individualmente ou em grupo) lê, explica e faz perguntas sobre aquela sessão, sendo que dependendo do formato de aplicação a(s) pessoa(s) responde abertamente ou apenas reflete sobre o que foi perguntado, escrevendo em um papel para organizar os pensamentos. Depois de algumas perguntas da mesma sessão, pede-se que o coachee (quem está passando pelo processo de coaching) dê uma nota para a situação atual do seu time em relação aquela seção.

Após passar por todas seções, pode-se colorir a roda de maneira que ela fique bem visual e os gaps apareçam facilmente, como na imagem abaixo.

Enquanto na roda original do coaching temos seções como Relacionamentos e Finanças, na Roda Ágil temos Pipeline e DevOps. Faz sentido, não? Eu particularmente uso uma versão pessoal que fiz, com menos áreas e focando no que deve trazer mais valor para o time no momento.

Com base no resultado da roda (que é apenas uma fotografia do momento), o Scrum Master pode identificar junto do time pontos a se trabalhar, ações e estratégias de melhoria, o que pode ser feito em uma Sprint Retrospective. Já o Agile Coach auxilia o SM e guarda o resultado da roda para conferência futura, para verificar se este time está conseguindo avançar ou não.

É importante nunca comparar um time com outro, pois o rigor e consequentemente a escala usada para pintar a roda pode variar entre os times. A Roda serve para o time se comparar consigo mesmo entre um ciclo e outro de melhoria.

Outra ferramenta parecida e que talvez você se interesse em usar é o Team Self-Assessment do SAFe. Segue a mesma ideia mas já inclui as perguntas , ou seja, é para ser feita de maneira individual e completamente introspectiva, enquanto que a Roda Ágil tem um fit maior com os princípios ágeis de transparência, colaboração, comunicação, etc. Ainda assim, pode ser uma opção, especialmente se você tiver times distribuídos.

Lean Enterprise Radar

Já que falei em SAFe, não posso deixar de citar o excelente Lean Enterprise Radar, fruto de um assessment muito bem construído pela Scaled Agile Inc. A ideia aqui é medir a empresa e não o time, então é uma ferramenta mais focada em gestores e executivos, para o Agile Coach aplicar.

Você já parou para pensar em que nível da sua transformação ágil sua empresa está hoje? Considerando 15 competências cheias de perguntas que derivam em um gráfico de radar, você pode ter esse diagnóstico mostrando como está a sua Cultura DevOps ou sua Governança Lean.

Como o Agile Coach muitas vezes vai ser um dos líderes da transformação e o principal facilitador da mesma no dia a dia, tirar essa fotografia junto aos gestores e executivos com alguma regularidade vai ajudar a identificar os principais ofensores à transformação e a evolução da mesma.

Talvez a organização não vá querer evoluir em todas essas frentes com a mesma intensidade, então adapte a ferramenta à sua realidade, embora a minha experiência mostre que Business Agility é isso aí mesmo.

Outro uso possível dessa ferramenta é combiná-la com um Modelo de Maturidade, construído a partir dos objetivos da empresa + resultado de um primeiro Lean Enterprise Assessment.

Nível de Maturidade dos Times

Quem me conhece sabe o quanto eu gosto de modelos de maturidade. Embora polêmicos dentre os agilistas é uma prática relativamente comum tanto entre metodologias tradicionais (CMMI) quanto ágeis. Os anos como Agile Coach profissional me mostraram que um modelo de maturidade bem construído ajuda e muito a dar o norte e o passo da transformação digital e/ou ágil de uma empresa.

Eu já escrevi bastante sobre esse assunto neste artigo sobre modelos de maturidade gamificados e não quero repetir por aqui. Como informação adicional eu recomendaria que você primeiro tirasse uma fotografia atual da empresa e dos times no que tange agilidade. Pode usar o Lean Enterprise Assessment que citei antes.

Depois da fotografia, defina onde queremos estar daqui há um ano em termos de Business Agility e Transformação Digital, olhando a fotografia e vendo o que faz sentido e/ou é alcançável com os recursos que queremos/podemos investir. No que tange Transformação Digital, sugiro se apoiar no Digital Transformation Framework da InfoQ, ilustrado na imagem abaixo.

Com essas informações em mãos, de onde estamos e onde queremos chegar em um ano, fica muito mais fácil de fazer o meu passo a passo de construção de modelo de maturidade gamificado que mostrei no outro artigo.

Ao término de cada ciclo, você pode realizar novos assessments, discutir se o plano ainda faz sentido (agilidade, afinal) e verificar a situação dos times frente ao modelo de maturidade: quantos subiram de nível no último ciclo, se algum caiu (se isso for possível no seu modelo), quantos novos entrantes surgiram, quantos se formaram (se não for um jogo eterno), etc.

Essas são apenas três ferramentas que podem gerar insights importantes para Agile Coaches liderando e/ou facilitando transformações ágeis e espero que lhe sirvam de inspiração.

Conhece mais alguma? Tem alguma dúvida sobre as apresentadas?

Deixe nos comentários!

* OBS: curtiu o post? Então dá uma olhada no meu livro de Scrum e Métodos Ágeis e/ou no meu curso sobre o mesmo assunto!

Tutorial de validação de Input de dados em Node.js

Este tutorial requer conhecimento prévio de Node.js, que podem ser obtidos em outros artigos, em meus livros ou meu curso online, onde inclusive possui uma aula em vídeo ensinando a fazer a mesma coisa.

Validar o input/entrada de dados em aplicações é uma das poucas verdades absolutas no mundo da programação. Você simplesmente não pode, jamais, confiar que os dados enviados para sua aplicação processar estarão no formato e tipo corretos que você precisa.

Mesmo que você adicione validação na sua interface ou front-end, dificilmente você conseguirá garantir que, em algum momento, algum usuário descuidado ou malicioso acabe lhe enviando dados fora do padrão que você espera e isso pode ser desastroso.

Quando você pensa em desenvolvimento web então, nem se fala. Existem muitas formas de burlar validações colocadas no front-end, seja através de maneiras simples como desativando javascript ou inspecionando e alterando o HTML da página e muito mais, a formas mais complexas como capturando requisições HTTP do front para o backend e alterando as mesmas (Man in the Middle Attack).

No caso do Node.js, mais especificamente do web framework Express, o mais usado nesta plataforma, os dados recebidos são provenientes dos objetos body, param e query, que aceitam apenas texto de qualquer formato. Se você está fazendo web APIs RESTful, esta validação que vou ensinar neste tutorial será a sua primeira e muitas vezes única defesa contra o descuido e as más intenções de quem for utilizar as suas APIs.

Embora você possa fazer todas suas validações manualmente, usando ‘ifs’ e outras práticas básicas de programação, isso geralmente leva a muito código repetitivo, complexo de testar unitariamente e arquiteturas pouco elegantes. Usaremos neste tutorial o pacote @hapi/joi, o mais popular atualmente para validação de dados e espero gerar alguns insights de como você pode levar validação a sério na sua aplicação sem torná-la um espaguete Javascript.

Então vamos lá!

Vamos começar de maneira bem simples, criando um novo projeto Node.js para mostrar o básico do @hapi/joi e mais tarde espero poder trazer conceitos mais avançados em artigos futuros.

Crie uma pasta chamada node-validation no seu computador e navegue até ela via terminal para criar um projeto dentro dela, usando o npm init. Crie também uma index.js aí.

Adicione no projeto a extensão que vamos usar, com o comando abaixo:

npm i @hapi/joi

1	npm i @hapi/joi

O @hapi/joi (evolução do antigo pacote Joi) usa uma linguagem descritiva para criar schemas de validação (ao contrário de estruturas imperativas como ifs) e é um desses schemas que vamos criar no início do seu index.js, usando o código abaixo de exemplo, que será explicado a seguir.

//index.js
const Joi = require('@hapi/joi');

const userSchema = Joi.object({
    username: Joi.string()
        .alphanum()
        .min(3)
        .max(30)
        .required(),

    password: Joi.string()
        .pattern(/^[a-zA-Z0-9]{3,30}$/),

    birth_year: Joi.number()
        .integer()
        .min(1900)
        .max(2001),

    email: Joi.string()
        .email({ minDomainSegments: 2, tlds: { allow: ['com', 'net'] } })
})

//index.js

const Joi = require('@hapi/joi');

const userSchema = Joi.object({

username: Joi.string()

.alphanum()

.min(3)

.max(30)

.required(),

password: Joi.string()

.pattern(/^[a-zA-Z0-9]{3,30}$/),

birth_year: Joi.number()

.integer()

.min(1900)

.max(2001),

email: Joi.string()

.email({ minDomainSegments: 2, tlds: { allow: ['com', 'net'] } })

})

Na primeira linha, apenas carregamos uma constante ‘Joi’ que será utilizada para criar nossos schemas de validação (através de Joi.object) e o primeiro deles será o userSchema, que possuirá todas as regras de validação de usuários cadastrados no sistema.

A primeira regra é relacionada ao username, que será uma string (Joi.string), alfanumérica (alphanum), com no mínimo 3 no máximo 30 caracteres (min e max) e que é uma propriedade obrigatória (required).

A segunda regra é no password, que também deve ser uma string mas deve seguir o padrão (pattern) declarado sob a forma de uma expressão regular que aceita de 3 a 30 letras maiúsculas, minúsculas e números.

Já a terceira regra, birth_year define que esse dado deve ser um número (Joi.number), inteiro (integer) e com o seu valor entre 1900 e 2001 (min e max).

A última regra, email, foi colocada com o intuito de mostrar o poder desta biblioteca que possui muitas funções utilitárias para facilitar a sua vida, como as já mostradas anteriormente (string, number, required, etc) e aqui temos a função email que recebe configurações por parâmetro como minDomainSegments (para definir o número de partes mínima no domínio do e-mail) e tlds (Top Level Domains – para permitir ou bloquear extensões específicas de domínio).

Agora, para usar este schema de validação é muito simples, basta chamar o objeto userSchema passando por parâmetro na function validate o objeto a ser validado, sendo importante que os nomes das propriedades coincidam.

const val1 = userSchema.validate({ username: 'abc', birth_year: 1994 });
console.log("passou na validação: " + !val1.error)

const val2 = userSchema.validate({});
console.log("passou na validação: " + !val2.error)

const val1 = userSchema.validate({ username: 'abc', birth_year: 1994 });

console.log("passou na validação: " + !val1.error)

const val2 = userSchema.validate({});

console.log("passou na validação: " + !val2.error)

No primeiro teste, o val1 virá com o erro vazio, pois o objeto passado por parâmetro atende aos requisitos do userSchema. Já no segundo teste, val2 terá um erro pois não foi passado o username, que é obrigatório segundo as regras que criamos (required).

Rode este projeto simples no terminal e você verá essas validações em ação.

Antes de prosseguir, sugiro que “desafie” as validações do Joi com outros testes que cubram mais cenários possíveis, só para ver que de fato ele funciona como deveria.

Agora que entendemos o básico, é importante que a gente separe a lógica de validação da lógica de aplicação.

Para fazer isso, crie outro arquivo na sua aplicação que chamaremos de validations.js, com o seguinte conteúdo:

//validations.js
const Joi = require('@hapi/joi');

const userSchema = Joi.object({
    username: Joi.string()
        .alphanum()
        .min(3)
        .max(30)
        .required(),

    password: Joi.string()
        .pattern(/^[a-zA-Z0-9]{3,30}$/),

    birth_year: Joi.number()
        .integer()
        .min(1900)
        .max(2001),

    email: Joi.string()
        .email({ minDomainSegments: 2, tlds: { allow: ['com', 'net'] } })
})

module.exports = {
    userSchema
}

//validations.js

const Joi = require('@hapi/joi');

const userSchema = Joi.object({

username: Joi.string()

.alphanum()

.min(3)

.max(30)

.required(),

password: Joi.string()

.pattern(/^[a-zA-Z0-9]{3,30}$/),

birth_year: Joi.number()

.integer()

.min(1900)

.max(2001),

email: Joi.string()

.email({ minDomainSegments: 2, tlds: { allow: ['com', 'net'] } })

})

module.exports = {

userSchema

}

Note que eu extraí a lógica de validação do index.js para o validations.js e apenas adicionei um module.exports no final, para expor o schema para fora deste módulo JS.

Agora o nosso index.js ficará bem menor, uma vez que a aplicação não faz nada exceto chamar as validações pré-configuradas.

//index.js
const validations = require("./validations");

const val1 = validations.userSchema.validate({ username: 'abc', birth_year: 1994 });
console.log("Passou na validação: " + !val1.error);

const val2 = validations.userSchema.validate({});
console.log("Passou na validação: " + !val2.error);

//index.js

const validations = require("./validations");

const val1 = validations.userSchema.validate({ username: 'abc', birth_year: 1994 });

console.log("Passou na validação: " + !val1.error);

const val2 = validations.userSchema.validate({});

console.log("Passou na validação: " + !val2.error);

Rode novamente esta aplicação no terminal e ela deve continuar funciona como anteriormente, mas agora com uma organização mais elegante!

E por hoje é só pessoal. Espero em próximos artigos explorar formas mais elaboradas de validação, incluindo usando middlewares do Express em aplicações web, mas tenho certeza que esta introdução já lhe deu algumas ideias de como fazê-lo.

Um abraço e sucesso!

Prof. Luiz

Curtiu o post? Então clica no banner abaixo e dá uma conferida no meu livro sobre programação web com Node.js!