n8n para devs: Reduzindo a carga do back-end

Arquitetura do offload - Apresentação

Apresentando o instrutor e o curso

Bem-vindos a mais um curso de N8n voltado para pessoas desenvolvedoras. Eu sou Ricardo Bugan, responsável pela rede operacional e rede de produto, e serei o instrutor neste curso.

Explorando o uso do N8n para aliviar a carga do servidor

Neste curso, vamos trabalhar com um novo caso em que o N8n pode auxiliar no dia a dia de desenvolvimento, especificamente em situações em que precisamos aliviar a carga do nosso servidor. Temos uma arquitetura de sistema na qual o back-end realiza uma série de processos e atividades, mas não está focado no núcleo do negócio.

Como podemos transferir operações do back-end para o N8n, aliviando o uso de recursos do servidor? Vamos trabalhar com uma integração de CRM, um caso muito comum, em que precisamos transferir informações de clientes que chegam à nossa empresa para outra equipe, utilizando uma ferramenta que essa equipe usa. Vamos criar um workflow que, além de reduzir a carga do servidor, é robusto, fácil de manter e lida com diversos tratamentos de casos de erro.

Abordando casos de erro e armazenamento de informações

No curso, vamos nos aprofundar na questão dos casos de erro: o que podemos prever, qual tipo de resposta devemos dar e como elaborar uma resposta interessante para o webhook. Também abordaremos como armazenar informações, que tipo de dados devemos guardar, e quando é vantajoso transferir processos do back-end para o N8n. Tudo isso será explorado ao longo do curso. Esperamos vocês lá!

Arquitetura do offload - Backend sobrecarregado

Introduzindo o conceito de offload de operações do back-end

Neste curso, vamos trabalhar com o offload de operações do back-end. Vamos entender melhor o que isso significa, quando devemos considerar essa abordagem e como podemos usar o N8n para transferir tarefas desnecessárias do back-end para um fluxo no N8n.

Para ilustrar, utilizaremos o Miro como exemplo visual, facilitando a compreensão do cenário. Imaginemos um back-end que, além de cuidar das regras de negócio do serviço oferecido, também realiza processos de ETL, pois é necessário transferir informações entre vários sistemas. Este back-end complexo agrega dados de diversos sistemas, realiza o processo de ETL para transformá-los e, assim, gerar relatórios.

Descrevendo as responsabilidades do back-end e os desafios de sobrecarga

Além disso, o back-end também é responsável por gerar relatórios e integrar-se com CRM e outras ferramentas externas, como gateways de pagamento ou APIs de terceiros. Ele também realiza integrações com APIs de terceiros e, periodicamente, executa tarefas que demandam processamento pesado. Este processamento periódico é característico de processos de ETL, que geralmente envolvem a coleta, agregação e limpeza de grandes volumes de dados, resultando em um processamento intenso.

Se o back-end estiver sobrecarregado com todas essas tarefas, ele estará consumindo mais recursos do que o necessário no servidor. Isso ocorre porque a máquina do servidor está realizando uma série de operações, incluindo a gestão de ferramentas internas e integrações que facilitam o trabalho das equipes. No entanto, o foco principal do back-end deveria ser as regras de negócio, garantindo que o negócio funcione de maneira eficiente.

Focando na otimização do back-end e delegando tarefas ao N8n

Em uma API, as regras de negócio também envolvem fornecer respostas rápidas aos clientes. Portanto, é essencial que o back-end esteja otimizado para essas funções principais, enquanto outras tarefas podem ser delegadas para sistemas como o N8n, aliviando a carga do servidor e melhorando a eficiência geral.

Quando pensamos em escala, especialmente em um sistema que está ganhando muito volume de requisições, nosso servidor precisa estar focado em receber essas requisições dos clientes, processá-las, aplicar as regras de negócio e fornecer uma resposta o mais rápido possível. Processos como ETL, geração de relatórios, integração com CRM e APIs externas são essenciais para a operação do negócio, mas não constituem o núcleo do negócio. O núcleo está nas regras que o back-end deve responder.

Transferindo processos operacionais para o N8n

A ideia é transferir esses processos que envolvem demora, atraso e são pesados para o N8n, que fará a parte mais operacional. O N8n pode distribuir a carga entre o que está no back-end e o que está nele próprio, sendo uma ferramenta mais tolerante a falhas. Enquanto o back-end deve focar nas regras de negócio, o N8n pode lidar com processos operacionais que, se atrasarem, não comprometem o sistema, pois já têm um tempo de espera maior.

Dessa forma, aliviamos o back-end e transferimos a carga para uma ferramenta que oferece várias vantagens, como discutido em cursos anteriores. O objetivo deste curso é abordar esse cenário de separação e transferência de carga para o N8n. Vamos explorar um caso de integração com CRM, que é comum e necessário para muitos, como RD-Station, MailChimp ou HubSpot. Muitas vezes, essa integração é feita diretamente no back-end ou, no pior dos casos, manualmente, sem automação.

Explorando a integração com CRM usando o MailChimp

Neste curso, trabalharemos com a integração com CRM usando o MailChimp, que é gratuito e já possui integração com o N8n. Se não tiver um CRM, é possível acompanhar usando o MailChimp. A ideia é que a integração e o conceito funcionem para qualquer CRM ou serviço. Vamos explorar como fazer essa escolha e trabalhar a parte operacional no N8n.

Já entendemos o problema que vamos abordar, então vamos começar a trabalhar nele.

Arquitetura do offload - Pensando no fluxo de integração

Analisando a integração do CRM

Para compreendermos a ideia da integração do CRM, vamos analisar como essa integração é normalmente realizada. Inicialmente, duplicamos o módulo e começamos a escrever algumas coisas de forma diferente. Ao considerarmos o fluxo de integração do CRM, ele estará no nosso back-end. Quando um novo cliente é criado, precisamos enviar uma mensagem para o CRM. Isso ocorre porque o fluxo mais comum de integração solicitado pelas equipes de marketing é saber sobre cada novo cliente que entra na base, quando um cliente realiza uma compra, eventos relacionados ao cliente, se ele participou de uma campanha ou está dentro de uma campanha.

Frequentemente, o time de marketing consegue realizar integrações nos sites de landing page de campanha e ferramentas externas pelo próprio CRM. No entanto, em algum momento, isso chega ao time de desenvolvimento, pois quando um lead se torna um cliente de fato, há um evento de mudança de status que precisa ser informado. Na integração do CRM, geralmente, a criação de um cliente é iniciada. Para o nosso back-end, essa informação chega através de uma API, por meio de uma chamada como /api/cliente/, onde podemos ter qualquer ID desejado, e isso será feito através de um POST. Recebemos uma chamada POST para uma API que estamos configurando.

/api/cliente/

Tratando chamadas no back-end

Nesse fluxo, o back-end precisa tratar a chamada, pois na criação de um cliente existem regras de negócio a serem validadas, como verificar se o cliente é válido, se está duplicado ou se é um cliente que está sendo reativado. Portanto, algumas regras precisam ser implementadas no back-end. Após as validações, o back-end pode chamar o CRM para cadastrar a pessoa como cliente. Mesmo que façamos um offload de carga, algumas tarefas permanecerão no back-end, como regras de negócio e validações importantes.

O vídeo mais claro representa o back-end. Quando chamamos o CRM, delegamos essa tarefa ao N8n, que será responsável pela integração. O back-end continua recebendo as chamadas e eventos, mas a operacionalização, como chamar o CRM e lidar com erros na camada de integração, é delegada ao N8n. Assim, temos duas camadas: o back-end continua existindo e sabendo de alguns eventos, mas a operação é passada para o N8n, que executa a tarefa.

Integrando ferramentas externas com N8n

Uma vantagem é que, ao criar um workflow no N8n, podemos integrar diversas ferramentas externas, incluindo o CRM. Isso nos permite chamar qualquer ferramenta cadastrada sem precisar consultar individualmente a documentação da API, o que aumenta a velocidade do processo. Por exemplo, ao usar o MailChimp, já temos o nó e os triggers disponíveis, além das ações que utilizaremos posteriormente. Podemos chamar campanhas, listar grupos, realizar ações em relação aos membros e etiquetar membros, tudo sem precisar conhecer profundamente o funcionamento da API do MailChimp.

Temos um nó que nos permite criar um membro. Basta configurá-lo e teremos um membro criado, o que nos proporciona agilidade. No contexto do MailChimp, ao adicionar um nó de ação, um nó de gatilho é automaticamente criado. No entanto, preferimos não utilizar um gatilho manual. Se considerarmos nosso diagrama no Miro, percebemos que, quando uma parte do nosso back-end reconhece um evento que está chegando na integração para CRM, ele deve delegar isso para o N8n. Essa delegação é feita através de um webhook, pois estamos lidando com dois sistemas: o N8n e nosso back-end. A integração entre eles ocorre via chamada de API ou, como estamos comunicando via eventos, através de um webhook, que permite enviar informações para o mesmo local sempre.

Utilizando webhooks para comunicação entre sistemas

Vamos utilizar o webhook como gatilho. Nosso back-end iniciará a operação, delegando-a e passando as informações necessárias. Este é um exemplo de comunicação entre dois sistemas, onde o webhook é bastante apropriado. Vamos pegar a URL do webhook e utilizá-la no Postman para criar uma nova requisição.

Precisamos definir quais informações são necessárias para que a criação de um membro no MailChimp funcione. Ao verificar, notamos que precisamos selecionar uma credencial e definir a operação de criação, além de fornecer o e-mail e o status. Existem diferentes status disponíveis, como "subscribed". Podemos mapear esses status e o e-mail, além de outras opções, como tipo de e-mail, idioma e tags. Todas essas informações podem ser incluídas no corpo da requisição.

No Postman, no modo raw, configuramos o corpo da requisição como JSON. No objeto JSON, definimos o e-mail como "email@teste.com". Também incluímos tags em um array e definimos o status como "subscribed", que é um status padrão do MailChimp. Outras informações relevantes também podem ser passadas para o nó através da API, pois nosso sistema recebeu essas informações do cliente e precisa repassá-las.

{
    "email": "email@teste.com",
    "tags": [],
    "status": "subscribed"
}

Corrigindo erros e finalizando a integração

Ao delegar a operação para o N8n, precisamos passar todas as informações necessárias. Por exemplo, podemos incluir campos de mesclagem (Merge Fields) e localização com latitude e longitude. Assim, conseguimos reunir todas as informações para chamar nosso webhook. Se o webhook estiver configurado para ouvir mensagens, ele poderá apresentar problemas, como ocorreu com o MailChimp. Nesse caso, removemos temporariamente o MailChimp e pedimos para o webhook continuar ouvindo.

Ao chamar a requisição, recebemos um erro de "failed parse request body" devido a uma vírgula extra. Após corrigir, o workflow iniciou corretamente, trazendo todas as informações, inclusive o corpo da requisição. Agora, podemos integrar efetivamente com o MailChimp, sabendo como a arquitetura funciona e como delegar informações do nosso back-end para o N8n. Isso alivia a carga de trabalho do nosso servidor, e o webhook é bastante útil nesse processo. Além disso, o N8n facilita a integração ao já ter vários aplicativos de terceiros configurados.

Sobre o curso n8n para devs: Reduzindo a carga do back-end

O curso n8n para devs: Reduzindo a carga do back-end possui 134 minutos de vídeos, em um total de 35 atividades. Gostou? Conheça nossos outros cursos de Automação e Produtividade em Programação, ou leia nossos artigos de Programação.

Matricule-se e comece a estudar com a gente hoje! Conheça outros tópicos abordados durante o curso:

• Arquitetura do offload
• Backend como produtor de eventos
• Processos longos e fluxos assíncronos
• Dados, estado e idempotência
• Consolidação da arquitetura