Criando API's com tRPC

[@lucasmrthomaz]

O mundo vai evoluindo e as necessidades dos sistemas também, de longe já é possível ver que o padrão rest deixa a desejar em determinadas situações... Nenhum protocolo ou técnologia é perfeita, elas vão mudando e tá aí uma que irá ajudar muito no cenário atual. Parabéns pelo conteúdo!

[@dogcodedev]

Faala fera, beleza? Realmente, nenhuma tecnologia é bala de prata que vai servir pra tudo. O tRPC é uma ótima ferramenta e que pode ser utilizada em vários cenários mas vale analisar bem o problema antes de sair aplicando ela.

[@opcoesdenegocio7948]

Por favor... faça a integração com o Next.JS :) Já deixei o like

[@dogcodedev]

Faala fera, beleza? Deixa pra nós ;)

[@codewithguillaume]

This morning I just shoot a crash test video on TRPC and it was very funny ! Just found yours and your channel, I'll subscribe :)

[@ofabiobaptista]

Muito boa explicação.. parabéns!

[@agnaldopereiradasilva6007]

Fantástico! Muito obrigado por passar o conhecimento!

[@rbpolim]

Parabéns pelo conteúdo! Faz back e front

[@dogcodedev]

Faala Rodrigo, beleza? Ficamos felizes em saber que você curtiu o conteúdo, conte com a gente 💙

[@duanyrf]

Show de vídeo! Gostaria de ver um vídeo integrando back com front, usando a Stack React + Typescript + tsx + tRPC + BD

[@dogcodedev]

Faala Duany, beleza? Boa, sugestão anotada.

[@arthurmelo88]

como funciona essa conexao com o servidor? usa websocket por debaixo ? as conexoes perduram quanto tempo? existe um ping pong entre cliente servidor? qual o limite de usuarios simultaneos que uma solucao dessa pode suportar?

[@ariell121]

O tRPC não abre conexões com servidor, ele faz chamadas HTTP normalmente, usando requests e responses, ele só não segue o padrão REST. Apesar de ele ter tRPC no nome, ele não é bem de fato um "Remote procedure call", tanto que até cogitaram mudar o nome da biblioteca mas como já tinha caido em cunho popular o nome lá na gringa e no hype, decidiram manter. A forma que o tTRPC funciona é a seguinte - Cria um servidor node que vai se comunicar via padrão API tRPC (parecido como uma API REST e uma API GraphQL) - O cliente faz chamadas pra essa api tRPC via HTTP (Fazendo uso de um tRPC cliente, que formata as queries para acessar as procedures) - O cliente sabe quais procedures estão disponiveis para sem chamadas e validadas no frontend, via uso de importação dos types definitions do server tRPC, por isso recomenda-se usar em um projeto com monorepo, onde seu frontend pode importar o type direto do backend, e ter as tipagens do que pode chamar, e validar os inputs antes de executar a procedure. - Servidor valida as requisições basedos nos input usando a lib zod - Servidor retorna um response de volta para o cliente Lados negativos do tRPC - Ele foi feito para funcionar em projetos fullstack typescript (back e frontend em typescript, com suporte inicialmente somente pra React, ainda não tem wrappers pra vue/angular) - Você precisa de um monorepo pra usar o tRPC de forma mais fácil. - Você consegue usar uma API tRPC sem um cliente tRPC no frontend(que atualmente só funciona pra typescript, javascript não funciona), porém vai ser um inferno manipular e fazer as queries, exemplo num app nativo iOS, ou Android. Trecho retirado do site do tRPC "If your project is built with full-stack TypeScript, you can share types directly between your client and server, without relying on code generation." Resumindo você declara um server tRPC no backend, exporta os types dele, ai no frontend você importa os types do backend, e passa as tipagens pro cliente e assim ele consegue inferir todos os possiveis procedures que podem ser chamadas, tudo usando chamadas HTTP normalmente, abrir abrir nenhuma conexão e etc. Ele é parecido como qualquer outra API Rest ou GraphQL, só muda a forma de comunicação entre o servidor e o cliente. Infelizmente o video passa muita informações erradas sobre tRPC :/

[@arthurmelo88]

​@@ariell121 poxa o seu comentario foi muito mais esclarecedor que o proprio video, obrigado por tirar seu tempo pra explicar tudo, eu li todo o comentario. Por um minuto achei que esse tRPC era um concorrente direto do gRPC para typescript, mas vi que nao tem nada a ver, o rpc original + google protobuffers é outro nivel em termos de arquitetura... no final esse tRPC é so mais uma gambiarra que os javascripteros fizeram , sad!

[@andersondossantoscruz3685]

@@ariell121 muito obrigado pelo comentário esclarecedor, resumindo prefiro ainda usar codegen no GQL pra gerar os types e ter uma API flexível.

[@paulorcvieira]

Faz integração com o Next.js... valeu!

[@TomerCarolla]

por favor faz um video trpc com react ! :)

[@amorimcode]

Muito bom, se possível faça um video integrando com react

[@devchines]

Eu fiquei com uma dúvida, numa aplicação que tem muitos usuários conectados simultaneamente, será que isso não geraria um novo problema com a concorrência de acesso a DB ou a processamento? Não sei se estou falando besteira mas isso passou pela minha cabeça, E parabéns pelo vídeo, ficou muito bem explicado o assunto

[@dogcodedev]

Faala Cheng, beleza? Ótima pergunta, esse problema é bem comum e várias empresas passam por ele ao escalar, tem várias técnicas que da para aplicar para evitar gargalo no banco como Load Balance.

[@reivideosum]

Da pra implementar com golang ?

[@srboca]

Faz uma aplicação com back e front

[@dogcodedev]

Faala Jonathan, beleza? Deixa pra nós.

[@AdeilsonTube]

Boa..... E dá para fazer igual ao graphql de restringir os campos do retorno?

[@dogcodedev]

Faala Adeilson, beleza? Nesse caso você está chamando funções, então você não consegue controlar o que ela retorna no Front, no caso do Mobile e Frontend você teria que ter duas funções.

[@cortaesai]

Faltou mostrar no react como que aparece essem trem

[@alexkads]

Quero isso no Remix!

[@saulotarsobc]

+1

[@cortaesai]

os dev Backend tem tando medo do Front que fazem um playground que simula o Front 😂😂😂😂

[@joelitonpimenta7765]

Nem aprendi rest ainda

[@fabricioaraujo7642]

Não consigo sinceramente ver vantagem usando esse trpc em relação ao modelo tradicional, essa comunidade js inventa coisa que simplesmente não precisava existir

[@luan_maik]

Era só ter integrado com o swagger para gerar a documentação dos endpoints da api, mas o criador preferiu reinventar a roda e criou ela quadrada

[@yurihnrq]

Nada a ver, experiências de desenvolvimento totalmente diferentes. tRPC cai super bem em projetos fullstack utilizando Next.js, por exemplo, te fornecendo tipagem dos endpoints na sua própria IDE

[@matheuscanuto6306]

Mas o tRPC foi feito para soluções monoliticas, não faz sentido ter integração com o swagger

[@matheuscanuto6306]

Vc quer uma aplicação para testar end-points para uma biblioteca que foi feita para ser utilizada no front-end