Construindo um aplicativo SaaS com o framework Django Web. Parte 1/2: O princípio

adonis simo Blocked Desbloquear Seguir Seguindo 8 de janeiro

Um software que está sendo executado diretamente no navegador da Web e os usuários têm que pagar por ele de diversas maneiras, como por hora, ou mesmo por usuário, etc., é chamado de um aplicativo de software as-a-service (SaaS). Desde os últimos anos, este modelo é muito utilizado pela startup para vender seus serviços. Neste primeiro artigo, vamos aprender sobre os princípios básicos disso.

Foto de Hack Capital em Unsplash

Ok, vamos começar, o princípio.

Na verdade, da minha pequena experiência falando sobre design de aplicativos SaaS e infra-estrutura envolvem falar sobre gerenciamento de dados, quero dizer perguntas como como armazenar dados no banco de dados ? como acessá-los ? Que tipo de banco de dados deve ser usado ? Como enviar uma solicitação recebida para a versão correta do aplicativo ? e assim por diante. Globalmente, o conceito é permitir a existência de muitas versões do mesmo aplicativo, cada instância, deve mostrar apenas seus dados e gerenciar apenas seus clientes.

1. Então, como os dados são realmente salvos no banco de dados, que tal acessá-los?

No aplicativo SaaS, cada instância do aplicativo é chamada de inquilino, portanto, a transação aqui é escolher uma técnica de separação de dados , apropriadamente:

Uma maneira de armazenar os dados do inquilino, garantindo que eles sejam salvos sem serem misturados.

Ok, na verdade isso pode ser feito diretamente no banco de dados, geralmente existem 3 maneiras principais para separar os dados armazenados, eles podem ser chamados de nível de isolamento de dados dentro do banco de dados. Então nós temos: Baixo isolamento , semi-isolamento e alto isolamento . Deixe-os mergulhar antes de começar a codificação.

– Baixo isolamento de dados

O princípio aqui é armazenar os dados do inquilino no mesmo banco de dados e nas mesmas tabelas. Então você está em um caso em que cada tabela tem um nome de coluna, por exemplo, como tenant_uuid esta coluna possui um identificador exclusivo para um inquilino, e há uma tabela em seu banco de dados nomeado por exemplo como: inquilinos, deve armazenar informações de cada inquilino como : nome, uuid, registration_date, status, pricing_plan_id etc … Neste caso, para todas as consultas ao banco de dados, você terá que adicionar uma instrução para garantir que você esteja recuperando os dados do inquilino certo, como:

 SELECT * FROM 'table_name' ONDE tenant_uuid = 5 

ou com o ORM do Django:

– Semi-isolamento de dados

O princípio aqui é salvar dados dentro do mesmo banco de dados, mesma tabela MAS esquemas diferentes . Um esquema pode ser visto como um banco de dados em um banco de dados, ele armazena tabelas como um banco de dados normal e você pode criar muitos esquemas como o DBMS permite, para aqueles que usam o PostgreSQL, eles trabalham no esquema padrão chamado: public e Consultas SQL para a tabela às vezes parecem

 SELECT * de público. Nome da mesa 

Com isso dito, o método de semi-isolamento consiste em criar um novo esquema para novos inquilinos (seus clientes, as pessoas que usam seu aplicativo SaaS) e todos os esquemas criados contêm as mesmas tabelas. Nesse caso, os dados dos usuários não são salvos no mesmo lugar. Eles estão tecnicamente em uma tabela separada (ou bancos de dados). Então, recuperar dados com o ORM é como:

Assumimos que existe um roteador de banco de dados encarregado de selecionar os esquemas certos para a execução da consulta. Vamos configurá-lo na próxima parte da série deste artigo.

– Alto nível de isolamento de dados

O princípio aqui é salvar os dados do inquilino em diferentes bancos de dados . Nesse caso, quando você tiver um novo cliente, você criará um novo banco de dados vazio para armazenar dados. É por isso que falamos de alto isolamento, o banco de dados pode ser até mesmo destruído, mas apenas um cliente será afetado, mas pode ser muito pesado em termos de consumo de recursos. Acessar dados com o Django ORM pode ser feito como:

o método using () (ou parâmetro) está diretamente disponível no Django, por padrão seu valor é 'default'; onde encontrar? No arquivo settings.py , nas credenciais de informações do banco de dados:

 BANCO DE DADOS = { 
'padrão': {},
'Comercial': {
'NAME': 'user_data',
'ENGINE': 'django.db.backends.mysql',
'USER': 'mysql_user',
'SENHA': 'superS3cret'
}
'clientes': {
'NAME': 'customer_data',
'ENGINE': 'django.db.backends.mysql',
'USER': 'mysql_cust',
'PASSWORD': 'veryPriv @ ate'
}
}

No exemplo acima, existem 3 bancos de dados realmente registrados por seus apelidos: default, usuários, clientes , então por padrão (se você não especificar using () ) o django irá escolher o padrão.

2. Como saber qual inquilino é necessário para uma solicitação recebida específica?

O pedido de entrada representa aqui um usuário do seu aplicativo que está conectado através do navegador e está prestes a usar o aplicativo. O ponto aqui é definir o que é chamado de estratégia de detecção de inquilino ;

É uma maneira correta de saber como interagir com dados armazenados no banco de dados, não está realmente relacionado ao nível de isolamento que você implementou em sua aplicação, o resultado desta operação é o nome do esquema (no caso de nível de isolamento) ou o uuid inquilino (em caso de baixo nível de isolamento) ou banco de dados (em caso de alto nível de isolamento) para usar para recuperação de dados.

Normalmente, para fazer isso, os desenvolvedores usam URL, adicionando algumas indicações, uma das maneiras mais simples e elegantes de fazer isso é definir um subdomínio para cada locatário ; Vamos supor que você aplicação é um motor de blog chamado www.bloghost.com cada cliente terá um sub-domínio e uma url apontando diretamente para seu blog como: client1.bloghost.com , outra maneira é definindo o parâmetro url da seguinte forma: www .bloghost.com / 85DE5148WFE848 e este token pode ser um hash usado para identificar o esquema | uuid do inquilino | banco de dados relacionado aos dados reais do cliente. Isso dependerá totalmente de você.

Agora, quando você identificou qual locatário é destinado por uma solicitação, você precisará apenas usar a consulta apropriada para o banco de dados. Você pode até conseguir isso usando cookies. Eu não vou muito longe neste artigo sobre isso porque o pacote do Django que vamos usar irá lidar com esse processo para nós, então eu apenas tentei explicar o conceito.

Texto original em inglês.