スキル graphql
📦

graphql

安全

Créer des APIs GraphQL sécurisées avec les meilleures pratiques

La flexibilité de GraphQL peut entraîner des problèmes de performance et de sécurité sans contrôles appropriés. Cette compétence fournit des modèles éprouvés pour l'utilisation de DataLoader, la limitation de la profondeur des requêtes et l'autorisation afin de créer des APIs GraphQL prêtes pour la production.

対応: Claude Codex Code(CC)
📊 71 十分
1

スキルZIPをダウンロード

2

Claudeでアップロード

設定 → 機能 → スキル → スキルをアップロードへ移動

3

オンにして利用開始

テストする

「graphql」を使用しています。 Concevoir un schéma pour un catalogue de produits e-commerce

期待される結果:

  • Schéma GraphQL avec les types Product, Category et Review
  • Nullabilité appropriée pour les champs optionnels comme discountPrice
  • Connections pour la pagination sur les avis de produits
  • Mutations pour les opérations CRUD avec des input types

「graphql」を使用しています。 Corriger les requêtes N+1 dans le resolver des posts utilisateur

期待される結果:

  • Implémentation DataLoader batchant les recherches d'ID utilisateur
  • Cache indexé par ID utilisateur pour prévenir les requêtes dupliquées
  • Intégration avec le contexte Apollo Server
  • Amélioration de performance passant de N requêtes à 1 requête batchée

セキュリティ監査

安全
v1 • 2/25/2026

This skill is a documentation file containing GraphQL best practices and patterns. Static analysis flagged false positives: line 69 references related skills (not shell execution), and lines 3, 22, 34, 63, 72 contain markdown content (not cryptographic code). No executable code or security risks detected.

1
スキャンされたファイル
73
解析された行数
0
検出結果
1
総監査数
セキュリティ問題は見つかりませんでした
監査者: claude

品質スコア

38
アーキテクチャ
100
保守性
87
コンテンツ
32
コミュニティ
100
セキュリティ
91
仕様準拠

作れるもの

Développeur Backend créant une nouvelle API

Concevoir et implémenter une API GraphQL prête pour la production avec des optimisations de performance appropriées et des contrôles de sécurité dès le départ.

Équipe Frontend intégrant GraphQL

Configurer Apollo Client avec une mise en cache normalisée et des modèles de récupération de données efficaces pour les applications React.

Tech Lead auditant une API existante

Identifier et corriger les anti-modèles courants de GraphQL comme l'absence de DataLoader, la profondeur de requête illimitée et les lacunes d'autorisation.

これらのプロンプトを試す

Concevoir un schéma GraphQL de base
Créez un schéma GraphQL pour un blog avec les types User, Post et Comment. Incluez une nullabilité appropriée, des relations et des opérations CRUD courantes sous forme de requêtes et mutations.
Implémenter DataLoader pour prévenir N+1
J'ai un resolver GraphQL qui récupère les auteurs pour les posts. Chaque resolver de post effectue une requête base de données séparée. Montrez-moi comment implémenter DataLoader pour batcher et mettre en cache ces requêtes.
Ajouter la limitation de profondeur des requêtes
Configurez la limitation de la profondeur des requêtes et l'analyse de complexité pour mon Apollo Server afin de prévenir les attaques DoS provenant de requêtes GraphQL profondément imbriquées. Incluez la configuration et la gestion des erreurs.
Implémenter l'autorisation au niveau des champs
Montrez-moi comment implémenter l'autorisation au niveau des champs dans les resolveurs GraphQL. Certains champs ne doivent être visibles que par les utilisateurs authentifiés ou les utilisateurs avec des rôles spécifiques.

ベストプラクティス

  • Toujours utiliser DataLoader pour batcher les requêtes base de données et prévenir les problèmes N+1
  • Limiter la profondeur et la complexité des requêtes pour se protéger contre les attaques DoS
  • Implémenter l'autorisation dans les resolveurs, pas seulement dans les directives de schéma

回避

  • Effectuer des appels base de données directement dans les resolveurs sans DataLoader
  • Autoriser une profondeur de requête illimitée sur votre endpoint GraphQL
  • S'appuyer uniquement sur les directives de schéma pour la logique d'autorisation

よくある質問

Pourquoi DataLoader est-il nécessaire pour GraphQL ?
Sans DataLoader, chaque resolver de champ effectue des requêtes base de données indépendantes. Une seule requête récupérant 10 posts avec leurs auteurs déclenche 11 requêtes (1 pour les posts, 10 pour les auteurs). DataLoader regroupe cela en 2 requêtes, améliorant considérablement les performances.
L'introspection doit-elle être activée en production ?
Généralement non. L'introspection expose la structure entière de votre schéma aux clients. Bien qu'utile pour les outils de développement, cela peut aider les attaquants à comprendre votre API. Désactivez-la en production sauf si vous avez spécifiquement besoin du support des outils clients.
Quelle est la différence entre autorisation de schéma et autorisation de resolver ?
Les directives de schéma déclarent qui peut accéder à quoi au niveau du type/champ. L'autorisation de resolver implémente la logique réelle. Implémentez toujours l'autorisation dans les resolveurs ; les directives seules peuvent être contournées ou mal configurées.
Comment gérer les erreurs versus les données nulles dans GraphQL ?
Utilisez une nullabilité appropriée dans votre schéma. Si un champ peut légitimement être vide, rendez-le nullable. S'il doit avoir une valeur, rendez-le non-null. Lorsqu'un champ non-null échoue, GraphQL nullifie tout l'objet parent, ce qui peut casser les requêtes.
Quelle limite de profondeur de requête dois-je utiliser ?
Commencez avec une limite de profondeur de 5-10 pour la plupart des APIs. Surveillez vos requêtes légitimes et ajustez en conséquence. Implémentez également l'analyse de complexité des requêtes pour détecter les requêtes coûteuses mais peu profondes qui contournent les limites de profondeur.
Dois-je nettoyer les subscriptions GraphQL ?
Oui. Les subscriptions maintiennent des connexions ouvertes. Lorsque les clients se déconnectent, assurez-vous que les gestionnaires de subscription côté serveur sont correctement nettoyés pour prévenir les fuites de mémoire. Implémentez le nettoyage dans vos resolveurs de subscription en utilisant des hooks de cycle de vie appropriés.

開発者の詳細

作成者

sickn33

ライセンス

MIT

参照

main

ファイル構成

📄 SKILL.md