Forem: Ankit Kumar

Why is GraphQL gaining adoption?

Ankit Kumar — Fri, 26 Sep 2025 10:49:37 +0000

If you've architected a modern application in the last few years, you've likely hit this wall: your elegantly designed REST API starts creaking under the weight of real-world requirements. The mobile team needs lighter payloads. The web team wants richer data in fewer round-trips. The new dashboard demands information on six services. Suddenly, your clean REST architecture, which used to be the de facto standard in the development of web API, turns into a Jenga game where every new requirement is going to bring the entire structure down.

This isn't a failure of REST-it's an evolution of requirements that REST wasn't designed to handle. At the time Roy Fielding proposed REST in 2000, our applications were less complicated, our clients were web browsers, and our biggest worry was the ability to make stateless, cacheable requests over unreliable networks. This is not the reality these days: many types of clients have different data requirements, microservices architectures with information that is distributed across the services, and users who want their information to respond in milliseconds.

The High Cost of Over-fetching and Under-fetching

A fundamental inefficiency in REST APIs is the problem of "over-fetching" and "under-fetching". Over-fetching occurs when a client receives more data than it actually needs from a REST endpoint. REST APIs are often designed to be generic, returning a fixed, comprehensive data structure for a given resource. This results in larger payloads, which increases network latency and wastes bandwidth, a critical issue for mobile applications.

Conversely, under-fetching describes a scenario where a single API request does not provide all the data required for a client-side view. For example, fetching a user's details may not include their posts, requiring a separate request for that related information. This architectural tension is a core reason why REST becomes unsustainable at scale: the rigid, server-defined contract of a REST API struggles to reconcile the desire for reusable APIs with the diverse and rapidly changing data needs of modern clients.

The Performance Killer: The Request Waterfall ⚡

The problem of under-fetching directly causes a specific and crippling performance issue known as the "request waterfall". This is a cascading effect where a front-end application must make a series of sequential API calls, where each request depends on the data from the previous one. For example, a parent component might fetch a user ID, a child component then uses that ID to fetch a list of posts, and a grandchild component then fetches details for each individual post.

This chain of blocking calls creates a waterfall pattern, significantly delaying the time it takes for a page to render and leading to a sluggish user experience. This issue is particularly painful for developers using component-based frameworks like React. GraphQL's single-query approach, which can fetch deeply nested and interconnected data in a single network round trip, fundamentally decouples the UI's data requirements from the underlying sequential API calls, thereby eliminating the waterfall effect by design.

Existing Solutions and Their Tradeoffs

Before GraphQL entered the picture, engineering teams developed several patterns to address REST's limitations, each with its own significant tradeoffs :

The Expansion Pattern: APIs offered query parameters to customize responses, like /api/usersfields=name,email&include=posts,comments. This can become unwieldy, adding conditional logic that makes the codebase fragile.
The BFF (Backend for Frontend) Pattern: Teams began building specialized backends for each client type. While this provides optimal experiences, it multiplies infrastructure costs and splits engineering efforts. Netflix pioneered this approach out of necessity, but most organizations lack its resources.
GraphQL-like REST Endpoints: Some teams created endpoints that accept JSON query specifications, effectively reinventing GraphQL without any of its tooling or ecosystem benefits.
API Versioning: The classic solution: when requirements change significantly, create /api/v2/. This postpones the problem rather than solving it, and maintaining multiple API versions becomes its own special hell, breaking existing client applications.

Each solution involves significant tradeoffs between performance, maintainability, and development velocity. Teams found themselves choosing between bad options, which explains why GraphQL's emergence felt like a revelation.

GraphQL: A Shift in API Design

GraphQL is an effective query language created and released as open-source in 2012 and 2015 by Facebook, respectively, and puts the client in control of the server. The main concept can be compared to a serve yourself metaphor: rather than being served a pre-cooked meal (a REST response), the client is allowed to prepare his or her plate, and ask only the data it requires, nothing more. This design allows having only one API endpoint that makes it easier to handle APIs and requires significantly fewer network requests to retrieve complex data.

The Core Innovation: A Strongly-Typed Schema

At its heart, GraphQL is a query language with a strong, predictable type system. The Schema serves as the single source of truth and a formal contract between the client and server.

Here is an example of what a GraphQL schema looks like:

type User {
  id: ID!
  name: String!
  email: String!
  posts(limit: Int, since: DateTime): [Post!]!
  friends: [User!]!
}

type Post {
  id: ID!
  title: String!
  content: String!
  author: User!
  comments(first: Int): CommentConnection!
}

This schema defines the types of data you can query and the relationships between them. Based on this schema, a frontend developer can write a single query to get precisely the data needed for a dashboard view, eliminating over-fetching and under-fetching in a single request.

query DashboardData($userId: ID!) {
  user(id: $userId) {
    name
    posts(limit: 5, since: "2024-01-01") {
      title
      comments(first: 3) {
        edges {
          node {
            content
            author { name }
          }
        }
      }
    }
  }
}

This single query accomplishes what might take several round-trips in a RESTful architecture, resulting in more efficient data fetching. The server might respond with a JSON object that has the same shape as the query, ensuring you always get back what you expect.

The Resolver Architecture

GraphQL's real power lies in its resolver pattern. A resolver is a function that populates the data for a field in the schema. This allows your GraphQL layer to become an orchestration layer over your entire data infrastructure.

const resolvers = {
  Query: {
    user: async (parent, args, context, info) => {
      // This resolver might fetch data from a user microservice
      return await context.dataSources.usersAPI.getUser(args.id);
    }
  },
  User: {
    posts: async (user, { limit, since }, context) => {
      // This resolver might hit a different Posts microservice
      return await context.dataSources.postsAPI.getPostsByUser(
        user.id, 
        { limit, since }
      );
    },
    friends: async (user, args, context) => {
      // And this resolver could query a third source, like a Redis cache
      const friendIds = await context.cache.get(`friends:${user.id}`);
      return await context.dataSources.usersAPI.getUsers(friendIds);
    }
  }
}

This architecture enables a single GraphQL API to fetch data from any number of disparate sources, including different databases, other REST APIs, SOAP services, or even gRPC backends. The client neither knows nor cares where the data comes from.

Federation: Enterprise Scale Solution

For large organizations, GraphQL's most compelling feature is its ability to create a "supergraph" or "federated graph". This model unifies an organization's various APIs, including legacy REST and internal microservices, into a single, cohesive, and evolving graph. Instead of one team owning the entire graph, different teams can own and operate different subgraphs, enabling a true microservices architecture at the API layer. The supergraph provides a unified API to the client, hiding the complexity of the underlying, distributed architecture and simplifying development.

Advantages and Tradeoffs

GraphQL's adoption is not without its tradeoffs. An expert-level understanding of the technology requires a balanced analysis of its benefits and limitations, recognizing that it is not a silver bullet.

The Benefits: Performance, Agility, and Evolvability

Development Velocity: The most immediate benefit is speed. Frontend teams can iterate without backend changes. Need an additional field? Add it to your query. This decoupling fundamentally changes the development dynamic, and companies like Airbnb have reported a "10 times greater agility at scale".
Enhanced Performance and Efficiency: By allowing clients to request precisely the data they need, GraphQL reduces payload sizes and minimizes network overhead, which leads to faster response times, especially for mobile applications or in limited bandwidth scenarios.
Simplified API Evolution: Because the schema can evolve without breaking existing clients, developers can add new fields and types without the need for complex and costly versioning strategies common in REST.
Type Safety and Tooling: The strongly-typed schema ensures data consistency and reliability between the client and server. The introspection feature fuels a rich ecosystem of development tools like GraphiQL, which provides an interactive, in-browser API playground.

The Limitations 🚨

Caching Complexity: Because GraphQL queries are dynamic and often sent as POST requests, they do not leverage traditional HTTP caching mechanisms by default. This forces developers to build or buy custom caching solutions, which can be expensive and lack features like granular observability or automated cache purging.
Security Concerns: GraphQL APIs are susceptible to new vulnerabilities. A single, deeply nested, or complex query can be computationally expensive and may overload the server. This can lead to a denial-of-service (DoS) attack if query depth limits, rate limiting, and cost analysis are not implemented. Additionally, sensitive information can be exposed if the introspection feature is not disabled in production.
Learning Curve and Complexity: GraphQL introduces new complexity compared to conventional RESTful APIs. Creating a schema, defining types, and answering queries require an investment in team education. For developers new to schema-driven APIs, this can be a difficult learning curve.
Monitoring and Debugging: Traditional APM (Application Performance Monitoring) tools don't understand GraphQL. Since a single endpoint handles all requests, you lose URL-based monitoring. You need GraphQL-aware observability tools to understand performance and errors at the field level.

GraphQL vs. REST vs. gRPC

GraphQL is not the only alternative to REST. gRPC, a high-performance framework developed by Google, also offers a modern approach. A comparative analysis reveals that each technology has a distinct ideal use case.

The Enterprise Adoption Imperative

The value of GraphQL is best demonstrated in large-scale, real-world scenarios. Its adoption is not merely a choice of technology but a strategic imperative for organizations facing the complexities of modern, distributed architectures.

Case Studies in Large-Scale Adoption 🏢

Leading enterprises across various industries have adopted GraphQL to solve their most pressing technical challenges:

GitHub transitioned to GraphQL to allow clients to request only the specific data they needed, thereby reducing the cost of multiple round-trips and simplifying a previously convoluted REST API that required constant client-server communication.
Airbnb embarked on a staged migration from REST to GraphQL, leveraging a close partnership with Apollo's tooling. This move allowed them to achieve a "10 times greater agility at scale" and improve caching and content generation for a faster user experience.
Netflix implemented a GraphQL microservices architecture that has resulted in impressive productivity gains, with development teams deploying over 100 times daily.
State Farm chose federated GraphQL to unify numerous existing services, including legacy REST and SOAP APIs, under a single supergraph. This approach solved major challenges related to schema management and inconsistent naming conventions across their many teams.
PGA TOUR and Sky Italia both used GraphQL to modernize their stacks, reducing deployment time from weeks to minutes and decreasing data propagation time by a factor of 15, from minutes to milliseconds respectively.

Why This Matters Now 📅

GraphQL's rise is not an isolated trend but a direct response to, and an enabler of, other major industry shifts, such as the growth of complex, data-driven frontend applications and the widespread adoption of microservices architectures. Its ability to provide an intelligent, unified data layer is a direct answer to the challenges posed by these trends.

Looking ahead, GraphQL is poised to play an interesting role in the emerging world of AI. Its well-defined data relationships and strongly typed schema can act as a map to the AI agents and enable them to learn and communicate with APIs in a more efficient manner. This is a potential that can be useful because AI becomes a deeper component of the software ecosystem.

The pragmatic approach is that GraphQL is not going to be a silver bullet that supersedes all other API technologies. It is probable that the most viable and efficient enterprise solutions will be a hybrid architecture with GraphQL co-existing with REST, gRPC, and others, with each deployed to its best application. GraphQL is a proven solution for organizations with complex data needs, with multiple types of clients, or a microservices architecture.

Conclusion

GraphQL's adoption isn't about REST being "bad"; it is just that the requirements have changed since the creation of REST. GraphQL offers teams the flexibility and efficiency they require in a world of diverse clients, distributed data, and rapid iteration. It is not a matter of adopting GraphQL, but where and how. The most successful adoptions I have observed take a more pragmatic approach, which involves GraphQL adding a layer of aggregation to an existing set of APIs in the area where it can be of greatest value, like complex queries or mobile apps.

The architectural evolution from REST to GraphQL mirrors our industry's broader evolution: from monoliths to microservices, server-rendered to client-rich applications, and single platform to omnichannel experiences. GraphQL is becoming popular due to the fact that it is the appropriate abstraction to our current state and our future.

We will continue this story in the next upcoming blog. Stay tuned!

What the Heck is Model Context Protocol?

Ankit Kumar — Tue, 10 Jun 2025 14:23:23 +0000

So I was vibe-coding my way through an LLM app when I hit a wall. You know the kind — you prompt something like “Build a Next.js app that fetches data from Supabase” and the model just… forgets everything 2 prompts later. 😩

Enter: Model Context Protocol — or MCP for short.

I stumbled on this repo while doom-scrolling GitHub, and honestly? It blew my mind. MCP is like giving your AI working memory. And not just "remember this name" memory — actual scoped, structured memory for apps, projects, and developer workflows.

So... What Is Model Context Protocol?

At a high level:

Model Context Protocol is an open standard for managing memory, tools, and documents in AI systems. Think of it as a context API, but for LLM agents.

If you're building anything with large language models (ChatGPT, Claude, Gemini), you’ve probably hit the limits of prompt engineering. You want your model to “know” about:

your file structure
open tabs
your docs
a running task list
API credentials

MCP says: “Cool, let’s formalize that.😂”
It introduces ideas like:

Workspaces (like projects)
Documents (files, notes, tasks)
Tools (executables, like dev servers or linters)
Models(your LLMs)

And it lets you wire them together like LEGO.

Why Does This Matter?

Because the future of dev tools is LLM-native.
Right now, we’re hacking autocomplete and chat into VS Code. But what we really want is an AI partner that:

understands project structure
knows what's in scope
remembers what you asked earlier
can run real tools and reflect on the output

MCP gives us the plumbing for that.

How Does It Work?

The servers repo gives you reference implementations of an MCP server — it handles state management for your AI agent.

You can:

Create a Workspace via API
Add files, tools, notes
Start a session with your favorite LLM (OpenAI, Anthropic, etc.)
Send prompts that pull from structured context

Instead of sending giant prompts every time, you give your model a memory, a brain, and some hands.

What’s Cool for Beginners?

I’m still wrapping my head around agentic coding, but MCP is beginner-friendly if:

You're building an LLM app and sick of prompt bloat
You want structured memory without wiring up Redis, LangGraph, etc.
You like open standards (this is all public + MIT licensed)

Here’s how you could start:

Clone modelcontextprotocol/servers
Run the server locally with Docker
Hit the API with curl or Postman to create your first Workspace
Hook it up to an LLM (OpenAI key, Anthropic, etc.)
Start querying with scoped memory!

Bonus: You can use MCP client libraries in Python, TypeScript, and Rust.

Why I’m Hyped?

This feels like the Rails moment for agentic systems. Not just "cool demos", but a standardized way to build dev tools that remember.

It’s not just about one repo. It's about the idea that your LLM shouldn't start from scratch every prompt.

And that’s the vibe. 💡

Resources

🔗 Model Context Protocol GitHub
📚 MCP Spec
⚙️ Servers Repo
🧠 Want to build an LLM IDE? Start here.

TLDR

If you’re building with LLMs in 2025, Model Context Protocol is your new best friend. It gives your model memory, tools, structure — and a better chance at shipping real software, not just vibe-code spaghetti.

Follow me for more breakdowns like this. ✌️

🚀Fixing AI Code with Model-Based Testing: A Developer's Tale

Ankit Kumar — Thu, 08 May 2025 12:04:01 +0000

🧠 The Wake-Up Call

Last week, I read about Cursor's AI support bot confidently inventing a non-existent company policy. It caused public outrage.

But for me? It wasn’t even surprising.

As a Software developer working on enterprise systems, I’ve seen that kind of AI “confidence” firsthand — not in chat replies, but in code.

It looked right. It passed some tests.
But when I deployed it?

🧨 Boom. Production bug.

The worst part? The AI didn’t know it was wrong. And neither did I… until it was too late.

🤖 My Journey with AI Coding Tools

I was an early adopter of GitHub Copilot, ChatGPT, and all the latest AI dev tools.
Like 97% of developers, I got swept up in the excitement. Who wouldn’t want:

Faster development?

Fewer repetitive tasks?

More time for “real” problem solving?

At first, it felt like magic.
But magic doesn’t always come with guardrails.

Over time, the bugs started creeping in. And they weren’t obvious ones.

Here’s what I ran into:

🔐 Authentication flows that skipped critical validation

🔍 API endpoints that looked perfect — but exposed security risks

🧪 Code that referenced packages that didn’t even exist

These weren’t rookie mistakes. They were subtle, sneaky, and often made it all the way to staging — or worse, production.

📉 The Reality Check

After one particularly painful outage, I started digging into how widespread this issue was. What I found made it clear: it wasn’t just me.

⚠️ 32% of AI-generated code is incorrect

🐛 Our internal bug count jumped 41% after AI tooling adoption

🔓 About 30% of AI code included security vulnerabilities

It wasn’t hype. It was happening.

🧪 Why Traditional Testing Failed Me

I did everything a responsible dev should do:

✅ Added more unit tests
✅ Tightened code reviews
✅ Wrote more integration tests

But here’s the problem: AI writes code faster than we can test it.

Our QA team was drowning in new code. Manual reviews weren’t enough.
Bugs slipped through. Technical debt piled up. Releases got riskier.

I knew we needed a smarter way to test.

🧭 Discovering Model-Based Testing (MBT)

After falling into a deep rabbit hole of Reddit threads, dev forums, and research papers, I came across something called Model-Based Testing.

It blew my mind.

Instead of writing individual test cases, you describe how your system should behave — and the testing framework automatically generates comprehensive test scenarios.

Think of it like this:

What if your tests understood your system's logic, not just its functions?

That’s when I discovered Provengo — a platform that made MBT actually usable in my workflow.

My Experience with Provengo

I started experimenting with Provengo, and here's what I found:

✅ What Worked Well

🚫 It caught AI hallucinations before they hit production
🔄 Test maintenance became mostly automated
🧪 I could validate behavior before implementation, not after
⚙️ It fit smoothly into our CI/CD pipeline

⚠️ What Was Challenging

📚 There’s a learning curve — behavioral modeling isn’t second nature
🕓 Initial setup took more time than I expected
😐 Some teammates were skeptical at first
📖 The docs were good, but advanced examples needed more clarity

Real Results from My Team

After using Provengo alongside our AI coding tools for a few months:

🐞 Debugging time dropped by ~60%
🚨 Production bugs decreased significantly
💬 Confidence in AI-generated code went up
🏎️ We moved faster, but without sacrificing quality

Was it perfect? No.
Was it worth it? Absolutely.

🧠 What I Learned

AI gives me speed — but speed without safety is just risk.

Provengo has become my protective layer. It doesn’t replace AI, but it makes working with AI safer, smarter, and more reliable.

Our industry doesn’t need to fight AI.
We need to build better systems around it.

The Perfect Partnership

🧠 AI Coding Assistant	🔍 Provengo MBT
Writes code quickly	Validates it thoroughly
Doesn’t understand logic	Understands expected system behavior
Can hallucinate	Flags misbehavior before it ships
Speeds up development	Speeds up testing
Increases tech debt	Reduces debugging time by up to 60%

You Try It?

The process of mastering behavioral modeling needs sufficient time for acquisition.
Your team needs to be open to a new testing paradigm
Complex projects receive greater advantages than basic projects do

✅ Final Thoughts

This tool functions as my safety net when working with AI in production systems.

It’s not perfect — no tool is.

But it’s helped me turn unpredictable code into reliable software, and that’s a win I’ll take every time.

Follow me for more such experiences!!