@powerhousedao/academy 3.3.0-dev.0 → 3.3.0-dev.2

package/CHANGELOG.md

@@ -1,3 +1,17 @@
+## 3.3.0-dev.2 (2025-07-05)
+
+### 🩹 Fixes
+
+- **academy:** graphql at powerhouse update ([fea4eae24](https://github.com/powerhouse-inc/powerhouse/commit/fea4eae24))
+
+### ❤️ Thank You
+
+- Callme-T
+
+## 3.3.0-dev.1 (2025-07-04)
+
+This was a version bump only for @powerhousedao/academy to align it with other projects, there were no code changes.
+
 ## 3.3.0-dev.0 (2025-07-02)
 
 ### 🚀 Features

package/docs/academy/01-GetStarted/home.mdx

@@ -98,7 +98,7 @@ import BrowserOnly from '@docusaurus/BrowserOnly';
       </h3>
     </div>
     <div className={styles.cardContent}>
-      <a href="/academy/MasteryTrack/WorkWithData/ReadingAndWritingThroughTheAPI" className="path-button">Read & write through the API</a>
+      <a href="/academy/MasteryTrack/WorkWithData/UsingTheAPI" className="path-button">Read & write through the API</a>
       <a href="/academy/MasteryTrack/WorkWithData/WorkingWithSubgraphs" className="path-button">Create your own subgraph</a>
       <a href="/academy/MasteryTrack/WorkWithData/Analytics-Engine/intro" className="path-button">Use the analytics engine</a>
     </div>

package/docs/academy/02-MasteryTrack/03-BuildingUserExperiences/02-ConfiguringDrives.md

@@ -66,7 +66,7 @@ You can also add a new remote drive to your Connect environment programmatically
   `bash
   ph reactor
   `
-- The GraphQL endpoint of your instance. For example, for the staging environment, use: `https://staging.switchboard.phd/graphql/system` (this is a supergraph gateway. Read more about [subgraphs and supergraphs here](/academy/MasteryTrack/WorkWithData/WorkingWithSubgraphs).
+- The GraphQL endpoint of your instance. For example, for the staging environment, use: `https://staging.switchboard.phd/graphql/system` (this is a supergraph gateway. Read more about [subgraphs and supergraphs here](/academy/MasteryTrack/WorkWithData/UsingSubgraphs).
 - Appropriate permissions to perform mutations.
 :::
 
@@ -143,6 +143,6 @@ This approach allows you to automate drive creation and integration with other s
 You've now experienced the use of GraphQL to modify or read data captured in Powerhouse for the first time. 
 You can now either continue with:
 - User interfaces and [build a custom drive experiences](/academy/MasteryTrack/BuildingUserExperiences/BuildingADriveExplorer) 
-- Keep playing with data and the [Switchboard API](/academy/MasteryTrack/WorkWithData/ReadingAndWritingThroughTheAPI)
+- Keep playing with data and the [Switchboard API](/academy/MasteryTrack/WorkWithData/UsingTheAPI)
 
 Enjoy!

package/docs/academy/02-MasteryTrack/04-WorkWithData/{02-GraphQLAtPowerhouse.md → 01-GraphQLAtPowerhouse.md}

@@ -1,9 +1,10 @@
 # GraphQL at Powerhouse
 
-In this section, we will cover **the core concepts of GraphQL with examples applied to the Powerhouse ecosystem**. More specifically, GraphQL is used as:
-- The **schema definition language (SDL)** for defining our document models and thereby self-documenting the API to the data model. It allows developers to define the structure and relationships of data in a strongly-typed format.
-- As the **query language in subgraphs**, which allow different services to expose and query structured data dynamically. Jump to the section [GraphQL and Subgraphs](/academy/MasteryTrack/WorkWithData/WorkingWithSubgraphs/GraphQLAndSubgraphs) to learn more about this.
+In this section, we will cover **the core concepts of GraphQL with examples applied to the Powerhouse ecosystem**. GraphQL plays a fundamental role in defining document model data schemas, handling data access patterns, and enabling event-driven workflows within the Powerhouse ecosystem.
 
+More specifically, GraphQL is used as:
+- The **schema definition language (SDL)** for defining our document models and thereby self-documenting the API to the data model. It allows developers to define the structure and relationships of data in a strongly-typed format.
+- As the **query language in subgraphs**, which allow different services to expose and query structured data dynamically.
 
 ### Why GraphQL?
 
@@ -152,5 +153,132 @@ When dealing with lists of data, GraphQL employs a pattern that includes:
     ```
 
 ---
+
+## GraphQL Subgraphs in Powerhouse
+
+Powerhouse structures its data into **subgraphs**, which are modular GraphQL services that connect to the Reactor (Powerhouse's core data infrastructure) or Operational Data Stores fueled by data from processors. Each subgraph has its own SDL, ensuring modularity and flexibility while working within the ecosystem.
+
+### Fetching data from the Reactor
+
+Powerhouse uses GraphQL to expose system-level data, such as drives, users, and operational records through the **System Subgraph**, which allows querying of drives, stored files and folders.
+
+### Operational data stores
+
+Custom subgraphs can be created to store and retrieve operational data in real time. For example, a subgraph can track file uploads and expose this data via GraphQL queries:
+
+```graphql title="File Schema Example"
+type File {
+  id: ID!
+  name: String!
+  size: Int!
+  createdAt: DateTime!
+}
+
+type Query {
+  getFile(id: ID!): File
+}
+```
+
+This schema ensures that every File entity has an ID, name, size, and timestamp, providing a structured approach to file management data.
+
+---
+
+## CQRS Architecture with GraphQL
+
+Powerhouse uses **CQRS (Command Query Responsibility Segregation)** to separate write operations (commands) from read operations (queries). This improves system scalability and flexibility:
+
+- **GraphQL Queries** handle read operations, retrieving structured data efficiently
+- **GraphQL Mutations** handle write operations, modifying the state in a controlled manner
+
+Powerhouse's subgraphs act as the read layer, while processors handle write operations into operational data stores. This prevents conflicts between querying and modifying data.
+
+| Layer | Role | GraphQL Usage | Implementation |
+| --- | --- | --- | --- |
+| Write Model (Commands) | Handles state changes (adding, modifying, deleting) | GraphQL Mutations | Processor |
+| Read Model (Queries) | Optimized for fetching/reading/retrieving data | GraphQL Queries | Subgraph |
+
+### Read and write separation  
+
+**Read Model (Query)**  
+- Optimized for data retrieval
+- Structured using GraphQL Queries
+- Aggregates and exposes data via a subgraph
+- Pulls data from Operational Data Stores, Analytics Stores, and Reactor
+- Subgraphs do not directly modify the data—they only expose pre-processed information
+
+```graphql title="Example Query Operation"
+query {
+  getFile(id: "123") {
+    name
+    size
+    createdAt
+  }
+}
+```
+
+**Write Model (Mutation)** 
+- Handles state changes (adding, modifying, deleting)
+- Structured using GraphQL Mutations
+- Writes data to Operational Data Stores
+
+```graphql title="Example Mutation Operation"
+mutation {
+  createFile(name: "document.pdf", size: 1024) {
+    id
+    name
+    createdAt
+  }
+}
+```
+
+---
+
+## GraphQL and Event-Driven Architecture
+
+Event-Driven Architecture (EDA) enables asynchronous processing where events trigger actions. Powerhouse uses GraphQL to expose real-time event data from its Reactor and Operational Data Stores.
+
+### How GraphQL fits into EDA
+
+- **Real-Time Data Exposure** – Subgraphs fetch event-based data updates
+- **Event Subscription Mechanism** – Powerhouse is working towards integrating GraphQL Subscriptions for real-time updates
+- **Efficient Decoupling** – Events are stored in an operational datastore, and GraphQL queries retrieve structured results
+
+### Example: Powerhouse's event flow
+
+1. Processor detects an event (e.g., file upload)
+2. Writes event data to the Operational Data Store
+3. Subgraph exposes the updated data via GraphQL
+
+---
+
+## GraphQL Subscriptions
+
+Although Powerhouse currently uses queries and mutations, **GraphQL Subscriptions** could allow real-time streaming of event-based data in future implementations:
+
+```graphql title="Example Future Subscription"
+subscription {
+  fileUploaded {
+    id
+    name
+    size
+    createdAt
+  }
+}
+```
+
+This would enable clients to listen for new file uploads without polling, providing a more efficient real-time experience.
+
+---
+
 ## Summary
-GraphQL offers a streamlined and efficient approach to data retrieval, particularly useful when you need granular control over your API interactions. By defining a robust schema, using precise fields and arguments, and leveraging introspection, GraphQL minimizes unnecessary data transfers. If you want to learn more about GraphQL, there is the following link to the official documentation: [Introduction to GraphQL](https://graphql.org/learn/).
+
+GraphQL offers a streamlined and efficient approach to data retrieval, particularly useful when you need granular control over your API interactions. In the Powerhouse ecosystem, GraphQL serves multiple critical functions:
+
+- **Schema Definition**: Defines document models and self-documents APIs
+- **Subgraph Architecture**: Enables modular, scalable data services
+- **CQRS Implementation**: Separates read and write operations for better performance
+- **Event-Driven Integration**: Supports real-time data exposure and future subscription capabilities
+
+By defining robust schemas, using precise fields and arguments, leveraging introspection, and implementing subgraphs with CQRS principles, GraphQL minimizes unnecessary data transfers while maximizing flexibility and scalability in the Powerhouse platform.
+
+For more information about GraphQL fundamentals, visit the [Introduction to GraphQL](https://graphql.org/learn/) documentation.

package/docs/academy/02-MasteryTrack/04-WorkWithData/{01-ReadingAndWritingThroughTheAPI.mdx → 02-UsingTheAPI.mdx}

@@ -1,9 +1,10 @@
-# Read and write through the API
+# Using the API
 
 ## Introduction to Switchboard
 
-**Switchboard** is the API interface that allows developers and data engineers to get access to data collected through document models in Connect and Fusion.
-After structurally capturing the desired data from your formalized business processes, it can be used to build insightful experiences in external websites, drive widgets, or create specific reports and dashboards in Fusion.
+**Switchboard** is the API interface that enables developers and data engineers to access data captured through document models in Connect and Fusion.
+
+Once you've structured and captured data from your business processes, Switchboard allows you to leverage that data to build insightful experiences in external websites, create interactive drive widgets, or generate detailed reports and dashboards in Fusion.
 
 :::tip Using your document's state schema
 Since your document models are defined with a GraphQL schema, you can use the same objects and fields in your queries and mutations to retrieve or write data from and to your documents.
@@ -39,10 +40,10 @@ This will return a URL to access the Reactor.
 
 ### Adding a remote drive or Reactor to Connect
 
-If the remote drive or Reactor isn't present yet in Connect, you can add it by clicking the (+) button in the Connect drive navigation and using the localhost URL to add a new drive with its underlying reactor. Usually, this is http://localhost:4001/d/powerhouse.
+If the remote drive or Reactor isn't present yet in Connect, you can add it by clicking the (+) 'Create New Drive' button in the Connect drive navigation and using the localhost URL to add a new drive with its underlying reactor. Usually, this is http://localhost:4001/d/powerhouse.
 
 Get access to an **organization's drive** instances by adding their drive to your Connect Drive navigation tree view with the help of the correct drive URL.
-Click the (+) to add a public drive. To add a new drive, you'll have to know the correct public URL of the drive. Read more about [configuring drives](/academy/Architecture/WorkingWithTheReactor).
+Click the (+) 'Create New Drive' to add a public drive. To add a new drive, you'll have to know the correct public URL of the drive. Read more about [configuring drives](/academy/Architecture/WorkingWithTheReactor).
 
 <figure className="image-container">
   <img src={require("./images/AddNewDriveURL.png").default} alt="Add a drive through an URL" />
@@ -92,7 +93,7 @@ Copy this ID to use it in the Switchboard API.
   <figcaption>You can copy your Document ID from your operations history.</figcaption>
 </figure>
 
-When you navigate to your Switchboard endpoint (e.g., http://localhost:4001/graphql/system, https://switchboard.phd/graphql/system, or a custom domain), you can use this document ID to query the state of your document.
+When you navigate to your Switchboard endpoint by adding **`/graphql/system`** to the end of your URL. (e.g., http://localhost:4001/graphql/system, https://switchboard.phd/graphql/system, or add it to a custom domain), you can use this document ID to query the state of your document.
 The documentation on the left-hand side of the Apollo Sandbox will show you all the different fields that are available to query.
 
 <figure className="image-container">
@@ -128,7 +129,7 @@ It extracts common metadata fields such as **id**, **name**, **documentType**, *
 
 ### Get the state of the document
 
-Once you've found your document via any of the three options, you'll be able to query its state.
+Once you've found your document via any of the three options above, you'll be able to query its state.
 
 In the previous step, we queried for document metadata. Now let's query for the actual content of the document state.
 
@@ -230,4 +231,7 @@ After performing a write mutation, you can verify that the change was successful
 1.  **Query the document state again:** Rerun the `getDocument` query from earlier in this tutorial. You should see the new item in the list or the deleted item removed.
 2.  **Check the Operation History:** The operation history in Connect will show the new `ADD_TODO_ITEM` or `DELETE_TODO_ITEM` operation, along with who performed it and when. This provides a complete audit trail of all changes to the document.
 
+
+### Summary
+
 This ability to programmatically read from and write to documents via the GraphQL API is a powerful feature of Powerhouse. It unlocks countless possibilities for integrating your structured data into other applications, building automated workflows, and creating rich, data-driven user experiences.

package/docs/academy/02-MasteryTrack/04-WorkWithData/03-UsingSubgraphs.md

@@ -0,0 +1,649 @@
+# Using Subgraphs
+
+This tutorial will demonstrate how to create and customize a subgraph using our To-do List project as an example.
+Let's start with the basics and gradually add more complex features and functionality.
+
+## What is a subgraph?
+
+A subgraph in Powerhouse is a **GraphQL-based modular data component** that extends the functionality of your document models. While document models handle the core state and operations, subgraphs can:
+1. Connect to external APIs or databases
+2. Add custom queries and mutations
+3. Automate interactions between different document models
+4. Provide additional backend functionality
+
+### Subgraphs can retrieve data from
+
+- **The Reactor** – The core Powerhouse data system or network node.   
+- **Operational Data Stores** – Structured data storage for operational processes, offering real-time updates, for querying structured data.  
+- **Analytics Stores** – Aggregated historical data, useful for insights, reporting and business intelligence.
+
+### Subgraphs consist of
+
+- **A schema** – Which defines the GraphQL Queries and Mutations.
+- **Resolvers** – Which handle data fetching and logic.
+- **Context Fields** – Additional metadata that helps in resolving data efficiently.
+
+#### Additionally, context fields allow resolvers to access extra information, such as:
+- **User authentication** (e.g., checking if a user is an admin).
+- **External data sources** (e.g., analytics).
+
+
+
+```typescript title="Example of a context field"
+context: {
+  admin: async (session) => {
+    const admins = await operationalStore.get("admins");
+    return admins.includes(session.user);
+  }
+}
+```
+
+## 1. How to generate a subgraph
+
+Lets start by generating a new subgraph. For our tutorial we will create a new subgraph within our To-do List project.   
+Open your project and start your terminal.
+The Powerhouse toolkit provides a command-line utility to create new subgraphs easily.   
+
+```bash title="Run the following command to generate a new subgraph"
+ph generate --subgraph <to-do-list-subgraph>
+```
+
+```bash title="Expected Output"
+Loaded templates: node_modules/@powerhousedao/codegen/dist/codegen/.hygen/templates
+       FORCED: ./subgraphs/to-do-list-subgraph/index.ts
+     skipped: ./subgraphs/index.ts
+      inject: ./subgraphs/index.ts
+```
+
+### What happened?
+1. A new subgraph was created in `./subgraphs/to-do-list-subgraph/`
+2. The subgraph was automatically registered in your project's registry
+3. Basic boilerplate code was generated with an example query
+
+If we now run `ph reactor` we will see the new subgraph being registered during the startup of the Reactor.
+  > Registered /todolist subgraph.
+
+Alternatively, when you are running a local reactor with `ph reactor` a series of subgraphs will automatically get registered, amongst those one for the available document models in your Powerhouse project. 
+
+```
+Initializing Subgraph Manager...
+> Registered /graphql/auth subgraph.  
+> Registered /graphql/system subgraph.
+> Registered /graphql/analytics subgraph.
+> Registered /d/:drive subgraph.
+> Updating router
+> Registered /graphql supergraph 
+> Registered /graphql/to-do-list subgraph. 
+> Updating router
+> Registered /graphql supergraph 
+  ➜  Reactor:   http://localhost:4001/d/powerhouse
+```
+
+## 2. Building a To-do List Subgraph
+
+Now that we've generated our subgraph, let's build a complete To-do List subgraph that extends the functionality of our To-do List document model. This subgraph will provide additional querying capabilities and demonstrate how subgraphs work with document models.
+
+### 2.1 Understanding the To-do List Document Model
+
+Before building our subgraph, let's recall the structure of our To-do List document model from the [DocumentModelCreation tutorial](/academy/MasteryTrack/DocumentModelCreation/SpecifyTheStateSchema):
+
+```graphql
+type ToDoListState {
+  items: [ToDoItem!]!
+  stats: ToDoListStats!
+}
+
+type ToDoItem {
+  id: ID!
+  text: String!
+  checked: Boolean!
+}
+
+type ToDoListStats {
+  total: Int!
+  checked: Int!
+  unchecked: Int
+}
+```
+
+The document model has these operations:
+- `ADD_TODO_ITEM`: Adds a new to-do item
+- `UPDATE_TODO_ITEM`: Updates an existing to-do item
+- `DELETE_TODO_ITEM`: Deletes a to-do item
+
+### 2.2 Define the Subgraph Schema
+
+Now let's create a subgraph that provides enhanced querying capabilities for our To-do List documents. 
+
+**Step 1: Define the schema in `subgraphs/to-do-list/schema.ts`:**
+
+```typescript
+export const typeDefs = `
+  type Query {
+    todoList: TodoListSummary
+    todoItems(checked: Boolean): [TodoItem!]!
+    todoItemsCount(checked: Boolean): Int!
+  }
+
+  type TodoListSummary {
+    total: Int!
+    checked: Int!
+    unchecked: Int!
+  }
+
+  type TodoItem {
+    id: ID!
+    text: String!
+    checked: Boolean!
+  }
+`;
+```
+
+**Step 2: Create resolvers in `subgraphs/to-do-list/resolvers.ts`:**
+
+```typescript
+// subgraphs/to-do-list/resolvers.ts
+// subgraphs/to-do-list/resolvers.ts
+interface SubgraphInstance {
+  operationalStore: any;
+}
+
+export const createResolvers = (subgraphInstance: SubgraphInstance) => ({
+  Query: {
+    todoList: async () => {
+      const items = await subgraphInstance.operationalStore.getAll("todo_items");
+      const total = items.length;
+      const checked = items.filter((item: any) => item.checked).length;
+      const unchecked = total - checked;
+      
+      return {
+        total,
+        checked,
+        unchecked
+      };
+    },
+    
+    todoItems: async (parent: any, { checked }: any) => {
+      let query = subgraphInstance.operationalStore.select("*").from("todo_items");
+      
+      if (checked !== undefined) {
+        query = query.where("checked", checked);
+      }
+      
+      const items = await query.orderBy("created_at", "asc");
+      return items;
+    },
+    
+    todoItemsCount: async (parent: any, { checked }: any) => {
+      let query = subgraphInstance.operationalStore.count("* as count").from("todo_items");
+      
+      if (checked !== undefined) {
+        query = query.where("checked", checked);
+      }
+      
+      const result = await query.first();
+      return result?.count || 0;
+    }
+  }
+});
+```
+
+**Step 3: Implement the main class in `subgraphs/to-do-list/index.ts`:**
+
+```typescript
+// subgraphs/to-do-list/index.ts
+import { typeDefs } from './schema.js';
+import { createResolvers } from './resolvers.js';
+
+export default class ToDoListSubgraph {
+  path = '/to-do-list';
+  
+  typeDefs = typeDefs;
+  resolvers: any;
+  operationalStore: any;
+  
+  constructor() {
+    this.resolvers = createResolvers(this);
+  }
+
+  async onSetup() {
+    await this.createOperationalTables();
+  }
+
+  async createOperationalTables() {
+    await this.operationalStore.schema.createTableIfNotExists(
+      "todo_items",
+      (table: any) => {
+        table.string("id").primary();
+        table.string("text").notNullable();
+        table.boolean("checked").defaultTo(false);
+        table.timestamp("created_at").defaultTo(this.operationalStore.fn.now());
+        table.timestamp("updated_at").defaultTo(this.operationalStore.fn.now());
+      }
+    );
+  }
+
+  async process(event: any) {
+    // Handle To-do List document operations
+    if (event.type === "ADD_TODO_ITEM") {
+      await this.operationalStore.insert("todo_items", {
+        id: event.input.id,
+        text: event.input.text,
+        checked: false,
+        created_at: new Date(),
+        updated_at: new Date()
+      });
+      
+      console.log(`Added todo item: ${event.input.text}`);
+    }
+    
+    if (event.type === "UPDATE_TODO_ITEM") {
+      const updateData: any = {
+        updated_at: new Date()
+      };
+      
+      // Only update fields that were provided
+      if (event.input.text !== undefined) {
+        updateData.text = event.input.text;
+      }
+      if (event.input.checked !== undefined) {
+        updateData.checked = event.input.checked;
+      }
+      
+      await this.operationalStore.update("todo_items")
+        .where("id", event.input.id)
+        .update(updateData);
+      
+      console.log(`Updated todo item: ${event.input.id}`);
+    }
+    
+    if (event.type === "DELETE_TODO_ITEM") {
+      await this.operationalStore.delete("todo_items")
+        .where("id", event.input.id);
+      
+      console.log(`Deleted todo item: ${event.input.id}`);
+    }
+  }
+}
+```
+
+**What this schema provides:**
+- `todoList`: Returns statistics about all to-do items (total, checked, unchecked counts)
+- `todoItems`: Returns a list of to-do items, optionally filtered by checked status
+- `todoItemsCount`: Returns just the count of items, optionally filtered by checked status
+
+### 2.3 Understanding the Implementation
+
+**What this multi-file approach provides:**
+
+1. **Schema separation** (`schema.ts`): Clean GraphQL type definitions
+2. **Resolver isolation** (`resolvers.ts`): Business logic separated from structure  
+3. **Main orchestration** (`index.ts`): Combines everything and handles lifecycle methods
+
+**Key features implemented:**
+- A `todo_items` operational table to store individual to-do items
+- Fields that match our document model structure
+- Timestamps for tracking when items were created and updated
+- Resolvers that fetch and filter todo items from the operational store
+- Event processing to keep the subgraph data synchronized with document model changes
+
+### 2.4 Connect to Document Model Events (Processor Integration)
+
+To make our subgraph truly useful, we need to connect it to the actual To-do List document model events. This ensures that when users interact with To-do List documents through Connect, the subgraph data stays synchronized.
+
+Add this processor integration to your subgraph:
+
+```typescript
+async process(event) {
+  // Handle To-do List document operations
+  if (event.type === "ADD_TODO_ITEM") {
+    await this.operationalStore.insert("todo_items", {
+      id: event.input.id,
+      text: event.input.text,
+      checked: false,
+      created_at: new Date(),
+      updated_at: new Date()
+    });
+    
+    console.log(`Added todo item: ${event.input.text}`);
+  }
+  
+  if (event.type === "UPDATE_TODO_ITEM") {
+    const updateData = {
+      updated_at: new Date()
+    };
+    
+    // Only update fields that were provided
+    if (event.input.text !== undefined) {
+      updateData.text = event.input.text;
+    }
+    if (event.input.checked !== undefined) {
+      updateData.checked = event.input.checked;
+    }
+    
+    await this.operationalStore.update("todo_items")
+      .where("id", event.input.id)
+      .update(updateData);
+    
+    console.log(`Updated todo item: ${event.input.id}`);
+  }
+  
+  if (event.type === "DELETE_TODO_ITEM") {
+    await this.operationalStore.delete("todo_items")
+      .where("id", event.input.id);
+    
+    console.log(`Deleted todo item: ${event.input.id}`);
+  }
+}
+```
+
+**What this processor does:**
+- Listens for document model operations (`ADD_TODO_ITEM`, `UPDATE_TODO_ITEM`, `DELETE_TODO_ITEM`)
+- Updates the operational store in real-time when these operations occur
+- Provides console logging for debugging
+- Maintains data consistency between the document model and the subgraph
+
+### 2.5 Summary of What We've Built
+
+- **Added two main queries**: `todoList` for statistics and `todoItems` for item lists
+- **Created an operational table** `todo_items` to store the todo items with proper schema
+- **Added resolvers** to fetch and filter todo items from the operational store
+- **Implemented event processing** to keep the subgraph data synchronized with document model changes
+- **The todoItems query accepts an optional checked parameter** to filter items by their completion status
+- **The todoList query returns the full statistics** including total, checked, and unchecked counts
+
+## 3. Testing the To-do List Subgraph
+
+### 3.1. Start the reactor
+To activate the subgraph, run:
+
+```bash
+ph reactor
+```
+Or, for full system startup:
+
+```bash title="Start the Reactor & Connect in Studio or Locally"
+ph dev 
+```
+
+You should see the subgraph being registered in the console output:
+```
+> Registered /graphql/to-do-list subgraph.
+```
+
+### 3.2. Create some test data
+Before testing queries, let's create some To-do List documents with test data:
+
+1. Open Connect at `http://localhost:3001`
+2. Add the 'remote' drive that is running locally via the (+) 'Add Drive' button. Add 'http://localhost:4001/d/powerhouse'
+3. Create a new To-do List document
+4. Add some test items:
+   - "Learn about subgraphs" (leave unchecked)
+   - "Build a To-do List subgraph" (mark as checked)
+   - "Test the subgraph" (leave unchecked)
+
+### 3.3. Access GraphQL playground
+Open your browser and go to:
+
+```bash
+http://localhost:4001/graphql/to-do-list
+```
+
+### 3.4. Test the queries
+
+**Query 1: Get To-do List statistics**
+```graphql
+query {
+  todoList {
+    total
+    checked
+    unchecked
+  }
+}
+```
+
+**Query 2: Get all to-do items**
+```graphql
+query {
+  todoItems {
+    id
+    text
+    checked
+  }
+}
+```
+
+**Query 3: Get only unchecked items**
+```graphql
+query {
+  todoItems(checked: false) {
+    id
+    text
+    checked
+  }
+}
+```
+
+**Query 4: Get count of completed items**
+```graphql
+query {
+  todoItemsCount(checked: true)
+}
+```
+
+### 3.5. Expected responses
+
+**For the statistics query:**
+```json
+{
+  "data": {
+    "todoList": {
+      "total": 3,
+      "checked": 1,
+      "unchecked": 2
+    }
+  }
+}
+```
+
+**For the items query:**
+```json
+{
+  "data": {
+    "todoItems": [
+      {
+        "id": "item-1",
+        "text": "Learn about subgraphs",
+        "checked": false
+      },
+      {
+        "id": "item-2",
+        "text": "Build a To-do List subgraph",
+        "checked": true
+      },
+      {
+        "id": "item-3",
+        "text": "Test the subgraph",
+        "checked": false
+      }
+    ]
+  }
+}
+```
+
+### 3.6. Test real-time updates
+
+To verify that your subgraph stays synchronized with document changes:
+
+1. Keep the GraphQL playground open
+2. In another tab, open your To-do List document in Connect
+3. Add a new item or check/uncheck an existing item
+4. Return to the GraphQL playground and re-run your queries
+5. You should see the updated data immediately
+
+This demonstrates the real-time synchronization between the document model and the subgraph through event processing.
+
+## 4. Working with the supergraph or gateway
+
+A supergraph is a GraphQL schema that combines multiple underlying GraphQL APIs, known as subgraphs, into a single, unified graph. This architecture allows different teams to work independently on their respective services (subgraphs) while providing a single entry point for clients or users to query all available data
+
+### 4.1 Key concepts
+
+*   **Subgraph:** An independent GraphQL service with its own schema. Each subgraph typically represents a specific domain or microservice within a larger system.
+*   **Gateway/Router:** A server that sits in front of the subgraphs. It receives client queries, consults the supergraph schema, and routes parts of the query to the relevant subgraphs. It then stitches the results back together before sending the final response to the client.
+
+### 4.2 Benefits of using a supergraph
+
+*   **Federated Architecture:** Enables a microservices-based approach where different teams can own and operate their services independently.
+*   **Scalability:** Individual subgraphs can be scaled independently based on their specific needs.
+*   **Improved Developer Experience:** Clients interact with a single, consistent GraphQL API, simplifying data fetching and reducing the need to manage multiple endpoints.
+*   **Schema Evolution:** Subgraphs can evolve their schemas independently, and the supergraph can be updated without breaking existing clients, as long as breaking changes are managed carefully.
+*   **Clear Separation of Concerns:** Each subgraph focuses on a specific domain, leading to more maintainable and understandable codebases.
+
+
+### 4.3 Use the Powerhouse supergraph
+
+The Powerhouse supergraph for any given remote drive or reactor can be found under `http://localhost:4001/graphql`. The gateway / supergraph available on `/graphql` combines all the subgraphs, except for the drive subgraph (which is accessible via `/d/:driveId`). To get to the endpoint open your localhost by starting the reactor and adding `graphql` to the end of the url. The following commands explain how you can test & try the supergraph. 
+
+- Start the reactor:
+
+  ```bash
+  ph reactor
+  ```
+
+- Open the GraphQL editor in your browser:
+
+  ```
+  http://localhost:4001/graphql
+  ```
+
+The supergraph allows to both query & mutate data from the same endpoint. 
+
+**Example: Using the supergraph with To-do List documents**
+
+1. Create a todo document in the `powerhouse` drive using the `ToDoList_createDocument` mutation:
+   ```graphql
+   mutation {
+     ToDoList_createDocument(
+       input: {
+         documentId: "my-todo-list"
+         name: "My Test To-do List"
+       }
+     ) {
+       id
+       name
+     }
+   }
+   ```
+
+2. Add some items to your to-do list using the `ToDoList_addTodoItem` mutation:
+   ```graphql
+   mutation {
+     ToDoList_addTodoItem(
+       docId: "my-todo-list"
+       input: {
+         id: "item-1"
+         text: "Learn about supergraphs"
+       }
+     )
+   }
+   ```
+
+3. Query the document state using the `GetDocument` query:
+   ```graphql
+   query {
+     ToDoList {
+       getDocument(docId: "my-todo-list") {
+         id
+         name
+         state {
+           items {
+             id
+             text
+             checked
+           }
+           stats {
+             total
+             checked
+             unchecked
+           }
+         }
+       }
+     }
+   }
+   ```
+
+4. Now query the same data through your subgraph (which should be included in the supergraph):
+   ```graphql
+   query {
+     todoList {
+       total
+       checked
+       unchecked
+     }
+     todoItems {
+       id
+       text
+       checked
+     }
+   }
+   ```
+
+This demonstrates how the supergraph provides a unified interface to both your document models and your custom subgraphs, allowing you to query and mutate data from the same endpoint. 
+
+## 5. Summary
+
+Congratulations! You've successfully built a complete To-do List subgraph that demonstrates the power of extending document models with custom GraphQL functionality. Let's recap what you've accomplished:
+
+### What you built:
+- **A custom GraphQL schema** that provides enhanced querying capabilities for To-do List documents
+- **An operational data store** that efficiently stores and retrieves to-do items
+- **Real-time event processing** that keeps your subgraph synchronized with document model changes
+- **Advanced query capabilities** including filtering and counting operations
+- **Integration with the supergraph** for unified API access
+
+### Key concepts learned:
+- **Subgraphs extend document models** with additional querying and data processing capabilities
+- **Operational data stores** provide efficient storage for subgraph data
+- **Event processing** enables real-time synchronization between document models and subgraphs
+- **The supergraph** unifies multiple subgraphs into a single GraphQL endpoint
+
+### Next steps:
+- Explore adding **mutations** to your subgraph for more complex operations
+- Implement **data aggregation** for analytics and reporting
+- Connect to **external APIs** for enhanced functionality
+- Build **processors** that automate workflows between different document models
+
+This tutorial has provided you with a solid foundation for building sophisticated data processing and querying capabilities in the Powerhouse ecosystem.
+
+## Subgraphs are particularly useful for
+
+1. **Cross-Document Interactions**: For example, connecting a To-do List with an Invoice document model:
+   - When an invoice-related task is marked complete, update the invoice status
+   - When an invoice is paid, automatically check off related tasks
+
+2. **External Integrations**: 
+   - Sync tasks with external project management tools
+   - Connect with notification systems
+   - Integrate with analytics platforms
+
+3. **Custom Business Logic**:
+   - Implement complex task prioritization
+   - Add automated task assignments
+   - Create custom reporting functionality
+
+### Prebuilt subgraphs
+
+Some subgraphs (e.g., System Subgraph, Drive Subgraph) already exist.  
+To integrate with them, register them via the Reactor API.
+
+### Future enhancements
+
+Bridge Processors and Subgraphs – Currently, there's a gap in how processors and subgraphs interact. Powerhouse might improve this in future updates.
+
+
+
+
+
+
+

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@powerhousedao/academy",
-  "version": "3.3.0-dev.0",
+  "version": "3.3.0-dev.2",
   "homepage": "https://powerhouse.academy",
   "repository": {
     "type": "git",

package/src/components/HomepageFeatures/index.tsx

@@ -25,7 +25,7 @@ const FeatureList: FeatureItem[] = [
   {
     title: "Switchboard",
     imageSrc: require("@site/static/img/switchboard.png").default,
-    docPath: "/docs/academy/MasteryTrack/WorkWithData/ReadingAndWritingThroughTheAPI",
+    docPath: "/docs/academy/MasteryTrack/WorkWithData/UsingTheAPI",
     description: <>Get access to the open API interface with Switchboard</>,
   },
   {
@@ -200,7 +200,7 @@ export default function HomepageFeatures() {
               <h3 className={styles.cardTitle}>Work with Data</h3>
             </div>
             <div className={styles.cardContent}>
-              <a href="//docs/academy/MasteryTrack/WorkWithData/ReadingAndWritingThroughTheAPI" className={styles.pathButton}>Reading & Writing through the API</a>
+              <a href="//docs/academy/MasteryTrack/WorkWithData/UsingTheAPI" className={styles.pathButton}>Reading & Writing through the API</a>
               <a href="/docs/academy/MasteryTrack/WorkWithData/WorkingWithSubgraphs" className={styles.pathButton}>Create your own Subgraph</a>
               <a href="/docs/academy/WorkWithData/Analytics Engine/intro" className={styles.pathButton}>Using the Analytics Engine</a>
             </div>

package/docs/academy/02-MasteryTrack/04-WorkWithData/03-WorkingWithSubgraphs/02-GraphQLAndSubgraphs.mdx

@@ -1,119 +0,0 @@
-# GraphQL and subgraphs
-
-GraphQL plays a fundamental role in defining document model data schemas, handling data access patterns, and enabling event-driven workflows within the Powerhouse ecosystem.   
-This document provides an intro to graphQL and how it is used at Powerhouse when dealing with subgraphs
-
-More specifically, GraphQL is used as:
-- The **schema definition language (SDL)** for defining our document models and thereby self-documenting the API to the data model. It allows developers to define the structure and relationships of data in a strongly-typed format.
-- As the **query language in subgraphs**, which allow different services to expose and query structured data dynamically.
-
-
-## Powerhouse's use of GraphQL subgraphs
-Powerhouse structures its data into subgraphs, which are modular GraphQL services that connect to the Reactor, Powerhouse's core data infrastructure, or Operational Data Stores fueled by data from a processor.
-
-### Fetching data from the Reactor
-
-Powerhouse uses GraphQL to expose system-level data, such as drives, users, and operational records.  
-Example: The **System Subgraph** allows querying of drives, stored files and folders.
-
-### Operational data stores
-
-Custom subgraphs can be created to store and retrieve operational data in real time.
-Example: A subgraph can track file uploads and expose this data via GraphQL queries.    ????
-
-??
-
-```graphql
-type File {
-  id: ID!
-  name: String!
-  size: Int!
-  createdAt: DateTime!
-}
-
-type Query {
-  getFile(id: ID!): File
-}
-```
-This schema ensures that every File entity has an ID, name, size, and timestamp.
-
-??
-
-In Powerhouse, each subgraph has its own SDL, ensuring modularity and flexibility while working within the ecosystem.
-
-## CQRS breakdown
-
-Powerhouse uses CQRS to separate write operations (commands) from read operations (queries).   
-This improves system scalability and flexibility. 
-- GraphQL Queries handle read operations, retrieving structured data efficiently. 
-- GraphQL Mutations handle write operations, modifying the state in a controlled manner.
-
-Powerhouse's subgraphs act as the read layer, while processors handle write operations into operational data stores. This prevents conflicts between querying and modifying data.
-
-| Layer | Role | GraphQL Usage | Implementation |
-| --- | --- | --- | --- |
-| Write Model (Commands) | Handles state changes (adding, modifying, deleting) | GraphQL Mutations | Processor |
-| Read Model (Queries) | Optimized for fetching/reading/retrieving data | GraphQL Queries | Subgraph |
-
-### Read and write separation  
-**Read Model (Query)**  
-
-- Optimized for data retrieval
-- Structured using GraphQL Queries
-- Aggregates and exposes data via a subgraph
-- Pulls data from Operational Data Stores, Analytics Stores, and Reactor
-- Subgraphs do not directly modify the data—they only expose pre-processed information  
-
-
-
-```graphql title="Example of a Powerhouse Contributor schema in GraphQL"
-query {
-  getFile(id: "123") {
-    name
-    size
-  }
-}
-```
-
-**Write Model (Mutation)** 
-- Handles state changes (adding, modifying, deleting)
-- Structured using GraphQL Mutations
-- Writes data to Operational Data Stores
-
-```graphql title="Example of a Powerhouse Contributor schema in GraphQL"
-mutation {
-  createFile(name: "document.pdf", size: 1024) {
-    id
-    name
-  }
-}
-```
-
-### GraphQL and event-driven architecture (EDA)
-Event-Driven Architecture (EDA) enables asynchronous processing where events trigger actions. Powerhouse uses GraphQL to expose real-time event data from its Reactor and Operational Data Stores.
-
-How GraphQL Fits into EDA
-- **Real-Time Data Exposure** – Subgraphs fetch event-based data updates.
-- **Event Subscription Mechanism** – Powerhouse is working towards integrating GraphQL Subscriptions for real-time updates.
-- **Efficient Decoupling** – Events are stored in an operational datastore, and GraphQL queries retrieve structured results.
-
-#### Example: Powerhouse's event flow
-1. Processor detects an event (e.g., file upload).
-2. Writes event data to the Operational Data Store.
-3. Subgraph exposes the updated data via GraphQL.
-
-
-## GraphQL subscriptions
-Although Powerhouse currently uses queries and mutations, GraphQL Subscriptions could allow real-time streaming of event-based data.
-
-#### Example (future implementation):
-
-```graphql 
-subscription {
-  fileUploaded {
-    id
-    name
-  }
-}
-```
-This would enable clients to listen for new file uploads without polling.

package/docs/academy/02-MasteryTrack/04-WorkWithData/03-WorkingWithSubgraphs/03-WorkingWithSubgraphs.md

@@ -1,312 +0,0 @@
-# Working with subgraphs
-
-This tutorial will demonstrate how to create and customize a subgraph using our To-do List project as an example.
-Let's start with the basics and gradually add more complex features and functionality.
-
-## What is a subgraph?
-
-A subgraph in Powerhouse is a **GraphQL-based modular data component** that extends the functionality of your document models. While document models handle the core state and operations, subgraphs can:
-1. Connect to external APIs or databases
-2. Add custom queries and mutations
-3. Automate interactions between different document models
-4. Provide additional backend functionality
-
-### Subgraphs can retrieve data from
-
-- **The Reactor** – The core Powerhouse data system or network node.   
-- **Operational Data Stores** – Structured data storage for operational processes, offering real-time updates, for querying structured data.  
-- **Analytics Stores** – Aggregated historical data, useful for insights, reporting and business intelligence.
-
-### Subgraphs consist of
-
-- **A schema** – Which defines the GraphQL Queries and Mutations.
-- **Resolvers** – Which handle data fetching and logic.
-- **Context Fields** – Additional metadata that helps in resolving data efficiently.
-
-#### Additionally, context fields allow resolvers to access extra information, such as:
-- **User authentication** (e.g., checking if a user is an admin).
-- **External data sources** (e.g., analytics).
-
-
-
-```typescript title="Example of a context field"
-context: {
-  admin: async (session) => {
-    const admins = await operationalStore.get("admins");
-    return admins.includes(session.user);
-  }
-}
-```
-
-## 1. How to generate a subgraph
-
-Lets start by generating a new subgraph. For our tutorial we will create a new subgraph within our To-do List project.   
-Open your project and start your terminal.
-The Powerhouse toolkit provides a command-line utility to create new subgraphs easily.   
-
-```bash title="Run the following command to generate a new subgraph"
-ph generate --subgraph <to-do-list-subgraph>
-```
-
-```bash title="Expected Output"
-Loaded templates: node_modules/@powerhousedao/codegen/dist/codegen/.hygen/templates
-       FORCED: ./subgraphs/to-do-list-subgraph/index.ts
-     skipped: ./subgraphs/index.ts
-      inject: ./subgraphs/index.ts
-```
-
-### What happened?
-1. A new subgraph was created in `./subgraphs/to-do-list-subgraph/`
-2. The subgraph was automatically registered in your project's registry
-3. Basic boilerplate code was generated with an example query
-
-If we now run 'phreactor' we will see the new subgraph being registered during the startup of the Reactor.
-  > Registered /todolist subgraph.
-
-## 2. Customizing your subgraph with a schema
-
-Now that we've generated our subgraph, let's open it and define the schema inside the `index.ts` file.
-
-### 2.1 Define the schema
-
-Here we define the schema (typeDefs) which defines the structure of your queries and mutations.
-For educational purposes we will define a simple query that mimics the functionality of the todoList interface (or editor): 
-- Returns the total number of todo's
-- The number of todo's that are checked
-- The number of todo's that are not checked
-
-
-
-```graphql
-type Query {
-  fileIds: [String]
-}
-```
-
-### What happened?
-
-- Added two queries: todoList and todoItems
-- Created an operational table todo_items to store the todo items
-- Added resolvers to fetch and filter todo items
-- Removed the example code
-- The todoItems query accepts an optional checked parameter to filter items by their status
-- The todoList query returns the full list with its statistics
-
-
-### 2.2 Implement the resolver for the subgraph's schema
-Resolvers define how data is retrieved or modified.
-If you query for a specific value you can retrieve the value from either the reactor itself or an operational datastore.    
-We'll look into this in more detail in the next section.
-
-```js
-resolvers: {
-  Query: {
-    fileIds: async () => {
-      return ["file1", "file2", "file3"];
-    }
-  }
-}
-```
-
-### 2.3 Add operational data storage (optional)
-If you need to persist data, initialize an operational datastore inside onSetup():
-
-```typescript title="Adding an operational datastore"
-async onSetup() {
-  await this.createOperationalTables();
-}
-
-async createOperationalTables() {
-  await this.operationalStore.schema.createTableIfNotExists(
-    "fileIds",
-    (table) => {
-      table.string("id").primary();
-    }
-  );
-}
-```
-
-### 2.4 Fetching from an operational store
-If your subgraph interacts with an Operational Data Store, modify the resolver:
-
-```typescript title="Example of a resolver that fetches data from an operational store"
-resolvers: {
-  Query: {
-    fileIds: async (_, __, { operationalStore }) => {
-      return await operationalStore.getAll("fileIds");
-    }
-  }
-}
-```
-
-### 2.5 Connecting to a processor (optional, but recommended)
-
-#### Why connect a processor?
-Subgraphs alone are limited. A subgraph only queries data, but doesn't generate or store it.
-To make subgraphs useful, connect them with processors that update the data dynamically.
-**A processor listens to system events and updates the operational store in real-time.**
-
-Making use of a processor allows for:
-- **Live updates** instead of static data.
-- **Scalable architecture** through event-driven data changes.
-- **Seamless integration** with other Powerhouse components.
-
-Inside your processor, you can listen for new files, which in turn update the datastore:
-
-```typescript title="Example: Creating a Simple Processor"
-async process(event) {
-  if (event.type === "ADD_FILE") {
-    await this.operationalStore.insert("fileIds", { id: event.fileId });
-  }
-}
-```
-
-Then, modify your subgraph resolver to return real-time data:
-
-```js
-resolvers: {
-  Query: {
-    fileIds: async (_, __, { operationalStore }) => {
-      return await operationalStore.getAll("fileIds");
-    }
-  }
-}
-```
-
-## 3. Testing the subgraph
-
-### 3.1. Start the reactor
-To activate the subgraph, run:
-
-```bash
-ph reactor
-```
-Or, for full system startup:
-
-```bash title="Start the Reactor & Connect in Studio or Locally
-ph dev 
-```
-
-### 3.2. Access GraphQL playground
-Open your browser and go to:
-
-```bash
-http://localhost:4001/<subgraph-name>
-```
-Example:
-
-```bash
-http://localhost:4001/test-subgraph
-```
-
-### 3.3. Run a query
-
-```graphql
-query {
-  fileIds
-}
-```
-
-### 3.4. Expected response
-If everything works, you should see:
-
-```json
-{
-  "data": {
-    "fileIds": ["file1", "file2", "file3"]
-  }
-}
-```
-
-## 4. Working with the supergraph or gateway
-
-A supergraph is a GraphQL schema that combines multiple underlying GraphQL APIs, known as subgraphs, into a single, unified graph. This architecture allows different teams to work independently on their respective services (subgraphs) while providing a single entry point for clients or users to query all available data
-
-### 4.1 Key concepts
-
-*   **Subgraph:** An independent GraphQL service with its own schema. Each subgraph typically represents a specific domain or microservice within a larger system.
-*   **Gateway/Router:** A server that sits in front of the subgraphs. It receives client queries, consults the supergraph schema, and routes parts of the query to the relevant subgraphs. It then stitches the results back together before sending the final response to the client.
-
-### 4.2 Benefits of using a supergraph
-
-*   **Federated Architecture:** Enables a microservices-based approach where different teams can own and operate their services independently.
-*   **Scalability:** Individual subgraphs can be scaled independently based on their specific needs.
-*   **Improved Developer Experience:** Clients interact with a single, consistent GraphQL API, simplifying data fetching and reducing the need to manage multiple endpoints.
-*   **Schema Evolution:** Subgraphs can evolve their schemas independently, and the supergraph can be updated without breaking existing clients, as long as breaking changes are managed carefully.
-*   **Clear Separation of Concerns:** Each subgraph focuses on a specific domain, leading to more maintainable and understandable codebases.
-
-
-### 4.3 Use the Powerhouse supergraph
-
-The Powerhouse supergraph for any given remote drive or reactor can be found under `http://localhost:4001/graphql`. The gateway / supergraph available on `/graphql` combines all the subgraphs, except for the drive subgraph (which is accessible via `/d/:driveId`). To get to the endpoint open your localhost by starting the reactor and adding `graphql` to the end of the url. The following commands explain how you can test & try the supergraph. 
-
-- Start the reactor:
-
-  ```bash
-  ph reactor
-  ```
-
-- Open the GraphQL editor in your browser:
-
-  ```
-  http://localhost:4001/graphql
-  ```
-
-The supergraph allows to both query & mutate data from the same endpoint. 
-
-- Create a todo document in the `powerhouse` drive using the `ToDo_createDocument` mutation.
-  ![ToDo_createDocument](https://i.ibb.co/GQTZr7Wk/Screenshot-2025-05-01-at-1-22-23-PM.png)
-
-- Get the document state using the `GetDocument` query.
-  ![GetDocument](https://i.ibb.co/v47cj4Q4/Screenshot-2025-05-01-at-1-22-41-PM.png)
-
-- In a different terminal, start connect:
-
-  ```bash
-  ph connect
-  ```
-
-- Open Connect and add the `powerhouse` drive:
-
-  ```
-  http://localhost:4001/d/powerhouse
-  ```
-
-- You should now see the todo document you've created earlier. Edit the todo document with the document editor and add a few tasks that you can query later. 
-
-- Go back to the GraphQL explorer and use the `GetDocument` query again — you should see the updated state.
-
-This is a quick example of how the supegraph can be used. 
-
-
-## Subgraphs are particularly useful for
-
-1. **Cross-Document Interactions**: For example, connecting a To-do List with an Invoice document model:
-   - When an invoice-related task is marked complete, update the invoice status
-   - When an invoice is paid, automatically check off related tasks
-
-2. **External Integrations**: 
-   - Sync tasks with external project management tools
-   - Connect with notification systems
-   - Integrate with analytics platforms
-
-3. **Custom Business Logic**:
-   - Implement complex task prioritization
-   - Add automated task assignments
-   - Create custom reporting functionality
-
-### Prebuilt subgraphs
-
-Some subgraphs (e.g., System Subgraph, Drive Subgraph) already exist.  
-To integrate with them, register them via the Reactor API.
-
-### Future enhancements
-
-Bridge Processors and Subgraphs – Currently, there's a gap in how processors and subgraphs interact. Powerhouse might improve this in future updates.
-
-
-
-
-
-
-

package/docs/academy/02-MasteryTrack/04-WorkWithData/03-WorkingWithSubgraphs/_category_.json

@@ -1,8 +0,0 @@
-{
-    "label": "Working With Subgraphs",
-    "position": 4,
-    "link": {
-      "type": "generated-index",
-      "description": "Learn how to work with graphQL, subgraphs, and processors in Powerhouse."
-    }
-}