SaaS Single-tenant vs Multi-tenant (devo criar um banco por empresa!)

Рет қаралды 21,853

Күн бұрын

Пікірлер: 29

@codegus_ 8 ай бұрын

Eu trabalhei numa empresa que tinha o conceito de Multi-Tenant, mas era para a área de autenticação e user management. Basicamente nossa APP servia multiplas empresas e cada uma dessas empresas tinham seus clientes, então nós tinhamos multi-tenants e cada tenant tinham seus clientes. Quem logava na nossa aplicação eram os clientes dos clientes, mas cada um tinha as informações apenas do seu tenant relacionado. Era um banco para todos os nossos tenants e clientes deles, tudo baseado em tenant id e outras coisas similares.

@vkRenan 8 ай бұрын

Puta que pariu, que maluquice.

@wanderhungerbuhler 8 ай бұрын

Curto demais seus vídeos Diego/Rocketseat, mas o mercado não está apenas com MicroSaaS, React e NextJS. Estão mais exigentes e pedindo AWS, GCP principalmente. Seria interessante trazer conteúdos com esse aspecto ou liberar dentro da plataforma para quem é membro.

@rafaelsantana588 8 ай бұрын

Up. Um curso pra área de DevOps na plataforma seria sensacional. Criação de imagem docker para produção, desenvolvimento de aplicação voltada para escalabilidade horizontal com múltiplas instâncias, orquestração com swarm ou ferramentas AWS seriam sensacionais.

@DiogoMoreira-u1s 8 ай бұрын

ansioso pra ver o codigo-fonte dessa maravilha

@ageurodriguesdeoliveira8953 7 ай бұрын

Antigamente não, aqui na empresa ainda é feito assim. Delphi, Firebird e por ai vai :)

@RafaelRodriguesdeveloper-cb9mw 8 ай бұрын

Muito boa a explicação Diego. Trabalhei em uma empresa que o SaaS deles era Single-Tenant, tinha muita dificuldade para fazer atualizações. Neste caso compensaria construir uma nova aplicação Multi-tenant pra sanar este problema? E qual seria o nível de dificuldade?

@riadyounes00 8 ай бұрын

Quando esse curso vai pra dentro da plataforma ?

@wesleyall 8 ай бұрын

Ficou meio vago, sentir falta de soluções o que possivelmente essas empresas grandes usam. Pq assim.. sobre multi tenant eu só imagino 4 possibilidades: Separados por DOMINIOS, BANCOS, SCHEMA DE BANCO OU FK que identifica o cliente. Essa de FK é o melhor custo mas bem chata de implementar pq em toda consulta tem q por onde clienteId=clienteId. Se possível fala mais sobre. Estou a frente de um projeto multi tenant e fiquei curioso sobre o que vcs tem a falar. Vlw!

@rafaelsantana588 8 ай бұрын

Eu utilizo essa estratégia do FK, como utilizo jwt para autenticação, posso confiar no tenant_id e user_id que ele envia. Assim, todos os meus controllers passam para os use cases o tenant_id (e se preciso o user_id) e a primeira coisa que faço em casa use case é validar se o recurso solicitado pertence ao usuário. Realmente é meio chato e é uma consulta a mais no banco de dados, mas depois que acostuma já fica automático fazer a validação nas primeiras linhas do use case (e o copilot já aprendeu e sugere a validação certinha 😂😂😂😂). Mas HOJE acho que se eu fosse fazer outro SAAS do zero, usaria um schema por tenant, que não precisaria dessas validações…

@wesleyall 8 ай бұрын

@@romulo886 psr. Por schema é bom pq utilizamos somente um banco. E os clientes ficam separados internamente no schema. Mas a manutenção em casa de update na estrutura vai precisar ser aplicada para cada schema logo deixa difícil na manutenção. É tal dos prós e contras. E sobre a condição eu falei clienteId=clienteId só pra ilustrar. Eu uso ORM. Ele tem já as configs pra evitar esses ataques. Tmj

@wesleyall 8 ай бұрын

@@rafaelsantana588 exatamente kk fica meio complexo mesmo, essa tbm é minha dor kk, mas acostuma. Por isso queria ouvir mais sobre. Sobre o schema é bom pq evita as condições mas a manutenção fica mais difícil se tiver necessidade de por exemplo: adicionar uma coluna nova. Vai ter q replicar para todos os tenants.

@williammendonca9975 8 ай бұрын

Diego, quando este projeto entra no Ignate?

@juniorrocha8888 8 ай бұрын

Gostei da explicação. Então o ideal seria multi tenant de schema?

@thimor 7 ай бұрын

tem 3 abordagens. um schema por empresa, um schema para todas as empresas ou um banco para cada empresa.

@Mora0219 7 ай бұрын

Onde ele faz live?

@jejeexd 8 ай бұрын

esse projeto vai completo pro ignite?

@felipeduartebarbosa7009 5 ай бұрын

A vantagem do multi-bancos, alem do isolamento de dados ser trabalhado com mais facilidade, eu tenho a liberdade de escolher a infra por cliente, nao preciso ficar gastando uma infra de 32GB e 8 CPUS para minha instancia do banco de dados, para aquele cliente que nao tem muitas requisicoes, onde escolho algo mais real para o cliente, onde acabo tendo uma economia, a desvantagem é a complexidade de manutencao disso, trabalhar com varios bancos, atualizacoes é um saco, mas da para desenvolver ferramentas para esse tipo de coisa.

@marcosferreira8463 5 ай бұрын

E como vc faz para atualizar as estruturss de tds os bancod ao mesmo tempo?

@EduardoMeneghel-g8f Ай бұрын

@@marcosferreira8463 Usando um migration acredito que resolveria, da para colocar o migration rodar em todos os bancos quando é feito o deploy

@bragancx Ай бұрын

@@marcosferreira8463 foi mal a demora, mas basicamente você pode gerar um script usando alguma linguagem de programação que consiga se conectar ao seu banco de dados, algo como python, e faz um loop rodando os scripts em todos os bancos 🖊️🔥

@LucasSoaresAraujo 8 ай бұрын

Existem várias abordagens de multi tenant para banco de dados, algumas delas são: bancos de dados separados; banco de dados compartilhado e esquema de dados separados; banco de dados e esquema de dados compartilhados.