Episode Details
Back to Episodes
Course 37 - Building Web Apps with Ruby On Rails | Episode 18:Navigating GraphQL and the Graphiti Middle Ground
Published 1 week, 4 days ago
Description
In this lesson, you’ll learn about: REST limitations, GraphQL fundamentals, and the hybrid approach with Graphiti1. The Problem with REST APIsUsing REST:🔹 Key limitations:
REST is simple and scalable—but not always efficient2. Example of Overfetching🔹 Request:GET /users/1 🔹 Response:{ "id": 1, "name": "John", "email": "john@example.com", "address": "...", "preferences": "...", "settings": "..." } 👉 Problem:
REST responses are fixed by the server, not flexible for clients3. Introducing GraphQLUsing GraphQL:🔹 What it solves:
GraphQL eliminates overfetching and underfetching4. GraphQL Schema (Core Concept)🔹 Schema:
GraphQL is strongly typed, unlike REST5. Queries vs Mutations🔹 Queries (read data):{ users { name } } 🔹 Mutations (write data):mutation { createUser(name: "John") { id } } 👉 Key Insight
GraphQL separates read and write operations clearly6. Testing with GraphiQL🔹 Tool:
GraphiQL improves developer experience significantly7. Downsides of GraphQL🔹 Trade-offs:
GraphQL flexibility comes with added complexity8. Introducing Graphiti (Hybrid Approach)Using Graphiti:🔹 Goal:
Graphiti gives you flexibility without abandoning REST9. Graphiti Resources🔹 Concept:
Resources act like a structured API layer10. REST vs GraphQL vs Graphiti🔹 REST:
There is no perfect solution—only trade-offs11. When to Use Each🔹 Use REST:
Choose based on project complexity and team needsKey Takeaways
- Overfetching
- Client receives more data than needed
- Underfetching
- Requires multiple requests to get all data
- No strict typing
- Errors happen at runtime
- Heavy reliance on documentation
REST is simple and scalable—but not always efficient2. Example of Overfetching🔹 Request:GET /users/1 🔹 Response:{ "id": 1, "name": "John", "email": "john@example.com", "address": "...", "preferences": "...", "settings": "..." } 👉 Problem:
- Client may only need name
REST responses are fixed by the server, not flexible for clients3. Introducing GraphQLUsing GraphQL:🔹 What it solves:
- Clients request exactly what they need
GraphQL eliminates overfetching and underfetching4. GraphQL Schema (Core Concept)🔹 Schema:
- Defines types and relationships
- Acts as a contract between client and server
GraphQL is strongly typed, unlike REST5. Queries vs Mutations🔹 Queries (read data):{ users { name } } 🔹 Mutations (write data):mutation { createUser(name: "John") { id } } 👉 Key Insight
GraphQL separates read and write operations clearly6. Testing with GraphiQL🔹 Tool:
- GraphiQL
- Run queries in browser
- Explore schema
- Debug
GraphiQL improves developer experience significantly7. Downsides of GraphQL🔹 Trade-offs:
- No native HTTP caching
- More complex setup
- Boilerplate code
- No strict naming conventions
GraphQL flexibility comes with added complexity8. Introducing Graphiti (Hybrid Approach)Using Graphiti:🔹 Goal:
- Combine REST simplicity + GraphQL flexibility
- Filtering
- Sorting
- Including relationships
Graphiti gives you flexibility without abandoning REST9. Graphiti Resources🔹 Concept:
- Define API behavior using “Resources”
Resources act like a structured API layer10. REST vs GraphQL vs Graphiti🔹 REST:
- Simple
- Fast
- Limited flexibility
- Flexible
- Precise data fetching
- More complex
- Balanced approach
- Keeps HTTP benefits
- Adds flexibility
There is no perfect solution—only trade-offs11. When to Use Each🔹 Use REST:
- Simple APIs
- Standard CRUD apps
- Complex frontend needs
- Multiple data sources
- Want flexibility + REST structure
Choose based on project complexity and team needsKey Takeaways
- REST suffers from overfetching and lack of typing
- GraphQL provides flexible, precise queries
- GraphQL introduces complexity and trade-offs
- Graphiti offers