Home » Jak wybrać dostawcę danych dla swojego projektu web3?

Jak wybrać dostawcę danych dla swojego projektu web3?

by Tim

Poza tokenami kryptowalutowymi, blockchain umożliwia również analitykom uzyskanie jaśniejszego obrazu praktycznie każdego projektu GameFi, NFT, rynku lub protokołu DeFi, dzięki Footprint.

W Footprint stworzyliśmy metodologię, która kompiluje i sensownie agreguje surowe dane blockchain. I dotyczy to integracji programistycznych.

1 . Sposoby pracy z danymi z blockchaina

Porozmawiajmy najpierw o metodach integracji programistycznych. Istnieje kilka różnych sposobów pracy z danymi blockchain, a wybrane przez Ciebie podejście będzie zależało od Twoich konkretnych potrzeb i celów. Oto szybki przegląd:

1.1 Odkrywcy Blockchain

Odkrywcy blockchaina to strona internetowa lub narzędzie, które pozwala na przeglądanie danych przechowywanych na blockchainie. Może to być szybki i łatwy sposób na uzyskanie dostępu do informacji o konkretnych transakcjach, blokach i innych danych na blockchainie.

Eksploratory blockchain mogą być użytecznym narzędziem do uzyskiwania dostępu i przeglądania danych przechowywanych na blockchainie, ale mają pewne ograniczenia dotyczące integracji oprogramowania. Oto kilka przykładów rzeczy, których może brakować eksploratorom blockchain:

  • Głównie skupiają się na surowych danych. Eksploratory blockchain zazwyczaj wyświetlają surowe dane z blockchaina. To wymaga implementacji abstrakcji nad surowymi danymi, co może być żmudne, zwłaszcza w przypadku projektów skupionych na dostarczaniu, a nie na technicznych szczegółach niektórych blockchainów.
  • Opcje dostosowawcze: Eksploratory blockchain są zwykle zaprojektowane tak, aby były przyjazne dla użytkownika i łatwe w użyciu, co oznacza, że mogą nie oferować wielu opcji dostosowywania. Może to utrudnić dostosowanie eksploratora do konkretnych potrzeb lub preferencji.
  • Zaawansowana funkcjonalność wyszukiwania: Eksploratory Blockchain często mają podstawową funkcjonalność wyszukiwania, ale mogą nie obsługiwać bardziej zaawansowanych funkcji wyszukiwania, takich jak operatory Boolean lub wyrażenia regularne. Może to utrudniać wyszukiwanie konkretnych informacji na blockchainie.
  • Interaktywność: Wiele eksploratorów blockchain jest w zasadzie narzędziami tylko do odczytu.

Choć eksploratory blockchain mogą być pomocnym sposobem dostępu i przeglądania surowych danych blockchain, mają one pewne ograniczenia, których należy być świadomym przed podjęciem decyzji o wdrożeniu opartej na nich infrastruktury rozwiązania.

1.2 Własne rozwiązanie indeksowania

Ustawienie własnego indeksera do pracy z danymi blockchain może mieć kilka zalet i potencjalnych wad. Poniżej przedstawiamy kilka przykładów każdego z nich:

Zalety:

  • Konfiguracja: Kiedy skonfigurujesz swój indekser, masz pełną kontrolę nad tym, jak dane są indeksowane i dostępne. Dzięki temu możesz dostosować indeksator do swoich specyficznych potrzeb i preferencji.
  • Niezależność: Ustawiając swój indeksator, nie polegasz na usłudze innej firmy, aby utrzymać i zaktualizować indeks. Może to zapewnić większą kontrolę i elastyczność w pracy z danymi blockchain.
  • Zwiększone bezpieczeństwo: Kiedy skonfigurujesz własny indeksator, możesz wdrożyć własne środki bezpieczeństwa, aby chronić dane i zapobiegać nieautoryzowanemu dostępowi.

Wady:

  • Kompleksowość: Konfiguracja twojego indeksera może być złożonym i czasochłonnym procesem, zwłaszcza jeśli jesteś nowy w pracy z technologią blockchain. Będziesz musiał zrozumieć podstawową technologię i być skłonnym do zainwestowania czasu i wysiłku wymaganego do uruchomienia indeksera.
  • Konserwacja: Po skonfigurowaniu indeksera, będziesz odpowiedzialny za jego utrzymanie i aktualizację. Może to wymagać ciągłej wiedzy technicznej i zasobów, co może być wadą, jeśli nie masz niezbędnej wiedzy lub wsparcia.
  • Koszt: Konfiguracja własnego indeksera może być kosztowna, ponieważ musisz zakupić sprzęt i oprogramowanie wymagane do uruchomienia indeksera i zapłacić za wszelkie powiązane koszty, takie jak energia elektryczna i pasmo.

Ogółem, skonfigurowanie własnego indeksera do pracy z danymi blockchain może zapewnić większą kontrolę i dostosowanie, ale może to być również złożony i kosztowny proces. Ważne jest, aby dokładnie rozważyć zalety i wady przed podjęciem decyzji, czy jest to właściwe podejście.

1.3 Baza danych jako usługa

Używanie indeksera innej firmy do pracy z danymi blockchain może mieć kilka zalet i potencjalnych wad. Oto kilka przykładów każdego z nich:

Zalety:

  • Łatwość użycia: Indeksatory innych firm są zazwyczaj zaprojektowane tak, aby były łatwe w użyciu, co oznacza, że możesz szybko rozpocząć pracę z danymi blockchaina bez konieczności uczenia się wielu szczegółów technicznych lub uruchamiania swojego niestandardowego rozwiązania indeksującego (nie ma znaczenia, czy jest to samodzielnie opracowany lub gotowy SDK)
  • Zaawansowana funkcjonalność wyszukiwania: Wiele indekserów stron trzecich oferuje zaawansowane funkcje wyszukiwania, takie jak operatory Boolean i wyrażenia regularne, ułatwiając wyszukiwanie konkretnych informacji na blockchainie. Mogą one mieć wiele rzeczywistych implementacji, ale indeksowane dane są często dodawane do relacyjnej bazy danych, co implikuje pełną obsługę SQL.
  • Skalowalność: Indeksatory firm trzecich są często zaprojektowane do obsługi dużych ilości danych, co oznacza, że mogą być dobrą opcją, jeśli potrzebujesz przeszukiwać lub uzyskiwać dostęp do danych z dużego blockchaina.
  • Reliability: Indeksatory stron trzecich są zwykle prowadzone przez profesjonalne organizacje posiadające zasoby i wiedzę, aby zapewnić, że indeks jest zawsze aktualny i dokładny. Rozwiązania nie zawsze są zdecentralizowane, ponieważ koncentrują się na przetwarzaniu ogromnych ilości danych, ale zdecydowana większość z nich jest open source, co zwiększa zaufanie użytkowników do usługi.

Wady:

  • Zależność: Korzystając z indeksera innej firmy, polegasz na tej usłudze, aby utrzymać i zaktualizować indeks. Jeśli indeksator doświadczy problemów technicznych lub przejdzie w tryb offline, możesz nie być w stanie uzyskać dostępu do danych blockchain.
  • Ograniczona personalizacja: Indeksatory innych firm są zwykle zaprojektowane tak, aby były łatwe w użyciu, co oznacza, że mogą nie oferować wielu opcji dostosowywania. Może to utrudnić dostosowanie indeksatora do konkretnych potrzeb lub preferencji.
  • Koszt: Niektóre indeksatory firm trzecich mogą pobierać opłaty za swoje usługi, co może być wadą, jeśli pracujesz z napiętym budżetem.

Podsumowując, korzystanie z indeksera strony trzeciej do pracy z danymi blockchain może być wygodną i skuteczną opcją, ale ograniczoną i czasami pozbawioną możliwości dostosowania.

1.4 Podsumowanie

Celem Footprinta jest przede wszystkim obniżenie poprzeczki dla wprowadzania analityki i pracy z danymi web3. Takie podejście to balans pomiędzy łatwością obsługi a elastycznością. Dlatego jedną z naszych usług jest DaaS (Database as the service type). Zanim przyjrzymy się bliżej zaletom naszej usługi, przyjrzymy się również innej opcji implementacji indeksatora, a mianowicie samodzielnie napisanemu rozwiązaniu lub SDK.

W kolejnych rozdziałach zbadamy podstawową cechę, jaką powinny mieć API blockchaina przeznaczone tylko do odczytu. Spojrzymy na problem z różnych stron i rozważymy alternatywne rozwiązania. Do jednych z najważniejszych cech interfejsów API blockchain należą:

  • Łatwość użycia i elastyczność
  • Skalowalność
  • Kompatybilność

Łatwość użycia i elastyczność to dwie ważne cechy interfejsów API blockchain. Łatwy w użyciu interfejs API blockchain ułatwi deweloperom rozpoczęcie budowy aplikacji opartych na blockchainie, pozwalając im szybko prototypować i testować swoje pomysły bez poświęcania dużej ilości czasu na naukę korzystania z API.

Z drugiej strony elastyczność odnosi się do zdolności interfejsu API blockchain do obsługi szerokiego zakresu przypadków użycia i aplikacji. Elastyczny interfejs API blockchain pozwoli programistom uzyskać dostęp do różnych części blockchaina i budować aplikacje, które wchodzą w interakcje z różnymi rodzajami inteligentnych kontraktów i innych aktywów opartych na blockchainie. Może to być szczególnie ważne dla programistów szukających aplikacji, które mogą być używane w różnych branżach i kontekstach.

Ogólnie rzecz biorąc, posiadanie API blockchain, które jest zarówno łatwe w użyciu, jak i elastyczne, może ułatwić programistom budowanie innowacyjnych i użytecznych aplikacji, które mogą wykorzystać unikalne cechy i możliwości technologii blockchain.

1.5 Footprint Analytics

Łatwość użytkowania i elastyczność zapewnia nasza organizacja danych, która wpływa na wszystkie aspekty interakcji z ekosystemem Footprint. Footprint posiada API zbudowane na szczycie tego modelu danych, które pozwala użytkownikom budować pełnoprawne rurociągi danych dla aplikacji do analizy danych i uczenia maszynowego. Nazywamy to Data API. Wspieramy jednocześnie dwa typy API i dwa podtypy w ramach jednego z nich, aby pokryć większość przypadków: Rest API i SQL API.

REST API pozwala na szybką integrację aplikacji, ponieważ każdy punkt końcowy jest wstępnie zbudowanym, twardym skryptem, który zidentyfikowaliśmy jako jeden z najbardziej popularnych. Wszystkie punkty końcowe są wyposażone w łatwe w użyciu narzędzia do filtrowania, sortowania i paginacji.


Dzięki bardziej adaptacyjnemu interfejsowi SQL API można uzyskać to dla bardziej specyficznych przypadków. Jedną z zalet używania tych samych zapytań SQL zarówno w aplikacji internetowej, jak i w API jest to, że może to uprościć rozwój i utrzymanie. Używając tych samych zapytań w obu interfejsach, programiści mogą uniknąć konieczności pisania i utrzymywania oddzielnych zestawów zapytań dla aplikacji internetowej i interfejsu API. Może to zaoszczędzić czas i wysiłek oraz zmniejszyć ryzyko wystąpienia błędów lub niespójności między dwoma interfejsami.


Dodatkowo użycie tych samych zapytań SQL zarówno w aplikacji internetowej, jak i w interfejsie API może ułatwić programistom stworzenie płynnego doświadczenia użytkownika. Używając tych samych zapytań, programiści mogą zapewnić, że dane udostępniane i manipulowane przez aplikację internetową i interfejs API są spójne, co pozwala użytkownikom przełączać się między tymi dwoma interfejsami bez napotykania jakichkolwiek niespójności lub zakłóceń.

1.6 Inne platformy

Wiele alternatywnych rozwiązań analitycznych pozwala użytkownikowi analizować różne sieci według różnych poziomów wymagań. W większości jednak rozwiązania alternatywne popadają w skrajności, implementując albo bardzo elastyczny produkt, który wymaga znajomości języków zapytań lub nawet języków programowania, albo bardzo prosty interfejs z przygotowanymi skryptami i odpowiednio niską elastycznością.

Rozwiązania takie jak Moralis czy Quicknode posiadają jedynie interfejs REST API. Nawet jeśli istnieje wiele punktów końcowych, to nadal ogranicza to dewelopera w elastyczności zwracanych danych.

Niedawno swoje API wprowadziła firma Dune. To asynchroniczne rozwiązanie zakłada wstępne istnienie na platformie zapytania pod określonym id (dune.com/query/{{query id}}), za pomocą którego możliwe jest wykonywanie zapytań w postaci SQL. Kluczowym ograniczeniem tego rozwiązania jest konieczność wstępnego zmodyfikowania SQL na platformie, tak aby zaktualizowane zapytanie zostało następnie wykonane.

Chainbase udostępnia SQL API w taki sam sposób jak Footprint. Jednak w przeciwieństwie do Footprinta, Chainbase nie posiada tak wyrafinowanego ETL, więc zapytania SQL mogą być wykonywane tylko dla surowych transakcji.

2. Skalowalność

Blockchain API powinny być w stanie obsłużyć duże ilości danych i transakcji, pozwalając deweloperom budować aplikacje, z których może korzystać wielu użytkowników jednocześnie.

2.1 Footprint Analytics

2.1.1 Nowoczesny otwarty stos danych

Zespół Footprint od momentu uruchomienia w sierpniu 2021 roku dokonał kilku modernizacji architektury, dzięki silnej zdolności do eksploracji i iteracji technologii. W mniej niż półtora roku zespół był w stanie z powodzeniem wdrożyć te zmiany. Jest to świadectwo umiejętności i wiedzy zespołu w zakresie technologii i nauki o danych.

Poprzez eksperymenty, Footprint iteracyjnie dokonał trzech globalnych aktualizacji architektury, ostatecznie dochodząc do architektury, która spełnia wymagania różnych przypadków użycia platformy. Więcej informacji na temat ewolucji wdrożenia można znaleźć w kolejnym artykule:

https://www.footprint.network/article/iceberg-spark-trino-a-modern-opensource-data-stack-for-blockchain-fp-HGZpPm3D

2.1.2 Wykonania synchroniczne i asynchroniczne

W Footprint istnieją dwa tryby wykonywania zapytań do SQL API – synchroniczny i asynchroniczny. Wywołania API do endpointu synchronicznego implikują, że zapytanie SQL zostanie wykonane przez serwery Footprinta zaraz po otrzymaniu żądania HTTP od aplikacji, utrzymując w ten sposób połączenie. Ma to sens w przypadku korzystania z lekkich zapytań, gdyż w tym przypadku aplikacja nie musi długo czekać na wykonanie. Szczegóły można znaleźć na następującej stronie:

https://docs.footprint.network/reference/post_native

W przypadku ciężkich żądań zaleca się stosowanie żądania asynchronicznego. W przeciwieństwie do synchronicznego, aplikacja kliencka nie musi utrzymywać połączenia z serwerem podczas wykonywania. Zamiast tego może natychmiast uzyskać request-id, według którego po pewnym czasie osobno otrzymuje wyniki wykonania. W ramach asynchronicznego API należy uwzględnić dwustopniowe pobieranie danych – poniższy endpoint posłuży do wysłania „zamówienia” na wykonanie SQL:

https://docs.footprint.network/reference/post_native-async

Drugim krokiem jest wysłanie żądania otrzymania wyników przez identyfikator uzyskany podczas dostępu do poprzedniego punktu końcowego. Punkt końcowy dla tego drugiego kroku opisany jest na następnej stronie:

https://docs.footprint.network/reference/get_native-execution-id-results

2.2 Inne rozwiązania

DuneV2 zmienia całą architekturę bazy danych. Dune odchodzi od bazy PostgreSQL na rzecz instancji [[Apache Spark]] hostowanej na [[Databricks]]. Tylko asynchroniczne API.

3. Kompatybilność

Blockchain API powinny być kompatybilne z szeroką gamą języków programowania i środowisk programistycznych, aby programiści mogli używać narzędzi i frameworków, które są im najbardziej znane.

REST jest łatwiejszy w integracji, ponieważ każdy język programowania posiada wiele bibliotek zapewniających wygodną pracę z tego typu API. Jednak ostatecznie zarówno API SQL, jak i REST działają przez HTTP, więc doświadczenie deweloperskie jest niemal identyczne w zakresie wysyłania żądania domyślnie.

4. Podsumowanie

Jak przeanalizowaliśmy, w większości przypadków wystarczy, aby aplikacja korzystała z gotowych rozwiązań DaaS z tego powodu, że mogą one zwracać abstrakcje (a nie tylko surowe dane) i pozwalają zaoszczędzić sporo czasu i pieniędzy, ponieważ ostatecznie pozwalają zespołom skupić się nie na infrastrukturze, ale na wartości produktu. Przechodząc przez różne rozwiązania na rynku DaaS,

Footprint wydaje się najbardziej optymalny do integracji, ponieważ posiada najbardziej elastyczny model generowania zapytań, będąc jednocześnie łatwym w obsłudze, a także mając pod maską nowoczesny open-source’owy stos danych, który zapewnia nieprzerwaną i co najważniejsze szybką realizację najbardziej złożonych zapytań.

Related Posts

Leave a Comment