HTML MASTER CLASS /// LEARN TAGS /// BUILD STRUCTURE /// SEMANTIC WEB /// HTML MASTER CLASS /// LEARN TAGS ///

Untitled Lesson

⚡ Total XP: 0|💻 backend XP: 0

Skill Matrix

UNLOCK NODES BY LEARNING NEW TAGS.

Select an unlocked node to view details root

Pascual Vila

Frontend Instructor // Code Syllabus

Common Pitfalls & Errors

The Error //

Assuming a GraphQL 200 OK response means the request succeeded

// Wrong: only checks status code
if (response.status === 200) { /* assumed success */ }

// Correct: also check the GraphQL errors array
const body = await response.json();
if (body.errors?.length) { throw new Error(body.errors[0].message); }

The Solution //

GraphQL almost always returns HTTP 200, even when a resolver throws or a database call fails, because the error is nested inside the response body's `errors` array instead of reflected in the status code. Monitoring tools and uptime checks configured to alert only on non-2xx responses will silently miss real GraphQL failures — always inspect the response body's `errors` field, not just the status code.

The Error //

Expecting a REST-style CDN cache to work transparently for a GraphQL endpoint

// REST: cached automatically by any standards-compliant CDN
GET /api/products/500

// GraphQL: invisible to the CDN without extra setup
POST /graphql  { query: '{ product(id: 500) { name } }' }

The Solution //

Because nearly all GraphQL traffic goes through POST /graphql with the query in the request body, standard HTTP caches and CDNs (which key on URL and typically only cache GET) never see a cacheable request and forward every call straight to the origin server. If edge caching matters for a GraphQL API, it requires deliberate work — persisted queries with GET, or an application-level cache — not the free caching REST gets by default.