A respeito do título do post, server rendering components só vão ter relação ou · brabo

A respeito do título do post, server rendering components só vão ter relação ou não com a a ausência de API's nas mãos de pessoas inexperientes.
Quando digo api's, nao estou falando necessariamente de rest, libs ou whatever, e sim de uma clara divisão de camadas e modularizaçao feita corretamente. Se isso vai passar por um fio ou nao, depende da necessidade do sistema.

Da mesma forma que, num passado nao distante, sua app jsf poderia ser uma presentation layer only que consumisse de API's externas em qlquer outra tecnologia.

Isso da margem pra má engenharia? dá... mas o que não dá? não falta gente commitando token de api em github publico tbm não rs.

Uma coisa não da pra negar... é muito engraçado olhar os ciclos das praticas de desenvolvimento e como nós reciclamos velhas ideias para velhos/novos problemas com uma nova roupagem.

Esse recurso do React é perfeito.

Um exemplo real, precisei criar um dashboard, então comecei fazendo o front em react e a api em nest. Se tornou algo muito cansativo. Para o modelo de negocio que eu estava desenvolvendo eu não precisaria de uma api. A api rest só faria sentido no meu caso se eu tivesse mais de um cliente para consumir ela.

Então iniciei o projeto do zero utilizando create-t3 + zenstack e obtive a stack perfeita. No componente react do front eu tenho um hook que acessa diretamente os metodos do prisma. Eu tenho por exemplo um hook usePost() e utilizo esse hook para fazer um crud na tabela post, claro, respeitando regras de roles, permissions e validations. Produtividade e DX no meu caso foi onde tive o maior ganho