Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
43 changes: 19 additions & 24 deletions docs/using-platform/11_middleware.md
Original file line number Diff line number Diff line change
Expand Up @@ -15,7 +15,7 @@ Follow these steps to add the middleware:
1. Select to which of your **smart contract sets** the middleware needs to connect, and click **Continue**.
2. Choose [Graph Middleware](#the-graph-middleware) or [Smart Contract Portal Middleware](#the-smart-contract-portal-middleware)
3. Choose a **Middleware name**. Choose one that will be easily recognizable in your dashboards.
4. Select the **storage provider**
4. Select the **storage provider** if needed.
5. Choose a **deployment plan**. Select the type, cloud provider, region and resource pack. [More about deployment plans.](../launch-platform/managed-cloud-deployment/13_deployment-plans.md)
6. You see the **resource cost** for this middleware displayed at the bottom of the form. Click **Confirm** to add the smart contract set.

Expand Down Expand Up @@ -48,10 +48,10 @@ Navigate to the **smart contract set** that you connected to the middleware, go

#### Subgraph raw configuration

Inside the root you will find a file called `subgraph.config.template.json` that contains the raw configuration of the subgraph. The important section is the **datasources** section.
Inside the root you will find a file called `subgraph.config.json` that contains the raw configuration of the subgraph. The important section is the **datasources** section.

- **Name** - here we defined the smart contracts with their name (the name of the artifact created in the 'deployments' folder when running the deploy task)
- **Address & Startblock** - You will notice the startblock and address to be 0. These will be filled in using the `graph:config` task based on the hardhat deployments.
- **Address & Startblock** - You will notice the startblock and address to be 0. You must fill these in when your contract has been deployed. The block number and the address can be found in the **deployment** folder, under **ignition**.
- **Module** - In the modules array all the indexing modules to activate for this smart contract.

#### About the indexing modules
Expand Down Expand Up @@ -88,22 +88,17 @@ Follow these steps to create a custom indexing module:

- Primitives to generate a GraphQL schema: `subgraph/datasource/x.gql.json` - In order to allow composability, the schema are not defined in the GraphQL format but rather in a dedicated JSON format which is can be assembled and compiled to GraphQL.
- Template to generate a subgraph manifest: `subgraph/datasource/x.yaml` - This file lists all the events that the datasources should listen to, and links that to the corresponding indexing logic.
- Indexing logic: `subgraph/datasources/x.ts` and (optionally) `subgraph/fetch/x.ts` - This is the core logic that processes the events and to index the onchain activity.
- Indexing logic: `subgraph/datasources/x.ts` and (optionally) `subgraph/fetch/x.ts` - This is the core logic that processes the events to index the onchain activity.

[To learn more, check it out on Github.](https://github.com/OpenZeppelin/openzeppelin-subgraphs)

#### Tweak the subgraph configuration

You can tweak the `subgraph.config.template.json` file to your liking, and run the `graph:config task`. This will generate `subgraph.config.json` for the next steps.
#### Start your subgraph

The following tasks need to be run in this sequence:

- `graph:compile` - Uses `subgraph.config.json` to generate the GraphQL schema and subgraph configuration.
- `graph:codegen` - Generates the AssemblyScript types for your contracts ABI based on the output of `graph:compile`.
- `graph:build` - Compiles the WASM files based on the outputs generated by `graph:codegen`.
- `graph:deploy` - Deploys the WASM files to IPFS and updates the middleware to start or update the indexing.

To make this a bit easier, the `graph:all` task executes all these steps in the right order.
- `btp-scs subgraph codegen` - Generates the AssemblyScript types for your contracts ABI.
- `btp-scs subgraph build` - Compiles the WASM files based on the outputs generated by `btp-scs subgraph codegen`.
- `btp-scs subgraph deploy` - Deploys the WASM files to IPFS and updates the middleware to start or update the indexing.

The indexing of your smart contracts has now started. This can take a while, but once done you can query the middleware for your data in seconds using the **GraphQL API**. You can find the **endpoint** in the **Connect-tab**.

Expand Down Expand Up @@ -166,25 +161,25 @@ Standard Webhooks has built [SDKs and useful tools](https://www.standardwebhooks
An example using Typescript, [Elysia](https://elysiajs.com/) and [standard webhooks](https://www.standardwebhooks.com/).

```ts
import { Elysia, t } from "elysia";
import { Webhook } from "standardwebhooks";
import { Elysia, t } from 'elysia';
import { Webhook } from 'standardwebhooks';

async function webhookConsumerBootstrap(secret: string) {
const webhookConsumer = new Elysia().post(
"/scp-listener",
'/scp-listener',
({ headers, body }) => {
try {
const wh = new Webhook(btoa(secret));
const verifiedPayload = wh.verify(JSON.stringify(body.payload), {
"webhook-id": headers["btp-portal-event-id"]!,
"webhook-signature": headers["btp-portal-event-signature"]!,
"webhook-timestamp": headers["btp-portal-event-timestamp"]!,
'webhook-id': headers['btp-portal-event-id']!,
'webhook-signature': headers['btp-portal-event-signature']!,
'webhook-timestamp': headers['btp-portal-event-timestamp']!,
});
console.log(
`Received a webhook event: ${JSON.stringify(verifiedPayload)}`
);
} catch (err) {
console.error("Webhook payload invalid", err);
console.error('Webhook payload invalid', err);
throw err;
}
},
Expand All @@ -211,7 +206,7 @@ async function webhookConsumerBootstrap(secret: string) {
webhookConsumerBootstrap(process.env.WEBHOOK_SECRET!)
.then((app) => app.listen(process.env.PORT || 5555))
.catch((error: Error) => {
console.error("Failed to start webhook consumer", error);
console.error('Failed to start webhook consumer', error);
process.exit(1);
});
```
Expand All @@ -223,7 +218,7 @@ The websocket endpoint exposes functionality to get real time updates on process
The url can be copied from the Connect tab.

```ts
import type { TransactionReceipt } from "viem";
import type { TransactionReceipt } from 'viem';

// Should include an api key (eg wss://smart-contract-portal-middleware.settlemint.com/sm_pat_.../ws)
const webSocketHost = process.env.WS_URL!;
Expand All @@ -247,7 +242,7 @@ export async function waitForTransactionReceipt(transactionHash: string) {
webSocket.onerror = reject;
webSocket.onclose = () => {
if (!isResolved) {
reject(new Error("Nothing received from the WebSocket"));
reject(new Error('Nothing received from the WebSocket'));
}
};
if (webSocket.readyState === WebSocket.OPEN) {
Expand Down Expand Up @@ -283,4 +278,4 @@ When setting up a new middleware, you'll need to adjust the Attestation Indexer

The Attestation Indexer's GraphQL API provides the capability to execute intricate queries on attestations. It allows for filtering based on attributes such as type, issuer, and subject, enabling the retrieval of specific attestations or sets of attestations that satisfy particular conditions.

![GraphQL](../../static/img/using-the-platform/eas-graphql.png)
![GraphQL](../../static/img/using-the-platform/eas-graphql.png)
2 changes: 1 addition & 1 deletion docs/using-platform/12_firefly.md
Original file line number Diff line number Diff line change
Expand Up @@ -7,7 +7,7 @@ Firefly FabConnect is an open-source middleware that lets you interact with your
- Check any transaction receipt.
- Create event streams and subscriptions.

:::warning
:::warning Warning

Before you start, make sure you are running:

Expand Down