Subscribe to smth0x
<100 subscribers
Share Dialog
Share Dialog
Джерело - link
Маючи понад 40 000 розгорнутих підграфів та більше тисячі підграфів, опублікованих в мережі The Graph, The Graph зарекомендував себе як найважливіший постачальник децентралізованих даних для web3. Магія The Graph обертається навколо підграфів: стандартизований рецепт ETLQ (Extract-Transform-Load-Query) для блокчейн-даних, які, будучи опублікованими в мережі The Graph і проіндексованими індексаторами, дозволяють користувачам запитувати попередньо змодельовані дані за допомогою GraphQL API. Від панелі аналітики Uniswap до DefiLlama, незліченна кількість децентралізованих додатків у web3 використовують The Graph та підграфи для надійного та ефективного отримання даних.
Однак факт залишається фактом - підграфи та великий обсяг даних, який вони надають, були розроблені для споживання в першу чергу фронтенд-додатками, а тому не є оптимальними для типового випадку використання для аналізу даних. У цій статті ми розповімо про те, як ми в Playgrounds Analytics розкриваємо потенціал The Graph для різноманітних випадків використання для аналізу даних. Більшість методів, розглянутих у цій статті, реалізовані в нашій бібліотеці Subgrounds з відкритим вихідним кодом Python, але я спробую зберегти агностичний підхід до її реалізації.
Використання інтроспекції Schema
Однією з найбільших переваг GraphQL порівняно з іншими стандартами API, такими як REST, є вбудована можливість інтроспекції (тобто запит структури самого API) в GraphQL.
Це означає, що ви можете не тільки запитувати дані з GraphQL API, але й запитувати метадані про API, такі як список всіх об’єктів, доступних на підграфі, або список параметрів фільтрування, які можна використовувати в запиті.
Наприклад, щоб отримати список усіх типів, визначених для даного API GraphQL, а також їхніх полів (якщо цей тип є об'єктом, тобто типом entity), ви можете зробити запит до метаполя __schema таким чином:
query {
__schema {
types {
name
kind
fields {
name
}
}
}
}
Виконання цього запиту на офіційному підграфі Uniswap V3 поверне наступні метадані (примітка: нижче показані тільки метадані для типу UniswapDayData для стислості).
{
"data": {
"__schema": {
"types": [
// …
{
"name": "UniswapDayData",
"kind": "OBJECT",
"fields": [
{
"name": "id"
},
{
"name": "date"
},
{
"name": "volumeETH"
},
{
"name": "volumeUSD"
},
{
"name": "volumeUSDUntracked"
},
{
"name": "feesUSD"
},
{
"name": "txCount"
},
{
"name": "tvlUSD"
}
]
}
]
}
}
}
Повний запит інтроспекції, який отримує всі метадані API GraphQL, ви можете знайти тут. (примітка: цей самий запит інтроспекції працює для всіх GraphQL API, а не тільки для підграфів!).
Інтроспекція GraphQL API відкриває багато корисних можливостей для аналізу даних, але ми зосередимося на двох з них і на тому, як Subgrounds їх реалізує, а саме на автоматичному створенні запитів і перевірці/конверсації типів.
Автоматичне створення запитів
У той час як розробник, який пише фронтенд-додаток на основі підграфів, вже знає, які дані і запити йому потрібні для досягнення своєї мети, для аналітика даних все по іншому. Він повинен спочатку дослідити дані, щоб проаналізувати їх. Найкращий спосіб досягти цього - витягнути якомога більше даних у потрібне середовище для обробки і використовувати його для дослідження даних.
Цей процес спрощується за допомогою інтроспекції shema, оскільки можна програмно заповнити вибірку GraphQL усіма доступними підполями. Наприклад, повертаючись до підграфа Uniswap V3, враховуючи перший неповний запит на uniswapDayDatas нижче, ми можемо використати результат нашого запиту інтроспекції вище, щоб вибрати всі підполя поля верхнього рівня uniswapDayDatas, таким чином запитуючи всі доступні дані, пов'язані з цим типом entity.
query {
uniswapDayDatas {
id
date
volumeETH
volumeUSD
volumeUSDUntracked
feesUSD
txCount
tvlUSD
}
}
Це аналогічно запиту SQL SELECT * FROM uniswapDayDatas.
Конвертація типів
Інтроспекція GraphQL також дозволяє нам виконувати розумну конвертацію типів, що особливо корисно, коли ми маємо справу з великими числами.
Багато активів web3, таких як токени ERC-20, часто діляться на дуже велику кількість десяткових знаків (найчастіше 18 десяткових знаків), що призводить до транзакцій, які містять дуже великі числа, які не можуть бути представлені звичайним 32-бітним цілим числом. Підграфи представляють ці великі числа за допомогою типів BigInt і BigDecimal, які відрізняються від стандартних типів Int і Float тим, що значення подаються у вигляді рядків при запиті через GraphQL.
Використовуючи інтроспекцію GraphQL, можна визначити, які рядки в відповіді на запит даних насправді є числовими значеннями (і, отже, повинні бути конвертовані на відповідний тип на стороні клієнта), а які рядки є "справжніми" рядками.
Автоматична пагінація
Основною проблемою для аналітиків даних, які працюють з підграфами, є запит великих обсягів даних для побудови змістовного аналізу. Причиною цього є те, що підграфи дозволяють розробникам запитувати лише 1000 об’єктів (тобто рядків) за один запит. Для більшості фронтенд-додатків, де ви рідко відображатимете більше кількох на сторінці, це не є проблемою. Однак, щоб виконати належний аналіз даних, вам часто потрібно набагато більше даних, а це означає, що пагінація необхідна.
Найкращий спосіб пагінації всіх об'єктів у певній колекції, як зазначено в документації The Graph, це використовувати унікальне поле (зазвичай id об'єкта) як курсор і збільшувати цей курсор для отримання кожної наступної порції даних. Ось як може виглядати цей процес:
1. Напишіть запит з фільтром на вашому унікальному полі, щоб кількість сутностей для запиту і значення фільтра можна було встановити як змінні. Переконайтеся, що порядок і напрямок впорядкування відповідають вашому фільтру (за замовчуванням об’єкти впорядковуються за id у зростаючому порядку, тому ми використовуємо фільтр id_gt).
2. Виконайте перший запит зі значенням фільтра, встановленим на найменше можливе значення (наприклад: 0 для рядкового поля, такого як id).
3. Візьміть найбільший id у даних відповіді і використовуйте його як значення фільтра для наступного запиту.
4. Повторіть кроки 2 і 3, постійно оновлюючи значення фільтра, доки або не буде повернуто жодних даних, або ви не отримаєте достатню кількість об’єктів для ваших потреб.
У документації The Graph добре пояснюється, як здійснювати пагінацію великих обсягів даних, але там не пояснено, як реалізувати алгоритм пагінації.
Ось можлива реалізація методу пагінації на Python:
import requests
# The GraphQL query string, we are querying Token entities
# along with their id and symbol
query_str = """
query($lastID: String, $numEntities: Int) {
tokens(first: $numEntities, where: { id_gt: $lastID }) {
id
symbol
}
}
"""
# The total number of entities we want to query
total_entities = 10_000
# Where we will accumulate the data
data = {"tokens": []}
# Initial value of the lastID variable
id_cursor = "0"
while len(data) < total_entities:
# Query the subgraph
response = requests.post(
url="https://api.thegraph.com/subgraphs/name/uniswap/uniswap-v3",
json={
"query": query_str,
"variables": {
"lastID": id_cursor,
"numEntities": min(1000, total_entities - len(data))
}
}
)
new_data = response.json()
# Stop paginating if no data is returned (i.e.: we have queried
# all entities in the collection)
if len(new_data["data"]["tokens"]) == 0:
break
# Store new data
data["tokens"] += new_data["data"]["tokens"]
# Update id cursor to get next page
id_cursor = new_data["data"]["tokens"][-1]["id"]
Зведення даних
Коли справа доходить до аналізу даних, рекомендованим способом організації даних часто (якщо не завжди) є таблиці. Таблиці, на відміну від даних JSON, дозволяють легко виконувати операції над рядками (наприклад, середнє значення, сума, розрахунок) і стовпцями (наприклад, проекції, перетворення).
Дані, що повертаються при запиті підграфів, представлені у форматі JSON, що полегшує їх аналіз з точки зору розробки інтерфейсу, але ускладнює роботу з ними з точки зору аналізу даних, особливо для даних, що мають багато рівнів розшарування.
Одним з рішень є зведення даних в одну або декілька таблиць. Однак, зведення даних своєрідне, і не завжди існує чіткий спосіб, як його зробити. Наприклад, розглянемо наступний GraphQL-запит і отримані в результаті дані JSON (з підграфа Uniswap V3):
query {
pools(
first: 10,
orderBy: volumeUSD,
orderDirection: desc
) {
id
token0 {
id
symbol
}
token1 {
id
symbol
}
poolDayData(
first: 7,
orderBy: date,
orderDirection: desc
) {
date
volumeUSD
token0Price
token1Price
}
}
}
Вищевказаний запит виводить 10 найбільших за обсягом пулів ліквідності, інформацію про токени пулів, а також тижневі дані про ціни та обсяги для кожного пулу. Дані у відповіді не лише мають багато рівнів розшарування, але й містять розшарований список. Існує два способи зведення даних:
1. Створити дві таблиці, одну для пулів і одну для щоденних датапоінтів, причому остання повинна містити додатковий стовпчик з ID пулу.
2. "JOIN" два списки в одну таблицю, щоб ті самі дані пулу повторювалися для кожної щоденного датапоінту.
Незалежно від того, який метод вирівнювання використовується, такі дані набагато зручніше аналізувати, ніж їхні “raw” JSON-аналоги.
Subgrounds: Поєднання цього всього разом
Всі описані вище методи використовуються бібліотекою Subgrounds/Playgrounds з відкритим вихідним кодом Python, які призначені для розкриття можливостей підграфів для аналітиків даних. Ось приклад Subgrounds, який витягує всі пули (і всі їхні поля) з підграфа Uniswap V3 і скидає все це у pandas dataframe (примітка: на момент написання статті на підграфі було близько ~14 000 пулів, тому встановлення first на 15 тисяч дозволить отримати всі пули):
from subgrounds import Subgrounds
sg = Subgrounds()
uniswap_v3 = sg.load_subgraph(
"https://api.thegraph.com/subgraphs/name/uniswap/uniswap-v3"
)
sg.query_df([
uniswap_v3.Query.pools(first=15_000)
])
Ось скріншот отриманого dataframe:
Цей 10-рядковий фрагмент коду використовує інтроспекцію schema GraphQL для автоматичного вибору всіх підполів поля верхнього рівня pools, автоматичну пагінацію для отримання до 15 000 рядків даних, зведення JSON для перетворення результату в зручну таблицю і конвертацію типів, щоб переконатися, що поля BigInt і BigDecimal в кінцевому підсумку будуть числовими значеннями в нашому dataframe. Тепер, коли всі дані завантажені у ваше середовище Python, прийшов час розпочати справжню роботу: аналіз!
Висновок
У цьому пості ми розглянули різні методи для покращення досвіду розробників у використанні The Graph та підграфів як джерел даних для аналізу великих обсягів даних. Ми побачили, як Subgrounds використовує ці методи, щоб забезпечити простий спосіб запитувати дані в The Graph і готувати їх для аналізу. Це демонструє ефективність The Graph як базового рівня інфраструктури даних web3, здатного забезпечити роботу більше ніж просто децентралізованим додаткам.
Щоб дізнатися більше про Subgrounds і Playgrounds в цілому, зайдіть на наш веб-сайт і приєднуйтесь до нашого Discord, щоб поговорити про все, що стосується The Graph і даних web3!
Можливість долучитися до The Graph Builders Blog
Як децентралізований проект, ми щиро віримо, що обмін знаннями має вирішальне значення для зростання і розвитку всієї екосистеми. Блог The Graph Builders - це платформа для розробників і тих, хто працює з екосистемою The Graph, де вони можуть ділитися своїми ідеями, досвідом і практикою, пов'язаними зі створенням децентралізованих додатків за допомогою The Graph.
Беручи участь у блозі The Graph Builders Blog, ви матимете можливість продемонструвати свій досвід, поділитися розв'язанням певних проблем та отримати доступ до спільноти розробників-однодумців. Ми впевнені, що ваші ідеї надихатимуть і навчатимуть інших, а також внесуть свій вклад у повністю децентралізоване майбутнє.
Переваги авторства у блозі The Graph Builders Blog
Після того, як редактори The Graph затвердять ваш блог, ви будете представлені на сайті The Graph, який має охоплення в понад сотні тисяч читачів, з зазначенням вас як автора блогу;
Ми виділимо та позначимо вас у соціальних мережах, включаючи Twitter з майже 300 тис. підписників;
Ви отримаєте POAP “The Graph Builders Blog Author”;
Ви зможете додати, що ви є автором блогу The Graph Builders Blog до свого LinkedIn та резюме.
Щоб подати заявку на участь у блозі The Graph Builders Blog, заповніть цю форму, і ми зв'яжемося з вами.
Про The Graph
The Graph - це складова індексації та запитів у web3. Розробники створюють та публікують відкриті API, так звані підграфи, до яких додатки можуть звертатися за допомогою GraphQL. Наразі Graph підтримує індексацію даних з понад 40 різних мереж, включаючи Ethereum, NEAR, Arbitrum, Optimism, ZkSync, Polygon, Avalanche, Celo, Fantom, Moonbeam, IPFS, Cosmos Hub та PoA, а незабаром буде додано ще більше мереж. На сьогодні на хостинговому сервісі розгорнуто понад 88900 підграфів. Десятки тисяч розробників використовують The Graph для таких додатків, як Uniswap, Synthetix, KnownOrigin, Art Blocks, Gnosis, Balancer, Livepeer, DAOstack, Audius, Decentraland та багатьох інших.
Сервіс самообслуговування для розробників The Graph Network був запущений у липні 2021 року; з того часу понад 800+ підграфів мігрували до Мережі, а 450+ індексаторів обслуговують запити до підграфів, 11 300+ делегатів та 2 500+ кураторів на сьогодні.Нині було використано понад 5,6 мільйона токенів GRT для подачі сигналів. Якщо ви розробник, який створює додаток або програму у web3, ви можете використовувати підграфи для індексації та запитів даних з блокчейнів. The Graph дозволяє додаткам ефективно і продуктивно представляти дані в інтерфейсі користувача і дозволяє іншим розробникам також використовувати ваш підграф! Ви можете розгорнути підграф в мережі за допомогою нещодавно запущеної Subgraph Studio або запитувати наявні підграфи, які знаходяться в Graph Explorer. The Graph буде радий вітати вас як Індексаторів, Кураторів та/або Делегатів в основній мережі The Graph. Приєднуйтесь до спільноти The Graph, представивши себе в The Graph Discord для технічних обговорень, приєднуйтесь до чату The Graph в Telegram, а також слідкуйте за The Graph у Twitter,
The Graph Foundation контролює The Graph Network. The Graph Foundation контролюється Technical Council, Edge & Node, StreamingFast, Semiotic Labs, The Guild, Messari та GraphOps - це лише кілька з основних організацій, що входять в екосистему The Graph.
Джерело - link
Маючи понад 40 000 розгорнутих підграфів та більше тисячі підграфів, опублікованих в мережі The Graph, The Graph зарекомендував себе як найважливіший постачальник децентралізованих даних для web3. Магія The Graph обертається навколо підграфів: стандартизований рецепт ETLQ (Extract-Transform-Load-Query) для блокчейн-даних, які, будучи опублікованими в мережі The Graph і проіндексованими індексаторами, дозволяють користувачам запитувати попередньо змодельовані дані за допомогою GraphQL API. Від панелі аналітики Uniswap до DefiLlama, незліченна кількість децентралізованих додатків у web3 використовують The Graph та підграфи для надійного та ефективного отримання даних.
Однак факт залишається фактом - підграфи та великий обсяг даних, який вони надають, були розроблені для споживання в першу чергу фронтенд-додатками, а тому не є оптимальними для типового випадку використання для аналізу даних. У цій статті ми розповімо про те, як ми в Playgrounds Analytics розкриваємо потенціал The Graph для різноманітних випадків використання для аналізу даних. Більшість методів, розглянутих у цій статті, реалізовані в нашій бібліотеці Subgrounds з відкритим вихідним кодом Python, але я спробую зберегти агностичний підхід до її реалізації.
Використання інтроспекції Schema
Однією з найбільших переваг GraphQL порівняно з іншими стандартами API, такими як REST, є вбудована можливість інтроспекції (тобто запит структури самого API) в GraphQL.
Це означає, що ви можете не тільки запитувати дані з GraphQL API, але й запитувати метадані про API, такі як список всіх об’єктів, доступних на підграфі, або список параметрів фільтрування, які можна використовувати в запиті.
Наприклад, щоб отримати список усіх типів, визначених для даного API GraphQL, а також їхніх полів (якщо цей тип є об'єктом, тобто типом entity), ви можете зробити запит до метаполя __schema таким чином:
query {
__schema {
types {
name
kind
fields {
name
}
}
}
}
Виконання цього запиту на офіційному підграфі Uniswap V3 поверне наступні метадані (примітка: нижче показані тільки метадані для типу UniswapDayData для стислості).
{
"data": {
"__schema": {
"types": [
// …
{
"name": "UniswapDayData",
"kind": "OBJECT",
"fields": [
{
"name": "id"
},
{
"name": "date"
},
{
"name": "volumeETH"
},
{
"name": "volumeUSD"
},
{
"name": "volumeUSDUntracked"
},
{
"name": "feesUSD"
},
{
"name": "txCount"
},
{
"name": "tvlUSD"
}
]
}
]
}
}
}
Повний запит інтроспекції, який отримує всі метадані API GraphQL, ви можете знайти тут. (примітка: цей самий запит інтроспекції працює для всіх GraphQL API, а не тільки для підграфів!).
Інтроспекція GraphQL API відкриває багато корисних можливостей для аналізу даних, але ми зосередимося на двох з них і на тому, як Subgrounds їх реалізує, а саме на автоматичному створенні запитів і перевірці/конверсації типів.
Автоматичне створення запитів
У той час як розробник, який пише фронтенд-додаток на основі підграфів, вже знає, які дані і запити йому потрібні для досягнення своєї мети, для аналітика даних все по іншому. Він повинен спочатку дослідити дані, щоб проаналізувати їх. Найкращий спосіб досягти цього - витягнути якомога більше даних у потрібне середовище для обробки і використовувати його для дослідження даних.
Цей процес спрощується за допомогою інтроспекції shema, оскільки можна програмно заповнити вибірку GraphQL усіма доступними підполями. Наприклад, повертаючись до підграфа Uniswap V3, враховуючи перший неповний запит на uniswapDayDatas нижче, ми можемо використати результат нашого запиту інтроспекції вище, щоб вибрати всі підполя поля верхнього рівня uniswapDayDatas, таким чином запитуючи всі доступні дані, пов'язані з цим типом entity.
query {
uniswapDayDatas {
id
date
volumeETH
volumeUSD
volumeUSDUntracked
feesUSD
txCount
tvlUSD
}
}
Це аналогічно запиту SQL SELECT * FROM uniswapDayDatas.
Конвертація типів
Інтроспекція GraphQL також дозволяє нам виконувати розумну конвертацію типів, що особливо корисно, коли ми маємо справу з великими числами.
Багато активів web3, таких як токени ERC-20, часто діляться на дуже велику кількість десяткових знаків (найчастіше 18 десяткових знаків), що призводить до транзакцій, які містять дуже великі числа, які не можуть бути представлені звичайним 32-бітним цілим числом. Підграфи представляють ці великі числа за допомогою типів BigInt і BigDecimal, які відрізняються від стандартних типів Int і Float тим, що значення подаються у вигляді рядків при запиті через GraphQL.
Використовуючи інтроспекцію GraphQL, можна визначити, які рядки в відповіді на запит даних насправді є числовими значеннями (і, отже, повинні бути конвертовані на відповідний тип на стороні клієнта), а які рядки є "справжніми" рядками.
Автоматична пагінація
Основною проблемою для аналітиків даних, які працюють з підграфами, є запит великих обсягів даних для побудови змістовного аналізу. Причиною цього є те, що підграфи дозволяють розробникам запитувати лише 1000 об’єктів (тобто рядків) за один запит. Для більшості фронтенд-додатків, де ви рідко відображатимете більше кількох на сторінці, це не є проблемою. Однак, щоб виконати належний аналіз даних, вам часто потрібно набагато більше даних, а це означає, що пагінація необхідна.
Найкращий спосіб пагінації всіх об'єктів у певній колекції, як зазначено в документації The Graph, це використовувати унікальне поле (зазвичай id об'єкта) як курсор і збільшувати цей курсор для отримання кожної наступної порції даних. Ось як може виглядати цей процес:
1. Напишіть запит з фільтром на вашому унікальному полі, щоб кількість сутностей для запиту і значення фільтра можна було встановити як змінні. Переконайтеся, що порядок і напрямок впорядкування відповідають вашому фільтру (за замовчуванням об’єкти впорядковуються за id у зростаючому порядку, тому ми використовуємо фільтр id_gt).
2. Виконайте перший запит зі значенням фільтра, встановленим на найменше можливе значення (наприклад: 0 для рядкового поля, такого як id).
3. Візьміть найбільший id у даних відповіді і використовуйте його як значення фільтра для наступного запиту.
4. Повторіть кроки 2 і 3, постійно оновлюючи значення фільтра, доки або не буде повернуто жодних даних, або ви не отримаєте достатню кількість об’єктів для ваших потреб.
У документації The Graph добре пояснюється, як здійснювати пагінацію великих обсягів даних, але там не пояснено, як реалізувати алгоритм пагінації.
Ось можлива реалізація методу пагінації на Python:
import requests
# The GraphQL query string, we are querying Token entities
# along with their id and symbol
query_str = """
query($lastID: String, $numEntities: Int) {
tokens(first: $numEntities, where: { id_gt: $lastID }) {
id
symbol
}
}
"""
# The total number of entities we want to query
total_entities = 10_000
# Where we will accumulate the data
data = {"tokens": []}
# Initial value of the lastID variable
id_cursor = "0"
while len(data) < total_entities:
# Query the subgraph
response = requests.post(
url="https://api.thegraph.com/subgraphs/name/uniswap/uniswap-v3",
json={
"query": query_str,
"variables": {
"lastID": id_cursor,
"numEntities": min(1000, total_entities - len(data))
}
}
)
new_data = response.json()
# Stop paginating if no data is returned (i.e.: we have queried
# all entities in the collection)
if len(new_data["data"]["tokens"]) == 0:
break
# Store new data
data["tokens"] += new_data["data"]["tokens"]
# Update id cursor to get next page
id_cursor = new_data["data"]["tokens"][-1]["id"]
Зведення даних
Коли справа доходить до аналізу даних, рекомендованим способом організації даних часто (якщо не завжди) є таблиці. Таблиці, на відміну від даних JSON, дозволяють легко виконувати операції над рядками (наприклад, середнє значення, сума, розрахунок) і стовпцями (наприклад, проекції, перетворення).
Дані, що повертаються при запиті підграфів, представлені у форматі JSON, що полегшує їх аналіз з точки зору розробки інтерфейсу, але ускладнює роботу з ними з точки зору аналізу даних, особливо для даних, що мають багато рівнів розшарування.
Одним з рішень є зведення даних в одну або декілька таблиць. Однак, зведення даних своєрідне, і не завжди існує чіткий спосіб, як його зробити. Наприклад, розглянемо наступний GraphQL-запит і отримані в результаті дані JSON (з підграфа Uniswap V3):
query {
pools(
first: 10,
orderBy: volumeUSD,
orderDirection: desc
) {
id
token0 {
id
symbol
}
token1 {
id
symbol
}
poolDayData(
first: 7,
orderBy: date,
orderDirection: desc
) {
date
volumeUSD
token0Price
token1Price
}
}
}
Вищевказаний запит виводить 10 найбільших за обсягом пулів ліквідності, інформацію про токени пулів, а також тижневі дані про ціни та обсяги для кожного пулу. Дані у відповіді не лише мають багато рівнів розшарування, але й містять розшарований список. Існує два способи зведення даних:
1. Створити дві таблиці, одну для пулів і одну для щоденних датапоінтів, причому остання повинна містити додатковий стовпчик з ID пулу.
2. "JOIN" два списки в одну таблицю, щоб ті самі дані пулу повторювалися для кожної щоденного датапоінту.
Незалежно від того, який метод вирівнювання використовується, такі дані набагато зручніше аналізувати, ніж їхні “raw” JSON-аналоги.
Subgrounds: Поєднання цього всього разом
Всі описані вище методи використовуються бібліотекою Subgrounds/Playgrounds з відкритим вихідним кодом Python, які призначені для розкриття можливостей підграфів для аналітиків даних. Ось приклад Subgrounds, який витягує всі пули (і всі їхні поля) з підграфа Uniswap V3 і скидає все це у pandas dataframe (примітка: на момент написання статті на підграфі було близько ~14 000 пулів, тому встановлення first на 15 тисяч дозволить отримати всі пули):
from subgrounds import Subgrounds
sg = Subgrounds()
uniswap_v3 = sg.load_subgraph(
"https://api.thegraph.com/subgraphs/name/uniswap/uniswap-v3"
)
sg.query_df([
uniswap_v3.Query.pools(first=15_000)
])
Ось скріншот отриманого dataframe:
Цей 10-рядковий фрагмент коду використовує інтроспекцію schema GraphQL для автоматичного вибору всіх підполів поля верхнього рівня pools, автоматичну пагінацію для отримання до 15 000 рядків даних, зведення JSON для перетворення результату в зручну таблицю і конвертацію типів, щоб переконатися, що поля BigInt і BigDecimal в кінцевому підсумку будуть числовими значеннями в нашому dataframe. Тепер, коли всі дані завантажені у ваше середовище Python, прийшов час розпочати справжню роботу: аналіз!
Висновок
У цьому пості ми розглянули різні методи для покращення досвіду розробників у використанні The Graph та підграфів як джерел даних для аналізу великих обсягів даних. Ми побачили, як Subgrounds використовує ці методи, щоб забезпечити простий спосіб запитувати дані в The Graph і готувати їх для аналізу. Це демонструє ефективність The Graph як базового рівня інфраструктури даних web3, здатного забезпечити роботу більше ніж просто децентралізованим додаткам.
Щоб дізнатися більше про Subgrounds і Playgrounds в цілому, зайдіть на наш веб-сайт і приєднуйтесь до нашого Discord, щоб поговорити про все, що стосується The Graph і даних web3!
Можливість долучитися до The Graph Builders Blog
Як децентралізований проект, ми щиро віримо, що обмін знаннями має вирішальне значення для зростання і розвитку всієї екосистеми. Блог The Graph Builders - це платформа для розробників і тих, хто працює з екосистемою The Graph, де вони можуть ділитися своїми ідеями, досвідом і практикою, пов'язаними зі створенням децентралізованих додатків за допомогою The Graph.
Беручи участь у блозі The Graph Builders Blog, ви матимете можливість продемонструвати свій досвід, поділитися розв'язанням певних проблем та отримати доступ до спільноти розробників-однодумців. Ми впевнені, що ваші ідеї надихатимуть і навчатимуть інших, а також внесуть свій вклад у повністю децентралізоване майбутнє.
Переваги авторства у блозі The Graph Builders Blog
Після того, як редактори The Graph затвердять ваш блог, ви будете представлені на сайті The Graph, який має охоплення в понад сотні тисяч читачів, з зазначенням вас як автора блогу;
Ми виділимо та позначимо вас у соціальних мережах, включаючи Twitter з майже 300 тис. підписників;
Ви отримаєте POAP “The Graph Builders Blog Author”;
Ви зможете додати, що ви є автором блогу The Graph Builders Blog до свого LinkedIn та резюме.
Щоб подати заявку на участь у блозі The Graph Builders Blog, заповніть цю форму, і ми зв'яжемося з вами.
Про The Graph
The Graph - це складова індексації та запитів у web3. Розробники створюють та публікують відкриті API, так звані підграфи, до яких додатки можуть звертатися за допомогою GraphQL. Наразі Graph підтримує індексацію даних з понад 40 різних мереж, включаючи Ethereum, NEAR, Arbitrum, Optimism, ZkSync, Polygon, Avalanche, Celo, Fantom, Moonbeam, IPFS, Cosmos Hub та PoA, а незабаром буде додано ще більше мереж. На сьогодні на хостинговому сервісі розгорнуто понад 88900 підграфів. Десятки тисяч розробників використовують The Graph для таких додатків, як Uniswap, Synthetix, KnownOrigin, Art Blocks, Gnosis, Balancer, Livepeer, DAOstack, Audius, Decentraland та багатьох інших.
Сервіс самообслуговування для розробників The Graph Network був запущений у липні 2021 року; з того часу понад 800+ підграфів мігрували до Мережі, а 450+ індексаторів обслуговують запити до підграфів, 11 300+ делегатів та 2 500+ кураторів на сьогодні.Нині було використано понад 5,6 мільйона токенів GRT для подачі сигналів. Якщо ви розробник, який створює додаток або програму у web3, ви можете використовувати підграфи для індексації та запитів даних з блокчейнів. The Graph дозволяє додаткам ефективно і продуктивно представляти дані в інтерфейсі користувача і дозволяє іншим розробникам також використовувати ваш підграф! Ви можете розгорнути підграф в мережі за допомогою нещодавно запущеної Subgraph Studio або запитувати наявні підграфи, які знаходяться в Graph Explorer. The Graph буде радий вітати вас як Індексаторів, Кураторів та/або Делегатів в основній мережі The Graph. Приєднуйтесь до спільноти The Graph, представивши себе в The Graph Discord для технічних обговорень, приєднуйтесь до чату The Graph в Telegram, а також слідкуйте за The Graph у Twitter,
The Graph Foundation контролює The Graph Network. The Graph Foundation контролюється Technical Council, Edge & Node, StreamingFast, Semiotic Labs, The Guild, Messari та GraphOps - це лише кілька з основних організацій, що входять в екосистему The Graph.
No comments yet