You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: website/src/pages/en/subgraphs/querying/graphql-api.mdx
+46-48Lines changed: 46 additions & 48 deletions
Original file line number
Diff line number
Diff line change
@@ -2,21 +2,35 @@
2
2
title: GraphQL API
3
3
---
4
4
5
-
Learn about the GraphQL Query API used in The Graph.
5
+
Explore the GraphQL Query API for interacting with Subgraphs on The Graph Network.
6
6
7
7
## What is GraphQL?
8
8
9
9
[GraphQL](https://graphql.org/learn/) is a query language for APIs and a runtime for executing those queries with your existing data. The Graph uses GraphQL to query Subgraphs.
10
10
11
-
To understand the larger role that GraphQL plays, review [developing](/subgraphs/developing/introduction/) and [creating a Subgraph](/developing/creating-a-subgraph/).
11
+
## Core Concepts
12
+
13
+
### Entities
14
+
15
+
-**What they are**: Persistent data objects defined with `@entity` in your schema
16
+
-**Key requirement**: Must contain `id: ID!` as primary identifier
17
+
-**Usage**: Foundation for all query operations
18
+
19
+
### Schema
20
+
21
+
-**Purpose**: Blueprint defining the data structure and relationships using GraphQL [IDL](https://facebook.github.io/graphql/draft/#sec-Type-System)
22
+
-**Key characteristics**:
23
+
- Auto-generates query endpoints
24
+
- Read-only operations (no mutations)
25
+
- Defines entity interfaces and derived fields
12
26
13
27
## Queries with GraphQL
14
28
15
-
In your Subgraph schema you define types called `Entities`. For each `Entity` type, `entity` and `entities` fields will be generated on the top-level `Query` type.
29
+
In the Subgraph schema, types called `Entities`. For each `Entity` type, `entity` and `entities` fields will be generated on the top-level `Query` type.
16
30
17
-
> Note: `query` does not need to be included at the top of the `graphql` query when using The Graph.
31
+
### Example Queries
18
32
19
-
### Examples
33
+
> Note: `query` does not need to be included at the top of the `graphql` query when using The Graph.
20
34
21
35
Query for a single `Token` entity defined in your schema:
22
36
@@ -44,7 +58,7 @@ Query all `Token` entities:
44
58
45
59
### Sorting
46
60
47
-
When querying a collection, you may:
61
+
When querying a collection, you can:
48
62
49
63
- Use the `orderBy` parameter to sort by a specific attribute.
50
64
- Use the `orderDirection` to specify the sort direction, `asc` for ascending or `desc` for descending.
@@ -60,7 +74,7 @@ When querying a collection, you may:
60
74
}
61
75
```
62
76
63
-
#### Example for nested entity sorting
77
+
#### Example for Nested Entity Sorting
64
78
65
79
As of Graph Node [`v0.30.0`](https://github.com/graphprotocol/graph-node/releases/tag/v0.30.0) entities can be sorted on the basis of nested entities.
66
80
@@ -88,7 +102,7 @@ When querying a collection, it's best to:
88
102
- Use the `skip` parameter to skip entities and paginate. For instance, `first:100` shows the first 100 entities and `first:100, skip:100` shows the next 100 entities.
89
103
- Avoid using `skip` values in queries because they generally perform poorly. To retrieve a large number of items, it's best to page through entities based on an attribute as shown in the previous example above.
90
104
91
-
#### Example using`first`
105
+
#### Example Using`first`
92
106
93
107
Query the first 10 tokens:
94
108
@@ -101,9 +115,9 @@ Query the first 10 tokens:
101
115
}
102
116
```
103
117
104
-
To query for groups of entities in the middle of a collection, the `skip` parameter may be used in conjunction with the `first` parameter to skip a specified number of entities starting at the beginning of the collection.
118
+
To query for groups of entities in the middle of a collection, the `skip` parameter can be used in conjunction with the `first` parameter to skip a specified number of entities starting at the beginning of the collection.
105
119
106
-
#### Example using`first` and `skip`
120
+
#### Example Using`first` and `skip`
107
121
108
122
Query 10 `Token` entities, offset by 10 places from the beginning of the collection:
109
123
@@ -116,7 +130,7 @@ Query 10 `Token` entities, offset by 10 places from the beginning of the collect
116
130
}
117
131
```
118
132
119
-
#### Example using`first` and `id_ge`
133
+
#### Example Using`first` and `id_ge`
120
134
121
135
If a client needs to retrieve a large number of entities, it's more performant to base queries on an attribute and filter by that attribute. For example, a client could retrieve a large number of tokens using this query:
122
136
@@ -136,9 +150,9 @@ The first time, it would send the query with `lastID = ""`, and for subsequent r
136
150
- You can use the `where` parameter in your queries to filter for different properties.
137
151
- You can filter on multiple values within the `where` parameter.
138
152
139
-
#### Example using `where`
153
+
#### Using `where` Filtering
140
154
141
-
Query challenges with `failed` outcome:
155
+
Query challenges with `failed` outcome using 'where' filter:
142
156
143
157
```graphql
144
158
{
@@ -154,7 +168,7 @@ Query challenges with `failed` outcome:
154
168
155
169
You can use suffixes like `_gt`, `_lte` for value comparison:
156
170
157
-
#### Example for range filtering
171
+
#### Range Filtering
158
172
159
173
```graphql
160
174
{
@@ -166,7 +180,7 @@ You can use suffixes like `_gt`, `_lte` for value comparison:
166
180
}
167
181
```
168
182
169
-
#### Example for block filtering
183
+
#### Block Filtering
170
184
171
185
You can also filter entities that were updated in or after a specified block with `_change_block(number_gte: Int)`.
172
186
@@ -182,7 +196,7 @@ This can be useful if you are looking to fetch only entities which have changed,
182
196
}
183
197
```
184
198
185
-
#### Example for nested entity filtering
199
+
#### Nested Entity Filtering
186
200
187
201
Filtering on the basis of nested entities is possible in the fields with the `_` suffix.
188
202
@@ -200,11 +214,11 @@ This can be useful if you are looking to fetch only entities whose child-level e
200
214
}
201
215
```
202
216
203
-
####Logical operators
217
+
### Logical Operators
204
218
205
219
As of Graph Node [`v0.30.0`](https://github.com/graphprotocol/graph-node/releases/tag/v0.30.0) you can group multiple parameters in the same `where` argument using the `and` or the `or` operators to filter results based on more than one criteria.
206
220
207
-
##### `AND` Operator
221
+
####Using `and` Operator
208
222
209
223
The following example filters for challenges with `outcome``succeeded` and `number` greater than or equal to `100`.
210
224
@@ -234,7 +248,7 @@ The following example filters for challenges with `outcome` `succeeded` and `num
234
248
> }
235
249
> ```
236
250
237
-
##### `OR` Operator
251
+
#### Using `or` Operator
238
252
239
253
Thefollowingexamplefiltersforchallengeswith `outcome` `succeeded` or `number` greaterthanorequalto `100`.
240
254
@@ -250,7 +264,7 @@ The following example filters for challenges with `outcome` `succeeded` or `numb
250
264
}
251
265
```
252
266
253
-
> **Note**: When constructing queries, it is important to consider the performance impact of using the `or` operator. While `or` can be a useful tool for broadening search results, it can also have significant costs. One of the main issues with `or` is that it can cause queries to slow down. This is because `or` requires the database to scan through multiple indexes, which can be a time-consuming process. To avoid these issues, it is recommended that developers use and operators instead of or whenever possible. This allows for more precise filtering and can lead to faster, more accurate queries.
267
+
> **Note**: When writing queries, it is important to consider the performance impact of using the `or` operator. While `or` can be a useful tool for broadening search results, it can also have significant costs. One of the main issues with `or` is that it can cause queries to slow down. This is because `or` requires the database to scan through multiple indexes, which can be a time-consuming process. To avoid these issues, it is recommended that developers use and operators instead of or whenever possible. This allows for more precise filtering and can lead to faster, more accurate queries.
254
268
255
269
#### All Filters
256
270
@@ -287,15 +301,15 @@ In addition, the following global filters are available as part of `where` argum
287
301
_change_block(number_gte: Int)
288
302
```
289
303
290
-
### Time-travel queries
304
+
### Time-travel Queries
291
305
292
306
You can query the state of your entities not just for the latest block, which is the default, but also for an arbitrary block in the past. The block at which a query should happen can be specified either by its block number or its block hash by including a `block` argument in the toplevel fields of queries.
293
307
294
308
The result of such a query will not change over time, i.e., querying at a certain past block will return the same result no matter when it is executed, with the exception that if you query at a block very close to the head of the chain, the result might change if that block turns out to **not** be on the main chain and the chain gets reorganized. Once a block can be considered final, the result of the query will not change.
295
309
296
310
> Note: The current implementation is still subject to certain limitations that might violate these guarantees. The implementation can not always tell that a given block hash is not on the main chain at all, or if a query result by a block hash for a block that is not yet considered final could be influenced by a block reorganization running concurrently with the query. They do not affect the results of queries by block hash when the block is final and known to be on the main chain. [This issue](https://github.com/graphprotocol/graph-node/issues/1405) explains what these limitations are in detail.
297
311
298
-
#### Example
312
+
#### Example Time-travel Queries
299
313
300
314
```graphql
301
315
{
@@ -311,8 +325,6 @@ The result of such a query will not change over time, i.e., querying at a certai
311
325
312
326
This query will return `Challenge` entities, and their associated `Application` entities, as they existed directly after processing block number 8,000,000.
@@ -327,24 +339,24 @@ This query will return `Challenge` entities, and their associated `Application`
327
339
328
340
This query will return `Challenge` entities, and their associated `Application` entities, as they existed directly after processing the block with the given hash.
329
341
330
-
### Fulltext Search Queries
342
+
### Full-text Search Queries
331
343
332
-
Fulltext search query fields provide an expressive text search API that can be added to the Subgraph schema and customized. Refer to [Defining Fulltext Search Fields](/developing/creating-a-subgraph/#defining-fulltext-search-fields) to add fulltext search to your Subgraph.
344
+
Full-text search query fields provide an expressive text search API that can be added to the Subgraph schema and customized. Refer to [Defining Full-text Search Fields](/developing/creating-a-subgraph/#defining-fulltext-search-fields) to add full-text search to your Subgraph.
333
345
334
-
Fulltext search queries have one required field, `text`, for supplying search terms. Several special fulltext operators are available to be used in this `text` search field.
346
+
Full-text search queries have one required field, `text`, for supplying search terms. Several special full-text operators are available to be used in this `text` search field.
335
347
336
-
Fulltext search operators:
348
+
Full-text search operators:
337
349
338
350
| Symbol | Operator | Description |
339
-
| --- | --- | --- |
351
+
| --- | --- | --- | --- |
340
352
|`&`|`And`| For combining multiple search terms into a filter for entities that include all of the provided terms |
341
-
|||`Or`| Queries with multiple search terms separated by the or operator will return all entities with a match from any of the provided terms |
353
+
|||`Or`| Queries with multiple search terms separated by the or operator will return all entities with a match from any of the provided terms |
342
354
|`<->`|`Follow by`| Specify the distance between two words. |
343
355
|`:*`|`Prefix`| Use the prefix search term to find words whose prefix match (2 characters required.) |
344
356
345
-
#### Examples
357
+
#### Full-text Query Examples
346
358
347
-
Using the `or` operator, this query will filter to blog entities with variations of either "anarchism" or "crumpet" in their fulltext fields.
359
+
Using the `or` operator, this query will filter to blog entities with variations of either "anarchism" or "crumpet" in their full-text fields.
348
360
349
361
```graphql
350
362
{
@@ -357,7 +369,7 @@ Using the `or` operator, this query will filter to blog entities with variations
357
369
}
358
370
```
359
371
360
-
The `follow by` operator specifies a words a specific distance apart in the fulltext documents. The following query will return all blogs with variations of "decentralize" followed by "philosophy"
372
+
The `follow by` operator specifies that two words must appear a specific distance apart in full-text documents.. The following query will return all blogs with variations of "decentralize" followed by "philosophy"
361
373
362
374
```graphql
363
375
{
@@ -370,7 +382,7 @@ The `follow by` operator specifies a words a specific distance apart in the full
370
382
}
371
383
```
372
384
373
-
Combine fulltext operators to make more complex filters. With a pretext search operator combined with a follow by this example query will match all blog entities with words that start with "lou" followed by "music".
385
+
Combine full-text operators to make more complex filters. With a pretext search operator combined with a follow by this example query will match all blog entities with words that start with "lou" followed by "music".
374
386
375
387
```graphql
376
388
{
@@ -387,20 +399,6 @@ Combine fulltext operators to make more complex filters. With a pretext search o
387
399
388
400
Graph Node implements [specification-based](https://spec.graphql.org/October2021/#sec-Validation) validation of the GraphQL queries it receives using [graphql-tools-rs](https://github.com/dotansimha/graphql-tools-rs#validation-rules), which is based on the [graphql-js reference implementation](https://github.com/graphql/graphql-js/tree/main/src/validation). Queries which fail a validation rule do so with a standard error - visit the [GraphQL spec](https://spec.graphql.org/October2021/#sec-Validation) to learn more.
389
401
390
-
## Schema
391
-
392
-
The schema of your dataSources, i.e. the entity types, values, and relationships that are available to query, are defined through the [GraphQL Interface Definition Language (IDL)](https://facebook.github.io/graphql/draft/#sec-Type-System).
393
-
394
-
GraphQL schemas generally define root types for `queries`, `subscriptions` and `mutations`. The Graph only supports `queries`. The root `Query` type for your Subgraph is automatically generated from the GraphQL schema that's included in your [Subgraph manifest](/developing/creating-a-subgraph/#components-of-a-subgraph).
395
-
396
-
> Note: Our API does not expose mutations because developers are expected to issue transactions directly against the underlying blockchain from their applications.
397
-
398
-
### Entities
399
-
400
-
All GraphQL types with `@entity` directives in your schema will be treated as entities and must have an `ID` field.
401
-
402
-
> **Note:** Currently, all types in your schema must have an `@entity` directive. In the future, we will treat types without an `@entity` directive as value objects, but this is not yet supported.
403
-
404
402
### Subgraph Metadata
405
403
406
404
All Subgraphs have an auto-generated `_Meta_` object, which provides access to Subgraph metadata. This can be queried as follows:
0 commit comments