Apollo Angular: a GraphQL client that fits into an existing Angular app

What the client actually is

Apollo Angular is described as a fully-featured, production ready caching GraphQL client for Angular and every GraphQL server, and the README explains its purpose plainly: it allows you to fetch data from your GraphQL server and use it in building complex and reactive UIs using the Angular framework.

The scope note is worth reading carefully. Apollo Angular may be used in any context that Angular may be used: in the browser, in NativeScript, or in Node.js when you want to do server-side rendering. That is a real constraint, because the client is built on Angular's dependency injection and its reactive primitives, so it inherits Angular's platform assumptions rather than being a standalone GraphQL library with an Angular skin.

The seven characteristics the README lists are the sales pitch, and the ones with substance are incrementality and size. It is incrementally adoptable, so you can drop it into an existing JavaScript app and start using GraphQL for just part of your UI. It is universally compatible, working with any build setup, any GraphQL server, and any GraphQL schema. It is small and flexible, so you do not get stuff you do not need, with the core under 12 kB compressed. And it is built for interactive apps, so your users can make changes and see them reflected in the UI immediately.

The project is MIT licensed, written in TypeScript, the home page is apollo-angular.com, and the last push to the repository was on 2026-09-11. The releases are [email protected] from 2026-08-11, 14.1.0 from 2026-06-09, and 14.0.0 from 2026-05-13, so the major version moves with Angular's.

Installation, and the version mapping you have to respect

The install is either the Angular CLI schematic or three packages added by hand:

# installing Apollo Angular in Angular CLI
ng add apollo-angular

# installing each piece independently
pnpm add @apollo/client apollo-angular graphql

The README emphasises that Apollo Angular requires no complex build setup to get up and running, and that as long as you have a GraphQL server you can get started with Angular immediately. It works out of the box with the Angular CLI and with NativeScript with a single install.

There is also a version mapping that will save you an afternoon if you are porting an older app. If you are using Apollo Client v3, make sure to use apollo-angular@v3, and if you are using Apollo Client v2, use apollo-angular@v1, and for Angular 10 support, v1.10.0. The reason is structural: the client major version and the Angular package major version are not independent, because the client API changed underneath and the Angular wrapper had to follow.

The optional piece is the Apollo Client Developer tools for Chrome, which give you inspectability into your Apollo Angular data. The README lists inspectability as one of the seven characteristics, and the developer tools are how that is delivered in practice, since they show the queries, the cache contents, and the mutations as they happen.

The query pattern, and why it reads the way it does

The usage example is a single component with a GraphQL document, and it shows the shape of the whole API.

import { Apollo, gql } from 'apollo-angular';
import { map, Observable } from 'rxjs';
import { AsyncPipe } from '@angular/common';
import { Component, OnInit } from '@angular/core';

const GET_DOGS = gql`
  {
    dogs {
      id
      breed
    }
  }
`;

@Component({
  selector: 'dogs',
  template: `
    <ul>
      @for (dog of dogs | async; track dog.id) {
        <li>
          {{ dog.breed }}
        </li>
      }
    </ul>
  `,
})
export class DogsComponent implements OnInit {
  public dogs!: Observable<any>;

  constructor(private readonly apollo: Apollo) {}

  ngOnInit() {
    this.dogs = this.apollo
      .watchQuery({
        query: GET_DOGS,
      })
      .valueChanges.pipe(map(result => result.data && result.data.dogs));
  }
}

Three things in that code are the design.

The Apollo service is injected through the constructor, so the client is a dependency rather than a global, and it is a per-application instance rather than per-request, which is what lets the cache live across the app.

The query is a watchQuery, not a query, and that single word choice is the difference between a GraphQL client that fetches once and one that stays subscribed. A watchQuery keeps the request open and pushes new results as the server's view changes, which is what makes the UI reflect a change the moment it happens elsewhere.

The result is an Observable, and the template consumes it with the async pipe and the new control flow syntax. There is no subscribe call, no manual unsubscribe in ngOnDestroy, and no state to keep in a component field. The observable is the component's state, and the async pipe handles the subscription lifecycle. That is the whole integration story: Angular's reactivity meets GraphQL's subscription model, and the bridging is a pipe rather than a subscription management problem.

The map at the end narrows the result to the data field, and the expression guards against data being undefined, which matters because a GraphQL response can carry errors alongside partial data.

The monorepo, and the changesets release flow

The repository is a pnpm workspace named apollo-angular-monorepo, and the root manifest describes the release machinery.

The build script fans out with pnpm run --recursive build, and the deploy script does the same for deploy. There is a prebuild step that removes the build directories under packages with rimraf, and a prerelease script that runs the build first. The release script is changeset publish, and the dev dependencies include both the changesets CLI and a GitHub changelog plugin, which is what generates the release notes from the changeset files in the .changeset/ directory.

Changesets rather than a conventional bump-and-commit flow is a deliberate choice for a monorepo. Each package in packages/ can be versioned independently, and a contributor adds a changeset file describing the change rather than editing a version number, and the release tooling computes the bumps and the changelog entries from those files. For a library that has to track Angular's release cadence, being able to publish a patch to one package without touching the others is worth the extra file.

The rest of the tooling is a standard Guild setup. Prettier comes from @theguild/prettier-config, lint-staged with husky runs prettier over the TypeScript sources in packages, and the test script fans out with pnpm run --recursive test. There are two integration test entry points beyond the unit tests: ci-only:integration runs a script for integration tests, and test:e2e runs a shell script for end-to-end tests locally.

The dev dependencies also pin the Angular CLI at 20.3.0, and the repository has a .nvmrc for the Node version, a renovate.json for dependency updates, a website/ directory for the documentation site, and a scripts/ directory holding the integration and end-to-end runners.

Where the documentation and the community live

The documentation is entirely on the website rather than in the repository, and the README is explicit about it: all the documentation for Apollo Angular including usage articles and helpful recipes lives on apollo-angular.com.

The article to start with is the one on queries, linked from the usage section, and the README's advice is to begin reading there rather than to work through the API surface. That is a reasonable instruction for a client whose surface is mostly a thin reactive layer over @apollo/client, since the part worth understanding is the query model rather than the wrapper.

The contributing section points at the Apollo Contributor Guidelines, and the project says it uses Lerna for bootstrapping, with a pnpm install for that step, pnpm test to run the tests locally, and pnpm prettier to format the code with prettier. It also notes that the project uses TypeScript for static typing and that you can get it built into your editor with no configuration by opening the project in Visual Studio Code.

The description in the repository metadata calls the client a fully-featured, production ready caching GraphQL client for Angular and every GraphQL server, and the topics list apollographql, apollo-client, graphql-client, the-guild, angular, and typescript. The The Guild organisation is the group behind most of the GraphQL tooling ecosystem, and the shared prettier config, the changeset setup, and the Discord and X handle conventions in the README are all consistent with that.

One small thing worth noting for anyone tracking the project: the README still carries a Lerna bootstrapping instruction while the root manifest is a pnpm workspace with a pnpm packageManager pin at 12.3.4. The instructions and the tooling are not fully in step, which is a small reminder to read the package manifest rather than the README when you are setting up a fork.

Editorial conclusion

Adopt Apollo Angular if your team already works in Angular and wants GraphQL with a normalised cache and reactive queries without hand-wiring the client. Do not adopt it if your app is not Angular, since the whole API surface is Angular-shaped. Verify first which major version of @apollo/client you are on, because the README maps the v2 and v3 client lines to different major versions of apollo-angular.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. the-guild-org/apollo-angular on GitHub