Foi a galera vendedora de curso que popularizou a arquitetura de usar serviços free.

Supabase pra DB, vercel pra front, nada de back, essa mania de separar a aplicação em locais diferentes, procurando plataformas "grátis" que te apunhalam pelas costas quando vc menos espera.

São ferramentas incríceis? até que são, mas a facilidade que elas oferecem tem um trade-off que custa muito

como exemplo o supabase. Nada mais é que um postgres com uma interface bonitinha. (sim, todas as funções que ele oferece tem no postgres.)

Qual o custo de você não precisar configurar o DB? planos EXTREMAMENTE CAROS se você atingir o limite.

Sim, é muito mais caro que vc pegar uma máquina na cloud e configurar.

A vercel a mesma coisa, lembro de quando eles mudaram a política de cache e a fatura do Tabnews ia subir pra MILHARES DE REAIS

(O banco ser acessado do front), é algo ruim?

imagina assim, o banco de dados é como uma biblioteca gigantesca que tem alguns documentos oficiais, o backend são os atendentes e seguranças.

O banco de dados ser acessível do front é tipo "entra aí e pega os documentos que tu precisar, vamos confiar que você não vai pegar nenhum que não pode"

O banco de dados ser acessível só do backend obriga ao usuário perguntar o que precisa aos atendentes. Eles só vão entregar os documentos que o usuário tem acesso, e não vão deixar ele se passar poroutra pessoa.

(Se o código for construído certinho, claro)

Qual é o certo?

O certo NA MINHA OPINIÃO é fugir totalmente do que vendendor de curso fala, e de todo o hype.

Qual empresa realmente grande que usa supabase e vercel? não conheço nenhuma.

(O banco ser acessado do front), é algo ruim? Qual é o certo?

O código que acessa o banco precisa da URL/porta, usuário e senha. Se isso está no frontend, então é fácil para qualquer um obter essas informações. Afinal, o código do frontend é baixado pelo browser e qualquer um que saiba mexer no developer tools vai conseguir encontrar.

E não é só isso: o frontend roda no browser, então se ele acessa o banco diretamente, quer dizer que o servidor do banco de dados está aberto na internet. Qualquer um de qualquer lugar consegue acessá-lo diretamente. E uma vez tendo acesso, qualquer pode rodar qualquer query que quiser.

Pior, nesse caso o código do frontend terá algumas queries, então vc também está entregando de mão beijada a estrutura do banco (nomes das tabelas e colunas), o que facilita muito ataques de SQL Injection. Sem contar que facilita o vazamento de informações, pois basta fazer SELECT * em todas as tabelas para obter todos os dados. Se o usuário tiver permissão de UPDATE ou DELETE então, imagine o estrago que ele pode fazer...

Agora se existe um backend no meio, o acesso é mais controlado.

O frontend acessa o backend via rotas previamente configuradas, como por exemplo http://servidor.com/api/fazAlgo. E essa URL fazAlgo executa o respectivo código que acessa o banco, mas rodando somente as queries que foram programadas no backend.

O frontend não precisa (e nem deve) saber os dados de acesso ao banco, pois isso fica escondido lá no backend. O frontend não fica sabendo quais queries rodaram, nem o nome das tabelas e colunas envolvidas (pois o backend pode retornar apenas parte das informações, e não necessariamente refletem a estrutura do banco, pois ele pode formatar os dados antes de retorná-los, juntar informações em um campo só, etc).

Mesmo se o backend fizer um UPDATE ou DELETE, também é mais controlado, pois ele pode restringir quais informações podem ser alteradas ou apagadas, em vez de permitir queries que apaguem qualquer coisa.

O backend pode controlar o acesso, retornando erro caso o usuário não tenha permissão para acessar/modificar/apagar aqueles dados, pode aplicar restrições (só pode consultar X registros a cada Y minutos, pode limitar a quantidade de requests por segundo para evitar ataques de DDOS, etc), pode usar cache para determinados dados (não onerando desnecessariamente o banco), etc etc etc. Além de fazer outras validações e melhorias, como higienizar/validar os dados antes de mandar pro banco, tratamento para evitar SQL Injection, usar um pool de conexões (em vez de cada cliente abrir uma nova conexão do seu browser) e por aí vai.

O código do frontend pode até fazer essas coisas, mas como vc já entregou os dados de acesso ao banco e a estrutura dele, qualquer um vai poder passar por cima de tudo isso, acessando o banco diretamente e rodando as queries que quiser.

Agora se o frontend só acessa o backend (o único que está aberto na internet), e o backend é o único que acessa o banco (cujo servidor não precisa ficar exposto na internet), e claro, supondo que o backend foi bem feito, aí vc elimina (ou pelo menos minimiza bastante) esses problemas.