Présentation : Les requêtes RPC constituent la passerelle d'une application vers le cluster Solana. Ces requêtes sont traitées par des nœuds RPC, généralement dédiés à cette tâche plutôt qu'à la participation au consensus. Néanmoins, du point de vue de l'utilisateur d'une application, une mauvaise performance RPC équivaut à une mauvaise performance du cluster. Pour offrir à vos utilisateurs une expérience exceptionnelle et mettre en valeur la rapidité et la faible latence de Solana, il est essentiel de disposer d'une infrastructure RPC à la hauteur.
Développement : Les développeurs sont encouragés à utiliser un cluster local pendant le développement, en particulier dans les premières étapes et pour les tests. Les clusters locaux offrent plus de flexibilité que les offres publiques, permettant d'exécuter des itérations précoces non optimisées. Le moyen le plus simple d'exécuter un cluster local est d'utiliser le binaire solana-test-validator, inclus dans la suite d'outils Solana CLI. Une fois que l'application atteint un état stable, le déploiement sur un cluster public devient plus approprié.
Comme pour toutes les tâches d'optimisation de code, en ce qui concerne les requêtes RPC, moins c'est mieux. Évitez de faire des appels fréquents et répétitifs pour les mêmes données. Évitez de créer des clients qui effectuent des requêtes RPC directement. Les « dApps sans backend » sont un mythe ; vous ne faites que marteler l'infrastructure de quelqu'un d'autre. Mettez en cache les appels coûteux (en particulier getProgramAccount, getSignaturesForAddress2 et getConfirmedBlock) de manière optimisée pour l'application et servez vos utilisateurs à partir du cache. Prendre le temps d'optimiser votre code avant la mise en ligne peut vous épargner de nombreux problèmes liés aux rapports de mauvaise expérience utilisateur et réduire considérablement vos dépenses d'infrastructure.
Plusieurs fournisseurs offrent un accès RPC gratuit aux clusters publics Solana. Ces services sont adaptés aux tests en conditions réelles, aux premières démonstrations et aux petits programmes bêta privés. Gardez à l'esprit que vous obtenez exactement ce pour quoi vous payez. Les services gratuits ne s'adaptent généralement pas automatiquement, sont limités en débit, n'offrent aucun SLA et n'hésitent pas à bannir les abus. Lorsqu'une application est prête à être ouverte au public, il est temps d'investir dans un accès RPC privé.
Quelques fournisseurs RPC gratuits :
Testnet
Devnet
Mainnet-beta
En raison de la variabilité des exigences RPC entre les applications, l'infrastructure RPC publique généralisée convient rarement. Pour garantir une bonne expérience utilisateur, les applications publiques doivent sécuriser leur propre accès RPC privé. Cela vous permettra d'adapter automatiquement l'échelle en fonction de la demande des utilisateurs, d'assouplir les limites de débit selon votre application et d'avoir l'esprit tranquille en sachant que les utilisateurs d'autres applications n'évinceront pas les vôtres. Plusieurs organisations proposent des services RPC à haute disponibilité et à la demande ; voir ci-dessous. Si aucun des fournisseurs ne convient et que vous êtes prêt à gérer votre propre service RPC, veuillez contacter la Fondation Solana pour obtenir des conseils.