📄️ Réduire au maximum les intermédiaires
Plus vous ajoutez de couches intermédiaires, plus vous faites de "mappers" (et donc du boilerplate code). Bien entendu, ne pas réutiliser les mêmes structures de données entre votre base de données et votre couche métier fait sens, mais à quoi bon passer par des états intermédiaires au moment de passer sur le réseau ?
📄️ tRPC
tRPC veut dire "TypeScript Remote Procedure Call". Vous l'aurez peut-être deviné mais cela va vous permettre de définir les contrats de vos endpoints d'API avec du TypeScript. Vous pouvez réutiliser vos structures métiers pour l'encodage et le décodage pour les communications API. Cela sera transparent pour vous et vous aurez de bout en bout typé votre backend jusqu'au frontend.
📄️ Permettre l'évolutivité
Notre parti pris est de faire du TypeScript de bout en bout, mais sachez qu'en utilisant tRPC vous ne vous bridez pas à simplement générer des clients TypeScript. Vous pouvez très bien faire de votre produit un "produit API" de qualité avec des clients API dans différents langages.
📄️ Validation des données entrantes
Que ce soit sur vos endpoints tRPC ou sur un endpoint à part dans Next.js pour recevoir des webhooks, la devise est de toujours valider les données entrantes.
📄️ Préférez l'API à la mise en cache frontend
Qu'est-ce que ça veut dire ? Dans React, un outil comme Redux permet de gérer des "stores" pour gérer l'état global de votre frontend au fil des pages. Comme entre les pages vous allez probablement récupérer certaines mêmes données, il peut vite être tentant de chercher à économiser les requêtes réseaux en réutilisant ce qui a déjà été récupéré.
📄️ Avoir de la réactivité avec une API traditionnelle
Lorsque votre application autorise des interactions entre plusieurs utilisateurs (directement ou indirectement), il peut être envisagé d'avoir des mises à jour de la donnée en temps réel.