Firebase ako hlavný dátový zdroj

Nedávno sme vydali mobilnú aplikáciu OTKD 2017 pre bežcov štafetového behu o dĺžke 345km — Od Tatier k Dunaju.

Nápad na aplikáciu sa zrodil u mňa, keďže sa podobných pretekov zúčastňujem ako bežec aj kapitán, presne viem, aké požiadavky obe strany používateľov potrebujú.


Fáza 1 — Vydefinovanie funkcií a návrh dizajnu

V prvej fáze sme spísali funkcie, ktoré sú dôležité pre:

  • bežca
  • kapitána

Následne funkcie boli rozdelené do viacerých fáz (sprintov) podľa jednotlivých rolí a prešlo sa k vytvoreniu dizajnu.

S každou funkciou bol spojený popis použitia, správanie na mobilnom zariadení a rola, pod ktorou je funkcia dostupná.


Hlavné funkcie aplikácie:

  • prihlásenie ako bežec/kapitán
  • správa úsekov a bežcov na nich pridelených
  • chat v tíme
  • profil používateľa
  • výsledky bežca
  • výsledky na úseku
  • celkové poradie
  • sledovanie bežca na trati
  • nahlásiť zrazenie organizátorovi

Fáza 2 — Návrh architektúry

V druhej fáze sme navrhli architektúru na základe nasledujúcich požiadaviek:

  • funkcionalita aplikácie
  • prostredie
  • počet používateľov
  • počet aktualizácií za časovú jednotku

Prostredie

Prostredie, v ktorom aplikácia bola využívaná bolo najčastejšie:

  • úseky v lese bez dátového pripojenia
  • úseky na dedinách so slabým pripojením
  • väčší počet užívateľov využívajúcich dáta zjednotených väčšinou na jednom mieste — predávkové miesta

Počet používateľov

Aplikácia očakávala priemerne okolo 2000 aktívnych používateľov.

  1. Android — 80% používateľov
  2. iOS — 19% používateľov
  3. Windows Phone — 1% používateľov

Aktualizácia dát

Dáta bolo potrebné aktualizovať v reálnom čase po každom prebehnutí každého bežca predávkovým miestom. Naraz na tratili bolo postupne od 10tich do 2000 bežcov, ktorí behom hodiny a niekedy aj v kratšom/dlhšom čase prebehli predávkou a v tej chvíli bolo potrebné:

  • prerátať poradie na vybranom úseku
  • prerátať celkové poradie voči všetkým tímom
  • aktualizovať počty bežiacich tímov
  • prerátať čas konkrétneho bežca
  • aktualizovať výsledky nad mapou
  • aktualizovať úseky priradené jednotlivým bežcom

Technologické riešenie

Technologické riešenie bolo postavené na základe vyššie uvedených požiadaviek nasledovne:

  1. Dátová vrstva — Firebase
  2. Aplikačná vrstva — Swift, Kotlin
  3. Prezentačná vrstva — Swift, Kotlin

Firebase sme zvolili najmä z dôvodov:

  • real time aktualizácie dát
  • offline podpora
  • obmedziť a presunúť záťať z webu na externú službu, ktorá je na podobné situácie navrhnutá a postavená

Funkcionalita počas behu

  1. Po prebehnutí bežca každým úsekom/odštartovaní tímu/dobehnutí tímu do cieľu sa dáta zo zariadenia na predávkových miestach odošlú do DB pre webovú stránku.
  2. Dáta sa aktualizujú a prekreslia na webe zobrazované používateľom sledujúcim beh pretekov doma alebo počas pretekov cez web
  3. Aktualizovaný json obsahujúci nové dáta z databázy sa odošle do Firebase
  4. Dáta v nodoch pre firebase sa aktualizujú
  5. Aktualizácia v mobilnej aplikácii

Dátový model

Dátový model obsahoval nasledovné nody s prihliadnutím na denormalizáciu dát. Firebase je NoSQL databáza, preto návrh štruktúry bol pre jej potreby optimalizovaný a zohľadnený.

  • locations
  • login runner
  • results
  • sections
  • tem members
  • user data
  • messagging

pričom aktualizované boli takmer nody všetky z dôvodu zmeny bežcov v tíme aj ich poradia možného aj počas pretekov.

Počas pretekov štatistiky z Firebase vyzerali nasledovne:

Firebase sme prepli do platenej verzie, zvládajúcej 100 tisíc pripojení na inštanciu, 2,5 GB na ukladanie dát, 20GB na sťahovanie dát, čo samozrejme nestačilo pri prvej forme platenej verzie. Finálna suma do dnešného dňa za spotrebu predstavovala 17 dolárov.

Implementačné riešenie na strane mobilnej aplikácie

Na strane mobilnej aplikácie architektúra vyzerala nasledovne:

Hlavním úkolem mobilní aplikace je zobrazovat výsledky v reálném čase. Firebase SDK používá k předávání dat návrhový vzor Observer, rozhodli jsme se pro zbytek aplikace jít cestou reaktivního programování. Tok dat přes všechny vrstvy architektury byl implementován pomocí knihoven RxSwift respektive RxKotlin.

Vzhledem k tomu, že Firebase se také sám dokáže postarat o offline ukládání dat, tak Model sestává pouze z entitních tříd a tenkého wrapperu nad připojením k Firebase databázi a aplikační logika je pouze ve ViewModelu.

Postrehy počas pretekov

  • hlavním problémem byla dle očekávání kvalita internetového připojení na trase
  • node results, který se aktualizoval každých několik minut, obsahoval příliš velké množství dat, v kombinací se špatným připojením tak docházelo ke zpoždění 5–20 minút
  • offline režim firebase fungoval pro naše potřeby dobře, vždy byla uživateli zobrazena naposledy dostupná data
  • kvůli způsobu fungování webu a databáze se do Firebase posílala data při každém update přibližně 200x (změny v týmech se neprovedly najedou, ale pro každý tým zvlášť), což vedlo k vysoké spotřebě dat i výkonu
  • nejnáročnější proces bylo zpracování jsonu do objektů

Vylepšenia do budúcnosti

Do budúcnosti je potrebné pre zabezpečenie hladšieho behu mobilnej aplikácie a spracovania dát:

  • denormalizovať dáta na menšie časti, vyčleniť pre každý úsek výsledky do samostatného nodu, rovnako samostatný node pre každého bežca zvlášť
  • upraviť časť dizajnu pre potreby denormalizovaných dát
  • omezit frekvenci aktualizace dat ve firebase
  • optimalizovat zpracování jsonu v modelu aplikace

Prvá verzia aplikácií je dostupná:

Autor článku: Svetlana Margetová , Ondřej Mařík
Show your support

Clapping shows how much you appreciated Nanooq IT’s story.