DEV Community: Muhammad Zain Naseer

REST vs. GraphQL: A Decision Framework, Not a Holy War

Muhammad Zain Naseer — Thu, 25 Jun 2026 09:24:31 +0000

Ask which API style you should use and you'll get answers with the emotional intensity of a religious debate. GraphQL evangelists will tell you REST is a legacy relic. REST loyalists will tell you GraphQL is complexity cosplay. Both camps are arguing about the wrong thing — because the right choice almost never depends on which technology is "better." It depends on the shape of your data, the shape of your clients, and the shape of your team.

Here's a framework for deciding based on your actual situation instead of the loudest blog post.

What each one is actually good at

Strip away the tribalism and the core difference is simple.

REST gives you a set of URLs, each returning a fixed, server-defined shape of data. /users/42 returns a user. /users/42/orders returns their orders. The server decides what each endpoint contains; the client takes what it's given. This is predictable, cacheable by default, and trivially understood by anyone who's used the web.

GraphQL gives you a single endpoint and a query language. The client describes exactly the data it wants — these fields from the user, those fields from each of their orders, nested however it likes — and gets back precisely that shape in one round trip. The power moves to the client.

That single distinction — who decides the response shape — drives almost everything else.

The problems GraphQL was built to solve

Two specific pains push teams toward GraphQL, and if you don't have them, you don't need it.

Over-fetching and under-fetching. With REST, an endpoint returns a fixed payload. A mobile screen that needs only a user's name and avatar still downloads their full profile — bio, settings, timestamps, the works (over-fetching). Meanwhile, a screen that needs a user plus their last three orders plus each order's status has to hit three endpoints and stitch the results together client-side (under-fetching). GraphQL collapses both problems: ask for exactly the fields you need, across exactly the relationships you need, in one query.

Many diverse clients evolving fast. If you have a web app, an iOS app, an Android app, and a partner integration — each needing a different slice of the same data, each shipping on its own schedule — REST tends to sprout either bloated do-everything endpoints or a proliferation of bespoke ones. GraphQL lets each client self-serve from a single schema without the backend cutting a new endpoint every sprint.

If those two paragraphs describe your life, GraphQL is earning its complexity. If they don't, keep reading.

The problems GraphQL quietly introduces

GraphQL isn't free. It moves complexity rather than removing it, and the new complexity lands in places that are easy to underestimate.

Caching gets harder. REST rides on a decade of HTTP caching infrastructure — CDNs, browser caches, ETags — all keyed on URLs. GraphQL's single POST endpoint defeats most of that out of the box. You get caching back, but you build it yourself at the application or client layer, and it's real work.

Performance footguns multiply. The flexibility that lets a client ask for deeply nested data also lets it ask for expensive deeply nested data. The infamous N+1 query problem — one query fanning out into hundreds of database calls — is a constant hazard, and you'll need tools like DataLoader-style batching and query-cost analysis to keep it contained. A naive GraphQL server is a denial-of-service vulnerability waiting for a curious client.

Observability and security need new habits. Every REST endpoint is a natural unit for rate limiting, monitoring, and access control. With one GraphQL endpoint, you have to reconstruct all of that at the field and query-cost level. It's doable and well-trodden, but it's a different mental model your whole team has to learn.

The decision framework

Forget which is trendier. Walk these questions in order.

1. How many clients consume this API, and how different are their data needs?
One client, or several with near-identical needs → REST. Multiple clients with genuinely divergent, fast-changing needs → GraphQL starts paying off.

2. How relational and nested is your data?
Mostly flat resources fetched independently → REST fits naturally. Deeply connected graphs where clients routinely need "this, plus its related that, plus their related other thing" → that's literally what GraphQL is named for.

3. How much does HTTP caching matter to you?
Public, cacheable, read-heavy content (think a content site or product catalog) → REST's free CDN caching is a serious advantage. Highly personalized, per-user data that wasn't going to cache well anyway → you lose less by going GraphQL.

4. What does your team already know?
This one is underrated. A team fluent in REST that adopts GraphQL for a CRUD app will spend its first quarter relearning caching, error handling, and performance tuning it already had for free. Technology you can operate confidently beats technology that's theoretically optimal.

5. Do you actually have the GraphQL pains today?
Not "might we someday." Today. If you're over-fetching badly or drowning in client-specific endpoints right now, that's a real signal. If you're choosing GraphQL for a problem you're imagining, you're buying complexity on credit.

The answer nobody wants to hear

For a large share of products — a single app talking to a backend, mostly straightforward resources, a small team — REST is the right call, and it's not close. It's simpler to build, simpler to cache, simpler to secure, and simpler to hire for. "Boring" is a feature when it's load-bearing.

GraphQL is a genuinely excellent answer to a specific set of problems: many clients, deeply relational data, and rapid independent evolution. When you have those problems, it's transformative. When you don't, it's a sophisticated solution looking for a question.

And you're not locked in. Plenty of mature systems run REST for their cacheable public surface and GraphQL for their complex internal client needs. The two aren't enemies — they're tools with different sweet spots, and the senior move is matching the tool to the shape of the work rather than to the shape of the argument.

Pick the one your situation is asking for. Let everyone else fight about it online.

How to Put an LLM in Your Product Without Wrecking Your Costs or Your Latency

Muhammad Zain Naseer — Thu, 25 Jun 2026 09:21:40 +0000

Adding an AI feature looks deceptively easy. You sign up for an API key, paste in a prompt, and within an hour you've got a working demo that makes the whole team lean over your shoulder. Then you ship it, traffic arrives, and two things happen at once: your latency graph develops a long, ugly tail, and your monthly bill arrives with a number that makes finance schedule a meeting.

The gap between "impressive demo" and "production feature" is almost entirely about cost and latency engineering. The model is the easy part. Here's how to cross that gap.

First, understand what you're actually paying for

Most LLM APIs bill by tokens — roughly ¾ of a word each — and they bill both directions: the tokens you send (input) and the tokens the model generates (output). Output tokens are usually several times more expensive than input tokens, which has a non-obvious consequence: a verbose prompt is cheaper than a verbose answer.

This reframes optimization. People obsess over trimming their prompts while letting the model ramble for 800 tokens when 80 would do. If you want to cut cost, the highest-leverage move is almost always constraining the output: ask for JSON, ask for a single sentence, set a max_tokens ceiling, and tell the model explicitly to be terse.

Latency follows the same logic. Generation is sequential — the model produces one token at a time — so output length is the single biggest driver of how long a request takes. A 50-token answer is fast almost regardless of model. A 2,000-token answer is slow even on the fastest infrastructure.

Lever 1: Don't call the model when you don't have to

The cheapest, fastest LLM call is the one you never make. Two techniques eliminate a startling share of traffic.

Caching identical and near-identical requests. Many real-world prompts repeat — the same FAQ-style question, the same document summarized twice, the same classification of similar inputs. A cache keyed on the normalized prompt turns a repeat request into a sub-millisecond lookup. For exact repeats, a simple key-value cache works. For similar requests, a semantic cache — where you embed the query and return a cached answer if a previous query is close enough in vector space — can absorb far more traffic, at the cost of some tuning.

Routing to the right tier. You do not need your most capable model for every task. Classifying a support ticket into one of five buckets is a job for a small, cheap, fast model. Drafting a nuanced customer email is worth the premium one. A simple router — even a keyword or length heuristic before anything fancy — that sends easy work to a cheap model and hard work to an expensive one can cut spend dramatically without anyone noticing a quality drop.

Lever 2: Make latency feel lower than it is

Sometimes you genuinely need a long, high-quality response, and it's genuinely going to take a few seconds. You can't always make it faster — but you can make it feel fast, which is often what actually matters to the user.

Stream the response. Instead of waiting for the full answer and dumping it at once, stream tokens as they're generated. The user starts reading after a few hundred milliseconds, and the perceived wait collapses even though total generation time is unchanged. This is the single highest-impact UX change for any chat-style feature, and most SDKs support it with a one-line change.

Show honest progress for non-streamed work. If you're doing something multi-step — retrieve, then reason, then format — tell the user what's happening ("Searching your documents…", "Drafting an answer…"). A visible, truthful status beats a spinner that gives no information about whether anything is working.

Lever 3: Control the worst case, not just the average

Your average latency is a comforting lie. LLM endpoints have heavy tails: most requests are fine, but a meaningful slice take 3–5× longer, and a few time out entirely. If your product blocks on those, a small fraction of slow requests can dominate the experience.

Defend against the tail explicitly:

Set aggressive timeouts and decide in advance what happens when you hit one — a cached fallback, a smaller model, a graceful "try again" — rather than letting the request hang.
Add a retry with backoff for transient failures, but cap it. Infinite retries against an overloaded provider just make the outage worse.
Add a circuit breaker for sustained failures. If the provider is clearly down, fail fast to your fallback instead of sending every user into a 30-second wait.

These aren't AI-specific patterns — they're the same resilience engineering you'd apply to any external dependency. The mistake is treating the LLM as magic instead of as what it is: a slow, occasionally flaky network call to someone else's servers.

Lever 4: Measure the things that actually move

You can't optimize what you don't track. From day one, log three numbers per request: input tokens, output tokens, and end-to-end latency. Tag them by feature and by model. Within a week you'll have a cost-and-latency breakdown by feature, and it will almost certainly surprise you — there's usually one endpoint quietly responsible for most of the bill, and it's rarely the one you'd guess.

A useful derived metric is cost per successful user outcome, not cost per API call. A feature that calls the model twice but actually solves the user's problem is cheaper, in every way that matters, than one that calls it once and gets ignored.

The mindset shift

The teams that ship AI features sustainably stop thinking of the model as the product and start thinking of it as an expensive, high-variance dependency they're responsible for managing. The prompt gets you the demo. Caching, routing, streaming, and tail control get you a feature you can afford to keep running.

None of it is exotic. It's the same discipline that makes any external service production-ready — applied to a service that happens to charge by the word and answer at the speed of thought, one token at a time.

How to Structure a Scalable Flutter App Before It Structures You

Muhammad Zain Naseer — Thu, 25 Jun 2026 09:18:35 +0000

Every Flutter app starts the same way: one main.dart, a StatelessWidget, and a feeling of total control. Then features arrive. A login screen needs the same user object the profile screen mutates. A network call that lived happily inside a widget now needs to be reused in three places. Six weeks in, you're scrolling through a 1,400-line widget file looking for the one setState that's causing a rebuild storm, and "control" is the last word you'd use.

The good news: scalable Flutter architecture isn't a framework you bolt on later. It's a small number of boundaries you draw early, and then refuse to cross. This guide walks through the boundaries that matter, why each one exists, and how to apply them without turning a simple app into an enterprise cathedral.

The one rule that prevents most pain

If you take nothing else from this article, take this: your UI should never talk directly to your data sources.

A widget should not know whether the user's name came from a REST API, a local SQLite cache, or a hard-coded mock. The moment a widget knows that, you've welded your interface to your infrastructure. Swapping the API, adding a cache, or writing a test now means touching UI code — and UI code is the most volatile, most frequently rewritten code you own.

The fix is to put layers between them. Three is usually enough.

The three layers

1. Presentation — widgets, and the state objects that feed them. This layer's only job is to render state and forward user intent ("the user tapped Save"). It holds no business rules.

2. Domain — the logic that defines what your app actually does. "A user can't check out with an empty cart." "A draft auto-saves after 5 seconds of inactivity." This layer is pure Dart: no Flutter imports, no HTTP, no database. That purity is the point — it's the part of your app that's trivially testable and rarely needs to change just because a button moved.

3. Data — repositories and the data sources behind them (API clients, local storage, platform channels). This layer knows about JSON, status codes, and cache invalidation so that nothing above it has to.

Dependencies point in one direction only: Presentation → Domain → Data. The domain never imports the UI. The data layer never imports the domain's business logic. When you find yourself wanting to break that arrow, that's the signal you've put logic in the wrong place.

What this looks like in practice

Say you're building a screen that shows a user's profile. Here's the shape, layer by layer.

The data layer exposes a repository with an honest, source-agnostic interface:

abstract class UserRepository {
  Future<User> getUser(String id);
}

class UserRepositoryImpl implements UserRepository {
  UserRepositoryImpl(this._api, this._cache);
  final UserApi _api;
  final UserCache _cache;

  @override
  Future<User> getUser(String id) async {
    final cached = await _cache.read(id);
    if (cached != null) return cached;

    final user = await _api.fetchUser(id);
    await _cache.write(user);
    return user;
  }
}

Notice that the caching strategy lives here and nowhere else. The screen above will never know it exists — and if you later switch from a read-through cache to stale-while-revalidate, the UI doesn't change at all.

The presentation layer holds a state object that depends on the abstraction, not the implementation:

class ProfileNotifier extends ChangeNotifier {
  ProfileNotifier(this._users);
  final UserRepository _users;

  AsyncValue<User> state = const AsyncLoading();

  Future<void> load(String id) async {
    state = const AsyncLoading();
    notifyListeners();
    try {
      state = AsyncData(await _users.getUser(id));
    } catch (e) {
      state = AsyncError(e);
    }
    notifyListeners();
  }
}

And the widget just renders whatever state it's handed. Loading, error, and success are explicit states — not an afterthought you remember to handle after a crash report.

Choosing a state management approach (without the holy war)

Flutter's state management debate is exhausting because people argue about tools when the real question is about scope. Here's a pragmatic way to decide:

Ephemeral, single-widget state (a checkbox, an expanded/collapsed panel): just use setState. Reaching for a global solution here is over-engineering.
Shared, app-level state (the logged-in user, a shopping cart, feature flags): use a dependency-injected solution — Riverpod, Bloc, or provider with ChangeNotifier. Which one matters far less than using one consistently.

The trap isn't picking the "wrong" library. It's mixing three of them in the same codebase because each feature was built by someone with a different favorite. Pick one, write it in your team's README, and move on.

Organize by feature, not by type

A surprising amount of long-term maintainability comes from how you name folders. The instinct is to group by technical type:

lib/
  widgets/
  models/
  services/
  screens/

This works until you have forty screens, at which point every change to one feature means hopping across four directories. Group by feature instead:

lib/
  features/
    auth/
      data/
      domain/
      presentation/
    profile/
      data/
      domain/
      presentation/
  core/        // shared utilities, theming, networking

Now a feature is a vertical slice you can reason about — or delete — in one place. New developers can find things. And the layer boundaries from earlier show up right there in the folder names, which quietly enforces the discipline.

Where most teams actually go wrong

The failure mode is almost never "we didn't have enough architecture." It's the opposite: a team reads a clean-architecture article, generates eleven files and four abstractions to display a single string, and concludes that architecture is bureaucracy.

Scale your structure to your app. A weekend project doesn't need repositories. A two-screen utility might live happily with setState and a couple of service classes. The three-layer model earns its keep when you have real business logic, multiple data sources, or a team larger than one — and you'll feel the pull toward it naturally as those conditions appear.

The skill isn't applying every pattern. It's recognizing the moment a boundary will save you more than it costs, and drawing it then — one layer before the file gets to 1,400 lines, not one crisis after.