[:pt]Como renovamos a arquitetura do nosso CRM com Node e Vue[:]

[:pt]Neste artigo vamos falar sobre a evolução do nosso sistema de CRM focando no conjunto de tecnologias que passamos a utilizar, em como nos adaptamos às mudanças necessárias e qual caminho decidimos ser o melhor entre tantas linguagens e frameworks possíveis.
Para quem não sabe, CRM é um tipo de produto que as empresas utilizam para gerir o relacionamento com os seus clientes. Nosso CRM especificamente é feito para o segmento de hotelaria e serve não só para gerir o relacionamento com os hóspedes – pessoas como eu, você e todo mundo – como também de vendas corporativas. Essa gestão é feita através de envios de email marketing e também do acompanhamento de perto com os clientes empresariais através de executivos de venda. Resumindo, o Pmweb CRM ajuda as redes de hotéis a manter contato com seus clientes há mais de 15 anos, mantendo sempre constantes aprimoramentos em todo seu sistema.

O Desafio

A aplicação era desenvolvida, em sua maior parte, na linguagem .NET WebForms porém com módulos legados e já havia passado por diversas arquiteturas  durante o tempo.
Com a tecnologia em constante mutação havia a necessidade de nos atualizarmos, era evidente que estávamos tecnologicamente defasados e como nos últimos anos estivemos vinculados apenas a tecnologias Microsoft, decidimos que era a hora de visualizar novos horizontes.
Tínhamos  a necessidade de renovar a arquitetura do sistema, e depois de muito estudo, definimos que o melhor caminho seria migramos para tecnologias mais recentes e de amplo uso pela comunidade de desenvolvimento. Mesmo que em um primeiro momento não fosse possível renovar nosso banco de dados.
Apesar das grandes mudanças que viriam com a troca de tecnologia, tínhamos que manter a velocidade de desenvolvimento e obviamente de resposta da aplicação, sem estender os prazos já definidos de novos releases. Não havia espaço para termos uma grande curva de aprendizado, então para onde iriamos? Descobrimos na combinação de Node.js + Vue.js a resposta. Mais do que isso, descobrimos uma forma não só de manter o que queríamos, mas também de aumentar tanto a produtividade, quanto a performance do nosso sistema.
Com isso estruturamos a nova arquitetura em 3 camadas:

  • SQL (Banco de Dados);
  • Node.JS (API Rest);
  • Vue.JS (Interface).

A API

Todo o time contava com vasta experiência em .NET, alguns já conheciam Node, porém sem grande expertise. Como possuímos uma cultura de nos mantermos sempre atentos às áreas de desenvolvimento, nós também desenvolvíamos features em Javascript para a interface. Foi durante uma das pesquisas sobre tecnologias, que percebemos a facilidade que teríamos em desenvolver com base em uma linguagem relativamente próxima ao nosso cotidiano. Seria preciso alterar a nossa infra-estrutura para comportar adequadamente a nova api, porém manteríamos a mesma tração em sua codificação, a partir dessa definição começamos a criar novas provas de conceito e a realmente investir na tecnologia.
Após muita conversa entre o time, foi definido que uma arquitetura em duas camadas se adaptaria melhor a nossa necessidade. Teríamos uma Model onde é feita a comunicação com o banco de dados e uma Controller onde efetivamente trataríamos a informação antes de repassarmos o resultado ao consumidor da Api.
A primeira dúvida foi: Já que não iríamos alterar o SQL Server, como fazer a conexão com o banco? No .Net usamos um framework chamado Dapper onde ele faz o controle de mapeamento de objetos, porém havia uma quebra de paradigma aqui, não existia mais a necessidade de um objeto tipado previamente, com isso começamos a notar as pequenas diferenças na forma de pensar ao desenvolver utilizando a nova linguagem. Após pouco tempo chegamos ao conector que definiríamos como padrão, node-mssql, um plugin já bem conceituado na comunidade e com todas as features necessárias para a nossa demanda.
Tecnologia definida, arquitetura criada e conexão com o banco de dados estabelecida, era hora de criar o primeiro método: Validação de Login. Neste caso em específico deveria haver total integração entre a nova Api e o legado, mas estávamos redefinindo toda a arquitetura e não queríamos manter a forma antiga, então reconstruímos nossa autenticação para o formato JWT, de forma que os dois ambientes entenderiam o login e trocariam informações pertinentes entre si. Ao longo desse desenvolvimento e dos próximos que seguiram, a cada melhoria íamos aprimorando nossa arquitetura, até mesmo o formatado de documentação foi alterado e começamos a utilizar o ApiDocs. Não foi um caminho fácil até alcançar o resultado final, pois além de problemas que não existiam na versão antiga, como o controle de rotas que solucionamos com o Express.js, haviam as quebras de paradigma que faziam cada desenvolvedor quebrar a cabeça para começar a pensar no novo padrão.
Chegamos ao resultado desejado, reestruturamos o nosso back-end e as pessoas envolvidas já trabalhavam diariamente no novo ambiente. Porém como não é só de Api que sobrevive um sistema, repensamos também o front-end, saindo do asp.net com jQuery para algo mais moderno e que nos possibilitou uma rápida adaptação para novos conceitos.

Nova Interface

A interface do sistema foi totalmente repensada e redesenhada com um novo layout mais moderno e adequado para melhorarmos ainda mais a usabilidade dos nossos usuários.
Começamos mapeando todas as funcionalidades do CRM com a nossa equipe de UX/UI Designer, então definimos quais seriam nossas prioridades e desenvolvemos um Style Guide para a aplicação. Durante todo esse processo a comunicação aberta com a equipe de UX foi de extrema importância, pois possibilitou que juntos, as equipes encontrassem as melhores soluções para a interface de usuário.
Primeiramente buscamos uma nova forma de desenvolvermos nossa interface, que antes era construída numa combinação ASP.net + JQuery. Em nossas buscas vimos um pouco de tudo sobre o que está em alta no mundo Front-end, como React, Angular e Vue, esses são, o que podemos chamar de, a tríplice coroa dos frameworks JavaScript dos últimos anos. Adotamos também como padrão as novas features do JavaScript, lançadas em 2015, conhecidas como ES6.
Nessa parte da história é onde entra em ação o Vue.js e como esse framework facilitou (muito) o nosso trabalho.
Para você que ainda não tinha ouvido falar, Vue.js é um framework JavaScript criado por Evan You, ex engenheiro da Google, em meados de 2014, o projeto surgiu como uma alternativa ao Angular e cresceu rapidamente, tomando grande popularidade na comunidade de desenvolvimento.
Mas o que a gente viu no Vue?
Vimos no Vue um framework com uma suave curva de aprendizagem, o que facilitou a aceitação da equipe, mesmo apenas um desenvolvedor tendo experiência anterior com Vue a integração do framework dentro da equipe foi rápida e evoluiu naturalmente.
Vue também é muito versátil e fácil de adaptar em diversas arquiteturas. Como prova de conceito, desenvolvemos alguns componentes em Vue dentro da nossa arquitetura .NET antes de partimos de fato para a nova interface da aplicação, agora uma SPA que consome a nova API Rest que falamos anteriormente.
E a cereja do bolo são os Single File Components do Vue, que simplificaram a componentização da interface e facilitaram a reutilização de componentes e manutenção dos mesmos.
Ecossistema Vue
O ecossistema Vue nos trouxe diversos plugins e ferramentas que auxiliam no desenvolvimento, uma dessas ferramentas é a Vue CLI, que entre seus tantos recursos, também nos entrega todo suporte necessário para Webpack, Babel, Lint, teste unitário, etc. O que nos poupa de ter que configurar tudo isso manualmente.
Outros plugins Vue interessantes que utilizamos são:

  • Vue Router:  para o controle de rotas
  • Vuex: Controle de Estados centralizado
  • Vue i18n: plugin multi idioma, onde controlamos as traduções da interface.

Mais do que apenas Tecnologia

Até então criamos e definimos novos padrões para o nosso desenvolvimento, atualizamos tecnologicamente nossa arquitetura e descobrimos que abrir os olhos e sair da caixa pode trazer resultados melhores do que o esperado. Conseguimos não só manter, mas aumentar a produtividade do time mesmo atualizando toda a stack do projeto. Com isso, não focamos em uma só área como back-end ou front-end mas sim no ciclo de vida como um todo. Não focamos este artigo nesses assuntos, porém a infraestrutura, a forma de publicação e o versionamento também foram atualizados durante o processo.
Ainda temos um longo caminho para a reestruturação completa do legado, afinal são 15 anos de desenvolvimento, mas dessa forma garantimos que todas novas features serão desenvolvidas na nova arquitetura e que o legado só receberá a manutenção necessária, o que é um ponto importantíssimo para qualquer projeto que esteja sendo remodelado.
Durante esse percurso pretendemos adicionar cada vez mais metodologias e tecnologias, esse é um processo que não pode e não será parado, sistemas devem evoluir através de pesquisas para continuarem no mercado mesmo já sendo líderes do segmento.
Neste artigo contamos um pouco da trajetória que passamos ao adotarmos novas tecnologias para um produto já estável e consolidado, mas e quanto a você? Nos conte suas experiências com essas tecnologias ou desafios semelhantes nos comentários abaixo e não esqueça de deixar alguns claps.
Este artigo é de autoria dos nossos desenvolvedores Gustavo Luzia e César Martinez.[:]