Salutare tuturor! Luna trecută am decis să-mi rezolv o frustrare veche. Nicio aplicație de habit tracking din store nu se potrivea cu stilul meu, așa că am pus mâna pe tastatură. Am vrut ceva simplu, rapid și care să funcționeze perfect fără conexiune la internet.
După trei weekenduri de codat printre picături, am lansat aplicația în store-uri. Surpriza a fost că, după o postare pe Reddit și un thread pe Twitter, am strâns 200 de utilizatori activi în prima lună. Nu e o cifră uriașă, dar e destul cât să-mi arate unde am dat-o în bară cu arhitectura.
Stack-ul tehnic: De ce m-am zgârcit la infrastructură
Am mers pe React Native cu Expo. Cu Expo Application Services (EAS), deployment-ul a devenit o joacă față de acum 5 ani când îți venea să-ți smulgi părul din cap cu Xcode și Gradle.
Pentru baza de date, am vrut o abordare offline-first. Am folosit expo-sqlite pentru stocarea locală și Supabase pentru sincronizare în cloud și autentificare. Stilurile le-am scris rapid cu NativeWind.
Trade-off-ul a fost evident de la început. Expo îți oferă o viteză incredibilă la start. Am economisit lejer 30% din timpul de setup pe care l-aș fi pierdut cu un proiect React Native clasic. Partea proastă? Când am vrut să adaug widget-uri native pentru ecranul de pornire pe iOS, am dat de zid. Expo Go nu te lasă să rulezi cod nativ custom, așa că a trebuit să trec la development builds. Procesul e ok, dar adio simplitate absolută.
Marea greșeală: Sync engine-ul scris de mână
Dacă este un lucru pe care îl regret profund, este că am zis: "Cât de greu poate fi să sincronizez un SQLite local cu Supabase?". Răspunsul scurt: extrem de greu.
Am vrut să evit biblioteci mari ca WatermelonDB sau Realm, crezând că scap mai ieftin cu un sistem simplu bazat pe timestamp-uri de actualizare. Am pățit exact ce speram să evit. Userii își editau obiceiurile pe tabletă, apoi pe telefon, iar la sincronizare datele se suprascriau aiurea. Am pierdut vreo trei nopți debuguind conflicte de sincronizare pe care un tool dedicat le-ar fi rezolvat nativ.
Dacă aș lua-o de la capăt, aș folosi un CRDT sau aș lăsa baza de date locală să fie singura sursă de adevăr, oferind doar un export/import manual în JSON pentru backup. Pentru un MVP, sincronizarea în timp real e un overkill care îți mănâncă timp prețios.
Ce am învățat din feedback-ul celor 200 de oameni
Oamenilor nu le pasă de stack-ul tău. Nu-i interesează că folosești cele mai noi reducer-e sau că ai baze de date relaționale optimizate la sânge. Ei vor doar ca aplicația să nu agațe când dau scroll și să nu le piardă progresul când intră în metrou unde nu au semnal.
Am avut un bug stupid în care layout-ul se strica pe ecranele mai mici (iPhone SE de primă generație). Unul dintre primii utilizatori mi-a dat un review de o stea direct în magazin din cauza asta. Am învățat lecția: testează mereu pe cel mai mic ecran posibil, nu doar pe simulatorul de iPhone 15 Pro Max.
Voi cum gestionați sincronizarea offline-first în aplicațiile voastre de mobil? Mergeți pe soluții gata făcute sau preferați să țineți totul local până când cere publicul un cloud sync?