Modelando tenants e membros, mais ReBAC e sync offline no PWA

Dia de modelar acesso e propriedade, e de escrever sobre as duas metades disso: quem pode o quê, e o que acontece quando a rede cai.

Projeto cliente (NDA)

Segui trabalhando a modelagem multitenant. O formato mais limpo é uma tabela members que se relaciona com empresas, em vez de uma estrutura empresa-membro embutida, porque a mesma pessoa pode trabalhar para mais de uma empresa, às vezes como serviço prestado. Os papéis apareceram como gestor, piloto, técnico e apoio. Também modelei tabelas de referência para estados e cidades: duas tabelas (estado e municipio) em vez de uma tabela larga, com chaves adequadas, e removi a coluna de código externo que não servia para nada aqui. O lado prático foi abrir um banco Access legado no DBeaver e salvar um DDL limpo, além de mesclar a main e resolver conflitos.

tgmarinho-ai-website

Escrevi um post sobre ReBAC (controle de acesso baseado em relacionamento), usando um motor de permissões open-source como referência de como um único core expressa RBAC, ABAC e ReBAC ao mesmo tempo: uma regra é uma condição sobre o registro, uma caminhada por um relacionamento, ou uma checagem de que um campo é igual ao ator.

Depois fui fundo na metade offline de um PWA. Um leitor fez um comentário certeiro: a maioria dos PWAs cacheia o shell e para por aí, então abrem offline mas não mostram nada. O trabalho de verdade é IndexedDB mais replay. Destrinchei o fluxo inteiro: instalar o app, guardar dados localmente, deixar a pessoa agir offline e então sincronizar quando volta a conexão, incluindo quem escuta a rede voltar e o que dispara as escritas na fila de volta para a API. Uma passada rápida em JWT fechou o dia.

O tecido que liga tudo: permissão e sync offline tratam do mesmo problema, confiar numa decisão tomada antes, em outro contexto, e honrá-la corretamente depois.