GraphQL Complete Guide

History of GraphQL

In 2012, Facebook's mobile team faced a growing crisis. The Facebook iOS app was slow, unreliable, and consumed excessive bandwidth. The root cause was architectural: the app's News Feed aggregated data from dozens of REST endpoints — user profiles, posts, comments, likes, photos, friend lists — each returning a fixed data structure. The client received far more data than it needed (over-fetching) and still had to make multiple round trips to assemble a single screen (under-fetching).

Lee Byron, Dan Schafer, and Nick Schrock at Facebook began working on a solution. They created a query language that allowed the mobile client to describe exactly what data it needed in a single request, and the server would return exactly that shape of data — nothing more, nothing less. They called it GraphQL (Graph Query Language), because it modeled data as a graph of interconnected objects.

GraphQL powered Facebook's mobile apps internally from 2012, handling billions of queries per day. In September 2015, Facebook open-sourced the GraphQL specification along with a reference implementation in JavaScript (graphql-js). The response from the developer community was immediate and enthusiastic.

In November 2018, Facebook transferred GraphQL to the newly formed GraphQL Foundation, hosted by the Linux Foundation. This move ensured that GraphQL's governance was vendor-neutral, with companies like Airbnb, AWS, Apollo, Gatsby, GitHub, IBM, PayPal, Shopify, and Twitter as founding members.

The GraphQL Type System

GraphQL is a strongly-typed language. Every piece of data in a GraphQL API has a specific type, and the schema defines all available types and their relationships. This type system is what enables the powerful developer tooling (auto-complete, validation, documentation) that makes GraphQL productive to work with.

Scalar Types

# Built-in scalar types
type Example {
    id: ID!           # Unique identifier (serialized as String)
    name: String!     # UTF-8 character sequence (! means non-nullable)
    age: Int          # 32-bit signed integer (nullable)
    rating: Float     # Double-precision floating point
    active: Boolean   # true or false
}

# Custom scalar types (defined by the server)
scalar DateTime       # e.g., "2026-04-01T12:00:00Z"
scalar JSON           # Arbitrary JSON
scalar URL            # Validated URL string
scalar EmailAddress   # Validated email

Object Types

# Object types define the shape of data
type User {
    id: ID!
    email: String!
    name: String!
    avatar: String
    posts: [Post!]!       # Non-nullable list of non-nullable Posts
    followers: [User!]!
    createdAt: DateTime!
}

type Post {
    id: ID!
    title: String!
    body: String!
    author: User!          # Relationship to User type
    comments: [Comment!]!
    tags: [String!]
    publishedAt: DateTime
}

type Comment {
    id: ID!
    text: String!
    author: User!
    post: Post!
    createdAt: DateTime!
}

Enums, Interfaces, and Unions

# Enum: a type with a fixed set of values
enum PostStatus {
    DRAFT
    PUBLISHED
    ARCHIVED
}

enum Role {
    ADMIN
    EDITOR
    VIEWER
}

# Interface: shared fields across types
interface Node {
    id: ID!
}

interface Timestamped {
    createdAt: DateTime!
    updatedAt: DateTime!
}

type User implements Node & Timestamped {
    id: ID!
    name: String!
    createdAt: DateTime!
    updatedAt: DateTime!
}

# Union: one of several possible types
union SearchResult = User | Post | Comment

type Query {
    search(query: String!): [SearchResult!]!
}

Input Types

# Input types are used for mutation arguments
input CreatePostInput {
    title: String!
    body: String!
    tags: [String!]
    status: PostStatus = DRAFT   # Default value
}

input UpdatePostInput {
    title: String
    body: String
    tags: [String!]
    status: PostStatus
}

input PaginationInput {
    first: Int = 10
    after: String          # Cursor-based pagination
}

Queries & Fields

Queries are how clients read data from a GraphQL API. The fundamental principle is that the client specifies exactly which fields it wants, and the server returns exactly that shape — no more, no less.

Field Selection

# Query: fetch a user with selected fields only
query {
    user(id: "123") {
        name
        email
        avatar
    }
}

# Response: exactly the requested shape
# {
#     "data": {
#         "user": {
#             "name": "Jane Doe",
#             "email": "jane@example.com",
#             "avatar": "https://cdn.example.com/avatars/jane.jpg"
#         }
#     }
# }

Nested Fields and Relationships

# Traverse the graph — follow relationships
query {
    user(id: "123") {
        name
        posts(first: 5) {
            title
            publishedAt
            comments {
                text
                author {
                    name
                }
            }
        }
    }
}

# This single query replaces what would be 3+ REST calls:
# GET /users/123
# GET /users/123/posts?limit=5
# GET /posts/{id}/comments (for each post)

Arguments, Aliases, and Variables

# Aliases: rename fields to avoid conflicts
query {
    currentUser: user(id: "123") {
        name
        email
    }
    otherUser: user(id: "456") {
        name
        email
    }
}

# Variables: parameterize queries (essential for production)
query GetUser($userId: ID!, $postLimit: Int = 10) {
    user(id: $userId) {
        name
        email
        posts(first: $postLimit) {
            title
        }
    }
}

# Variables JSON (sent alongside the query):
# { "userId": "123", "postLimit": 5 }

Fragments

# Fragments: reusable field selections
fragment UserBasic on User {
    id
    name
    avatar
}

fragment PostSummary on Post {
    id
    title
    publishedAt
    author {
        ...UserBasic
    }
}

query FeedQuery {
    feed(first: 20) {
        ...PostSummary
        comments(first: 3) {
            text
            author {
                ...UserBasic
            }
        }
    }
}

Mutations & Input Types

Mutations are how clients modify data in a GraphQL API. They follow a convention: the mutation name describes the action, it accepts an input argument, and it returns the modified data so the client can update its cache.

# Schema: define mutations
type Mutation {
    createPost(input: CreatePostInput!): CreatePostPayload!
    updatePost(id: ID!, input: UpdatePostInput!): UpdatePostPayload!
    deletePost(id: ID!): DeletePostPayload!
    likePost(postId: ID!): LikePostPayload!
}

# Payload types include the result + potential errors
type CreatePostPayload {
    post: Post
    errors: [UserError!]!
}

type UserError {
    field: String
    message: String!
}

# Client: execute a mutation
mutation CreatePost($input: CreatePostInput!) {
    createPost(input: $input) {
        post {
            id
            title
            body
            status
            author {
                name
            }
        }
        errors {
            field
            message
        }
    }
}

# Variables:
# {
#     "input": {
#         "title": "Introduction to GraphQL",
#         "body": "GraphQL is a query language...",
#         "tags": ["graphql", "api"],
#         "status": "PUBLISHED"
#     }
# }

Server-Side Implementation

// Apollo Server: mutation resolver
const resolvers = {
    Mutation: {
        createPost: async (_, { input }, context) => {
            // Authentication check
            if (!context.user) {
                return {
                    post: null,
                    errors: [{ field: null, message: 'Authentication required' }],
                };
            }

            // Input validation
            const errors = [];
            if (input.title.length < 5) {
                errors.push({ field: 'title', message: 'Title must be at least 5 characters' });
            }
            if (input.body.length < 20) {
                errors.push({ field: 'body', message: 'Body must be at least 20 characters' });
            }
            if (errors.length > 0) {
                return { post: null, errors };
            }

            // Create the post
            const post = await db.posts.create({
                ...input,
                authorId: context.user.id,
                publishedAt: input.status === 'PUBLISHED' ? new Date() : null,
            });

            return { post, errors: [] };
        },
    },
};

Real-Time Subscriptions

Subscriptions enable real-time data push from server to client. When a client subscribes to an event, the server holds the connection open (typically via WebSocket) and pushes data whenever the event occurs.

# Schema: subscription type
type Subscription {
    postCreated: Post!
    commentAdded(postId: ID!): Comment!
    userStatusChanged(userId: ID!): UserStatus!
}

type UserStatus {
    userId: ID!
    online: Boolean!
    lastSeen: DateTime
}

// Apollo Server: subscription with PubSub
import { PubSub } from 'graphql-subscriptions';

const pubsub = new PubSub();

const resolvers = {
    Mutation: {
        createPost: async (_, { input }, context) => {
            const post = await db.posts.create({
                ...input,
                authorId: context.user.id,
            });

            // Publish the event to all subscribers
            pubsub.publish('POST_CREATED', { postCreated: post });

            return { post, errors: [] };
        },

        addComment: async (_, { postId, text }, context) => {
            const comment = await db.comments.create({
                postId,
                text,
                authorId: context.user.id,
            });

            // Publish with a dynamic channel based on postId
            pubsub.publish(`COMMENT_ADDED_${postId}`, { commentAdded: comment });

            return comment;
        },
    },

    Subscription: {
        postCreated: {
            subscribe: () => pubsub.asyncIterator(['POST_CREATED']),
        },
        commentAdded: {
            subscribe: (_, { postId }) =>
                pubsub.asyncIterator([`COMMENT_ADDED_${postId}`]),
        },
    },
};

// Client-side: subscribing with Apollo Client
import { useSubscription, gql } from '@apollo/client';

const COMMENT_SUBSCRIPTION = gql`
    subscription OnCommentAdded($postId: ID!) {
        commentAdded(postId: $postId) {
            id
            text
            author {
                name
                avatar
            }
            createdAt
        }
    }
`;

function CommentFeed({ postId }) {
    const { data, loading } = useSubscription(COMMENT_SUBSCRIPTION, {
        variables: { postId },
    });

    if (data) {
        // New comment arrived in real-time
        console.log('New comment:', data.commentAdded);
    }

    return /* render comments */;
}

Resolver Architecture

Resolvers are functions that populate the data for each field in your schema. They form a chain — each resolver receives the result of the parent resolver and can fetch additional data, transform values, or delegate to other data sources.

Resolver Signature

// Every resolver receives four arguments:
// parent  — the return value of the parent field's resolver
// args    — the arguments passed to this field
// context — shared per-request state (auth, dataloaders, db)
// info    — AST information about the query

const resolvers = {
    Query: {
        user: async (parent, args, context, info) => {
            return context.db.users.findById(args.id);
        },

        posts: async (parent, { first, after, status }, context) => {
            return context.db.posts.find({
                status,
                limit: first,
                cursor: after,
            });
        },
    },

    // Field-level resolvers on the User type
    User: {
        // 'parent' here is the User object returned by Query.user
        posts: async (parent, { first = 10 }, context) => {
            return context.db.posts.findByAuthorId(parent.id, { limit: first });
        },

        followers: async (parent, args, context) => {
            return context.db.follows
                .findFollowers(parent.id)
                .then(follows => context.db.users.findByIds(follows.map(f => f.followerId)));
        },

        // Computed field — not stored in the database
        fullName: (parent) => {
            return `${parent.firstName} ${parent.lastName}`;
        },
    },
};

Error Handling in Resolvers

// Structured error handling
import { GraphQLError } from 'graphql';

const resolvers = {
    Query: {
        user: async (_, { id }, context) => {
            const user = await context.db.users.findById(id);

            if (!user) {
                throw new GraphQLError('User not found', {
                    extensions: {
                        code: 'USER_NOT_FOUND',
                        argumentName: 'id',
                        http: { status: 404 },
                    },
                });
            }

            return user;
        },
    },

    Mutation: {
        deletePost: async (_, { id }, context) => {
            const post = await context.db.posts.findById(id);

            if (!post) {
                throw new GraphQLError('Post not found', {
                    extensions: { code: 'NOT_FOUND' },
                });
            }

            if (post.authorId !== context.user.id) {
                throw new GraphQLError('Not authorized to delete this post', {
                    extensions: { code: 'FORBIDDEN' },
                });
            }

            await context.db.posts.delete(id);
            return { success: true, deletedId: id };
        },
    },
};

The N+1 Problem & DataLoader

The N+1 problem is the most common performance pitfall in GraphQL. It occurs when a resolver for a list field triggers a separate database query for each item in the list.

The Problem

// Naive resolvers — N+1 problem
const resolvers = {
    Query: {
        posts: () => db.query('SELECT * FROM posts LIMIT 10'), // 1 query
    },
    Post: {
        // Called ONCE FOR EACH post — 10 posts = 10 more queries!
        author: (post) => db.query('SELECT * FROM users WHERE id = ?', [post.authorId]),
    },
};

// Query:
// { posts { title author { name } } }
//
// SQL executed:
// 1. SELECT * FROM posts LIMIT 10
// 2. SELECT * FROM users WHERE id = 1
// 3. SELECT * FROM users WHERE id = 2
// 4. SELECT * FROM users WHERE id = 3
// ... 10 more queries
// Total: 11 queries for 10 posts (1 + N)

The Solution: DataLoader

DataLoader (created by Facebook, now maintained by the GraphQL Foundation) batches and caches individual lookups within a single request tick. Instead of N individual queries, DataLoader collects all keys in the current tick and executes a single batched query.

import DataLoader from 'dataloader';

// Create a DataLoader for batch-loading users by ID
function createLoaders() {
    return {
        userLoader: new DataLoader(async (userIds) => {
            // Single query for ALL requested user IDs
            const users = await db.query(
                'SELECT * FROM users WHERE id IN (?)',
                [userIds]
            );
            // CRITICAL: return results in the same order as the input IDs
            const userMap = new Map(users.map(u => [u.id, u]));
            return userIds.map(id => userMap.get(id) || null);
        }),

        postsByAuthorLoader: new DataLoader(async (authorIds) => {
            const posts = await db.query(
                'SELECT * FROM posts WHERE author_id IN (?)',
                [authorIds]
            );
            // Group posts by authorId
            const postsByAuthor = new Map();
            posts.forEach(post => {
                if (!postsByAuthor.has(post.authorId)) {
                    postsByAuthor.set(post.authorId, []);
                }
                postsByAuthor.get(post.authorId).push(post);
            });
            return authorIds.map(id => postsByAuthor.get(id) || []);
        }),
    };
}

// In Apollo Server setup: create new loaders per request
const server = new ApolloServer({
    typeDefs,
    resolvers,
    context: ({ req }) => ({
        user: authenticateRequest(req),
        loaders: createLoaders(), // Fresh loaders per request
    }),
});

// Updated resolvers — now use DataLoader
const resolvers = {
    Post: {
        author: (post, _, { loaders }) => {
            return loaders.userLoader.load(post.authorId);
            // DataLoader batches all .load() calls in the current tick
        },
    },
    User: {
        posts: (user, _, { loaders }) => {
            return loaders.postsByAuthorLoader.load(user.id);
        },
    },
};

// Now the same query executes only 2 queries:
// 1. SELECT * FROM posts LIMIT 10
// 2. SELECT * FROM users WHERE id IN (1, 2, 3, ...) — batched!

Apollo Client & Server

Apollo is the most popular GraphQL ecosystem, providing both a client library (for React, Vue, Angular, iOS, and Android) and a server framework. Apollo Client's normalized cache is one of its most powerful features.

Apollo Server Setup

// Apollo Server 4 with Express
import { ApolloServer } from '@apollo/server';
import { expressMiddleware } from '@apollo/server/express4';
import express from 'express';

const typeDefs = `#graphql
    type Query {
        users: [User!]!
        user(id: ID!): User
        posts(first: Int, after: String): PostConnection!
    }

    type User {
        id: ID!
        name: String!
        email: String!
        posts: [Post!]!
    }

    type Post {
        id: ID!
        title: String!
        body: String!
        author: User!
    }

    type PostConnection {
        edges: [PostEdge!]!
        pageInfo: PageInfo!
    }

    type PostEdge {
        node: Post!
        cursor: String!
    }

    type PageInfo {
        hasNextPage: Boolean!
        endCursor: String
    }
`;

const server = new ApolloServer({ typeDefs, resolvers });
await server.start();

const app = express();
app.use('/graphql', express.json(), expressMiddleware(server, {
    context: async ({ req }) => ({
        user: await authenticateRequest(req),
        loaders: createLoaders(),
    }),
}));

app.listen(4000, () => console.log('GraphQL server running on :4000'));

Apollo Client Setup & Hooks

// Apollo Client 3 with React
import { ApolloClient, InMemoryCache, ApolloProvider, gql, useQuery, useMutation } from '@apollo/client';

const client = new ApolloClient({
    uri: 'https://api.example.com/graphql',
    cache: new InMemoryCache({
        typePolicies: {
            Query: {
                fields: {
                    posts: {
                        // Cursor-based pagination merge
                        keyArgs: false,
                        merge(existing = { edges: [] }, incoming) {
                            return {
                                ...incoming,
                                edges: [...existing.edges, ...incoming.edges],
                            };
                        },
                    },
                },
            },
        },
    }),
});

// useQuery hook in a React component
const GET_USER = gql`
    query GetUser($id: ID!) {
        user(id: $id) {
            id
            name
            email
            posts {
                id
                title
            }
        }
    }
`;

function UserProfile({ userId }) {
    const { loading, error, data } = useQuery(GET_USER, {
        variables: { id: userId },
        fetchPolicy: 'cache-and-network', // Show cache first, then update
    });

    if (loading) return <Spinner />;
    if (error) return <ErrorMessage error={error} />;

    const { user } = data;
    return (
        <div>
            <h1>{user.name}</h1>
            <p>{user.email}</p>
            <h2>Posts</h2>
            {user.posts.map(post => (
                <PostCard key={post.id} post={post} />
            ))}
        </div>
    );
}

// useMutation with optimistic update
const CREATE_POST = gql`
    mutation CreatePost($input: CreatePostInput!) {
        createPost(input: $input) {
            post {
                id
                title
                body
                status
            }
            errors {
                field
                message
            }
        }
    }
`;

function CreatePostForm() {
    const [createPost, { loading }] = useMutation(CREATE_POST, {
        // Optimistic response: update UI immediately before server responds
        optimisticResponse: {
            createPost: {
                post: {
                    id: 'temp-id',
                    title: formData.title,
                    body: formData.body,
                    status: 'DRAFT',
                    __typename: 'Post',
                },
                errors: [],
                __typename: 'CreatePostPayload',
            },
        },
        // Update the cache after the mutation completes
        update(cache, { data }) {
            if (data.createPost.post) {
                cache.modify({
                    fields: {
                        posts(existingPosts = []) {
                            const newPostRef = cache.writeFragment({
                                data: data.createPost.post,
                                fragment: gql`fragment NewPost on Post { id title body status }`,
                            });
                            return [...existingPosts, newPostRef];
                        },
                    },
                });
            }
        },
    });
}

Authentication & Authorization

GraphQL does not prescribe how authentication should work — it is transport-agnostic. However, the community has converged on several patterns for integrating auth with GraphQL resolvers.

Context-Based Authentication

// Extract auth from the request in the context factory
const server = new ApolloServer({
    typeDefs,
    resolvers,
    context: async ({ req }) => {
        const token = req.headers.authorization?.replace('Bearer ', '');
        let user = null;

        if (token) {
            try {
                const payload = await verifyJWT(token);
                user = await db.users.findById(payload.sub);
            } catch (e) {
                // Invalid token — user remains null (unauthenticated)
            }
        }

        return { user, loaders: createLoaders() };
    },
});

// Resolvers can check context.user
const resolvers = {
    Query: {
        me: (_, __, { user }) => {
            if (!user) throw new GraphQLError('Not authenticated', {
                extensions: { code: 'UNAUTHENTICATED' },
            });
            return user;
        },
    },
};

Directive-Based Authorization

# Schema directives for declarative authorization
directive @auth(requires: Role = VIEWER) on FIELD_DEFINITION | OBJECT

type Query {
    publicPosts: [Post!]!
    me: User! @auth
    adminDashboard: Dashboard! @auth(requires: ADMIN)
    analytics: Analytics! @auth(requires: EDITOR)
}

type User @auth {
    id: ID!
    name: String!
    email: String! @auth(requires: ADMIN)  # Only admins can see emails
    role: Role!
}

// Implementing the @auth directive
import { mapSchema, getDirective, MapperKind } from '@graphql-tools/utils';

function authDirectiveTransformer(schema) {
    return mapSchema(schema, {
        [MapperKind.OBJECT_FIELD]: (fieldConfig) => {
            const authDirective = getDirective(schema, fieldConfig, 'auth')?.[0];
            if (!authDirective) return fieldConfig;

            const requiredRole = authDirective.requires || 'VIEWER';
            const originalResolve = fieldConfig.resolve;

            fieldConfig.resolve = async (parent, args, context, info) => {
                if (!context.user) {
                    throw new GraphQLError('Authentication required', {
                        extensions: { code: 'UNAUTHENTICATED' },
                    });
                }

                const roleHierarchy = { VIEWER: 0, EDITOR: 1, ADMIN: 2 };
                if (roleHierarchy[context.user.role] < roleHierarchy[requiredRole]) {
                    throw new GraphQLError(`Requires ${requiredRole} role`, {
                        extensions: { code: 'FORBIDDEN' },
                    });
                }

                return originalResolve(parent, args, context, info);
            };

            return fieldConfig;
        },
    });
}

GraphQL vs REST

The "GraphQL vs REST" debate is one of the most common discussions in API design. The truth is that both have valid use cases, and the best choice depends on your specific requirements.

When to Choose GraphQL

• Multiple client types — mobile, web, TV apps each need different data shapes for the same entities
• Complex, nested data — social graphs, content management, e-commerce with products/variants/reviews
• Rapid frontend iteration — frontend teams need to change data requirements without backend changes
• API aggregation — BFF (Backend for Frontend) layer that combines data from multiple microservices

When to Choose REST

• Simple CRUD operations — straightforward resource-based APIs
• HTTP caching is critical — CDN caching with ETags and Cache-Control headers
• File-heavy APIs — file upload/download as a primary use case
• Public APIs with many consumers — REST is more universally understood
• Microservice-to-microservice communication — gRPC is often better than both REST and GraphQL for this

Case Studies

Case Study 1: GitHub API v4

GitHub launched their GraphQL API (v4) in September 2016, making them one of the first major platforms to offer a production GraphQL API alongside their existing REST API (v3). The motivation was clear: the REST API required too many round trips for common workflows.

Consider fetching a repository's recent issues with their labels and assignees. With REST v3, this required three sequential requests: (1) GET /repos/:owner/:repo/issues, (2) GET /repos/:owner/:repo/issues/:number/labels for each issue, and (3) GET /repos/:owner/:repo/issues/:number/assignees for each issue. With GraphQL v4, a single query returns everything:

# GitHub GraphQL API v4: Single query replaces 20+ REST calls
query RepoIssues {
    repository(owner: "facebook", name: "react") {
        issues(first: 10, states: OPEN, orderBy: { field: CREATED_AT, direction: DESC }) {
            nodes {
                title
                number
                createdAt
                author { login avatarUrl }
                labels(first: 5) {
                    nodes { name color }
                }
                assignees(first: 3) {
                    nodes { login avatarUrl }
                }
                comments { totalCount }
            }
            pageInfo { hasNextPage endCursor }
        }
        stargazerCount
        forkCount
    }
}

GitHub reported that their GraphQL API reduced the average API call volume for common workflows by 50-80%, particularly for their mobile app and third-party integrations like CI/CD tools.

Case Study 2: Shopify Storefront API

Shopify migrated their Storefront API to GraphQL in 2018, enabling millions of online stores to build custom storefronts. The Storefront API handles checkout, product queries, and cart management — operations where over-fetching is costly because every byte impacts page load time and conversion rates.

Shopify's implementation is notable for its strict query cost analysis. Every field in their schema has a cost weight, and each query is analyzed before execution. If the total cost exceeds the client's rate limit (which varies by plan), the query is rejected with an informative error explaining the cost breakdown. This prevents clients from writing expensive queries that could degrade service quality.

// Shopify's cost analysis in the response extensions
{
    "data": { /* ... */ },
    "extensions": {
        "cost": {
            "requestedQueryCost": 42,
            "actualQueryCost": 38,
            "throttleStatus": {
                "maximumAvailable": 1000,
                "currentlyAvailable": 962,
                "restoreRate": 50
            }
        }
    }
}

Case Study 3: Airbnb's Migration

Airbnb adopted GraphQL in 2018 as part of a broader frontend infrastructure modernization. Their key challenge was that the Airbnb website had over 800 REST endpoints, and the mobile app needed different data shapes than the web app for the same pages. They implemented GraphQL as a BFF (Backend for Frontend) layer — a GraphQL server that sits between the clients and the internal microservices, aggregating data from multiple backend services into a single graph.

Airbnb's approach, which they called "Niobe," involved automatically generating GraphQL schemas from their existing Thrift service definitions, so they could migrate incrementally without rewriting backend services. They reported that page load times improved by 10-30% for mobile web users because GraphQL eliminated redundant data transfer.

Exercises

GraphQL Schema Design Generator

Use this tool to document your GraphQL schema design — types, queries, mutations, subscriptions, and resolver strategy. Download as Word, Excel, PDF, or PowerPoint for architecture review, team onboarding, or API documentation.

Conclusion & Resources

GraphQL represents a fundamental shift in how we think about API design — from server-defined endpoints to client-driven data requirements. When used appropriately, it delivers significant improvements in developer experience, network efficiency, and frontend velocity.

Further Learning Resources