Válidações, no back-end ou no front-end?

Primeiro ponto importante: deve haver validação no backend sempre. A não ser que não seja validação de fato.

Todo dado que entra no servidor deve ser validado, ainda que em alguns casos minimamente. E a estratégia deve ser recusar tudo que não atenda certos critérios, só provando que está ok é que deve ser aceito.

Não vou entrar em detalhes aqui porque já respondi antes.

O uso da validação no cliente é meramente questão de UX, em quase todos os casos. UX é muito importante e muito programador deixa de lado.

Validar só no backend, ainda que em fases diferentes, pode ser bem efetivo em UX e facilidade de programação. Em alguns casos pode ser muito mais vantajoso, e isso muitas pessoas não percebem porque lidam com o "99%", e não se importam com o "1%" que vai sofrer. Isso não é UX. Fica assim, mas a pessoa não consegue ver porque pra ela e muita gente está bom:

Como sempre, depende, mas sem extensiva experiência as pessoas decidem errado, em geral não considerando todas as situações.

Validar no backend pre submit pode ser melhor que validar só no frontend. Note que validar no backend post submit não está em discussão, conforme o início desta resposta. As pessoas esquecem que podem dar boa UX, até melhor em certas situações, sem usar o frontend.

Tem a questão do custo. Mas aí pode então ter sido uma decisão errada escolher algo que custa caro. Eu sempre falo que as pessoas tomam uma decisão errada, casam com ela, ou seja, se comprometem com o erro, e aí passa ter que fazer um monte de ações para compensar ou deixam algum problema pendurado na solução dela. Por isso não canso de dizer que tem que deixar modinha de lado e tomar decisões de engenharia real.

Farei algo que muitos pedem para aprender a programar corretamente, gratuitamente. Para saber quando, me segue nas suas plataformas preferidas. Quase não as uso, não terá infindas notificações (links aqui).

cara que conteudo incrivel!! Congratulations!!

Em nome de toda equipe meta.

Nos dois!

Nem todo usuário é bem intencionado, ou sabe o que precisa fazer.
Valide sempre nas duas pontas, aliás valide sempre que um dado trafegar de uma entidade para outra.

Usuário digitou input, valida!
O dado chegou na controller, valida!
o backend enviou algo pra sua Api, valida!
Requisição pra escrever no banco, valida....

e por ai vai...

Também acho que o ideal é em ambos os lados, aí o JS brilha, dá pra reaproveitar codigo de validações. Inclusive lembrei que há um banco do governo que não faz validações no back, você consegue adulterar o formulário para cadastrar ou retificar informações de funcionários que não são permitidas...

Quando vc disse "Regra de negócio" achei que era algo mais profundo que apenas "requisito de formulário".
Mas sim, front e back devem fazer tratativas.

O front pois, como você mesmo disse, dá um feedback imediato para o usuário. Seria horrivel ter "botões" num site que o front te permite clicar, mas o back não executa ação pq vc "não tem credenciais necessárias", é melhor que nem apareçam então.

Mas como é sempre possível quebrar o front end, o back deve revalidar tudo, para evitar vazamento de dados sensíveis, ou até mesmo "quebrar" o site.

Regra de negócio não é a mesma coisa que validação de form. Se você colocar regra de negócio no front, o sistema será hackeado ou plagiado.

Então vamos seguir com validação de forms/interações do usuário. Se você puder escolher apenas um lugar, escolha o back, pelos mesmos motivos que no parágrafo anterior.

Validar no front acelera a interatividade com o usuário, melhorando a experiência geral. O usuário nem saberá explicar e provavelmente a maioria nem manifestará. Mas terá uma experiência melhor, mais óbvia, fluida.

resposta curta: backend

Em um dos vídeos do Fabio Akita, ele comenta a respeito disso:

No front-end, você tem que assumir que tudo que vem do cliente é lixo, que todo mundo é hacker tentando encontrar uma brecha. E se você está no back-end, tem que assumir que tudo que vem do front-end também é lixo, que ninguém fez validação de nada.