From 242558de398d4797aacfa90ea277258e1590f175 Mon Sep 17 00:00:00 2001 From: Joshua Croft <32483134+devjsc@users.noreply.github.com> Date: Wed, 8 Jan 2025 10:06:11 +0000 Subject: [PATCH] feat(docs): removing indexer from docs (#1128) Co-authored-by: Joshua Croft Co-authored-by: felix.bucsa <72919584+FelixNicolaeBucsa@users.noreply.github.com> --- next.config.js | 20 +++ pages/concepts.mdx | 10 -- pages/concepts/fetch-network/_meta.json | 3 +- pages/concepts/fetch-network/indexer.mdx | 41 ----- .../fetch-network/intro-fetch-network.mdx | 6 +- pages/examples.mdx | 6 +- .../{intermediate => DeltaV}/dice-roll.mdx | 0 .../local-agent-registration.mdx | 0 .../running-an-agent-on-agentverse.mdx | 2 +- .../local-agent-langchain.mdx | 0 pages/examples/intermediate/_meta.json | 17 -- pages/guides/agent-courses/agents-for-ai.mdx | 2 +- .../CrewAI/creating-an-agent-with-crewai.mdx | 2 +- .../creating-an-agent-with-langchain.mdx | 2 +- pages/references.mdx | 26 ---- pages/references/_meta.json | 3 +- pages/references/indexer.mdx | 12 -- pages/references/indexer/_meta.json | 6 - pages/references/indexer/endpoints.mdx | 19 --- pages/references/indexer/entities.mdx | 32 ---- pages/references/indexer/querying.mdx | 147 ------------------ pages/references/indexer/versioning.mdx | 58 ------- 22 files changed, 29 insertions(+), 385 deletions(-) delete mode 100644 pages/concepts/fetch-network/indexer.mdx rename pages/examples/{intermediate => DeltaV}/dice-roll.mdx (100%) rename pages/examples/{intermediate => agentverse}/local-agent-registration.mdx (100%) rename pages/examples/{intermediate => examplestech}/local-agent-langchain.mdx (100%) delete mode 100644 pages/examples/intermediate/_meta.json delete mode 100644 pages/references/indexer.mdx delete mode 100644 pages/references/indexer/_meta.json delete mode 100644 pages/references/indexer/endpoints.mdx delete mode 100644 pages/references/indexer/entities.mdx delete mode 100644 pages/references/indexer/querying.mdx delete mode 100644 pages/references/indexer/versioning.mdx diff --git a/next.config.js b/next.config.js index a5f61efe4..e690f7582 100644 --- a/next.config.js +++ b/next.config.js @@ -636,6 +636,26 @@ module.exports = withNextra({ destination: "/examples/examplestech/jupyter-agent", permanent: true, }, + { + source: "/concepts/fetch-network/indexer", + destination: "/concepts/fetch-network/intro-fetch-network", + permanent: true, + }, + { + source: "/concepts/fetch-network/indexer/:path*", + destination: "/concepts/fetch-network/intro-fetch-network", + permanent: true, + }, + { + source: "/references/indexer", + destination: "/concepts/fetch-network/intro-fetch-network", + permanent: true, + }, + { + source: "/references/indexer/:path*", + destination: "/concepts/fetch-network/intro-fetch-network", + permanent: true, + }, ]; }, }); diff --git a/pages/concepts.mdx b/pages/concepts.mdx index dff89cc7c..23c56788d 100644 --- a/pages/concepts.mdx +++ b/pages/concepts.mdx @@ -98,16 +98,6 @@ import { AgentsIcon, AgentverseIcon ,FetchNetwork, LedgerIcon} from "src/icons/m path: "/concepts/fetch-network/ledger/validators", }, ], - }, - { - type: "Indexer", - icon: AgentsIcon, - data: [ - { - title: "Indexer: An Introduction", - path: "/concepts/fetch-network/indexer", - }, - ], } ]} /> diff --git a/pages/concepts/fetch-network/_meta.json b/pages/concepts/fetch-network/_meta.json index 20db84868..25e555241 100644 --- a/pages/concepts/fetch-network/_meta.json +++ b/pages/concepts/fetch-network/_meta.json @@ -8,6 +8,5 @@ "timestamp": true }, "almanac": { "title": "The Almanac contract", "timestamp": true }, - "ledger": { "title": "Ledger", "timestamp": true }, - "indexer": { "title": "Indexer", "timestamp": true } + "ledger": { "title": "Ledger", "timestamp": true } } diff --git a/pages/concepts/fetch-network/indexer.mdx b/pages/concepts/fetch-network/indexer.mdx deleted file mode 100644 index 955d62a39..000000000 --- a/pages/concepts/fetch-network/indexer.mdx +++ /dev/null @@ -1,41 +0,0 @@ -import { Callout } from 'nextra/components' - -# Indexer / Ledger SubQuery - -## Overview - -The **ledger-subquery** is a [SubQuery-based ↗️](https://www.subquery.network/) indexer for the [Fetch ledger ↗️](/concepts/fetch-network/ledger/intro). An indexer is a tool which allows to create a structured list of data items (i.e., an index) that allows to quickly search and retrieve information. In this context, the ledger-subquery acts as an indexer specifically designed to optimize data accessibility by providing a [Graphql ↗️](https://www.subquery.network/) API for querying tracked entities within the Fetch ledger. This enables direct and efficient retrieval of data, simplifying the process for developers who need to access information from the ledger. - -A detailed list of tracked entities is accessible via the [schema.graphql file ↗️](https://github.com/fetchai/ledger-subquery/blob/main/schema.graphql). - - - You can learn more on how to [run ↗️](https://academy.subquery.network/run_publish/run.html) or [change the SubQuery Project ↗️](https://academy.subquery.network/quickstart/quickstart_chains/cosmos.html), get your own custom GraphQL API for your app, by [visiting the SubQuery Academy ↗️](https://academy.subquery.network/) for further documentation. - - - - Check out the [GitHub repository ↗️](https://github.com/fetchai/ledger-subquery) or head over to the [Indexer references ↗️](/references#indexer) for additional information. - - -## Architecture: Components Diagram - -The ledger-subquery architecture comprises several key components that work together to provide a GraphQL API for querying data from the Fetch ledger, enabling efficient data retrieval and interaction with the Fetch ledger. - -Here, we outline the components and their relationships: - -![subquery architecture component diagram](../../../src/images/docs/indexer/architecture_legend_1.svg) - -![subquery architecture component diagram](../../../src/images/docs/indexer/architecture_legend_2.svg) - -### Key Components - -The system architecture core is the **SubQuery Node** and showcases a GraphQL-based interface for client interactions and a backend for data management and storage. - -The entry point for users to interact with the system is the **Public GraphQL Endpoint** through which they can submit GraphQL queries. The **Apollo Server** receives the GraphQL query and processes it based on the GraphQL schema generated by **Postgraphile**. This latter one acts as a translator between the structure of the PostgreSQL database (i.e., **PostgresDB**) and the GraphQL query language. It automatically generates a GraphQL schema based on the structure of the database which allows to efficiently query and manipulate data through the GraphQL interface. In few words, it simplifies the process of exposing the PostgresDB data as GraphQL APIs. - -The data retrieval process starts when the **SubQuery Node** receives the GraphQL query from the Apollo Server. Based on the query, the **Indexer Manager** and **Fetch service** work together within the SubQuery Node to efficiently retrieve and process the data. The **Indexer Manager** oversees the management of various indexers selecting the most suitable ones based on the incoming GraphQL query and coordinates their activities. Once the Indexer Manager identifies the required indexers, the **Fetch service** retrieves data from the specified sources to fetch the requested information (e.g., **Fetch Ledger Node**) thanks to the **public RPC endpoint** which works as the gateway to external data. Once the data is fetched, it is returned to the Indexer Manager for further processing and storage. - -The received data is the processed by the Indexer Manager and it is then stored by the **Store Service** in the PostgresDB. Indeed, the Store Service acts acts as the bridge between this two components by storing and retrieving data based on requests from the Indexer Manager. - -Once a query from the GraphQL API is received, the data requested is retrieved by the Store Service, which in turn fetches it from the PostgresDB through the **Private DB Connection**. By isolating the database interaction with this private connection, the system enhances security, performance, and reliability. The data is then formatted into a structure that aligns with the original GraphQL query by the SubQuery Node prepares this data in a format suitable for the GraphQL API to process and return it to the client. The data is then sent back to the Apollo Server. This last component takes in this data, combines it with the information from the GraphQL query, and constructs the final GraphQL response which is finally transmitted back to the client who initiated the query. - -This architecture enables efficient data retrieval and querying, providing a powerful tool for developers to interact with the Fetch ledger. diff --git a/pages/concepts/fetch-network/intro-fetch-network.mdx b/pages/concepts/fetch-network/intro-fetch-network.mdx index 02e4480c5..34de988aa 100644 --- a/pages/concepts/fetch-network/intro-fetch-network.mdx +++ b/pages/concepts/fetch-network/intro-fetch-network.mdx @@ -14,12 +14,10 @@ The Almanac facilitates remote communication between agents but also provides a The [Fetch Name Service (FNS) ↗️](/guides/agents/advanced/name-service) is another key element providing human-readable names for interacting with Agents and Functions. The FNS simplifies resource identification and makes it easier for developers and users to access agents and functions and thus enhancing overall user accessibility. -### Fetch Ledger and Indexer +### Fetch Ledger The [Fetch Ledger ↗️](/concepts/fetch-network/ledger/intro) is an additional central component of the Fetch Network. It provides a secure, decentralized, and transparent record of all transactions and data exchanges that take place within the Fetch Ecosystem itself. The Ledger uses the [FET token ↗️](/concepts/fetch-network/native-and-erc20-fet-tokens) to facilitate transactions, agent interactions, and smart contracts execution, but it also to ensure that the integrity and efficiency of the Network is maintained. -In order to enhance the Ledger data accessibility, the Fetch Network employs an [Indexer ↗️](/concepts/fetch-network/indexer) which is based on **SubQuery**. The aim of the Indexer is to organize and index the Ledger data and provide a GraphQL API to enable developers to efficiently query and retrieve information for their applications directly from the Fetch Ledger. - ### Jenesis An additional tool is [Jenesis ↗️](/guides/fetch-network/jenesis/getting-started); it simplifies the development and deployment of smart contracts and decentralized applications (i.e., dApps) on the Fetch Network and other CosmWasm-enabled platforms. Jenesis offers a streamlined environment for developers that reduces the complexity of building blockchain-based solutions and accelerates the deployment of decentralized services and applications. @@ -30,6 +28,6 @@ As a complementary tool to the above ones, [CosmPy ↗️](/guides/fetch-network ### Conclusions -These components together constitute the backbone structure of the Fetch Network. These tools are essential in enabling a decentralized economy of autonomous Agents and AI-driven Agent Functions. By leveraging the Fetch Ledger, Almanac Contract, FNS, Indexer, Jenesis, and CosmPy, the Fetch Network focuses on creating an environment where agents can autonomously manage tasks, interact with each other, and create value in a secure and scalable way. +These components together constitute the backbone structure of the Fetch Network. These tools are essential in enabling a decentralized economy of autonomous Agents and AI-driven Agent Functions. By leveraging the Fetch Ledger, Almanac Contract, FNS, Jenesis, and CosmPy, the Fetch Network focuses on creating an environment where agents can autonomously manage tasks, interact with each other, and create value in a secure and scalable way. The FET token empowers the Fetch Ecosystem, providing the economic incentive and governance framework necessary for the sustainability and evolution of the Network itself. The token acts both as the medium of exchange and the incentive structure for participants, while supporting the Network's governance and staking mechanisms. diff --git a/pages/examples.mdx b/pages/examples.mdx index d031f883b..97ca95901 100644 --- a/pages/examples.mdx +++ b/pages/examples.mdx @@ -128,10 +128,6 @@ import { AgentsIcon, LedgerIcon, AgentverseIcon} from "src/icons/main-page-icons title: "Agentverse Functions: register a coin toss function on DeltaV", path: "/examples/intermediate/coin-toss" }, - { - title: "Agentverse Functions: register a dice roll function on DeltaV", - path: "/examples/intermediate/dice-roll" - }, { title: "Agentverse Functions: register a local agent as a function", path: "/examples/local-agent-registration" @@ -146,7 +142,7 @@ import { AgentsIcon, LedgerIcon, AgentverseIcon} from "src/icons/main-page-icons }, { title: "Locally Hosted Agent with LangChain Integration", - path: "/examples/intermediate/local-agent-langchain" + path: "/examples/examplestech/local-agent-langchain" } ] }, diff --git a/pages/examples/intermediate/dice-roll.mdx b/pages/examples/DeltaV/dice-roll.mdx similarity index 100% rename from pages/examples/intermediate/dice-roll.mdx rename to pages/examples/DeltaV/dice-roll.mdx diff --git a/pages/examples/intermediate/local-agent-registration.mdx b/pages/examples/agentverse/local-agent-registration.mdx similarity index 100% rename from pages/examples/intermediate/local-agent-registration.mdx rename to pages/examples/agentverse/local-agent-registration.mdx diff --git a/pages/examples/agentverse/running-an-agent-on-agentverse.mdx b/pages/examples/agentverse/running-an-agent-on-agentverse.mdx index 370c9e15c..17dbf8a97 100644 --- a/pages/examples/agentverse/running-an-agent-on-agentverse.mdx +++ b/pages/examples/agentverse/running-an-agent-on-agentverse.mdx @@ -178,7 +178,7 @@ Let's consider the following local agent example: You can create a Mailbox by retrieving your **local agent address** and head over to the **Agentverse: My Agents** tab. Click on **Local Agents** and click on **Connect Local Agent** button. Provide the address and name of the local agent you wish to retrieve and wait for confirmation. You will then be able to see a **Mailbox API Key**. Copy and paste it within your local agent code by filling up the `AGENT_MAILBOX_KEY` field inline and restart the agent. -For an example of a complete code for a local agent with protocols registered on the Agentverse using the Mailbox feature, checkout this [example ↗️](/examples/intermediate/local-agent-langchain). +For an example of a complete code for a local agent with protocols registered on the Agentverse using the Mailbox feature, checkout this [example ↗️](/examples/examplestech/local-agent-langchain). When running the above local agent, you will see something like this on your terminal: diff --git a/pages/examples/intermediate/local-agent-langchain.mdx b/pages/examples/examplestech/local-agent-langchain.mdx similarity index 100% rename from pages/examples/intermediate/local-agent-langchain.mdx rename to pages/examples/examplestech/local-agent-langchain.mdx diff --git a/pages/examples/intermediate/_meta.json b/pages/examples/intermediate/_meta.json deleted file mode 100644 index 8a2ff7921..000000000 --- a/pages/examples/intermediate/_meta.json +++ /dev/null @@ -1,17 +0,0 @@ -{ - "dice-roll": { - "title": "Register a dice roll Agent as a Function [Intermediate]", - "tags": ["Intermediate", "Python", "Functions", "Hosted"], - "timestamp": true - }, - "local-agent-registration": { - "title": "Register a local Agent as a Function [Intermediate]", - "tags": ["Advanced", "Python", "Functions", "Local"], - "timestamp": true - }, - "local-agent-langchain": { - "title": "Locally Hosted Agent with LangChain Integration [Intermediate]", - "tags": ["Intermediate", "Python", "Functions", "LangChain", "Local"], - "timestamp": true - } -} diff --git a/pages/guides/agent-courses/agents-for-ai.mdx b/pages/guides/agent-courses/agents-for-ai.mdx index 386c4e169..aff852843 100644 --- a/pages/guides/agent-courses/agents-for-ai.mdx +++ b/pages/guides/agent-courses/agents-for-ai.mdx @@ -240,7 +240,7 @@ There are a lot of really cool, neat things you need to know from code above. Le - `OPENAI_API_KEY` is our API key to OpenAI's APIs. -We can now initialize the Agent and define the [Protocol ↗️](/references/uagents/uagents-protocols/agent-protocols). To read more about **Agent objects**, please check out [the reference docs ↗️](/references/uagents/uagents-api/agent#agent-objects). +We can now initialize the Agent and define the [Protocol ↗️](/references/uagents/uagents-protocols/agent-protocols). To read more about **Agent objects**, please check out [the reference docs ↗️](/references/uagents/api/agent#agent-objects). Then, we have the `on_message()` [handler ↗️](/guides/agents/intermediate/handlers): diff --git a/pages/guides/quickstart-with/CrewAI/creating-an-agent-with-crewai.mdx b/pages/guides/quickstart-with/CrewAI/creating-an-agent-with-crewai.mdx index 5637867db..dc2f844ed 100644 --- a/pages/guides/quickstart-with/CrewAI/creating-an-agent-with-crewai.mdx +++ b/pages/guides/quickstart-with/CrewAI/creating-an-agent-with-crewai.mdx @@ -186,7 +186,7 @@ Agents are defined with the `Agent` class: A `seed` is a unique phrase which `uagents` library uses to create a unique private key pair for your agent. If you change your `seed` you may lose access to previous messages, and also, the agent's address registered to the Almanac will change subsequently. The `port` allows us to define a local port for messages to be received. The `endpoint` defines the path to the in-built Rest API. The `name` defines the name of the agent. -There are more options for the `Agent` class; see [`Agent` Class ↗️](/references/uagents/uagents-api/agent) for further reference. +There are more options for the `Agent` class; see [`Agent` Class ↗️](/references/uagents/api/agent) for further reference. We then need to define our **communication model**: diff --git a/pages/guides/quickstart-with/langchain/creating-an-agent-with-langchain.mdx b/pages/guides/quickstart-with/langchain/creating-an-agent-with-langchain.mdx index d2c0ab979..d5becefc0 100644 --- a/pages/guides/quickstart-with/langchain/creating-an-agent-with-langchain.mdx +++ b/pages/guides/quickstart-with/langchain/creating-an-agent-with-langchain.mdx @@ -136,7 +136,7 @@ Agents are defined with the `Agent` class: A `seed` is a unique phrase which `uagents` library uses to create a unique private key pair for your agent. If you change your `seed` you may lose access to previous messages, and also, the agent's address registered to the Almanac will change subsequently. The `port` allows us to define a local port for messages to be received. The `endpoint` defines the path to the in-built Rest API. The `name` defines the name of the agent. -There are more options for the `Agent` class; see [`Agent` Class ↗️](/references/uagents/uagents-api/agent) for further reference. +There are more options for the `Agent` class; see [`Agent` Class ↗️](/references/uagents/api/agent) for further reference. We then need to define our communication model: diff --git a/pages/references.mdx b/pages/references.mdx index 7df53e214..81bf78780 100644 --- a/pages/references.mdx +++ b/pages/references.mdx @@ -108,32 +108,6 @@ import { AgentsIcon, LedgerIcon , AsiIcon} from "src/icons/main-page-icons" path: "/references/cosmpy/wallet-generation", } ] - }, - { - type: "Indexer", - icon: AgentsIcon, - data: [ - { - title: "Indexer", - path: "/references/indexer", - }, - { - title: "Endpoints / Playground UIs", - path: "/references/indexer/endpoints", - }, - { - title: "Querying", - path: "/references/indexer/querying", - }, - { - title: "Versioning", - path: "/references/indexer/versioning", - }, - { - title: "Entities", - path: "/references/indexer/entities", - } - ] } ]} /> diff --git a/pages/references/_meta.json b/pages/references/_meta.json index fcb14b59e..87427f56a 100644 --- a/pages/references/_meta.json +++ b/pages/references/_meta.json @@ -3,6 +3,5 @@ "uagents": "Agents: uAgents Framework", "agentverse": "Agentverse", "ledger": "Ledger", - "cosmpy": "CosmPy API", - "indexer": "Indexer" + "cosmpy": "CosmPy API" } diff --git a/pages/references/indexer.mdx b/pages/references/indexer.mdx deleted file mode 100644 index ad035bb4e..000000000 --- a/pages/references/indexer.mdx +++ /dev/null @@ -1,12 +0,0 @@ -# Indexer Documentation Index - -**Introduction**: - -- [Overview and Architecture ↗️](/concepts/fetch-network/indexer) - -**Resources**: - -- [Endpoints / Playground UIs ↗️](/references/indexer/endpoints) -- [Entities ↗️](/references/indexer/entities) -- [Querying ↗️](/references/indexer/querying) -- [Versioning ↗️](/references/indexer/versioning) diff --git a/pages/references/indexer/_meta.json b/pages/references/indexer/_meta.json deleted file mode 100644 index cf49f2e4c..000000000 --- a/pages/references/indexer/_meta.json +++ /dev/null @@ -1,6 +0,0 @@ -{ - "endpoints": { "title": "Endpoints / Playground UIs", "timestamp": true }, - "querying": { "title": "Querying", "timestamp": true }, - "entities": { "title": "Entities", "timestamp": true }, - "versioning": { "title": "Versioning", "timestamp": true } -} diff --git a/pages/references/indexer/endpoints.mdx b/pages/references/indexer/endpoints.mdx deleted file mode 100644 index a91b4f8ad..000000000 --- a/pages/references/indexer/endpoints.mdx +++ /dev/null @@ -1,19 +0,0 @@ -## Endpoints / Playground UIs - -The graphql API endpoints serve a playground UI to browsers for convenience. This UI is useful for rapid experimentation and iteration of queries as well as just getting some results. Features include: - - - Real-time query results. - - Query editor: - - - Auto-complete & validation via schema introspection. - - Can store multiple, named queries. - - Supports graphql variables. - - - Local persistence of query editor contents. - - Schema reference. - - Graphql docs reference. - -| Network | API / Playground URL | -| --- | --- | -| Fetchhub (mainnet) | https://subquery.fetch.ai ↗️ | -| Dorado (testnet) | https://subquery-dorado.fetch.ai ↗️ | diff --git a/pages/references/indexer/entities.mdx b/pages/references/indexer/entities.mdx deleted file mode 100644 index f79cab4e7..000000000 --- a/pages/references/indexer/entities.mdx +++ /dev/null @@ -1,32 +0,0 @@ -# Entities - -## Introduction - -An entity refers to a specific type of data that the indexer keeps track of. These entities can range from fundamental building blocks such as blocks, transactions, and messages to more complex constructs. Anyway, each entity type has its own attributes and relationships, making it a fundamental unit of information within the system. - -Entities tracked by the indexer exist at varying levels of abstraction. "Lower-level" entities include the [primitives ↗️](/references/indexer/entities#primitive-entities) (i.e. blocks, transactions, messages, and events), upon which "higher-level" entities are constructed (e.g. LegacyBridgeSwaps). - -Some entities are derived from objects which do not correspond to any network state change (e.g. failed transactions and their messages). - -In the case of failed transactions, it is desirable to index the associated data for end-user reference. -This notion may also apply to other objects but should be considered carefully to avoid storing invalid or useless data. - -## Primitive entities - -If you wish to have additional information, visit [schema.graphql ↗️](https://github.com/ledger-subquery/blob/main/schema.graphql). - -Primitive entities include: - - - blocks - - transactions - - messages - - events - - event attributes - -## Entity relationship diagrams - -![entity relationship diagram legend](../../../src/images/docs/indexer/entities_legend_1.svg) - -![entity database relationship diagram](../../../src/images/docs/indexer/entities_legend_2.svg) - -![entity api relationship diagram](../../../src/images/docs/indexer/entities_legend_3.svg) diff --git a/pages/references/indexer/querying.mdx b/pages/references/indexer/querying.mdx deleted file mode 100644 index 0d55378a0..000000000 --- a/pages/references/indexer/querying.mdx +++ /dev/null @@ -1,147 +0,0 @@ -import { Callout } from 'nextra/components' - -# Querying - -The graphql API relies heavily on [postgraphile ↗️](https://www.graphile.org/postgraphile/usage-library/) (as a library) to resolve graphql requests. - -Postgraphile plugins also play a critical role. In particular, the [connection-filter ↗️](https://github.com/graphile-contrib/postgraphile-plugin-connection-filter) and [pg-aggregates ↗️](https://github.com/graphile/pg-aggregates) plugins. - -## Pagination - -The graphql API implements [the connections specification ↗️](https://relay.dev/graphql/connections.htm) for pagination. For further information, have a look at [GraphQL pagination docs ↗️](https://graphql.org/learn/pagination/#end-of-list-counts-and-connections). - - - It is recommended to prefer using pagination operators by default (e.g. `first: `) to avoid unnecessary delays in query responses. - - -## Filtering - -Filtering is facilitated by [postgraphile ↗️](https://www.graphile.org/postgraphile/usage-library/) and its plugins. For specifics on supported operators and how to use them, please refer to their documentation: - - - [Connection-filter plugin ↗️](https://github.com/graphile-contrib/postgraphile-plugin-connection-filter) - - [Operators ↗️](https://github.com/graphile-contrib/postgraphile-plugin-connection-filter/blob/master/docs/operators.md#json-jsonb) - - [Query examples ↗️](https://github.com/graphile-contrib/postgraphile-plugin-connection-filter/blob/master/docs/examples.md) - -### Examples - -1. Filtering `NativeTransfers` for a given sender address: - - ```graphql - query nativeTransfersFromAddress { - nativeTransfers(first: 5, filter: { - fromAddress: { - equalTo: "fetch1t3qet68dr0qkmrjtq89lrx837qa2t05265qy6s" - } - }) { - nodes { - toAddress - amounts - } - } - } - ``` - -2. Filtering for `Messages` from a given sender address: - - ```graphql - query messagesFromAddress { - messages (first: 5, filter: { - transaction: { - signerAddress: { - equalTo: "fetch1t3qet68dr0qkmrjtq89lrx837qa2t05265qy6s" - } - } - }) { - nodes { - transaction { - signerAddress - } - } - } - } - ``` - -3. Filtering on `Events` within a given time frame and with a given type: - - ```graphql - query transferEventsDuring { - events(first: 5, filter: { - block: { - timestamp: { - greaterThanOrEqualTo: "2022-09-15T01:44:13.719", - lessThanOrEqualTo: "2022-09-19T02:15:28.632" - } - }, - type: {equalTo: "transfer"}, - }) { - nodes { - attributes { - nodes { - key - value - } - } - } - } - } - ``` - -## Order by / Sorting - -Each entity, by default, can be sorted by any of its respective fields. Additional support for ordering by certain fields on related entities is facilitated by custom ordering plugins generated from `makeAddPgTableOrderByPlugin`. Have a look at [postgraphile-docs ↗️](https://www.graphile.org/postgraphile/make-add-pg-table-order-by-plugin/) for additional information. - -### Block height - -Any entity which relates to `Block` can be ordered by a related block's `height` field: - - ```graphql - query contractExecByBlockHeight { - contractExecutionMessage (orderBy: EXECUTE_CONTRACT_MESSAGES_BY_BLOCK_HEIGHT_ASC) { - nodes { - id, - ... - Block { - height - } - } - } - } - ``` - -### Contract code ID - -The `contract` entity can be sorted by `codeId` through the `storeMessage` and `instantiateMessage` relations: - - ```graphql - query contractsByRelatedCodeID { - contracts (orderBy: CONTRACTS_BY_STORE_CONTRACT_MESSAGES_CODE_ID_ASC) { - # or CONTRACTS_BY_INSTANTIATE_CONTRACT_MESSAGES_CODE_ID_ASC - nodes { - id, - ... - storeMessage { - codeId - } - } - } - } - ``` - -### Order direction - -Each of these custom orders are implemented in both directions, ascending and descending. These directions are accessed through the ending characters of the order enum, by choosing either `_ASC` and `_DESC`. - -## Aggregation - -Aggregation is facilitated by the [pg-aggregates plugin ↗️](https://github.com/graphile/pg-aggregates). -Features include: - - - calculating aggregates - - grouped aggregates - - applying conditions to grouped aggregates - - ordering by relational aggregates - - filtering by the results of aggregates on related connections - -## Tests as examples - -Additional examples of queries and use cases can be found in the [end-to-end test suite ↗️](https://github.com/fetchai/ledger-subquery/tree/main/tests). diff --git a/pages/references/indexer/versioning.mdx b/pages/references/indexer/versioning.mdx deleted file mode 100644 index e03a82b19..000000000 --- a/pages/references/indexer/versioning.mdx +++ /dev/null @@ -1,58 +0,0 @@ -# Versioning - -The versions of both the GraphQL API and the Indexer itself can be retrieved simply using the following query on the GraphQL playground. - -## Example - - ```graphql - query ReleaseVersionTest { - _metadata { - queryNodeVersion - indexerNodeVersion - } - } - ``` - -Each of these version numbers are stored as the value to the key `"version"` within their relevant module `package.json` file. These files can be found in the `docker/node-cosmos/` and `subql/packages/query/` directories for the Indexer and GraphQL versions, respectively. - - ```yaml - // The Indexer version number, taken from "docker/node-cosmos/package.json" - { - "name": "@subql/node-cosmos", - "version": "1.0.0", - ... - } - ``` - -### The __metadata_ entity - -The `_metadata` entity has further utility beyond the scope of the example query given prior. Using any of the relevant fields from the type definition below, internal states and config information can be retrieved with ease. - - ``` - type _metadata { - lastProcessedHeight: Int - lastProcessedTimestamp: Date - targetHeight: Int - chain: String - specName: String - genesisHash: String - indexerHealthy: Boolean - indexerNodeVersion: String - queryNodeVersion: String - rowCountEstimate: [TableEstimate] - dynamicDatasources: String - } - ``` - -#### Example - -If a developer is curious about the `chain-id` or whether the Indexer has passed any health checks, he can use `indexerHealthy`. These values can be returned within the playground or otherwise connected projects. - - ```graphql - query ReleaseVersionTest { - _metadata { - chain - indexerHealthy - } - } - ```