React está querendo tornar "APIs" algo obsoleto?

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!

APIs Rest não surgiram para resolver o problema da bagunça entre camada de negócio e apresentação. O que resolveu isso foi MVC. APIs Rest surgiram para interoperar serviços de diferentes plataformas/linguagens.

"E por que raios surgiram tantos frameworks de front-end usando APIs Rest?"

A resposta é simples: Porque passou a ser possível.

🤪

Atualmente eu vejo pessoas falando que uma metodologia é melhor que a outra etc...

Minha opinião é que não tem problema ser simples e fácil, mas precisa ser escalável e seguro.

Eu sou programador PHP e adoro a forma fácil da linguagem, agora na versão 8 ficou um pouco mais burocrática, mas ainda muito simples de aprender.

A questão de utilizar API, ou até micro-serviços, facilita o trabalho em equipe e a evolução do código.

Gosto de comparar programação com a música, às vezes o compositor está com uma folha de pão e um lápis na mão escrevendo e tocando violão e tomando uma cerveja. Depois de pronta, aí apresenta para os músicos que vão melhorar a harmonia, digitalizar as partituras e deixar perfeita.

A burocracia às vezes atrapalha a criatividade da criação. Só não podemos utilizar como desculpa para não criar um código organizado. Tudo depende do objetivo e as ferramentas que temos em mãos.

Não acredito que o código do fecebook ou youtube nasceu de forma organizada. Tudo segue o fluxo conforme a evolução.

Eae pessoal. Comecei a estudar Next recentemente, há uns 10 dias, e estou vendo os funcionamentos de SSR, SSG, etc (Inclusive os vídeos da playlist Criando sites Modernos, do canal do Filipe, estão me ajudando demais a entender).

Da maneira que estou estudando, tudo é client-side, e se eu quero que algo seja feito no server-side, eu utilizo o getServerSideProps, ou getStaticProps (utilizando o getStaticPaths junto ou não, dependendo do caso), ou utilizando as API Routes. E a nova abordagem seria: Tudo é server-side, e o que eu quero que seja client-side, eu tenho que deixar explicito isso. Entendi errado, ou é isso mesmo, ou seja, uma inversão na maneira como o Next funciona ?

Isso me deixa muito, muito animado, pois como um dev que veio do React foi pra -> Rails, eu pude perceber o quão mais produtivo é trabalhar do lado do Servidor, com a maior parte do tempo sendo pensado nas regras de negócio em si, do que por exemplo no React (fazendo fetch e sincronizando os dados, criando contextos e tentando fazer formulários funcionarem direito), no Rails tudo parece ser meio mágico e isso é ótimo.

"Ah, mas será que isso vai funcionar?" R: Já funciona!

👉 Remix.js, pra quem não conhece, ele trouxe essa proposta muita antes do Next e agora do React, e é maravilhoso

Não sei se foi só para simplificar no exemplo, mas essa query direto no componente chega me deu calafrios. Acho sim que o futuro é o passado, ou seja, renderizar tudo no servidor. Claro que sempre terão alguns casos que uma SPA é necessária, mas caso não, não vejo porque deixar mais complicado algo simples.

Podem me odiar, mas essa modinha do React tá demais, é uma ótima tec, mas querer enfiar tudo no React é ser muito presunçoso. Existem N problemas pra serem resolvidos, N ferramentas pra resolver esses N problemas. Querer colocar tudo nas costas de uma lib js é demais.
Vai ser como qualquer outra tec que foi nesse caminho, ficar tão complexo e burocratico que vai se matar por si só.

Acredito que sera um tiro no pe, uma vez que sem apis sistemas diferentes nao conversariam.

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.

hum, blazor server faz isso ha um tempo, se nao me engano. Porem nao tem (ainda) a flexibilidade de ter um client side. mas tem o maui, que com um codigo voce tem um desktop nativo, móbile e web, parecido ou igual ao fluter..
mas o que me fez desanimar do Next e outros frameworks js, é que tem muitos, isso é bom, mas nao tem certa constância que um .net tem.. masssssss.... é uma otima opção.

Essa nova abordagem não elimina o método tradicional na minha opinião, no entanto é interessante ver esse paradigma voltando a ser relevante, ainda mais vindo de um framework conhecido por ser totalmente client-side originalmente. Ainda sim, isso mostra que o desenvolvimento do React continua acontecendo, o que é muito bom!.

Outros frameworks também estão aproveitando a onda pra implementar novas maneiras de resolver os problemas, um exemplo é a implementação de Signals no Angular.

Ainda assim, essa constante mudança pode acabar frustrando quem está conhecendo mais sobre esse mundo, é uma característica recorrente no ecossistema de JavaScript/TypeScript e se você tentar acompanhar todas essas mudanças sendo um iniciante, pode acabar ficando perdido nesse mar.

Pra quem quer aprender os fundamentos ou sossegar um pouco, recomendo usar uma stack mais simples como React + Express.js ou até mesmo frameworks de outras linguagens como Ruby on Rails, Django ou Phoenix do Elixir.

É importante acompanhar essas inovações, mas muita dessas inovações não necessariamente vão ser usadas no futuro visto que ferramentas assim mudam constantemente. Acredito o melhor caminho é focar em poucas tecnologias e aprender os fundamentos, já que eles dificilmente mudarão no futuro.

a única coisa que eu penso é que desenvolvedores react vão achar essa a forma ideal, mais simples e linda de fazer as coisas. eu sou bastante cético sobre isso ser uma boa ideia.

Deixa passar mais um tempo ja volta tudo para JS no client novamente :)
Particularmente nao acho essa abordagem um bala de prata. Estamos trabalhando com Dashboards e usando Vite ( SPA ) para algumas aplicacoes faz total sentido usar SSR para outras nem tanto. Achei interessante a abordagem do Astro2.0 ja deu uma olhada ? No mais esse movimento dos grandes players acabam colocando um padrao no desenvolvimento, que alguns casos caem como uma luva e outros adiciona uma camada mais complexa sem trazer muitos beneficios ( leia-se alguns casos ).

Eu testei o NextJS 13 na versão experimental que utilizava Server Components por padrão (e caso você precisasse de um componente do cliente você utilizava a diretiva 'use client') achei SUPER confuso e vi muita gente na epoca dessa revelação falando que seria muito dificil migrar bases de código pra esse novo formato, mas ao mesmo tempo é fácil de perceber as vantagens desse modelo.

Nunca usei Server Components, e eu achava que essa funcionalidade (async function Component) era do Next, não do React. Na verdade, ainda não sei se entendi certo esse ponto.

Acho a discussão interessante. Já aconteceu algo parecido com HTML, CSS e JS. Posso estar enganado, mas no começo basicamente tudo ficava num único .html, e com o passar do tempo as coisas foram se separando. Mais recentemente, o JSX veio e juntou novamente o HTML com JS, e depois passaram a surgir bibliotecas de css-in-js, terminando com tudo junto novamente (HTML, CSS e JS).

Isso me lembra JSF e me deixa bem agoniado...

Na minha opinião misturad o server-side com client-side rendering não é o grande problema, e sim quando se fazem codigos igual no exemplo, onde não há uma separação dos conceitos a nivel de regra de negocio.
Como muito bem citado, o PHP "brilhou" no início de tudo porém trouxe uma série de problemas da mesma forma como o .Net, não pela forma de server-side rendering mas sim pela falta de preocupação por parte dos desenvolvedores daquela época.
Embora os conceitos e patterns tenham sido inventados a muito tempo atrás só estão ganhando popularidade nos tempos atuais - ninguém queria saber saber de Clean Architecture, DDD, testes unitarios e etc... nos anos 2000, e ainda hoje em 2023 é comum ver programadoes agarrados as "Boas práticas" do passado.

Sendo assim eu acredito que o principal motivo para tudo isso ter fracassado no passado foi não a tecnologia mas sim a mentalidade de desenvolvimento daquela época. Nos dias atuais estamos cada vez mais voltados a patterns e estratégias de desacoplamento a nivel de regra de negócio. O exemplo ilustrado poderia ser facilmente corrigido aplicando: Inversão/Injeção de dependências juntamente com repository pattern e uma camada de domínios, dessa forma poderia facilmente invocar esta camada de dados em qualquer lugar da aplicação que posteriormente caso fosse necessário se tornaria muito fácil a implementação de Api endpoints.

Confesso que fiquei bem confuso com as mudanças do NextJs e ainda estou me adptando a elas, principalmente a parte de "use client" que lhe obriga a usar sempre que voce tem um state na pagina.

Sobre a questão que citou acima, o next js tambem esta caminhando para isto, mas no sentido de tornar o nextjs uma API ( backend ) voltando um pouco como era na web antiga, #tenhomedo.

A onde vamos chegar?

Confesso que ler isso me deu gatilho Filipe, kk.

Eu entendo que o futuro será mesmo ter o máximo de coisas sendo renderizadas no servidor, com o objetivo de ganhar poder computacional e ter menos coisas para serem renderizadas na tela de maneira dinâmica, porém, acredito na idéia de separar os dois mundos, e ter uma API entre elas, com o objetivo de termos mais coesão e baixo acoplamento nos nossos sistemas.

Essa API não necessariamente precisa ser uma API Web, se tiver entre o front e um backend uma API que simplesmente "abstrai" a conexão com o banco, pra mim já é um bom começo, pois o grande problema de se ter tudo no mesmo lugar, é perder governança, extensibilidade, manutenibilidade e a capacidade de isolar comportamentos/funções.

Eu não acho que isso vá tornar as APIs obsoletas, mas esses recursos, nas mãos erradas, pode se tornar um grande problema para um projeto.

Aguardemos cenas dos próximos capítulos.

Mas o PHP, principalmente nessa época, tinha os seus problemas naturalmente, onde um deles era que, em arquivos que montavam uma interface HTML, por exemplo, era costume também fazer consultas diretamente ao banco de dados e isso criava vários efeitos colaterais ruins. Um deles era a impossibilidade de reaproveitamento de código

Não creio que isso seja culpa do PHP!
As pessoas faziam coisas ruins. E a linguagem era a culpada!
PHP se deu bem e fez a web que conhecemos hoje pela sua simplicidade, facilidade em começar, qualquer um com pouco conhecimento colocava um site no ar.
E alguns ganhavam e ganham dinheiro com sites que arquiteturalmente são muito feios.
As pessoas não sabiam ou não queriam fazer algo melhor.

o HTML streaming que estão usando ai no react server já existe a dezenas de anos.
https://dev.to/tigt/the-weirdly-obscure-art-of-streamed-html-4gc2

Hoje em dia existem libs JS que fazem um site MPA(jeito antigo de fazer) paracer um SPA.
https://unpoly.com/

Pra mim isso é só inchar o react.

Colocar mais uma coisa no back pra pessoas cuidarem e terem dor de cabeça!
React é ótimo no front.
SSR com react é uma gambiarra, e isso é outra gambiarra para inchar o já inchado ecossistema react.

Mas deve gerar hype, e gente usando.

Já não basta qualquer projeto usarem front separado sem qualquer motivo real.
Um MPA serve pra uns 98% dos projetos hoje sendo feitos sem motivos em SPA.
É adicionar mais uma lib mais uma coisa pra dar dor de cabeça kkkkk

De resto, não sei no que isso vai dar, acho que nãp vai vingar quando começarem a usar
e terem os problemas que foram bem citados no texto!

Vamos ver o que vai ser. :)

Rapaz, esse codigo deu uma coceira aqui ... Vou atras do meu polaramine 😆😆😆

Imagina só a segurança disso... Ta doido kkk

Faço das suas as minhas palavras, Filipe: isso me dá um certo calafrio kkkkk

Acho que essa "amarra" do Front com o Back pode sim ter vantagens e deixar a parada mais simplificada... Mas, porém, contudo, entretanto, todavia, eu adoro a ideia de separar as responsas e deixar cada tarefa com quem é mais "preparado" pra lidar com ela.

Acredito que não vá tornar "obsoleto" o uso de API's, até por que muitas aplicações construídas, aí uso um ERP no exemplo, são constantemente integrados com outras aplicações para os mais diversos fins, e isso na sua grande maioria das vezes é feito pelas API's - a não ser as integrações de NFS-e de algumas cidades de SC que ainda é por XML :')

O que mais me preocupa é a questão de segurança nessas aplicações, além de questões como escalabilidade, manutenção, refatoração e ambientação de programadores que venham de outras tecnologias e se deparem com uma estrutura nesse sentido.

De volta para o passado? 😔

Se isso funcionar no mobile e o projeto for só pra mobile pode ser uma boa.
E hoje em dia as pessoas desenvolvedores tem acesso a mais informações, vao colocar o código em estrutura separadas para facilitar a manutenção. Enfim, aguardando os proximos capitulos kkkk.

Muito interessante! Obrigado pelo conteudo. Agora o next ta ficando igual php rsrs

Fico assustado de ver esses comentários. Sou da época dos MVC. Quando vejo a quantidade de framework e tecnologia envolvida fica difícil entender como isso pode simplificar. Tento há anos fazer a migração para Node + React. O NodeJS com Express achei legal. Já o React tem um aspecto de componente interessante, mas que pode ser feito com HTML5 e CSS, se não estou enganado. Mesmo assim, acho-o bem ruim, quase como se fosse um PHP na época que misturavam no HTML... Não é à toa que veio do Facebook...rsss. Quando vi que estavam usando essa coisa chamada NextJS então... não deu. Disse a mim mesmo que eu parava ali. Estou tentando DenoJS com Svelte, pela simplicidade. Achei muito mais fácil. Se não der certo, volto pro meu velho barco. As APIs Rest foram criadas para usarmos os verbos HTTP. Justamente porque vínhamos sendo vítimas de bigtechs ao usarmos aquela coisa horrível chamada webservice. Podem me chamar de velho. Mas, aquela ideia das vantagens de usar JS em tudo já caiu por terra há anos. De quê adianta se multiplicou-se a quantidade de frameworks e tecnologias novas. Novos aprendizados. E quem acredita que essas tecnologias/frameworks durem muito mais de cinco anos? Se um sistema não pode ser construído para ser funcional e manutenível por mais de cinco anos, então é o fim. Podem jogar tudo na mão da IA e veremos no que dá... Ah, e a propósito: você não precisa de ORM, na verdade, se um DB for bem desenhado, o ORM vai mais atrapalhar, quando não tornar impossível uma chamada a uma entidade com chave primária que não seja um int incremental ou ainda seja composta. Noto que avançamos sobre novas tecnologias às vezes sem ter consciência de que aquela existente já entrega a mesma funcionalidade. Quem trouxe o Rest chamou a atenção justamente para isso: os verbos HTTP raramente utilizados. O que o React faz com componentes tem pelo menos algumas coisas que já são entregues pelo HTML5 em estado puro etc.

Sua opinião se baseia em uma falsa equivalencia, não quer dizer que uma coisa que deu errado no passado vai dar agora, ainda mais se considerando tecnologia.
Mesma coisa que dizer que carros eletricos não funcionam por que tentaram fazer isso no passado e deu errado.

Talvez falhou porque o ASP.NET não era realmente WYSIWYG (acrónimo para "What You See Is What You Get"), "O que você vê é o que você tem". Você desenhava de um jeito, aparecia de outro.
Na época também a MS teimava em criar seus próprios padrões, era um inferno fazer as coisas renderizar corretamente no IE. Imagine que a empresa dona do navegador e dona da linguagem não conseguia integrar os dois, imagine nós, pobres coitados.
Pode fazer o Edge o melhor navegador do mundo, eu não uso, pois quero a MS bem longe desse mercado.
Também não sei se a ideia de "a ida, volta e atualização ser controlada pelo .NET" foi que deu errado, ou o quê mencionei acima.
Você mencionou "não poder engatar outros clients", sei lá, talvez vão inventar wrappers ou outra maluquice.

Acredito que isso não vá muito longe, já vimos a época onde lógica de negócio ficava perto da camada de apresentação e os resultados eram os mesmos, em pouco tempo o projeto se torna um caos.

Que o react continue indo por esse caminho, ansioso pelo fim do framework