Esse artigo foi escrito a muito tempo, mas estou soltando agora. Não faço mais parte da NewSchool, e essa arquitetura foi parcialmente feita, mas vou soltar ela agora para que possam ver minha etapa de pensamentos. Espero que isso ajude alguém que quer começar a mexer nessa parte de arquitetura de sistemas

Eu acho muito legal criar artigos pra falar sobre coisas que estou fazendo atualmente, é uma forma ótima de guardar meu conhecimento pra que eu possa comparar com o conhecimento Davi do futuro e também dissemina informação.

Bem, dessa vez, vou explicar sobre uma arquitetura que eu fiz para a NewSchool. A NewSchool é uma startup social onde o objetivo é ajudar pessoas carentes, e estamos criando uma plataforma de educação para pessoas que não tem como estudar. A ideia é transformar conteúdos de alto nível em conteúdos acessíveis para pessoas das quebradas.

Como somos uma startup social, temos o mesmo problema das ONG's - DINHEIRO -, por isso, atualmente temos uma arquitetura bem pequena e que por enquanto resolve nossos problemas.

O problema atualmente é: "Será que funciona se escalarmos?". Atualmente, provavelmente não. Temos um único backend - que se você que lê o artigo quiser ajudar, o link vai estar no final também - que possui tudo. Está bem separado por módulos, cada módulo é independente um do outro no sentido de que tem responsabilidades bem distintas, porém, eles se comunicam uma hora ou outra.

Pensando nisso, eu desenhei a arquitetura abaixo:

Vamos começar a explicar por partes:

Front end + BFF + API Gateway

O BFF é o cara que vai fazer as requisições pelo front, isso ajuda o front nos casos que é necessário fazer mais de uma requisição pra popular algo nas telas. Além disso, um BFF melhora a segurança, já que qualquer coisa que seja sobre segurança - no caso, nossos client credentials pra requisição - vão ficar em um servidor, onde o acesso é mais difícil.

Já o API Gateway vai garantir que a gente possa esconder nossos serviços de backend. Davi, como assim "esconder"? Esconder na questão de que todo e qualquer serviço que a gente tiver vai ter que ser exposto explicitamente no API Gateway, e além disso a gente pode configurar no API Gateway quais serviços vão precisar de autenticação - geralmente são todos, mas pelo menos é configurável

Segurança

Eu ainda não sei como, mas pretendo configurar no API Gateway pra validar se o usuário está autenticado ou não batendo nessa API aí

A gente fez o nosso próprio esquema de autenticação totalmente baseado em Oauth2. Esse carinha vai atuar na parte de guardar nossos usuários, logar eles e validar se estão autenticados.

Como na foto, os usuários estarão na parte do Resource Server salvos em um banco SQL, enquanto toda parte de guardar os JWT de quem está logado vai estar no Authorization Server em um Redis(eles vão estar juntos na mesma API, mas é legal separar os conceitos)

A ideia também é que usemos JWT opacos, que são basicamente stringonas que não significam nada. Essas stringonas são chaves para os JWT que estão no Redis.

Como toda request em qualquer api bate no serviço de segurança pra descriptografar os JWT, os serviços nem vão sentir essa mudança de JWT para JWT opacos!

Platform Management Ecossystem

Essa parte vai fazer toda parte de vincular os usuários com os cursos e avançar os usuários nas etapas. Pra isso, a gente separou em dois sisteminhas menores.

CMS

O CMS (Content Management Service) vai ser um serviço que vai ajudar os administradores a controlar a plataforma na questão de conteúdo. Ou seja, os administradores vão criar os cursos e os textos da aplicação tudo nessa parte.

O CMS é um sistema já feito por alguém, como o Wordpress, porém, vamos usar uma coisa chamada Headless CMS, que é o CMS só como API, assim o nosso front pode ser desenvolvido pela gente e apenas pegar os textos que vai ser escrito pelo próprio pessoal do negócio.

Além disso, ele vai ter toda parte de conteúdo dos cursos, então titulo, descrição, vincular as partes, exercícios, etc... Tudo vai ser feito pelos próprios administradores.

Platform Management System

Esse aí vai cuidar da parte da lógica, ou seja, realmente juntar tudo que for criado no CMS a lógica de negócio que a gente tem. Atualmente tudo ta junto no mesmo back, mas o ideal é a gente separar mesmo porque a gente se livra do pessoal de negócio o pessoal de negócio fica mais livre pra criar os conteúdos para a plataforma sem depender do time de desenvolvimento

Gamefication Ecossystem

Como o nome fala, toda a lógica de gamificação está aí! Os endpoints de outros sistemas tudo mandam eventos pra gamificação (se necessário), e a gamificação faz a regra que precisar.

Os pontos são computados em realtime, e logo que o usuário ganha os pontos, já pode ver atualizado no dashboard.

Ah, o sistema de gamificação também é conectado com o sistema que manda as notificações pros usuários, então assim que o usuário ganha ponto, recebe uma notificação na tela

Estamos em processo de evoluir nossa arquitetura, então a ideia é que cheguemos nisso daqui a algum tempo. Assim que chegarmos nisso, escrevo outro artigo pra falar dos resultados!

Se gostou, escreve aí abaixo o que achou e o que gostaria que eu escrevesse em seguida!

E não se esqueça de me seguir no Twitter!