Am încercat să construiesc pe OpenLedger timp de o săptămână — Iată de ce m-am oprit
Am vrut să testez ceva pentru mine.
Nu doar să folosesc OpenLedger ca utilizator, ci chiar să încerc să construiesc ceva deasupra lui. O aplicație reală. Ceva practic care ar putea deveni util mai târziu dacă infrastructura s-ar menține.
Așa că am petrecut cam o săptămână să mă aprofundez în asta.
Tehnic, m-am oprit în ziua cinci.
Nu pentru că ideea din spatele OpenLedger ar fi proastă. Sincer, cred în continuare că conceptul de bază are sens. Problema a fost experiența de a construi efectiv pe el. După o vreme a devenit mai frustrant decât productiv.
Ce Am Încercat Să Construiesc
Ideea în sine a fost destul de simplă.
Am vrut să creez o mică piață de date unde oamenii să poată încărca seturi de date, OpenLedger să poată gestiona urmărirea atribuirii, iar cumpărătorii să poată plăti pentru acces în timp ce contribuitorii primesc automat recompense.
Pe hârtie, părea de fapt să fie potrivirea perfectă pentru ceea ce OpenLedger încearcă să facă.
Contribuția de date. Atribuția. Plățile automate. Astea sunt, practic, lucrurile despre care vorbesc cel mai mult.
Așa că am configurat totul. Am instalat dependențele, am clonat repo-urile, am început să citesc documentele și să încerc exemple.
Acolo lucrurile au început încet să devină haotice.
Problema Documentației
Prima problemă a fost, sincer, doar să-mi dau seama unde locuia documentația reală.
O parte din ele erau pe GitBook. Unele erau în fișierele README de pe GitHub. Câteva lucruri importante erau ascunse în comentariile de cod. Apoi, alte răspunsuri existau doar în mesajele fixate pe Discord.
Am petrecut aproape două ore încercând să confirm ce versiune Node.js funcționa de fapt corect.
În cele din urmă am găsit răspunsul îngropat într-un comentariu de problemă GitHub din urmă cu câteva luni.
Și chiar și după asta, configurarea s-a simțit ciudat fragilă.
Lucruri necesare:
- Node.js 18 specific, nu 20
- O anumită versiune ethers.js
- Formatarea configurației personalizate care nu a fost explicată pe deplin
- Permisiuni locale care mi-au cauzat probleme aleatorii
Aproape fiecare pas s-a simțit ca o ghicire puțin. Sau întrebând pe Discord.
Pentru dezvoltatorii blockchain cu experiență poate că este gestionabil. Totuși, enervant. Pentru dezvoltatorii mai noi, cred sincer că ar fi copleșitor destul de repede.
APIs S-au Simțit Împrăștiate
A doua lucru care a început să mă deranjeze a fost designul API-ului.
Unele funcții foloseau callbacks. Altele foloseau promisiuni. Unele lucruri erau async, altele nu. Nu părea să existe un singur model clar în cadrul SDK-ului.
Asta poate suna mic, dar când construiești ceva mai mare, consistența contează mult mai mult decât cred oamenii.
Gestionarea erorilor a fost și ea dură.
Continuam să primesc mesaje de genul:
“EXEC_001”
Nicio explicație. Nicio informație de depanare semnificativă. Doar coduri.
La un moment dat am încercat să trimit date într-un Datanet și totul a eșuat în tăcere. Am petrecut aproape o oră depanând înainte să realizez că formatul necesar era explicat doar într-un thread de Discord, nu în documentele reale.
Și, sincer, această parte continua să se întâmple. Detalii mici lipsă peste tot.
Nu suficient pentru a rupe complet tehnologia. Doar suficient pentru a încetini constant totul.
Integrațiile Încă Lipsesc
Un alt lucru pe care l-am observat destul de repede este cât de izolat se simte ecosistemul acum.
Nu sunt multe integrații simple cu instrumentele pe care dezvoltatorii le folosesc deja.
Niciun suport Stripe.
Nicio integrare Auth0.
Nu există un sistem standard de webhook.
Nu există un fallback simplu REST.
Aproape totul depinde direct de interacțiunile blockchain.
Ceea ce înseamnă că dezvoltatorii ajung să construiască tone de infrastructură suplimentară înainte să poată să se concentreze chiar pe produsul lor real.
Asta a devenit obositor mai repede decât mă așteptam.
După un timp, a început să-mi pară că nu mai construiesc aplicația mea. Construiesc sisteme de suport în jurul OpenLedger doar pentru a face fluxurile de lucru de bază să funcționeze normal.
Testarea a Durat Ireparabil
Această parte m-a surprins cel mai mult, sincer.
Testarea pe testnet a fost dureros de lentă.
Tranzacțiile uneori au durat câteva minute pentru a fi confirmate. Rețeaua s-a resetat neașteptat de câteva ori. Și depanarea eșecurilor a fost confuză deoarece vizibilitatea asupra a ceea ce s-a întâmplat de fapt a fost destul de limitată.
Am încercat să simulez un scenariu de încărcare a datelor proaste.
Testul efectiv ar fi trebuit să dureze poate cinci secunde.
În schimb, am petrecut aproximativ 45 de minute așteptând confirmările și rerulând tranzacțiile.
Tipul acesta de întârziere schimbă complet cum se simte dezvoltarea.
În mod normal, iterezi rapid. Testezi, ajustezi, retry. Aici a devenit atât de lent încât am început să evit testarea schimbărilor mici pentru că întrerupea prea mult momentum-ul.
Și poate că asta sună dramatic puțin, dar după câteva zile te epuizează cu adevărat.
Ce Cred Că Acest Lucru Înseamnă De Fapt
Nu cred că tehnologia de bază a OpenLedger este falsă sau inutilă.
De fapt, cred opusul.
Ideea infrastructurii este interesantă. Urmărirea atribuirii pentru AI și contribuția de date este o problemă reală care merită rezolvată. Probabil că există o valoare reală pe termen lung acolo dacă execută corect.
Dar există o diferență între construirea tehnologiei și construirea a ceva pe care dezvoltatorii să poată construi confortabil.
Acum, OpenLedger pare blocat undeva între aceste două etape.
Viziunea backend-ului există.
Experiența dezvoltatorului nu există încă pe deplin.
Cel puțin nu într-un mod rafinat.
Cine Probabil Se Luptă Aici
Dacă ești profund experimentat cu infrastructura blockchain deja, probabil poți lucra prin majoritatea acestor lucruri. Tot va fi frustrant uneori, dar, în cele din urmă, îți vei da seama de lucruri.
Dacă ești o startup care încearcă să se miște repede, totuși, cred că asta devine o problemă reală.
Totul durează mai mult decât te aștepți.
Și dacă ești mai nou în dezvoltarea crypto, există o șansă decentă să renunți pe parcurs. Nu pentru că nu poți programa, ci pentru că frecarea se acumulează constant.
Lucruri mici. Repetat.
Ce Probabil Trebuie Să Repară
Sincer, soluțiile nu sună nici măcar atât de complicate.
Au nevoie de:
- Un hub de documentație curat
- Referințe API mai bune
- Mai multe exemple funcționale
- Mesaje de eroare ușor de citit
- Structură SDK consistentă
- Fluxuri de testare mai rapide
În mare parte, doar au nevoie de priorități mai puternice pentru experiența dezvoltatorului.
Acum, accentul pare să fie puternic tehnic, ceea ce este de înțeles la început. Dar, în cele din urmă, utilizabilitatea contează la fel de mult ca infrastructura.
Poate mai onest.
Gânduri Finale
Probabil că voi reveni la OpenLedger mai târziu anul acesta.
Pentru că, în ciuda tuturor frustrărilor, tot cred că direcția de bază are sens. Ideea în sine nu este problema.
Se simte ca infrastructura a devenit tehnic pregătită înainte să devină practic pregătită.
Și acel gol este mai mare decât realizează multe proiecte Web3.
.........