Construindo aplicações reativas com Undertow

O que é o Undertow

Este artigo apresenta o Undertow, novo web server do WildFly que trouxe a proposta de aumentar a performance do container da Red Hat e oferecer a possibilidade aos desenvolvedores de trabalhar com ele de forma isolada para construir serviços modularizados. Aqui, você verá como utilizá-lo para criar serviços mais rápidos e distribuídos, usufruindo de recursos para lidar com requisições de modo não bloqueante e garantido, assim, uma melhor performance a suas aplicações. Além disso, irá entender como, através da API do Undertow, é possível criar serviços utilizando Java e JavaScript. Profissionais que desejam aprender sobre o assunto podem adotar este artigo como ponto de partida para entender como migrar suas aplicações ou criá-las do zero utilizando essa ferramenta.

O mundo da computação está em constante mudança, e, com isso, muitas vezes precisamos deixar antigos paradigmas para trás e adotar novas opções para criarmos algo do zero. Hoje, com uma demanda cada vez mais crescente e diversificada, é exigido muito mais das soluções que disponibilizamos online, principalmente no que diz respeito ao modo de acesso, que não se limita mais a computadores.

A maneira como consumimos conteúdo também mudou, o que pode ser observado com o uso dos smartphones, responsáveis diretos por esse novo cenário. Atualmente, grande parte dos acessos se dá através de apps, e não mais através de navegadores. Isso tira de nossos serviços várias necessidades, como, por exemplo, servir conteúdo estático, como arquivos HTML, JavaScript, CSS, entre outros. O foco, então, passa a ser uma arquitetura voltada a disponibilizar serviços para atender a essa grande demanda gerada por apps, que são muitas vezes dependentes de serviços que os alimentem com informação.

Esse novo comportamento pode gerar um aumento sensível nos custos relacionados à infraestrutura do sistema, pois junto com a necessidade de disseminar conteúdo em diferentes formatos, existe também um aumento no custo para atender a essa nova demanda. Em casos mais extremos, requer que empresas reestruturarem seus serviços para conseguirem manter a qualidade, como já aconteceu com a Netflix. Enfim, esse trabalho de repensar a maneira como utilizamos serviços impacta não apenas a infraestrutura do sistema, mas todo um mercado de desenvolvimento.

Quando falamos de mobile, por exemplo, o uso de Node.js para criar serviços que atendam aos aplicativos vem se tornando uma grande referência, justamente por fazer uso de eventos em suas threads. Ele é apresentado, em seu próprio site, como um framework focado em eventos e em processos não bloqueantes, ou seja, as requisições trabalham de maneira que o processo nunca fique parado esperando por um retorno de um banco de dados ou mesmo a leitura de um arquivo, assim como acontece com os novos containers Java, como o Vert.x.

O Undertow veio como uma resposta a essa nova maneira de desenvolver aplicações. Como veremos, ele fornece, de forma semelhante, os recursos que fizeram o Node.js ter a relevância que possui no mercado.

Contudo, apesar do espaço que essas ferramentas vêm conquistando, o modelo monolítico de containers continua tendo seu espaço, afinal, a adoção ou não deles depende não somente de uma premissa de tecnologia, mas também de um ponto de vista de gestão e cultura nas empresas. No momento em que é tomada a decisão de utilizar containers como o Undertow, que focam em programação reativa e microservices, isso não só acarreta na necessidade de conhecer a tecnologia em si, mas também em uma mudança na gestão e no modo de pensamento da equipe.

Portanto, é necessário que a empresa tenha mentalidade voltada para DevOps, porque há necessidade de gerenciar melhor toda a estrutura na qual se baseia o desenvolvimento. Como exemplo, ações como o rollback de uma aplicação que apresentou problemas acabam não sendo mais um caminho de fácil acesso, pois, em sistemas que possuem vários serviços diferentes e dependentes uns dos outros, o rollback de um serviço pode acarretar na necessidade de realizar a mesma operação em vários outros. Dessa forma, quando utilizamos microservices pode ser mais fácil manter os serviços que estão funcionando da maneira esperada e lançar um novo pacote para corrigir um possível artefato que apresentou problemas.

Dado o alerta àqueles que querem entrar no mundo de microservices, é bom se habituar à ideia de mudar a sua forma de pensar. A princípio essa frase pode parecer um exagero, mas é a realidade, pois focar nesse novo modo de criar serviços exige uma maior organização da equipe, sendo necessário, também, saber o que as outras equipes estão criando para evitar a implementação de código duplicado. Outro item importante é o processo de deploy, que deve ser rápido e automatizado, pois cada serviço com problema pode acarretar na parada de vários outros.

Para evitar quedas e garantir uma alta disponibilidade, invista em monitoramento, afinal, se monitorar um único serviço monolítico já possuía seus custos e dificuldades, monitorar vários deles eleva consideravelmente essa complexidade. Esses são só alguns itens essenciais que precisam existir na cultura de sua empresa para que o trabalho com microservices seja realizado de forma eficiente.

Apesar de haver a necessidade de adequação, as vantagens de se trabalhar com microservices se sobressaem. O time como um todo sai mais fortalecido do processo de adequação, ganhando experiência e conhecimento, o que com certeza será um diferencial no dia a dia. Além da equipe, o próprio ecossistema da aplicação ganha em vários aspectos, como no tempo de disponibilidade, pois agora não teremos mais um monólito único representando toda a aplicação, mas sim pequenos serviços para atender a várias partes do negócio, e caso um deles fique indisponível, não significa que todo o sistema estará indisponível. Ademais, não há a obrigação de utilizar apenas uma linguagem ou plataforma. Serviços distintos podem ser desenvolvidos de maneiras distintas e, assim, resolver problemas através de tecnologias que atuem melhor em algum requisito específico.

O exemplo do JBoss AS se encaixa bem nesse caso. Há três anos esse produto possuía apenas duas versões: Community e Enterprise. Atualmente, oferece várias versões distintas, como o WildFly, que mesmo mantendo boa parte de sua estrutura, configuração e funcionamento fiel às suas versões mais antigas, tem seu core totalmente modificado. Seu web server, por exemplo, agora é o Undertow, enquanto nas versões mais antigas era utilizado um fork direto do Tomcat. Assim, desde 2013 o WildFly possui um web server novo, que fornece suporte a requisições não bloqueantes. Isso permite que requisições que exigem mais tempo do servidor, como um acesso a um banco de dados ou mesmo a leitura ou geração de um arquivo, sejam feitas em um pool de threads isolado e fora do ciclo principal de cada requisição. Outro container que se beneficia das capacidades do Undertow como web server é o Swarm, que abordamos em outro artigo, publicado na edição 150 da Java Magazine.

As vantagens do Undertow

Na documentação do Undertow, são listadas como suas principais características:

• A alta performance;
• Ser embeddable;
• O suporte a Servlets 3.1;
• O suporte a WebSockets;
• O proxy reverso.

A característica “alta performance” pode ser considerada um pouco abstrata, pois existem muitas situações diferentes que podem ocorrer durante uma requisição e que podem afetar diretamente o tempo de resposta. Por isso, a "