[phryneas]

Isn't that equal to just returning `{ typename: "MyTypeName", id: 123 }` from a resolver and then `graphql-js` just running the field resolvers on the `MyTypeName` type as needed?

Or is this doing more?

[matutetandil]

You're right that the core idea is the same — field resolvers in graphql-js already give you lazy resolution per field. LazyQL doesn't reinvent that mechanism; it sits on top of it.

The difference is developer experience:

With plain field resolvers, you'd write something like:

  // Scattered across your resolver map
  MyTypeName: {
    status: (parent) => db.getOrderStatus(parent.id),
    customer_email: (parent) => db.getCustomerEmail(parent.id),
    shipping_address: (parent) => db.getShippingAddress(parent.id),
    // ...15 more fields
  }

  With LazyQL, everything lives in a single class with shared state:

  @LazyQL(OrderDTO)
  class Order {
    constructor(private id: number, private db: Database) {}

    getStatus() { return this.db.getOrderStatus(this.id); }

    getGrandTotal() {
      return this.getOrderDetails().grand_total;
    }

    getCurrencyCode() {
      return this.getOrderDetails().currency_code;
    }

    @Shared()
    getOrderDetails() {
      // Called by two getters, but executes only once
      return this.db.getFullOrder(this.id);
    }
  }

The main wins: @Shared() caching across getters, startup validation (missing a getter = immediate error, not a silent null at runtime), and keeping all the logic for a type in one place instead of scattered field resolvers.

So it's not doing something fundamentally different — it's a pattern for organizing it better.