Project Blueprint Document
Status: Coming SoonPhase: blueprint readyarchitectEst: 50 hours

GraphQL Client Platform

Custom Query AST Parser & Normalized Cache Client

Build status noteParser AST schema complete. Cache normalization rules and mutation handler structures planned.
Architecture Focus:
GraphQL query compilationNormalized store cache mappingIn-flight request deduplicationTypeScript schema compilers
Tech Stack:
TypeScriptViteGraphQLJestTailwind CSS

Blueprint Information Only

This project's code implementation will come later in the curriculum. However, the complete architecture blueprint, functional specifications, core modules, milestones, and interview design explanations are fully active and available below to aid in your frontend system design study.

1. Problem Statement

Standard GraphQL client libraries (Apollo/Relay) have large bundle sizes, and simple fetch calls lack caching, leading to duplicate queries and slow user transitions.

2. Business Context & Friction

Using a lightweight GraphQL client decreases bundle size, boosting performance on mobile devices while ensuring consistent state across views.

Target Users:Application Developers, API Team Leads, Performance Engineers

3. Learning Objectives

  • Parse GraphQL query strings into structured AST trees
  • Store resources in a normalized client-side cache by ID
  • Build optimistic UI mutation updates with rollback capabilities
  • Deduplicate matching requests in flight to save bandwidth

4. Functional Requirements

GraphQL AST Parser

must-have

Compile GraphQL queries into Abstract Syntax Trees (AST) to validate fields and resolve arguments.

Normalized Client Cache

must-have

Flatten query responses and store records in a cache map by ID (`typename:id`) to prevent data inconsistency.

Optimistic Mutations Engine

should-have

Update UI views instantly when mutations start, and rollback changes cleanly if the API returns an error.

Fragment Fields Compiler

should-have

Support resolving nested GraphQL fragments to promote reusable component declarations.

5. Non-Functional Specifications

Performance

  • Core client library bundle size must remain under 8KB gzipped.
  • Parsing queries and matching cache nodes must take under 3ms.

Scalability

  • Normalized cache must handle up to 5,000 active nodes without slowing down UI lookups.
  • Support resolving nested query trees up to 10 levels deep.

Accessibility (A11y)

  • Include hooks that announce mutation progress and completion status to screen readers.
  • Ensure query loading views expose descriptive accessibility labels.

Security

  • Filter and escape query parameters to block injection attacks.
  • Manage auth headers securely using scoped middleware configurations.

Reliability & Fault Tolerance

  • Rollback optimistic UI changes cleanly if mutation API requests fail.
  • Auto-retry queries on network failures using exponential backoff schedules.

Observability & Telemetry

  • Expose diagnostic logs detailing cache hit rates and fetch times.
  • Export in-flight request deduplication metrics for analysis.

6. Core Modules Breakdown

Query AST Parser

Compiles GraphQL query strings into Abstract Syntax Trees (AST).

Responsibilities:
  • Tokenize GraphQL query strings
  • Build structured AST representations
  • Validate fields against schemas

Normalized Cache Store

Saves query records in a flattened map, keeping data consistent across views.

Responsibilities:
  • Flatten API responses into resource nodes
  • Query nodes by Typename and ID
  • Notify components when cached resources change

Request Deduplicator

Coordinates active requests in flight and forwards results to duplicate listeners.

Responsibilities:
  • Track active network requests
  • Group matching queries together
  • Broadcast response data to all subscribers

7. Key User Flows

User queries item data

  1. Component calls query client hook.
  2. Parser compiles query to AST; cache checks for matches.
  3. If found, the client returns cached data. If missing, it fetches the query and normalizes the response.

User submits optimistic mutation

  1. User updates post details.
  2. Client updates local cache instantly; views re-render with the new data.
  3. Mutations API requests are sent. If it fails, the client rolls back cache values to original state.

8. Architectural Blueprint

frontend Architecture

  • Lightweight TypeScript client library with custom React hooks wrappers.
  • Vite build tool configuration.

state Management

  • Custom normalized state store managing nodes maps.
  • Notify UI components when cached items update.

data Fetching

  • Standard POST requests sending query payloads to GraphQL gateways.
  • Dynamic request deduplication pipelines.

caching

  • Normalized in-memory cache.
  • Optionally save cache snapshots to localStorage.

routing

  • Compatible with all major routers; independent of routing layer.

deployment

  • Build and publish client package to NPM registry; host dashboard guides on Vercel CDN.

9. Component Execution Plan

ComponentResponsibilityNotes
QueryProviderMain Context component containing client cache store instances.Delivers cache access to child components.
useQueryCustom hook that handles query parsing, caching, and fetch requests.Subscribes to target cache changes.
useMutationCustom hook that runs mutations and handles optimistic UI updates.Runs rollback callbacks on failures.

10. API Specifications

POST/graphql
GraphQL Request

Send GraphQL queries and variables to the server gateway.

Request Payload
{
  "query": "query GetUser($id: ID!) { user(id: $id) { id name } }",
  "variables": { "id": "u1" }
}
Response Payload
{
  "data": {
    "user": { "id": "u1", "name": "Alex" }
  }
}

11. Logical Data Schemas

CacheRecord

Schema mapping normalized client cache nodes.

key: stringtypename: stringid: stringfields: Record<string, any>

12. Curriculum Milestones

Phase 1: Foundation

Parser AST Development

  • Build GraphQL query tokenizer.
  • Write parsing functions to compile queries into AST trees.
Phase 2: Core Features

Normalized Cache Store

  • Write cache normalizer flattening nested arrays.
  • Implement node query and update functions.
Phase 3: Advanced Features

Request Deduplication

  • Build in-flight request deduplicator wrapper.
  • Implement query component cache subscription hooks.
Phase 4: Production Hardening

Optimistic Mutations

  • Integrate useMutation hooks.
  • Build optimistic UI updates and rollback handlers.
Phase 5: Documentation and Interview Explanation

API Reference Docs

  • Publish detailed API reference documentation.
  • Prepare system design interview explanations detailing cache normalization.

13. Technical Execution Roadmap

1

Write query tokenizer parser

Convert query strings into tokens arrays.

2

Create normalized store

Build data structures to flatten and store objects by ID.

3

Develop React query hook

Create hooks that fetch queries and manage loading states.

4

Build optimistic mutations UI

Implement write policies that update caches before APIs resolve.

14. Systems Interview Deep Dive

Elevator Pitch

I built an 8KB GraphQL client with a custom query AST parser, a normalized cache store that flattens data, and an optimistic mutation engine that handles rollbacks cleanly.

Architecture Summary

Queries are compiled into ASTs. API responses are flattened into a normalized cache map (keyed by `typename:id`). UI components subscribe to cache changes, re-rendering only when their data updates.

Architectural Tradeoffs

  • Building a custom parser limits support for complex schema variables, but it reduces package size by 85% compared to Apollo.
  • Normalized caches require unique object IDs, which we handle by requiring 'id' and '__typename' fields in queries.

Possible Follow-up Questions

  • ?Explain how cache normalization works.
  • ?How do you implement request deduplication for concurrent page queries?

15. Future Enhancements

  • Add schema validation build scripts.
  • Support offline mutation sync queues.

Related Curriculum Tracks:

api data backend integrationperformance engineering