External Publication
Visit Post

I got tired of Apollo Angular bugs and built my own GraphQL client

DEV Community [Unofficial] June 28, 2026
Source

For the past year, I've been building Angular applications that talk to GraphQL backends. And for the past year, I've been fighting Apollo Angular.

Not fighting GraphQL. GraphQL itself is great. But every client available for Angular is either a React port with Angular bolted on, React-only entirely, or so opinionated it forces you to restructure your backend.

So I built my own. It's called DumbQL. This is the story of why, and what I learned.

The Problem with Existing Solutions

Let me be concrete about what I mean by "fighting Apollo Angular."

Apollo Angular: A React Client Wearing Angular Clothes

Apollo Angular is a wrapper around @apollo/client, which is fundamentally a React library. This creates a cascading set of problems:

  • Angular version always lags React. When @apollo/client v4.0 dropped, Apollo Angular stayed stuck on v3 compatibility. Issue #2371 captures this — it sat open for months with a maintainer comment essentially saying "I'll get to it eventually."
  • react is a dependency even in non-React projects. Install Apollo Angular, look at your node_modules — React is there. Always. Because @apollo/client has it as a peer dependency. Issue #8958.
  • Signals? Forget it. Angular 17+ made signals the core reactive primitive. Apollo Angular has no native signals support. You're on your own to bridge the gap.

The Cache Problem

Apollo's normalized cache is powerful. It's also a source of endless pain.

Every type in your schema needs typePolicies. Every mutation needs a manual update or refetchQueries. Forget one, and you have stale UI in production.

// Apollo: you write this for every type, forever
new InMemoryCache({
  typePolicies: {
    User: { keyFields: ['id'] },
    Post: { keyFields: ['id'] },
    Comment: { keyFields: ['id'] },
    // ... and so on
  }
})

And even when you set it up correctly, there are production bugs that have been open for years:

  • #9319 — INVALIDATE in cache.modify silently does nothing. Stale data persists with no refetch.
  • #10289 — cache.evict no-ops inside optimistic UI. Open since 2022.
  • #9735 — Internal results cache merges stale data into readFromStore in production only.

URQL: Doesn't Support Angular

URQL is actually well-architected. The exchange model is clean. But it's React-only. There's no Angular binding and no plans for one.

Relay: Great if Your Backend Speaks Relay

Relay is the most opinionated of the three. It requires your backend to implement the Node interface, the Connection spec for pagination, and a compiler build step. If you're not building a Meta-style architecture from scratch, Relay is off the table.

And it's React-only anyway.

So I Started with HttpClient

I wasn't planning to build a GraphQL client. I was planning to build a frontend.

I started with Angular's built-in HttpClient to make GraphQL requests. It's actually fine for basic usage:

this.http.post<{ data: { getUser: User } }>('/graphql', {
  query: `{ getUser { id name email } }`
}).pipe(map(r => r.data.getUser))

But then I needed caching. Then auth token refresh. Then file uploads. Then I wanted proper TypeScript types for my queries. Then I wanted DevTools to inspect what was happening.

Each one I added myself. And at some point I realized I had a GraphQL client.

What DumbQL Is

DumbQL is a modular GraphQL client suite built Angular-native from day one. The core is built on HttpClient. Everything else is opt-in.

Too dumb to be complex. Too smart to repeat the same mistakes.

The Core Philosophy: Opt-In Everything

@dumbql/core          ~10KB   — the minimum viable GraphQL client
@dumbql/cache         ~3KB    — normalized cache, only if you want it
@dumbql/middlewares   ~3KB    — auth refresh, retry, offline queue
@dumbql/subscriptions ~2KB    — WebSocket via graphql-transport-ws
@dumbql/pagination    ~2KB    — cursor + offset helpers
@dumbql/file-upload   ~1KB    — multipart uploads
@dumbql/ssr           ~1KB    — TransferState for Angular Universal
@dumbql/testing       ~1KB    — mock backend for unit tests
@dumbql/debugging     ~2KB    — operation recording + DevTools
@dumbql/codegen       —       — TypeScript types from your schema
@dumbql/downloader    ~1KB    — schema introspection CLI
@dumbql/fragments     ~1KB    — type-safe fragment utilities
@dumbql/persisted-queries ~1KB — APQ with SHA-256

You don't pay for what you don't use. Every package is sideEffects: false. If you only need @dumbql/core, that's all that's in your bundle.

Setup

// app.config.ts
import { provideDumbql } from '@dumbql/core';
import { provideHttpClient } from '@angular/common/http';

export const appConfig = {
  providers: [
    provideHttpClient(),
    provideDumbql({
      endpoint: 'http://localhost:4000/graphql',
    }),
  ],
};

That's it. No cache configuration. No link chain. No provider tree.

Usage

import { Component, inject } from '@angular/core';
import { GraphqlService, gql } from '@dumbql/core';
import { map } from 'rxjs';

const GET_USER = gql`{ getUser { id name email } }`;

@Component({
  standalone: true,
  template: `<div>{{ (user$ | async)?.name }}</div>`,
})
export class UserComponent {
  private gql = inject(GraphqlService);

  user$ = this.gql.query(GET_USER).pipe(
    map(r => r.status === 'success' ? r.data.getUser : null),
  );
}

The Cache Problem, Solved

The Apollo cache requires typePolicies for every type. DumbQL's cache requires nothing.

// DumbQL: this is the entire cache configuration
provideDumbql({
  endpoint: '/graphql',
  cache: { enabled: true }
})

Under the hood, @dumbql/cache uses __typename + id (or _id) auto-detection to normalize entities. Every response is walked recursively. Entities are extracted and stored keyed by __typename:id. Mutations automatically evict related cache keys.

No cache.modify. No refetchQueries. No stale UI.

If you need advanced behavior, typePolicies are available — but you don't start there.

cache: {
  enabled: true,
  typePolicies: {
    PaginatedResult: { merge: 'append' }, // only when you need it
  }
}

Middlewares: Everything Apollo Needs Third-Party Packages For

Apollo needs external packages for auth refresh, file uploads, persisted queries, and offline support. DumbQL ships all of these as first-party @dumbql/* packages with a unified config.

Auth Token Refresh

provideDumbql({
  endpoint: '/graphql',
  middlewares: {
    authRefresh: {
      enabled: true,
      refreshEndpoint: '/auth/refresh',
      triggerStatuses: [401],
      headerName: 'Authorization',
    }
  }
})

Requests that arrive during a token refresh are queued and replayed automatically.

Offline Queue

provideDumbql({
  endpoint: '/graphql',
  middlewares: {
    offlineQueue: {
      enabled: true,
      maxQueueSize: 50,
      persistQueue: true, // survives page reload
    }
  }
})

Mutations made while offline are queued in localStorage and replayed on reconnect.

Retry with Exponential Backoff

provideDumbql({
  endpoint: '/graphql',
  retryCount: 3,
  retryDelay: 1000, // 1s, 2s, 4s...
})

Angular-Native Features

Signals

DumbQL works with Angular signals out of the box since it's built on HttpClient and RxJS — the same primitives Angular's signal APIs interop with.

Router Integration

// Guarded routes that wait for GraphQL data
export const routes: Routes = [
  {
    path: 'profile',
    ...guardedRoute(GET_USER, {
      redirect: '/login',
      check: r => r.status === 'success' && !!r.data.getCurrentUser,
    }),
    component: ProfileComponent,
  }
];

Angular Pipes

<!-- Extract data or null on error -->
<div>{{ result | graphqlData | json }}</div>

<!-- Extract error string or null on success -->
<div *ngIf="result | graphqlError as err">{{ err }}</div>

ng add Schematics

ng add @dumbql/core

Interactive prompts generate a typed dumbql.config.ts for your project.

Type Safety

DumbQL ships TypedDocumentNode<TResult, TVars> with phantom types, so your query results are fully typed without a build step.

You can also use @dumbql/codegen to generate TypeScript interfaces directly from your GraphQL schema:

npm run schema:download  # introspection → schema.json + schema.graphql
npm run codegen          # schema → TypeScript interfaces



// graphql/types/index.ts (generated)
export interface User { id: string; username: string; email: string; }
export interface Query { getCurrentUser: User; getUsers: User[]; }

Error Handling

Apollo's errorPolicy has a type-narrowing problem — data can be undefined even on success. DumbQL uses a discriminated union:

service.query<{ user: User }>(GET_USER).subscribe(result => {
  if (result.status === 'success') {
    // result.data is User — fully typed, never undefined
    console.log(result.data.user);
  } else {
    // result.error is string
    console.error(result.error);
  }
});

Helper functions available: isSuccess, isError, unwrap, unwrapOrThrow, mapResult.

DevTools

DumbQL ships a browser extension for Chrome and Firefox. It connects to devtoolsMiddleware and shows:

  • Real-time request log with timing

  • Schema visualization (SDL tree)

  • Field tree inspector per query

  • Entity cache browser

  • Mutation timing charts

    provideDumbql({ endpoint: '/graphql', devtools: { autoConnect: true, maxRequests: 500 } })

Testing

import { MockGraphqlService, provideDumbqlTesting } from '@dumbql/testing';

TestBed.configureTestingModule({
  providers: [
    provideHttpClientTesting(),
    provideDumbqlTesting(),
  ],
});

const mock = TestBed.inject(MockGraphqlService);
mock.when(GET_USER, {
  status: 'success',
  data: { user: { id: '1', name: 'Test' } }
});

Simple when(query, result) API. FIFO queue. Optional simulated network delay.

Bugs Fixed from Other Clients

These are real GitHub issues that DumbQL addresses by design:

Project Issue Problem
Apollo #9319 INVALIDATE silently no-ops — stale data persists
Apollo #10289 cache.evict no-ops inside optimistic UI (open since 2022)
Apollo #11804 Skipped query ignores clearStore() — returns outdated data
Apollo #9735 Production-only: internal cache merges stale data
Apollo #8958 react required as dependency in non-React projects
Apollo Angular #2371 Angular version lags React — incompatible with @apollo/client v4
URQL #2414 relayPagination shows stale data when non-relay params change
URQL #668 Query doesn't refetch when variables change
URQL #3877 Pages concatenate in write order — flickering mis-ordered items
Relay #3406 React-only — no Angular, Vue, or Svelte support
Relay #183 Forces Node interface + Connection spec on your backend

What's Next

DumbQL started Angular-native. But the core is framework-agnostic — @dumbql/core has zero framework dependencies.

React and Vue bindings are in progress. The plan is the same opt-in model: @dumbql/react and @dumbql/vue as thin adapter layers over the same middleware pipeline and cache.

The goal isn't to replace Apollo everywhere. The goal is to give Angular developers a first-class GraphQL client that wasn't designed for a different framework first.

Try It

npm install @dumbql/core

Or with schematics:

ng add @dumbql/core

GitHub: https://github.com/DumbGQL/dumbql

Full comparison table, architecture diagram, and configuration reference in the README.

DumbQL is MIT licensed and actively developed. Issues and PRs welcome.

Discussion in the ATmosphere

Loading comments...