Je viens de voir un post qui dit que plus on segmente une architecture modulaire finement, plus un indexeur a de chances de « se bloquer ». J’ai trouvé ça soudainement assez intéressant.



La semaine dernière, à je ne sais combien de reprises, j’ai voulu consulter l’historique de données d’un protocole : le Subgraph est resté bloqué pendant des heures sans répondre. Puis j’ai changé pour un nœud RPC, et là, il m’a directement limité en débit. En gros, c’est exactement ce genre de situation : tu veux voir ce qui s’est passé on-chain, et au lieu de ça, il commence par te faire goûter au « plaisir d’attendre ».

En fait, si on dit les choses clairement, tout le monde vante maintenant la disponibilité des données, mais dès que tu vas vraiment chercher des données, si un seul maillon lâche — la vitesse de synchronisation d’un indexeur, celle d’un Subgraph, ou la stratégie de limitation de débit du RPC — côté utilisateur, c’est juste un énorme vide. La modularité, ça se démonte plutôt facilement, mais là où la combinabilité ne “fait pas la lumière”, ce sont justement ces moments où tout « se bloque ».

Les développeurs s’enthousiasment pour l’architecture, tandis que les utilisateurs ne comprennent pas « pourquoi ça disparaît encore ». Je ne sais pas vraiment comment résoudre ça, mais en tout cas, ces derniers temps en consultant des données on-chain, j’ai déjà entraîné mon état d’esprit : d’abord, boire un verre d’eau, puis seulement cliquer sur “rafraîchir”.
Voir l'original
Cette page peut inclure du contenu de tiers fourni à des fins d'information uniquement. Gate ne garantit ni l'exactitude ni la validité de ces contenus, n’endosse pas les opinions exprimées, et ne fournit aucun conseil financier ou professionnel à travers ces informations. Voir la section Avertissement pour plus de détails.
  • Récompense
  • Commentaire
  • Reposter
  • Partager
Commentaire
Ajouter un commentaire
Ajouter un commentaire
Aucun commentaire
  • Épinglé