Développez un peu le problème de GraphQL. L'avantage principal de GraphQL n'est pas vraiment le système de types, en réalité, les contraintes de type strictes peuvent également être bien mises en œuvre dans un système RESTful. En tirant pleinement parti de Zod, qui peut générer du code multi-plateforme avec la solution orpc, des solutions comme FastAPI + Pydantic dans l'écosystème Python peuvent obtenir des résultats similaires. L'avantage le plus fondamental de GraphQL réside dans la flexibilité des données, c'est-à-dire que le client peut demander des données de manière flexible en fonction de ses besoins. C'est également l'une des principales fonctions mises en œuvre par la couche BFF traditionnelle. Cependant, contrairement à la couche BFF traditionnelle, l'implémentation de GraphQL est généralement fortement liée aux affaires, sans avoir extrait une infrastructure distincte pour traiter des problèmes similaires. Dans cette situation, la flexibilité peut entraîner de nombreux problèmes, tant dans le système GraphQL (ou dans des solutions BFF similaires intégrées aux affaires). Le plus simple, c'est que la flexibilité entraîne une plus grande surface d'attaque. En effet, un utilisateur malveillant peut construire une requête suffisamment complexe pour consommer massivement les ressources de votre serveur simplement par l'analyse AST. Bien sûr, beaucoup de gens pourraient dire, ah, il suffit de limiter la complexité des requêtes, n'est-ce pas ? Alors je vous demande, le calcul de la complexité des requêtes nécessite-t-il également une analyse AST ? D'autres pourraient dire, eh bien, il suffit de limiter le modèle de requête, n'est-ce pas ? Alors je vous demande, votre modèle nécessite-t-il également une analyse AST ? De plus, vous limitez le plus grand avantage de GraphQL, quelle est la différence avec une API RESTful traditionnelle ? De plus, si l'analyse AST de GraphQL n'est pas séparée des affaires, combinée avec le modèle à thread unique de Node, votre boucle d'événements peut être directement affectée, ce qui dégrade l'expérience utilisateur de plusieurs niveaux. Beaucoup de choses que GraphQL doit faire nécessitent une infrastructure distincte pour se dissocier des affaires, comme la limitation de taux au niveau des requêtes, des logiques d'authentification spéciales, etc. Pour être franc, pour les plateformes de données ou les services internes, GraphQL peut être un choix assez bon. Cependant, pour les affaires toC à grande échelle, GraphQL peut apporter plus de complexité et d'incertitude que les API RESTful traditionnelles, nécessitant un développement d'infrastructure particulièrement important.