Wiring Database and Service Data Sources

Keep SQL Out of the Resolver Map

A resolver map that embeds queries works at ten fields and collapses at fifty:

const resolvers = {
  Query: {
    posts: async (_p, { first }, ctx) => {
      const { rows } = await ctx.pool.query(
        'SELECT id, title, author_id FROM posts WHERE published_at IS NOT NULL ORDER BY id LIMIT $1',
        [first]);
      return rows;
    },
  },
};

SQL now lives in the schema module, row mapping is hand-written per field, and testing a query means standing up GraphQL first. Extract the knowledge into an object:

class PostDataSource {
  constructor(pool) { this.pool = pool; }

  async published(limit) {
    const { rows } = await this.pool.query(
      'SELECT id, title, author_id FROM posts WHERE published_at IS NOT NULL ORDER BY id LIMIT $1',
      [limit]);
    return rows.map(toPost);   // one mapping convention, in one place
  }
}

const resolvers = {
  Query: {
    posts: (_p, { first }, ctx) => ctx.dataSources.posts.published(first),
  },
};

The resolver now reads like the business rule — published posts, take the first N — while the data source owns SQL, row mapping, and query choice. Testing splits along the same line: data sources get integration tests against a real database, resolvers get unit tests with a stub returning fixtures.

Draw class boundaries by aggregate or service (posts, orders, users), not one class per field. If background jobs need the same queries, they depend on the same data source; a second copy of the SQL in a job script is how the two implementations drift apart.

Where the pool itself comes from is a context question, not a schema question — see resolver context for how repositories reach the resolvers that call them.

One Pool for the Process

Postgres typically allows around 100 concurrent connections. The tempting mistake — opening a new connection inside every resolver call — exhausts that budget within seconds under load, and the failure arrives as a "too many connections" page at the worst possible time.

// db.js — one pool per process, created at startup
const pool = new Pool({
  max: 10,                    // leave headroom for migrations, psql, dashboards
  idleTimeoutMillis: 30000,   // return idle sockets instead of pinning them
  connectionTimeoutMillis: 2000,  // fail fast instead of queueing forever
});

Resolvers borrow from the pool through the data source they were handed. The rule: one pool per process, shared by every request — pooling is how N concurrent GraphQL executions fit inside a fixed database budget, and per-request pools multiply that budget by your traffic.

Transactions are the one place a resolver needs a dedicated connection:

async transfer(from, to, amountCents) {
  const client = await this.pool.connect();
  try {
    await client.query('BEGIN');
    await client.query('UPDATE accounts SET balance = balance - $1 WHERE id = $2', [amountCents, from]);
    await client.query('UPDATE accounts SET balance = balance + $1 WHERE id = $2', [amountCents, to]);
    await client.query('COMMIT');
  } catch (err) {
    await client.query('ROLLBACK');
    throw err;              // the executor turns this into a field error
  } finally {
    client.release();       // never leak — the pool budget depends on it
  }
}

Four details that decide whether the pool survives contact with production:

1. Release in finally. A leaked client shrinks the pool one slot at a time until every query times out.
2. Roll back before releasing. Releasing an open transaction leaves the next borrower in a transaction it did not start.
3. No network calls inside a transaction. Calling a payment API while holding a connection pins it for the duration of someone else's latency; send the charge after commit or make the flow idempotent and retryable.
4. Watch sibling fan-out. Resolver siblings execute concurrently (see async resolver patterns), so a query with twenty parallel fields temporarily wants twenty checkouts — size max for that peak, not the average.

Downstream Services Need a Wrapper

When a resolver calls fetch() directly, every concern lands in the resolver: timeout, retries, auth headers, trace propagation, and error mapping. Put them behind one wrapper so resolvers see a method with a name:

class PricingClient {
  constructor(baseUrl, opts = {}) {
    this.baseUrl = baseUrl;
    this.timeoutMs = opts.timeoutMs || 1500;
    this.fetchImpl = opts.fetchImpl || fetch;
  }

  async quote(sku, requestId) {
    const res = await this.fetchImpl(this.baseUrl + '/quote?sku=' + encodeURIComponent(sku), {
      signal: AbortSignal.timeout(this.timeoutMs),   // bound every call
      headers: { 'x-request-id': requestId },        // one trace across services
    });
    if (!res.ok) throw new DownstreamError('pricing', res.status);
    return res.json();
  }
}

What the wrapper standardizes:

• A timeout on every call. Without one, a slow dependency turns into an unbounded resolver and a request that hangs while its siblings already finished.
• Retries only where they are safe. Retry idempotent reads with backoff; never blindly retry a request that charges a card. The idempotency key from serial execution travels through this wrapper on exactly those calls.
• Error mapping. Downstream failures become typed errors, which resolver error propagation converts into errors[] entries carrying an extensions.code a client can branch on — instead of connect ECONNREFUSED 10.4.2.9:8080 reaching consumers.
• Trace headers. Forward the request id created in the context factory so a slow quote is one log search away. See resolver context for where that id comes from.

Wiring stays in one place: construct wrappers in the context factory and expose them as ctx.dataSources.pricing. A wrapper holding no request state may be a process singleton instead — the test is whether it stores anything derived from a caller.

The acceptance check for the whole design: search the schema and resolver directory for SQL keywords and raw fetch( calls, and find nothing. Schema and resolvers describe what data is needed; data sources alone know how.