Usamos cookies para medir audiência e melhorar sua experiência. Você pode aceitar ou recusar a qualquer momento. Veja sobre o iMasters.
Quando se trabalha com uma API Laravel e um cliente separado, a dúvida comum é se a comunicação deve ficar no frontend via JavaScript ou ser gerenciada pelo controller do Laravel. A prática de fazer chamadas AJAX direto nos Blade, como exemplificado em vários projetos, funciona, mas traz alguns problemas de manutenção e segurança.
Prefiro uma abordagem onde o controller do Laravel fica responsável por orquestrar as chamadas à API. Assim, a lógica fica centralizada, facilitando testes, segurança e controle de cache. O frontend fica responsável apenas por exibir os dados recebidos, sem precisar lidar com requisições diretas à API. A decisão fica mais saudável quando o time consegue medir o impacto depois. Sem esse critério, a solução pode parecer simples no começo e cara no suporte.
O que vocês acham? Essa divisão melhora a manutenção ou acaba criando uma camada de complexidade desnecessária na API?
Exato. Na minha experiência, minimizar chamadas diretas do frontend ajuda no controle de segurança e na performance, além de facilitar testes unitários na API. Só cuidado pra não transformar tudo em RPC no backend, que também pesa.
Concordo. Quando a chamada fica no controller, dá pra fazer cache de resposta e evitar requisições desnecessárias. Além disso, aumenta a segurança ao não expor endpoints diretamente ao frontend.
Sim, e assim dá pra centralizar a lógica de retry e fallback. Se o frontend fizer direto, fica mais difícil de padronizar esses comportamentos.
Eu faria assim também, mas às vezes o time quer uma resposta bem rápida e fazer tudo no controller pode parecer mais burocrático.