Estratégia para performance na verificação das permissões

Olá, Thiago!
Tudo bem?

Excelente questionamento amigo.

--

O que você precisa fazer é usar os Gates ao longo do seu código para validar se o usuário possui ou não a permissão, essa dinâmica não tem como fugir, a não ser que você jogue tudo para o banco de dados, quando digo tudo, é toda a parametrização de recursos (menus e etc), porque assim você consegue aplicar os Gates de forma "automática" combinando com recursos parametrizados no banco (menus por exemplo) com permissões. Ficou claro?

Para minimizar as consultas ao banco, e diminuir a pressão no banco, você pode trabalhar com Cache, você pode combinar com este curso aqui: https://academy.especializati.com.br/curso/laravel-api-com-cache

Olá professor! Tudo bem, e com você?

Então, pra falar a verdade ainda estou meio confuso... Se puder me ajudar a esclarecer seria ótimo! Em meus projetos normalmente usava as views com blade e um pacote chamado SpatiePermission que me ajudava a fazer o gerenciamento, com as Roles, Permissions, etc. Porém agora estou precisando desenvolver um SPA desacoplado (utilizando Quasar/Vue) e um back-end (desacoplado) com Laravel. Minha cabeça ainda está funcionando daquela forma conforme o SpatiePermission, onde posso aliar usuário a um papel, que tem funções e checar isso em um método permission() na rota por exemplo, ou fazendo a checagem em cada método no controller, como por exemplo if($user->hasRole('write')){...}, contendo as tabelas roles, users, permissions, fazendo a relação entre elas...

Gostaria de ter essa mesma dinâmica no projeto, pois acredito que atenderia bem o propósito. Por se tratar de SPA, a montagem do menu por exemplo faria no momento do login, baseado num array em um arquivo de configuração usando uma propriedade "can", o que ja resolveria a questão do layout e recursos conforme a permissão do usuário logado, mas não garante integridade com requisições diretamente ao back-end com qualquer outro meio por exemplo.

Seria possível utilizar essa dinâmica com o Sanctum, onde poderia através do token recuperar o usuário, fazer as checagens de papéis e permissões para cada rota que o usuário tenta acessar com um custo de banco e processamento mais leve possível (como no caso do SpatiePermission), talvez até um cache dessas informações? Usar Gate em cada função do controller que centralizar a ação? (no caso do Spatie acredito que guarda as informações na sessão ou algo assim e acaba reduzindo a quantidade de requisições ao banco de dados, pois se a cada requisição precisar recuperar token, usuário, roles, permissions, isso acaba se multilicando e um simples GET pode ser umas 3 ou mais querys e sinceramente não acho isso legal e receio que o Gate possa acabar gerando isso...)

Apesar de se poder aliar "ações" ao token com o Sanctum, criar um token para cada ação do usuário seria um super trabalho penso eu, com milhares de tokens...  Não vejo isso como uma boa alternativa... Nesse contexto qual seria a solução que você abordaria visando desempenho, manutenção, custo reduzido, etc.? 

Primeiro ponto que precisa ficar claro, as regras de ACL ficam no backend, o papel da SPA (front) é apenas exibir/ocultar as permissões de acordo com a permissão do usuário.

Nessa nossa dinâmica, trabalhamos com Usuários x Permissões

No LaraFood fomos mais afundo, lá tem dois níveis de ACL, um que está mais de acordo com aquilo que vc precisa: Users x Roles x Permissions

Um usuário pode ter N roles, e 1 role pode ter N permissions, logo as possibilidades de permissões são ilimitadas.
(dê uma olhadinha amigo: https://github.com/especializati/larafood)

Após relacionar Users x Roles x Permissions, e depois validar se o usuário possui ou não a permissão para acessar o recursos x ou y, como? Usando o Authorization do Laravel: https://laravel.com/docs/9.x/authorization#main-content

Dê uma olhada no esquema de relacionamentos do LaraFood, talvez vai te atender mesmo, mesmo lá sendo boa parte um BFF, a dinâmica (forma de trabalhar) não muda para uma API ou BFF;