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

Ай бұрын

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

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

4 ай бұрын

Puta que pariu, que maluquice.

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

4 ай бұрын

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.

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

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?

ansioso pra ver o codigo-fonte dessa maravilha

Quando esse curso vai pra dentro da plataforma ?

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

4 ай бұрын

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

4 ай бұрын

@@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

4 ай бұрын

@@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.

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.

Diego, quando este projeto entra no Ignate?

o pessoal cria problema onde n tem!

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

@thimor

3 ай бұрын

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

Onde ele faz live?

Dúvida. Como fica a parte de backup para um banco apenas. Ex: cliente quer o backup dos dados dele?

@rafaelsantana588

4 ай бұрын

Partindo do pressuposto que toda tabela sua contém um tenant_id, era só fazer backup de todos os dados que contém aquele tenant_id.

Eu queria criar um crud multiusuários, tem curso?

esse projeto vai completo pro ignite?

Eu fiz estágio numa empresa que era desse jeito em delphi(2:23) kkkkkkkkkkkkkkkkk