Executando verificação de segurança...
Em resposta a React está querendo tornar "APIs" algo obsoleto?
5
filipefborba

Lendo os comentários, percebi que o pessoal ficou meio assustado com essa abordagem, mas para mim faz todo sentido!

Um dos desafios do desenvolvimento web é o fluxo de dados da aplicação.
Bibliotecas como useSWR, React Query e RTK Query tentam nos ajudar nessa questão, trazendo hooks/funções para facilitar a vida.

Dito isso, essa abordagem dos Server Components tenta facilitar isso de uma forma um tanto inédita (tanto que o autor do vídeo explica que ainda está pegando o jeito). Ao aproximar o componente do dado que ele precisa, estamos fazendo algumas coisas:

  • Facilitando testes (fácil de mockar a chamada)
  • Melhorando a legibilidade do código (sabemos que dado o componente precisa)
  • Escrevendo apenas o necessário (escrevo apenas o que o componente precisa, sem mais nem menos).

Na minha visão é uma maneira ainda melhor de separar os Smart Components (componentes que tem lógicas, chamadas de api, etc.) dos Dumb Components (coisas puramente apresentacionais). Pelo exemplo do vídeo, se parecem muito com os Higher Order Components (HOC) que já existem e promovem bastante reutilização de código.

Conclusão: parece promissor!

Obs: para quem se assustou com o SQL no meio do código, imagine apenas uma chamada de um ORM qualquer!
Obs2: imagina não ter o problema de compartilhar as interfaces entre front e back!

Carregando publicação patrocinada...
2
mborba

E aí parente, rs. Aquela velha frase: "depende da aplicação". Atualmente, trabalho em um projeto aonde o front-end é feito em React e o core da aplicação é exibir em tempo real através de dashboards, informações de centenas de dispositivos IoT. Pelo menos aqui, o conceito de Server Components não se aplica. Caso fosse migrar pra Next, teria que escrever em praticamente todos os componentes a diretiva 'use client', o que ao meu ver, não faz sentido, melhor deixar tudo como CSR.

Agora falando sobre compartilhar interfaces, realmente isso na prática acaba sendo um problema, pois as mudanças nas estruturas entre projetos de back-end e front-end precisam estar sempre sincronizadas. O back-end deste projeto é com ASP.NET 6, então já viu né, as interfaces dos modelos e DTO's tanto do TS e do C# precisam estar iguais, e é um saco quando precisa mudar algo em 2 lugares, seria muito melhor mudar em 1 lugar só.

Outra coisa é que já fizemos algumas POCS aqui pra ver se um "full-stack" funcionaria na prática, e até agora, não deu certo. Com o nodejs no backend, seus ORM's entregam "menos" do que o Entity Framework, mas o pior nem é isso, é que as ferramentas do mundo de automação industrial (usadas no IoT) funcionam melhor no ecossistema da MS. E falando em MS, testamos o Blazor para avaliar como seria a experiência de desenvolvimento de interfaces e é até legal, só que aí tu vai usar uma lib como MuiBlazor e se depara com muitos componentes faltando e bugados. Por outro lado, o MUI do React é muito mais consolidado e funcional.

1
filipedeschamps

Filipe, sensacional seu comentário, muito obrigado por tirar um tempo e esclarecer estes pontos aqui. O que me chamou mais atenção foi:

Escrevendo apenas o necessário (escrevo apenas o que o componente precisa, sem mais nem menos).

De fato, se focar no backend e no que os componentes precisam, facilita muito as coisas!

E sobre a mutação dos dados, como isto funciona? Como eu muto de volta para o backend algo?

2
filipefborba
Autor
Autor

Chega de escrever CRUD, meu xará! hahahah

Assim, eu não mexi com isso ainda, mas creio que seja que nem nas bibliotecas, como a useSWR que dispõe de uma função "mutate".

De maneira simples, você faz a alteração do dado e em seguida faz o GET novamente para fazer o refresh. Mas ele deve ser espertinho o suficiente para não fazer nenhum rerender e manter o estado.

Após uma pesquisinha rápida, é isso mesmo. Saca só: https://beta.nextjs.org/docs/data-fetching/mutating

Vale lembrar que ainda está sendo especificado (estado de RFC)

1
Genesonio

Se eu bem entendi a pergunta, atualmente o criador do vídeo, Theo, tem um boilerplate, chamado T3 Stack, que vem com o TRPc, nele temos uma função mutate que é ligada diretamente ao database usando context e o prisma.

1
filipefborba
Autor
Autor

Sem falar dos ganhos de performance por apenas cuspir o HTML pro client, sem nem ter que rodar nada de Javascript antes. O caching disso seria muito facilitado!