tRPC : l'API TypeScript révolutionnaire?
Si vous êtes développeur full-stack, vous êtes déjà familiers avec la difficulté de développer des API avec REST ou GraphQL. Les API REST sont parfaites pour les besoins simples, mais elles peuvent rapidement devenir complexes et difficiles à maintenir. Les API GraphQL, quant à elles, ont une courbe d'apprentissage sévère. Et si je vous disais qu'il existe une meilleure solution ? Dans cette vidéo, je vais vous présenter tRPC, qui révolutionne le développement fullstack en TypeScript.
Bonjour à tous ! Je m'appelle David, je développe depuis... eh bien, depuis le dernier millénaire. Et j'ai été intrigué lorsque j'ai entendu parler de tRPC pour la première fois. Vous voyez, quand Node.js est sorti, j'étais enthousiaste à l'idée de pouvoir partager du code et des types entre les projets client et serveur.
En pratique, les choses n'étaient jamais aussi simples. C'est là que tRPC entre en jeu. À la base, tRPC est un moyen de partager des informations de type entre le client et le serveur.
Alors... qu'est-ce que le tRPC ? Quelle est la signification de tRPC ?
Séparons cette question en deux. RPC signifie Remote Procedure Call (ou: appel de procédure à distance). Le RPC est une façon ancienne de faire de l'interaction client/serveur, antérieure même à REST. tRPC est une librairie open-source inspiré du fonctionnement de RPC.
La deuxième partie du nom est la principale force de tRPC, mais aussi sa plus grande faiblesse. Vous voyez, le "t" de tRPC fait référence à TypeScript. tRPC est idéal lorsque vous travaillez sur une application complète où les deux parties utilisent TypeScript.
Si vous devez créer une API publique, ou si votre stack comporte d'autres langages, tRPC ne va pas pouvoir servir. Mais pour moi, si vous utilisez TypeScript sur le serveur, sur le web et pour développer une application native... rien ne vaut tRPC. Permettez-moi d'expliquer pourquoi.
Commençons par le comparer à REST. REST est idéal pour les demandes simples, mais il devient rapidement complexe lorsque votre API se développe. Vous vous retrouvez avec de nombreux points de terminaison et des routes imbriquées, ce qui peut être difficile à maintenir. De plus, REST est une recommandation et non une norme. Il existe de nombreuses façons d'être RESTful, ce qui signifie que vous avez également besoin d'une documentation et de versions solides.
Avec tRPC, vous n'avez pas à vous soucier des points de terminaison et de la façon de leur parler. Au lieu de cela, vous définissez simplement les méthodes du serveur que vous voulez que votre client puisse appeler, et le framework fait le reste du travail. C'est le code lui-même, le TypeScript, qui _est _ la documentation. Cela permet d'obtenir une base de code propre et organisée, facile à maintenir.
Maintenant, comparons tRPC à GraphQL. GraphQL comporte une période initiale de prise en main. C'est un nouveau langage à apprendre. Après tout, QL signifie Query Language (langage de requête). GraphQL est auto-documenté. Le schéma est un contrat qui stipule : voici les données que je livre. Voici les données que je m'attends à recevoir en tant qu'interrogation. Il résout de nombreux inconvénients de REST.
Mais TypeScript consiste déjà à définir la forme de nos données. Avec tRPC, vous définissez vos structures de données à l'aide d'interfaces TypeScript, et le cadre garantit que les informations de type sont partagées entre le client et le serveur.
Quels sont les points forts de tRPC ? Tout d'abord, il est facile à apprendre et à utiliser, même pour les développeurs qui ne connaissent pas le développement d'API. Le framework génère le code passe-partout pour vous, ce qui vous permet de vous concentrer sur l'écriture de la logique métier. Deuxièmement, tRPC est sûr au niveau des types. Cela signifie que vous pouvez détecter les erreurs au moment de la compilation plutôt qu'au moment de l'exécution. Enfin, le tRPC est rapide et efficace car il regroupe les appels au serveur.
Bien sûr, le tRPC n'est pas parfait. Il présente certaines limites par rapport à REST et GraphQL. Pour commencer, comme je l'ai déjà mentionné, il ne convient qu'aux projets entièrement en TypeScript. Pour en tirer le meilleur parti, vous devez structurer votre code client et serveur comme un mono-référentiel, par exemple en utilisant TurboRepo. tRPC est moins adapté à la consommation extérieure, qui est l'un des principaux objectifs des API.
Malgré tout, lorsque les conditions sont réunies, tRPC change la donne en matière de développement d'API. Il offre une approche unique qui combine le meilleur de REST et GraphQL tout en tenant compte de leurs limites. Elle est facile à apprendre et à utiliser, sans risque pour les types, rapide et efficace. Si vous êtes à la recherche d'une meilleure façon de construire des API, essayez tRPC. Il produit un lien plus étroit entre le code front et back. Dans les bonnes circonstances, il peut grandement vous faciliter la vie.
Par le passé, j'ai reçu plusieurs commentaires selon lesquels vous souhaitiez voir plus de choses en pratique. Au cours des prochaines semaines, je vais donc créer une application complète en utilisant TypeScript, Next.js, Prisma, tRPC, TurboRepo, React Native et Auth.js.
Nous allons commencer par la configuration initiale, et construire à partir de là, et dès qu'il est en place, vous pouvez cliquer ici pour suivre. Si vous voulez commencer par vous-même, il existe sur GitHub une solution de démarrage appelée "create-t3-turbo" qui rassemble tous ces éléments.
Et en attendant, si vous avez des questions ou des suggestions, laissez-les dans les commentaires ci-dessous et je serai heureux de vous aider. Et on se retrouve dans la prochaine vidéo !
