Learn how graph data structures and algorithms can streamline system performance. This presentation covers the basics of graphs, key algorithms, and real-world scenarios where graph thinking leads to measurable optimization

2. History

3. Early 2000s – REST APIs
 Designed for simpler web applications.
 Based on accessing resources through URLs.
 Introduced key ideas: stateless servers & structured resources.
2010 – Challenges with REST as apps grew
 Rise of mobile → need for efficient data loading.
 Multiple clients (web, mobile, IoT) → fixed data structures = inflexible.
 Faster product iterations → client changes often required server updates.
2012 – Birth of GraphQL at Facebook
 Created to power complex, data-driven mobile apps.
 Allowed clients to request exactly the data they need.
2015 – OpenSource Release
 Facebook released GraphQL publicly.
 Quickly adopted by the developer community.

4. Definition

5. GraphQL
 A query language for your API.
 A runtime for executing those queries.
 Uses a type system you define.
 Works with any database or backend.

6. Advantages

7. Fetch only required fields → smaller payloads, faster responses.
Single API call → eliminates multiple REST endpoints.
Reduces over-fetching & under-fetching → optimized client requests.
Unifies multiple backends under a single API.
Schema-driven design → easy integration with complex systems & microservices.
API evolution without versioning → deprecate fields instead of creating v2, v3…
Built-in validation & type checking → ensures queries match schema.
Auto-updating documentation via introspection.
Code reuse with fragments → share query parts across components.
Detailed error messages → query-level precision instead of generic codes.
Subscriptions for real-time data → live updates (chat, notifications, dashboards).

8. Disadvantages

9.  Performance issues with complex queries
– Deeply nested or heavy queries can overload the server.
 Overkill for small apps
– REST is often simpler and more efficient for small or resource-driven applications.
 Web caching complexity
– Harder to use standard HTTP caching since GraphQL has a single endpoint.
 File uploading limitations
– GraphQL doesn’t support file uploads natively.
 Extra Codes
– Requires learning schema definition, query language, and ecosystem tools

10. Work Flow

11. 1. Client Request
 The client sends a Query (to read) or Mutation (to write/update/delete).
 The request specifies exactly which fields the client needs.
2. Validation Against Schema
 The GraphQL server checks the request against the Schema.
 Ensures:
 The requested fields exist.
 Arguments and types are valid.
 Invalid queries are rejected before hitting the backend.
3. Resolvers Execution
 Each requested field is linked to a resolver function.
 Resolvers act as the bridge between schema fields and actual data sources.

12. 4. Data Fetching
Resolvers gather data from:
 Databases (SQL, NoSQL)
 REST APIs
 Microservices
 Third-party APIs
Supports nested and batched requests in one round-trip.
5. Response Assembly
 GraphQL compiles all resolved data into a single JSON response.
 The response structure mirrors the query.
6. Return to Client
 The client receives the JSON response.
 UI renders only the requested data → efficient & predictable.

13. Core Concepts

15. 1. Schema (the contract)
 Central to GraphQL: defines what data is available and how it can be accessed.
 Written in Schema Definition Language (SDL).
 Defines:
 Types → kinds of objects (e.g., User, Post)
 Fields → properties inside a type (e.g., User.name)
 Relationships → how types connect (e.g., User.posts)
 Acts as a contract between client and server.

16. 2. Types in GraphQL
 Scalar Types: primitive data (String, Int, Float, Boolean, ID).
 Object Types: group related fields (e.g., User { id, name, email }).
 Enums: restricted sets of values (e.g., Status { ACTIVE, INACTIVE }).
 Lists: represent arrays of objects (e.g., [Post]).
 Non-nullable Types: force required fields with !.
 Input Types: used for passing arguments in queries/mutations.

17. 3. Operations
 GraphQL has three main operations:
 Query → Read data.
 Mutation → Write/update/delete
data.
 Subscription → Real-time data (e.g.,
live chat, notifications).

18. 4. Resolvers
 Functions that connect schema fields to actual data sources.
 A resolver is a function that tells GraphQL how to fetch the data for a particular field in the
schema.
 Every field in your schema can have a resolver.
 GraphQL itself doesn’t know about your database or APIs—it just calls the resolver.
 Resolvers can fetch data from databases, REST APIs, or other services.
fieldName(parent, args, context, info) => returnValue

19. 5. Introspection
 GraphQL APIs are self-documenting.
 Clients can query the schema itself to discover:
 What types exist
 What fields are available
 What queries/mutations are allowed
 Tools like GraphiQL and GraphQL Playground leverage this.

20. Schema definition (SDL)
The server defines a Query type, which acts like the entry point. For example:
type Fruit { name: String price: Float }
type Query { fruits: [Fruit] }
Resolvers
You also provide resolver functions that tell GraphQL how to fetch the data.
const resolvers =
{ Query: { fruits: () => [ { name: "Apple", price: 1.2 }, { name: "Banana", price: 0.8 } ] } }
The query
When you send:
query GetFruitPrices { fruits { price } }

21. When you need to write a resolver
Custom fetching logic
When your field requires fetching data from a database, API, or computation.
const resolvers = { Query: { user: (_, { id }) => database.getUserById(id), }, };
Computed fields
If a field’s value is not directly stored, like fullName:
const resolvers = { User: { fullName: (user) => `${user.firstName} ${user.lastName}`, }, };
Authorization or conditional logic
If you need to check permissions before returning a value.
When you don’t need to write a resolver
1.Default resolvers work
GraphQL automatically resolves fields if the parent object has a property with the same name.
const user = { id: 1, name: "Alice" };
// Querying { user { id, name } } works without writing any resolver
2.Simple passthrough fields
•If your data matches your schema exactly and doesn’t need transformation.

22. Roles

23. Backend Developer Responsibilities
Define GraphQL types (Post, Author, etc.)
Define Queries and Mutations
Write Resolvers to fetch and return data
Connect GraphQL to database or other APIs
Example Resolver:
const resolvers = {
Query: {
posts: () => posts,
post: (_, { id }) => posts.find(p => p.id === id),
},
Post: {
author: (post) => authors.find(a => a.id === post.authorId),
},
};

24. Frontend Developer Responsibilities
 Write GraphQL queries/mutations in React
 Use Apollo Client (or other GraphQL client)
 Fetch exactly the data needed from backend
 Render data dynamically in UI components
Example Query in React:
query {
posts {
id
title
author {
name
}
}
}

25. Architecture

27. 1. Client Layer
Clients are responsible for constructing queries and sending them to the server.
 Apollo Client → rich feature set (caching, pagination, optimistic UI, error handling, prefetching,
connection with view layer).
 Relay → Facebook’s library for React, optimized for large-scale apps with strong type safety.
 GraphQL Request → lightweight client for Node & browsers, good for simple apps or scripts.
2. Server Layer
The GraphQL server receives queries, validates them against the schema, and executes resolvers.
 Apollo Server → most popular in JavaScript ecosystem, integrates seamlessly with Apollo Client.
 GraphQL Yoga → flexible, developer-friendly server built on Express & Apollo.
 GraphQL Ruby → Ruby implementation of GraphQL.
 Other languages → Java (graphql-java), Python (Graphene), Go (gqlgen), etc.

28. 3. Schema & Resolvers
 Schema defines the data types, queries, mutations, and subscriptions.
 Resolvers map schema fields to data sources (databases, APIs, microservices).
 Strong typing ensures queries are validated before execution.
4. Gateway / Federation Layer
 Gateways act as proxies or orchestrators on top of one or more GraphQL servers.
 Apollo Federation → enables multiple GraphQL services to compose into one “supergraph.”
 Apollo Engine → adds query tracing, caching, error tracking, and performance monitoring.
 Benefits: scalability, modular microservices, centralized analytics.

29. 5. Database-to-GraphQL Servers
Automatically generate GraphQL APIs directly from databases:
 Prisma → modern ORM with auto-generated GraphQL & TypeScript support.
 PostGraphile → instantly generates a GraphQL API from a PostgreSQL schema.
 Neo4j-GraphQL → specialized for graph databases.
6. Monitoring & Security Layer
 Query complexity analysis → prevent expensive nested queries (avoids DoS attacks).
 Depth limiting & rate limiting → control server load.
 Authentication & Authorization → control access at field level (e.g., roles, scopes).
 Monitoring via Apollo Studio, GraphQL Inspector, or custom observability tools.

30. Extra Tips

31. N+1 Problem & DataLoader
 In naive GraphQL, nested queries (e.g., users → posts) can cause many DB calls.
 Solution: DataLoader batches & caches requests.
Performance & Security Concerns
 Query depth limiting → prevent maliciously deep queries.
 Complexity analysis → control expensive queries.
 Rate limiting → protect backend from overuse.
.

32. Federation & Microservices
 Apollo Federation → compose multiple GraphQL services into one “supergraph.”
 Useful for large orgs with distributed systems.
GraphQL vs REST
REST → rigid endpoints, over-fetching.
GraphQL → flexible, client-driven, but heavier server complexity.

33. THANK YOU!