A utilização da biblioteca django-tenants na construção de uma aplicação multitenant com Django

O framework Django é um dos mais consolidados quando se fala sobre desenvolvimento web com Python, sendo, porém, geralmente aplicado juntamente de diversas bibliotecas auxiliares para cumprir determinadas funções e para a potencialização da solução.

Dessa forma, soluções que, devido às suas funcionalidades ou suas regras de negócio, decidem aplicar o conceito de multitenancy podem optar pelo uso da biblioteca django-tenants.

O que é multitenancy?

Multitenancy ou multilocação é um modelo de arquitetura de software aplicada quando deseja-se servir vários clientes de uma aplicação segregando os dados de cada um no que é chamado de tenant.

Dessa forma, apesar de compartilharem a mesma infraestrutura, os dados de cada cliente encontram-se isolados e só serão acessados e consumidos por ele.

Essa divisão dos dados em tenants pode ocorrer de mais de uma forma, como ilustrado na Figura 1, incluindo:

  • Bancos de dados separados: Nessa divisão cada tenant armazena seus dados em um banco de dados diferentes e a aplicação conecta-se a um banco de dados diferente a cada cliente que a utiliza.
  • Mesmo banco de dados, diferentes schemas: Desse modo, a aplicação permanece conectada a um único banco de dados, alternando apenas qual schema será acessado para consumir os dados desejados.
  • Mesmo banco de dados, mesmo schema: Quando a abordagem escolhida é esta, cria-se uma tabela principal de tenants e as demais tabelas do sistema devem possuir uma chave estrangeira que estabeleça a conexão entre as informações e o tenant.
Figura 1 – Ilustração dos diferentes tipos de multilocação

Django-tenants

A biblioteca django-tenants realiza a divisão de dados por schema e realiza o vínculo entre a aplicação web e o tenant através da URL. Por exemplo, os usuários do Cliente X terão acesso pelo link https://clientex.dominio.com e os usuários do Cliente Y terão acesso pelo link https://clientey.dominio.com.

Desse modo, os dados específicos de cada cliente somente serão consumidos quando seu host name estiver na URL, tendo ainda, porém acesso aos dados compartilhados, que ficam armazenados no schema ‘public’ do banco de dados.

Assim, o gerenciamento do sistema pode ser realizado separando tabelas que são de uso geral no schema ‘public’ e os dados que só podem ser vistos pelo cliente ficam no schema específico.

Com isso algumas configurações são necessárias no arquivo settings.py que já é criado automaticamente em um projeto Django.

Instalação e configurações básicas

A instalação da biblioteca geralmente ocorre via comando pip install django-tenants, além disso recomenda-se a manutenção de um arquivo ‘requirements.txt’, exemplificado na Figura 2, contendo todos os pacotes necessários para o sistema e suas respectivas versões para melhor controle.

Figura 2 – Exemplo de arquivo requirements.txt

Algumas configurações básicas são necessárias para o funcionamento da biblioteca django-tenants:

  • Definição da engine de banco de dados (DATABASE_ENGINE);
  • Configuração do gerenciador de rotas (DATABASE_ROUTERS);
  • Inclusão do middleware para redirecionamento ao schema correto (MIDDLEWARE);
  • Configuração do processador de contexto para gerenciamento das requisições de cada tenant (context_processors).

Além dessas, é necessário criar o modelo que armazenará as informações do tenant, que deve herdar da classe TenantMixin. Esse modelo pode ser usado para armazenar informações relevantes sobre cada cliente ou parâmetros de uso geral dentro do tenant posteriormente. Esse modelo será definido como valor para TENANT_MODEL.

Também deve ser criado o modelo ‘Domain’ herdando da classe DomainMixin, que armazenará os domínios em que cada tenant será acessado, como citado anteriormente. Esse modelo será definido como valor para TENANT_DOMAIN_MODEL.

É importante que estes dois modelos sejam criados em um app compartilhado no exemplo abaixo é possível observar a disposição dos apps nas listas SHARED_APPS e TENANT_APPS que posteriormente são unidas na lista INSTALLED_APPS.

Figura 3 – Exemplo de configuração de apps compartilhados e específicos de um tenant

Como pode ser observado, o app core é compartilhado por todos tenants, portanto todos os usuários do sistema que consumirem dados deste app acessarão as mesmas informações. Por outro lado, os apps chat e dashboard são exclusivos e, em cada tenant, apresentarão dados diferentes, pois estão localizados dentro de cada schema.

Vantagens e desvantagens

Antes da implementação do conceito de multilocação e da biblioteca django-tenants em uma aplicação é preciso entender se a arquitetura é adequada para o sistema que está sendo desenvolvido.

A arquitetura é comumente recomendada em aplicações SaaS (Software as a Service) devido à necessidade de isolar os dados de cada cliente e às vantagens que apresenta em relação à arquitetura single tenant.

Uma das vantagens é a otimização do uso de recursos e dos custos, pois a infraestrutura utilizada será a mesma para todos os tenants, sendo alterado somente o schema usado por cada tenant.

Além disso, a escalabilidade com uso de schemas torna-se facilitada, visto que, para cada novo cliente, somente é necessária a criação de mais um schema no banco de dados.

Entretanto, a abordagem de segregação via schema pode não ser recomendada caso o volume de dados seja consideravelmente grande e deve existir a restrição de acesso dos dados de um schema em outro, o que é feito pela biblioteca e deve ser assegurado pela aplicação desenvolvida.

Tendo em vista o conceito de arquitetura multilocação e o pacote django-tenants com suas configurações, bem como suas vantagens e desvantagens, é possível afirmar que a biblioteca simplifica e torna mais barata a implementação da arquitetura. Sendo assim é uma forma de viabilizar a construção de sistemas multitenant utilizando o framework web Django.

Referências

Autor: Gabriel da Silva dos Santos

Deixe um comentário

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *