Salutare! Am vrut să văd cum se mai comportă Expo în producție în 2024, așa că am pus pe picioare o aplicație simplă de habit tracking. După o lună de la lansare am strâns în jur de 200 de utilizatori activi și am adunat o listă lungă de chestii pe care le-am făcut prost.
Stack-ul tehnic și de ce l-am ales
Am vrut să livrez repede, așa că am mers pe o rețetă destul de clasică pentru ecosistemul React Native de azi:
- Expo cu Expo Router v3: Managementul rutelor bazat pe fișiere e genial, am salvat timp pe care altfel îl pierdeam cu configurarea React Navigation.
- expo-sqlite: Pentru că aplicația trebuia să fie offline-first, datele trebuiau să se încarce instant, fără loading spinners.
- NativeWind v4: Tailwind pentru React Native.
- Supabase: Doar pentru autentificare și sync-ul opțional în cloud al bazei de date.
Cu EAS (Expo Application Services) am economisit cel puțin 30% din timpul pe care îl pierdeam de obicei cu configurarea certificatelor de iOS și a build-urilor de Android. Rulezi o comandă în terminal și pleci să-ți faci o cafea, iar build-ul se face singur în cloud. Superb.
Unde s-a rupt filmul: Greșelile mari
Când ai 5 testeri interni, totul e roz. Când treci de 150-200 de useri reali, încep să apară cazurile speciale la care nu te-ai gândit niciodată.
Cea mai mare palmă am luat-o de la sincronizarea offline-online. Am vrut să fiu deștept și am scris un algoritm propriu de sync bazat pe timestamp-uri (updated_at). Am zis că dacă modifici un obicei pe telefon, trimit timestamp-ul în Supabase și facem update dacă e mai nou.
Am pățit rapid clasica problemă: useri care foloseau aplicația pe tabletă și pe telefon în același timp. Sau useri care își schimbau manual ora telefonului ca să "trișeze" la obiceiurile din ziua precedentă. Algoritmul meu simplist a început să suprascrie date bune cu date vechi. A ieșit un haos total în tabele. Trebuia să folosesc de la început o soluție matură de CRDTs sau o librărie dedicată precum WatermelonDB, care știe să gestioneze conflictele de sync nativ.
A doua problemă a fost cu NativeWind v4. Deși e mult mai stabil decât versiunile anterioare, am avut surprize mari pe Android. Anumite stiluri de layout (în special flex-box-uri imbricate) se randau total diferit pe un Samsung mai vechi față de simulatorul de iOS. Am pierdut vreo două nopți bune reparând bug-uri de UI raportate de useri pe Google Play.
Trade-off-ul de care trebuie să fii conștient
SQLite local e incredibil de rapid. Query-urile rulează în mai puțin de 2ms, ceea ce face ca aplicația să se simtă extrem de fluidă. Totuși, trade-off-ul e că ești blocat pe mobil. Dacă mâine vreau să lansez o versiune web pentru aplicație, managementul SQLite pe web prin WASM e încă destul de experimental și greoi de configurat în Expo.
În plus, dacă userul își pierde telefonul și nu a activat sync-ul cu Supabase (care era opțional), datele lui sunt pierdute definitiv. Am avut deja un utilizator destul de supărat care a pățit asta după ce și-a scăpat telefonul în apă.
Ce aș schimba dacă aș lua-o de la capăt
În primul rând, aș renunța complet la sync-ul custom. Ori o lăsam 100% offline (fără opțiune de cloud, simplu și curat), ori foloseam un serviciu gata integrat pentru sync offline-first, cum e PowerSync sau RxDB. Să scrii tu logică de reconciliere a datelor e o rețetă sigură pentru fire albe în cap.
În al doilea rând, n-aș mai forța userii să își facă cont chiar de la primul ecran. Din cei 200 de oameni, destul de mulți mi-au zis că au fost la un pas să șteargă aplicația când au văzut ecranul de login. Trebuia să îi las să folosească aplicația anonim, local, și să le cer cont doar dacă voiau backup în cloud.
Voi ce folosiți pentru stocarea offline și sincronizare în proiectele de React Native? Rămâneți la variante clasice sau ați testat soluții mai noi?