Serve a second backend

provideAtomicClient() alone is enough at the application root, where the root singletons already resolve to the right client. A route or component subtree that targets another backend needs more: its own client and its own copy of everything that holds per-backend state. provideAtomicScope() provides both.

Minimal example

import { Routes } from "@angular/router";
import { provideAtomicScope } from "@sinequa/atomic-angular";

export const routes: Routes = [
  // The application root — first backend, provided at the application config level.
  { path: "research", loadComponent: () => import("./research/page") },

  // A branch served by a second backend, fully isolated.
  {
    path: "support",
    providers: [
      provideAtomicScope({
        app: "support",
        backendUrl: "https://support.example.com",
        storagePrefix: "support:",
      }),
    ],
    loadComponent: () => import("./support/page"),
  },
];

Inside the support branch, inject(AppStore), inject(QueryService), injectAtomicClient() — everything resolves to that scope's own instances, talking to the second backend with its own session. Outside it, nothing changes.

How it works

ATOMIC_SCOPED_PROVIDERS re-creates seven stores and thirteen services alongside the client — every one of them is providedIn: "root", so a store left at the root would keep the root client and silently read and write the first backend from inside the second backend's subtree.

ThemeStore is deliberately absent from that list: the theme is a user-interface preference, not backend state, and both scopes should keep sharing it.

Recipes

Two backends side by side

Two backends on the same screen is a component-tree question, not a routing one — provideAtomicScope() also works in a component's providers.

import { Component } from "@angular/core";
import { provideAtomicScope } from "@sinequa/atomic-angular";

@Component({
  selector: "support-panel",
  providers: [provideAtomicScope({ app: "support", backendUrl: "https://support.example.com", storagePrefix: "support:" })],
  template: `<results />`,
})
export class SupportPanelComponent {}

Each panel then runs its own search, with its own stores, against its own backend. Two instances of the same component cannot be configured differently, though — Angular resolves providers per component type, before any input() exists. Write one thin wrapper per backend, each with its own literal configuration, both delegating to a shared presentational component.

Composing the provider list yourself

ATOMIC_SCOPED_PROVIDERS is exported, for an application that wants to add its own scoped service alongside the library's.

providers: [provideAtomicClient(config), ...ATOMIC_SCOPED_PROVIDERS, MyOwnScopedService]

Options

Pitfalls

What's next