Forem: Cristian Angulo

Microservices Federation (GraphQL, Python and Apollo)

Cristian Angulo — Mon, 23 Mar 2026 18:29:59 +0000

graphql #python #fastapi #docker

When building microservices, one of the hardest challenges is exposing a single, unified API to the client without coupling your services together.

Apollo Federation 2 solves this: each service owns its slice of the graph, and a Gateway composes them into one supergraph — transparently.

This is the architecture we'll be building:

Client
  └─► Gateway :4000
         ├─► User Service    :5001  /graphql
         ├─► Product Service :5002  /graphql
         └─► Order Service   :5003  /graphql
                                        └─► Postgres :5432
                                             ├── users DB
                                             ├── products DB
                                             └── orders DB

The full source code is here: https://github.com/nietzscheson/microservices-federation

Stack

Gateway: Node.js + @apollo/gateway / Apollo Router (Rust)
Services: Python 3.13 + FastAPI + Strawberry GraphQL
ORM: SQLAlchemy 2 + Alembic
DB: PostgreSQL 17
Packages: uv
DI: dependency-injector
Infra: Docker Compose

Database: one Postgres, three databases

We use the same trick from my previous article: a single Postgres container that initializes multiple databases via an entrypoint script.

### docker/postgres/multiple-databases.sh

#!/bin/bash

set -e
set -u

function create_user_and_database() {
    local database=$1
    echo "  Creating user and database '$database'"
    psql -v ON_ERROR_STOP=1 --username "$POSTGRES_USER" <<-EOSQL
        CREATE USER $database;
        CREATE DATABASE $database;
        GRANT ALL PRIVILEGES ON DATABASE $database TO $database;
EOSQL
}

if [ -n "$POSTGRES_MULTIPLE_DATABASES" ]; then
    echo "Multiple database creation requested: $POSTGRES_MULTIPLE_DATABASES"
    for db in $(echo $POSTGRES_MULTIPLE_DATABASES | tr ',' ' '); do
        create_user_and_database $db
    done
    echo "Multiple databases created"
fi

Docker Compose

Each service gets its own DATABASE_URL pointing to its isolated database inside the same Postgres instance. The services share a single multi-stage Dockerfile.

### docker-compose.yaml

services:
  postgres:
    image: postgres:17.4
    container_name: postgres
    ports:
      - "6543:5432"
    environment:
      POSTGRES_PASSWORD: postgres
      POSTGRES_MULTIPLE_DATABASES: users,products,orders
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U postgres"]
      interval: 5s
      timeout: 5s
      retries: 5
    volumes:
      - ./docker/postgres/multiple-databases.sh:/docker-entrypoint-initdb.d/multiple-databases.sh

  user:
    build:
      context: ./services
      dockerfile: ./Dockerfile
      target: user
    environment:
      DATABASE_URL: postgresql://postgres:postgres@postgres:5432/users
    ports:
      - 5001:5000
    depends_on:
      postgres:
        condition: service_healthy

  product:
    build:
      context: ./services
      dockerfile: ./Dockerfile
      target: product
    environment:
      DATABASE_URL: postgresql://postgres:postgres@postgres:5432/products
    ports:
      - 5002:5000
    depends_on:
      postgres:
        condition: service_healthy

  order:
    build:
      context: ./services
      dockerfile: ./Dockerfile
      target: order
    environment:
      DATABASE_URL: postgresql://postgres:postgres@postgres:5432/orders
    ports:
      - 5003:5000
    depends_on:
      postgres:
        condition: service_healthy

  gateway:
    build:
      context: ./gateway
    ports:
      - "4000:4000"
    depends_on:
      user:
        condition: service_healthy
      product:
        condition: service_healthy
      order:
        condition: service_healthy

Multi-stage Dockerfile

All three services share a single Dockerfile using multi-stage builds and uv for fast dependency installation.

### services/Dockerfile

FROM python:3.13 AS base

COPY --from=ghcr.io/astral-sh/uv:latest /uv /uvx /usr/local/bin/

ENV UV_PROJECT_ENVIRONMENT=/opt/venv
ENV PATH="/opt/venv/bin:$PATH"
ENV PYTHONPATH=.

FROM base AS user
WORKDIR /services/user
COPY user/pyproject.toml ./
RUN uv sync --no-install-project
CMD ["uv", "run", "uvicorn", "src.app:app", "--host", "0.0.0.0", "--port", "5000"]

FROM base AS product
WORKDIR /services/product
COPY product/pyproject.toml ./
RUN uv sync --no-install-project
CMD ["uv", "run", "uvicorn", "src.app:app", "--host", "0.0.0.0", "--port", "5000"]

FROM base AS order
WORKDIR /services/order
COPY order/pyproject.toml ./
RUN uv sync --no-install-project
CMD ["uv", "run", "uvicorn", "src.app:app", "--host", "0.0.0.0", "--port", "5000"]

Dependency Injection

Each service uses the same DI pattern: pydantic-settings reads DATABASE_URL from the environment, and dependency-injector wires the SQLAlchemy engine and session as singletons.

### services/order/src/containers.py

from dependency_injector import containers, providers
from sqlalchemy import create_engine
from sqlalchemy.orm import sessionmaker
from src.settings import Settings


class MainContainer(containers.DeclarativeContainer):

    settings = providers.Configuration(pydantic_settings=[Settings()])

    engine = providers.Singleton(
        create_engine,
        settings.database_url,
    )

    session = providers.Singleton(
        sessionmaker,
        bind=engine,
        expire_on_commit=False,
    )

The Federation Pattern

This is the core of the project. Here's how the three services relate to each other without a single Python import between them.

User Service — owns the entity

The User service defines the full UserType with keys=["id"] and implements resolve_reference. The Gateway calls this whenever another service references a UserType by its ID.

### services/user/src/app.py

@strawberry.federation.type(keys=["id"])
class UserType:
    id: strawberry.ID
    name: str

    @classmethod
    def resolve_reference(cls, **representation) -> "UserType":
        with Session() as session:
            user = session.get(User, representation["id"])
            return cls(id=user.id, name=user.name)

Product Service — stubs UserType

The Product service doesn't import anything from the User service. It declares a stub UserType with only id. The Gateway knows it needs to resolve the rest from the User service.

strawberry.Private is the key pattern here: it stores the raw foreign key integer inside the Python object without exposing it to the GraphQL schema.

### services/product/src/app.py

@strawberry.federation.type(keys=["id"])
class UserType:
    id: strawberry.ID = strawberry.federation.field  # stub

    @classmethod
    def resolve_reference(cls, id: strawberry.ID):
        return UserType(id)


@strawberry.federation.type(keys=["id"])
class ProductType:
    id: strawberry.ID
    name: str
    _created_by: strawberry.Private[typing.Optional[int]] = None

    @strawberry.field
    def created_by(self) -> typing.Optional[UserType]:
        if self._created_by is not None:
            return UserType(id=self._created_by)
        return None

Order Service — stubs both

The Order service stubs both UserType and ProductType. An OrderType holds both foreign keys privately and exposes them as federated references.

### services/order/src/app.py

@strawberry.federation.type(keys=["id"])
class UserType:
    id: strawberry.ID = strawberry.federation.field

    @classmethod
    def resolve_reference(cls, id: strawberry.ID):
        return UserType(id)


@strawberry.federation.type(keys=["id"])
class ProductType:
    id: strawberry.ID = strawberry.federation.field

    @classmethod
    def resolve_reference(cls, id: strawberry.ID):
        return ProductType(id)


@strawberry.federation.type(keys=["id"])
class OrderType:
    id: strawberry.ID
    name: str
    _created_by: strawberry.Private[typing.Optional[int]] = None
    _product: strawberry.Private[typing.Optional[int]] = None

    @strawberry.field
    def created_by(self) -> typing.Optional[UserType]:
        if self._created_by is not None:
            return UserType(id=self._created_by)
        return None

    @strawberry.field
    def product(self) -> typing.Optional[ProductType]:
        if self._product is not None:
            return ProductType(id=self._product)
        return None

So a query like this, sent to the Gateway on port 4000:

query {
  orders {
    id
    name
    createdBy {
      name
    }
    product {
      name
    }
  }
}

Is resolved by the Gateway in three steps:

Fetch orders from the Order service → gets createdBy: {id} and product: {id}
Send an _entities lookup to the User service to hydrate the user
Send an _entities lookup to the Product service to hydrate the product

The services are completely decoupled at the code level. The contract is purely a runtime GraphQL protocol.

The Gateway

We ship two gateway implementations.

Apollo Gateway (Node.js)

Simple, no compile step. Introspects each subgraph at startup.

### gateway/server.js

const { ApolloGateway, IntrospectAndCompose } = require("@apollo/gateway");
const { ApolloServer } = require("@apollo/server");

const gateway = new ApolloGateway({
    supergraphSdl: new IntrospectAndCompose({
        subgraphs: [
            { name: "users", url: "http://user:5000/graphql" },
            { name: "products", url: "http://product:5000/graphql" },
            { name: "orders", url: "http://order:5000/graphql" },
        ],
    }),
});

const server = new ApolloServer({ gateway });

Apollo Router (Rust)

The Dockerfile for the gateway uses this approach. It composes a static SDL file using the rover CLI (retrying for 30s while services come up), then starts the high-performance Apollo Router binary.

### gateway/entrypoint.sh

for i in $(seq 1 30); do
    if rover supergraph compose --config /app/supergraph.yaml 2>/dev/null > /tmp/supergraph.graphql \
        && [ -s /tmp/supergraph.graphql ]; then
        cp /tmp/supergraph.graphql /app/supergraph.graphql
        echo "Supergraph composed successfully"
        break
    fi
    echo "Waiting for subgraphs... (attempt $i/30)"
    sleep 3
done

exec router --dev --config /app/router.yaml --supergraph /app/supergraph.graphql --log info

The supergraph.yaml tells rover where to find each subgraph:

### gateway/supergraph.yaml

federation_version: =2.9.0
subgraphs:
  users:
    routing_url: http://user:5000/graphql
    schema:
      subgraph_url: http://user:5000/graphql
  products:
    routing_url: http://product:5000/graphql
    schema:
      subgraph_url: http://product:5000/graphql
  orders:
    routing_url: http://order:5000/graphql
    schema:
      subgraph_url: http://order:5000/graphql

Running it

docker compose up --build

Open the Apollo Router sandbox at http://localhost:4000 and run:

mutation {
  userCreate(name: "Alice") { id name }
}

mutation {
  productCreate(name: "Widget", createdBy: 1) { id name }
}

mutation {
  orderCreate(name: "Order #1", createdBy: 1, product: 1) { id name }
}

query {
  orders {
    id
    name
    createdBy { name }
    product { name }
  }
}

Key Takeaways

resolve_reference is the federation contract — any federated entity must implement it so the Gateway can hydrate it from just an id.
strawberry.Private lets you store raw foreign keys in your Python object without leaking them into the GraphQL schema.
Services are truly decoupled — zero Python imports across service boundaries. The only contract is the GraphQL protocol at runtime.
One Dockerfile, three services — multi-stage builds keep your infra DRY.
uv over pip/poetry — significantly faster installs, especially in Docker layer caching.

Turning block/goose into an AI SRE Agent

Cristian Angulo — Wed, 14 Jan 2026 01:25:02 +0000

In this post, I’ll explain how I configured Goose to behave like a real SRE: querying AWS CloudWatch, reasoning about incidents, and operating inside a fully reproducible Nix environment.

What is block/goose?

block/goose is an autonomous agent framework designed to execute workflows using LLMs plus external tools. Think of it as a CLI-native AI operator that can:

Call tools (APIs, CLIs, MCP servers)
Maintain session context
Execute multi-step reasoning loops

What makes Goose interesting for SRE is that it does not try to replace tools — it orchestrates them.

Why an AI SRE Agent?

A real SRE spends most of their time doing:

Investigations across logs, metrics, and alarms
Repeating the same diagnostic steps
Cross-referencing infra state with recent changes
Reducing operational toil

This repo turns Goose into an agent that can:

Query CloudWatch logs, metrics, and alarms
Reason about AWS infrastructure health
Follow structured incident workflows
Act as a first-response investigator

This is not ChatOps fluff — it’s an operational assistant.

Architecture Overview

The setup has three pillars:

Goose as the reasoning engine
MCP servers as tool providers
Nix Flakes as the environment orchestrator

Goose (LLM Agent)
   ├── CloudWatch MCP Server
   ├── AWS CLI
   ├── GitHub MCP (optional)
   └── Local tooling (jq, httpie, docker, task)

Everything runs inside a reproducible dev shell.

The Reproducible Environment (Nix)

Just like all my other projects, this one is driven by a flake.nix.

Why? Because SRE tooling is fragile:

AWS CLI versions
Node vs Python tooling
MCP servers via uvx or npx

Nix eliminates all of that drift.

Once inside the shell, you already have:

AWS credentials
Goose CLI
CloudWatch tooling
JSON processing tools

No README ritual. No “install this first”.

Configuring Goose as an SRE Agent

The heart of the system is the Goose configuration.

Provider & Model

NIXPKGS_ALLOW_UNFREE=1
GOOGLE_GEMINI_MODEL_NAME=gemini-2.5-flash
GITHUB_PERSONAL_ACCESS_TOKEN=
SENTRY_ACCESS_TOKEN=

Fast, cheap, and good at tool orchestration — perfect for SRE tasks.

CloudWatch as a First-Class Tool

This is where Goose becomes useful.

CloudWatch MCP Extension

GOOSE_PROVIDER: google
GOOSE_MODEL: gemini-2.5-flash
extensions:
  cloudwatch:
    enabled: true
    type: stdio
    name: cloudwatch
    description: AWS CloudWatch Observability (metrics/logs/alarms) via awslabs.cloudwatch-mcp-server
    cmd: uvx
    args:
    - awslabs.cloudwatch-mcp-server@latest
    envs:
      region: us-east-1
      profile: default
      FASTMCP_LOG_LEVEL: ERROR
    env_keys: []
    timeout: 30000
    bundled: null
    available_tools: []
  github:
    enabled: true
    type: stdio
    name: github
    description: GitHub MCP Server
    cmd: npx
    args:
      - -y
      - "@modelcontextprotocol/server-github"
    timeout: 30000
  sentry:
      enabled: true
      type: stdio
      name: sentry
      description: Sentry MCP Server
      cmd: npx
      args:
        - -y
        - mcp-remote@latest
        - https://mcp.sentry.dev/mcp
      timeout: 30000

This gives the agent the ability to:

Fetch metrics
Query logs
Inspect alarms
Reason over time-series data

This is the same data an SRE would manually inspect — just faster.

How Goose Behaves Like an SRE

Instead of prompting Goose with generic questions, I treat it like a teammate.

Examples:

“Investigate elevated 5xx errors in the last 30 minutes.”
“Check if latency correlates with a deploy.”
“Summarize CloudWatch alarms for this service.”

Goose:

Chooses the right tool
Queries CloudWatch
Interprets the output
Produces a human-readable diagnosis

No dashboards. No clicking. Just answers.

Why This Works

1. Tools, Not Plugins

Goose doesn’t hallucinate metrics — it queries real AWS APIs.

2. Reproducibility

Anyone can clone the repo and get the same SRE agent.

3. Composability

You can add:

GitHub MCP (for correlating PRs)
PagerDuty
Terraform state inspection
Custom runbooks

The agent evolves with your infrastructure.

Entering the Environment

nix --extra-experimental-features 'nix-command flakes' develop --impure

Why --impure?

AWS credentials
Docker socket
Local MCP binaries

This is intentional and controlled.

What This Is Not

❌ A replacement for on-call engineers
❌ A magic “fix production” bot
❌ Another ChatOps toy

This is:

A first-response investigator
A context-gathering machine
A force multiplier for SREs

Conclusion

SRE work is pattern-based, repetitive, and highly procedural.

That makes it perfect for AI agents — as long as they:

Use real tools
Run in real environments
Respect operational boundaries

With block/goose, MCP servers, and Nix, you get exactly that.

If you’re curious about AI agents that actually do ops, this is a solid place to start.

Why I Love Using Nix for All My Projects

Cristian Angulo — Sat, 10 Jan 2026 21:18:46 +0000

"It works on my machine" is a phrase that has haunted software development for decades. Whether it's a teammate having a different version of Python, a CI server missing a specific C library, or your global Node.js version conflicting with a legacy project, environment drift is a silent productivity killer.

I resolved this by moving my entire development workflow to Nix Flakes.

Nix guarantees that if a project works today, it will work exactly the same way six months from now, or on a completely different machine, without manual installation steps.

Why Nix?

In modern software development, we don't just write code; we manage a fleet of tools. Nix provides a declarative way to handle:

Isolation: No more polluting your global /usr/local/bin. Every tool stays within the project.
Reproducibility: Every dependency is pinned. If I use Python 3.12.1, everyone on the team uses 3.12.1.
Automation: Using the shellHook, we can automate the startup of services, credential helpers, and environment variables.

The Project Orchestrator: `flake.nix`

I use a flake.nix in every repository. This specific configuration handles a complex stack: Python (managed by uv), AWS (with ECR automation), Docker, and various security tools.

flake.nix

{
  description = "DevShell con Terraform, Docker, Python y ECR login";

  inputs = {
    nixpkgs.url = "github:NixOS/nixpkgs/nixos-unstable";
    flake-utils.url = "github:numtide/flake-utils";
  };

  outputs = { self, nixpkgs, flake-utils }:
    flake-utils.lib.eachDefaultSystem (system:
      let
        pkgs = import nixpkgs { inherit system; };

        pythonEnv = pkgs.python312.withPackages (ps: with ps; [
          pip
        ]);

        commonDeps = with pkgs; [
          pythonEnv
          uv
          git
          terraform
          python312
          awscli
          gcc
          stdenv.cc.cc.lib
          httpie
          go
          go-task
          docker
          amazon-ecr-credential-helper
          jq
          nodejs_20
          nodePackages.lerna
          google-chrome
          subfinder
          amass
          imagemagick
          yarn
        ];
      in {
        devShells.default = pkgs.mkShell {
          packages = commonDeps;

          shellHook = ''
            # 1. Python & uv Setup
            pyenv global system
            export pythonEnv=${pythonEnv}
            export PATH=$PATH:${pythonEnv}/bin

            # Ensure uv uses the Nix-provided Python interpreter
            export UV_PYTHON=${pythonEnv}/bin/python

            # 2. Service Orchestration
            docker compose up --build -d
            docker compose ps -a
            task dependencies

            # 3. AWS & Docker Credential Automation
            mkdir -p ~/.docker
            echo '{
              "credsStore": "ecr-login"
            }' > ~/.docker/config.json
            echo "Docker config set to use docker-credential-ecr-login"
          '';

          LD_LIBRARY_PATH = pkgs.lib.makeLibraryPath [
            pkgs.stdenv.cc.cc.lib
          ];
        };
      });
}

How it works: A Deep Dive

The Declarative Environment Inside commonDeps, I list everything from compilers (gcc) to specialized tools like amazon-ecr-credential-helper. When someone joins the project, they don't need to "install" these manually. Nix handles the fetching and linking into an isolated environment, ensuring that your system remains clean and the project remains portable.

2. The uv Advantage

I use uv because of its incredible speed and its seamless integration with existing Python environments. By setting export UV_PYTHON=${pythonEnv}/bin/python in the shellHook, I tell uv to use the exact Python binary managed by Nix. This ensures total consistency between the package manager and OS-level dependencies.

3. The shellHook Magic

This is where Nix transcends being a simple package manager and becomes a project manager:

Automatic Infrastructure: As soon as I enter the shell, docker compose up runs. My databases and local services are ready before I even type my first line of code.

Automated Config: It writes the ~/.docker/config.json automatically. This allows me to push/pull from AWS ECR without ever having to run manual aws ecr get-login-password steps.

Task Execution: Running task dependencies ensures that any sub-requirements (like npm install or go mod download) are checked and verified as soon as the shell opens.

Entering the Environment

To activate this entire setup, I use the following command:


nix --extra-experimental-features 'nix-command flakes' develop --impure --command zsh

--extra-experimental-features 'nix-command flakes': Enables the modern Nix Flake commands required for this setup.

--impure: This is essential because the shellHook needs to interact with the outside world (your home directory for ~/.docker and the system Docker socket).

--command zsh: Drops me directly into my preferred shell with the entire environment already loaded and ready to go.

Conclusion

Nix has fundamentally transformed how I approach project setups. Instead of a long README.md containing 20 manual installation steps that are prone to failure, I provide a single flake.nix that defines the entire universe for the project.

It is faster, safer, and 100% reproducible. If it works for me, it will work for you.

Multiples Postgres databases in one service with Docker Compose

Cristian Angulo — Tue, 21 Mar 2023 20:36:35 +0000

Sometimes, we need to have multiple database instances to test our projects. Until now, Docker and Docker Compose don't have an easy alternative to resolve this.

Some people (and I) have gotten around this by creating services for each database they need:

### docker-compose.yaml
services:
  postgres_1:
    image: postgres:latest
  postgres_2:
    image: postgres:latest

I resolved this by adding a new entrypoint and setting a environment var in the Docker Compose Service for Postgres:

The container entrypoint:

### entrypoint.sh
#!/bin/bash

set -e
set -u

function create_user_and_database() {
    local database=$1
    echo "  Creating user and database '$database'"
    psql -v ON_ERROR_STOP=1 --username "$POSTGRES_USER" <<-EOSQL
        CREATE USER $database;
        CREATE DATABASE $database;
        GRANT ALL PRIVILEGES ON DATABASE $database TO $database;
EOSQL
}

if [ -n "$POSTGRES_MULTIPLE_DATABASES" ]; then
    echo "Multiple database creation requested: $POSTGRES_MULTIPLE_DATABASES"
    for db in $(echo $POSTGRES_MULTIPLE_DATABASES | tr ',' ' '); do
        create_user_and_database $db
    done
    echo "Multiple databases created"
fi

And the docker-compose service:

### docker-compose.yaml

  postgres:
    image: postgres:alpine
    container_name: postgres
    restart: unless-stopped
    ports:
      - 5432:5432
    environment:
        POSTGRES_PASSWORD: "postgres"
        POSTGRES_MULTIPLE_DATABASES: users, products, orders
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U postgres"]
      interval: 5s
      timeout: 5s
      retries: 5
   volumes:
     - ./<path-of-the-entrypoint>/multiple-databases.sh:/docker-entrypoint-initdb.d/multiple-databases.sh

Forem: Cristian Angulo

Microservices Federation (GraphQL, Python and Apollo)

graphql #python #fastapi #docker

Stack

Database: one Postgres, three databases

Docker Compose

Multi-stage Dockerfile

Dependency Injection

The Federation Pattern

User Service — owns the entity

Product Service — stubs UserType

Order Service — stubs both

The Gateway

Apollo Gateway (Node.js)

Apollo Router (Rust)

Running it

Key Takeaways

Turning block/goose into an AI SRE Agent

What is block/goose?

Why an AI SRE Agent?

Architecture Overview

The Reproducible Environment (Nix)

Configuring Goose as an SRE Agent

Provider & Model

CloudWatch as a First-Class Tool

CloudWatch MCP Extension

How Goose Behaves Like an SRE

Why This Works

1. Tools, Not Plugins

2. Reproducibility

3. Composability

Entering the Environment

What This Is Not

Conclusion

Why I Love Using Nix for All My Projects

Why Nix?

The Project Orchestrator: flake.nix

flake.nix

How it works: A Deep Dive

2. The uv Advantage

3. The shellHook Magic

Entering the Environment

Conclusion

Multiples Postgres databases in one service with Docker Compose

The Project Orchestrator: `flake.nix`