Desmitificando Multitenancy — Parte 1: Introdução
A solução mais simples é geralmente a correta.
Na primeira parte dessa série de artigos, iremos descrever os cenários mais comuns envolvem o conceito de multitenancy.
Na partes 2 e 3, iremos nos aprofundar na implementação atual usada na Kino Contabilidade Online.
Background
O problema é simples, quando falamos de software para grupos (geralmente empresas), temos duas entidades básicas, a empresa, e seus usuários.
Quando tratamos de SaaS, isso significa, que precisamos isolar os ambientes de cada empresa, e ao mesmo, o ambiente de cada empresa precisa ser compartilhado entre os diversos usuários da mesma.
Existe inúmeras abordagens sobre o tema. Nesse post vamos falar sobre a maioria delas, e finalmente, mostrar como resolvemos tal problema na Kino Contabilidade Online.
Para que você entenda melhor o cenário, vou ilustrar melhor nosso cenário, você provavelmente já teve que desenvolver algo semelhante.
A Kino é uma Startup de Contabilidade Online de qualidade e acessível. Nossos clientes são pessoas jurídicas, ou seja, empresas.
Cada empresa cliente, pode ter vários usuários. e é ai que começam os problemas.
Se cada usuário fosse restrito a uma empresa, esse problema seria fácil de ser resolver.
Porem uma das premissas é que um usuário pode ser funcionário de mais de uma empresa (por exemplo um coach financeiro que tem acesso aos resultados das empresas).
Como a Kino também fornece um gerenciador financeiro empresarial, a possibilidade de 1 usuário acessar mais de 1 empresa era algo eminente.
Primeiro vou listar algumas formas de como poderíamos ter resolvido o problema, e logo em seguida, falarei sobre o que fizemos.
Parte 1 — Arquitetura dos Dados
Antes mesmo de falarmos sobre rotas e outros detalhes, precisamos considerar a arquitetura de dados.
Vamos voltar um pouco nos conceitos, multi-tenancy, pode ser traduzido literalmente para vários-inquilinos, isso quer dizer que, existem vários conjuntos de dados (1 conjunto por cliente) vivendo dentro da sua aplicação.
Existem duas abordagens e cada uma delas é mais indicada para um tipo de projeto em específico:
1.1 — Vários Bancos de Dados
Nesse modelo, cada novo cliente do sistema ganha um banco de dados isolado, e a aplicação se encarrega de setar dinamicamente a conexão para o banco de dados adequado.
Esse modelo é recomendado para aplicações que tem como objetivo poucos clientes, com muitos usuários cada.
Um exemplo claro desse modelo é um sistema de gestão escolar.
Geralmente esse tipo de software é caro, a empresa que o desenvolve tem algumas dezenas de clientes no máximo.
Esses clientes por sua vez são escolas, que podem ter cada aluno como usuário.
A chave para esse modelo é baseada em poucos clientes com grandes conjuntos de dados. O que não é o caso da Kino.
1.2 — Banco único.
Esse modelo é o mais indicado para a Kino (e para a maioria dos casos).
Basicamente, você utilizará um banco de dados único, assim como nas outras aplicações.
Você precisa de uma entidade pai, que geralmente (incluindo esse case) é chamado de Tenant (t. inquilino).
Essa entidade, geralmente contará com um identificador (no caso geral, uma chave primária).
Abaixo dessa entidade, estão as entidades que pertencem a um tenant.
No caso da Kino, vamos citar como exemplo o caso das Notas Fiscais, que podem ser emitidas no sistema.
Cada registro de nota fiscal, recebe um atributo `tenant_id`, que indica qual empresa é “dona” do registro.
Indique nos comentários caso deseje uma abordagem mais detalhada sobre a modelagem.
Parte 2 — Detecção de Tenant
Existem algumas formas de se trabalhar com a detecção da empresa cliente, que como estabelecemos anteriormente, a chamamos de tenant.
Imagine o seguinte cenário: O cliente entra na sua plataforma, e é apresentado com 3 campos na tela de login.
Empresa: (tipo select)
email: (tipo email)
senha: (tipo password)
Obviamente essa é a pior forma de se trabalhar, visto que, se você tiver muitos clientes, será difícil manter esse select gigante.
Antes de apresentar como resolver esse problema, vale ressaltar que ele somente existe nos casos onde um usuário pode estar relacionado a mais de uma empresa.
Nos casos onde somente é permitido o usuário fazer parte de uma empresa, você pode logar o usuário e setar a empresa ativa diretamente a partir do usuário.
2.1 — Domínio Customizado
Esse é um modelo bem comum em muitas aplicações, como por exemplo:
minhaempresa.deploybot.com (DeployBot)
minhaempresa.basecamp.com (Basecamp)
minhaempresa.atlassian.net (JIRA)
Você já deve ter usado vários sistemas assim. Essa técnica é válida e tem seus benefícios, como simplicidade no código de detecção de clientes.
Porem, existe um problema: Você precisa gerenciar corretamente o DNS.
Isso inclui ter subdomínios wildcard, e é claro, SSL wildcard.
Em outras palavras, você irá precisar de ter entradas de dns no formato *.meu-saas.com e um certificado SSL que comtemple todos os subdomínios, meu-saas-.com / *.meu-saas.com.
Essa abordagem por mais que seja válida, só é necessária em casos extremos, onde cada cliente terá muitos dados e você talvez necessite distribuí-los em cluster isolados.
Tecnicamente, você vai detectar o domínio atual do usuário, e buscar o slug no seu cadastro de tenants, e assim setar o tenant ativo.
2.2 — Rota Customizada
Consiste em fazer exatamente o mesmo que a técnica anterior, porém, dessa vez, você irá utilizar um prefixo, ao invés de uma subdomínio.
Exemplo:
https://meu-saas.com/empresa-do-ciclano/contas-a-pagar
https://meu-saas.com/empresa-do-ciclano/usuarios
-
https://meu-saas.com/outra-empresa/contas-a-pagar
https://meu-saas.com/outra-empresa/usuarios
Dessa forma, você irá utilizar o prefixo das rotas para, pegar o slug e buscar no seu cadastro de empresas, qual corresponde e aplicar de forma correta.
2.3 — O nosso Jeito
Na Kino Contabilidade resolvemos o problema de uma forma bem menos complexa, que se mostrou mais flexível.
Não utilizamos nem subdomínios nem prefixos, e ainda assim, um usuário pode alternar entre diferentes empresas.
Nossa técnica consiste em, um relacionamento muitos-pra-muitos entre as entidades usuário e tenant.
Entrando brevemente em ACL, essa tabela de ligação também indica qual o papel (role) cada usuário tem dentro de cada empresa.
Nesse caso, digamos que o usuário tem acesso a duas empresas. Ao fazer login, a aplicação olha uma propriedade setada no usuário, que diz qual a ultima empresa esse usuário estava trabalhando. Caso seja o primeiro login, setamos como ativa a primeira empresa em que o usuário tem acesso.
Quando o usuário solicita alternar empresas no sistema, salvamos a preferencia, que é sempre lida por um middleware responsável por essa lógica.
Continua
Na parte 2 desse artigo, iremos abordar o planejamento e estrutura de dados usada em nossa implementação.
Na parte 3 desse artigo, iremos de fato, entrar no código necessário para tal implementação.
Conheça a Kino
A Kino é uma Contabilidade Online, Eficaz e Acessível, com planos a partir de R$ 58,00, Você tem acesso a uma contabilidade completa, além de uma plataforma de gestão financeira para sua empresa.
Nosso foco são empresas de prestação de serviço, como Startups, Agências e PJ’s.
