Kipróbáltuk a Firebase-t
Valószínűleg ő lesz a következő legjobb barátunk
Talán egy példával a legegyszerűbb illusztrálni, hogy mi is a Firebase. Tegyük fel, hogy van egy mobilalkalmazásod, és azt szeretnéd, hogy a felhasználók
- bejelentkezhessenek,
- kedvencek közé rakhassanak tartalmakat, és
- push notificationt kapjanak bizonyos események után.
Ez elég egyszerűnek tűnik, a valóságban azonban egy több hétig tartó, komplex, több résztvevős, backendet is igénylő fejlesztés keretén belül valósítható csak meg, ami a költségvonzata mellett rengeteg extra hibalehetőséget is szülhet.
A Firebase egy olyan szolgáltatáscsomag a Google-től, amin keresztül a fenti funkciók mindegyike (és még sok minden más is) megvalósítható backend infrastruktúra és fejlesztő nélkül, egyszerűen, gyorsan — akár teljesen ingyen.
Jól hangzik, ugye? Valóban, persze ez sem csodaszer, nem mindenre jó, de amire igen, arra nagyon.
2012 áprilisában James Tamplin a Firebase első publikus bemutatóján arról beszélt, hogy olyan — a hagyományos szervereket kiváltó — felhő alapú mobil backend szolgáltatást (divatos betűszóval MBaaS-t) terveznek, ami lehetővé teszi a fejlesztőknek, hogy csak a kliensoldali kódra tudjanak koncentrálni. Ebben az időszakban több startup is úgy gondolta, hogy megpróbál megoldást adni az ezen a téren éledező keresletre: a Firebase mellett többek közt a nagyon sokáig jutott Parse is berobbant már ekkor (bár pont az elmúlt napokban zárt be sajnos véglegesen).
Az elmúlt 5 évben sok minden történt nemcsak a piaccal, hanem a Firebase-zel is. A szolgáltatás jövőjét alighanem leginkább meghatározó esemény 2014 végén történt, amikor a Google bejelentette, hogy felvásárolja a teljes céget, és az Amazon AWS-sel konkuráló Cloud Platformjának a részévé teszi.
Másfél év kellett ahhoz, hogy integrálják és új köntösbe öltöztessék a szolgáltatáscsomagot, majd a tavalyi Google I/O-n egy rendkívül impresszív bemutatót tartottak az eredményről (bővebben: összefoglaló a TechCrunchon, ill. előadás a Youtube-on). Azóta teszteljük a rendszert, kíváncsiak voltunk, milyen előnyökkel járhat a csomag egyes moduljainak használata a Mitóban fejlesztett alkalmazásokba építve.
Minden egy helyen
A Firebase önmagában nem egy konkrét termék, hanem sok kisebb-nagyobb, rendkívül hasznos tool egy nagy integrált egésszé gyúrva. Az alábbi ábrán láthatóak összefoglalva az egyes elemek:
Ezek közül azt használod, amire szükséged van. Lehet olyan helyzet, ahol mondjuk csak az Authentication modult, de lehet olyan is, hogy mindent, és az app teljes egészében ki- és felhasználja a szolgáltatásokat.
A Google láthatóan rendkívül sok energiát rakott a Firebase-be, így a 2012-ben ambiciózus terv mára lényegében valósággá vált — sőt, igazából már jócskán túl is mutat a kezdeti álmokon. A pár héttel ezelőtti Fabric és Fastlane felvásárlással még teljesebbé vált/válik a platform, ezzel együtt már egy valóban ütős szolgáltatáscsomagot rakott a Google a Firebase-be, ami így reális alternatívája lehet az eddig megszokott megoldásoknak.
Az elmúlt 9 hónapban igyekeztünk kipróbálni a csomag minél több összetevőjét, lehetőség szerint élesben. Volt olyan kisebb, játszós projektünk, ahol kifejezetten arra mentünk rá, hogy a Firebase legyen “a” backend a háttérben, míg voltak olyan esetek is, amikor már futó, élesben elérhető appokba húztunk be 1–1 hasznos modult vagy újdonságot.
A következőkben összefoglaljuk a főbb komponensekkel kapcsolatos tapasztalatainkat, de nem térünk ki a platform minden részletére, ezzel egy high level képet adva a platform jelenlegi állapotáról és használhatóságáról azoknak, akik érdeklődnek a bevezetés iránt.
Analytics
A Google-nél valamiért néha szeretnek kísérletezni hasonló szolgáltatások párhuzamos futtatásával (ott van nekik a Hangouts, az Allo, a Duo és a sima SMS-eket kezelő Messenger — vajon mennyire lenne bonyolult ezeket végre egyetlen üzenőprogramba összegyúrni?), és első ránézésre a Firebase-be épített analitikai szolgáltatásnál is hasonló érzésünk lehet. Ez az érzés azonban csak részben valós, a Google Analyticshez képest bőven találunk felhasználásbeli eltéréseket, sajnos a Firebase Analytics kárára. Jó úton jár az eszköz, de több komoly negatívummal is találkoztunk a használat során:
- A report felület azonnal megjelenít tucatnyi, mobilfejlesztés szempontból releváns információt, viszont testreszabhatóság szempontjából eléggé kötött — például egy készülékcsoport-specifikus konverziós anomália kiszűrése rendkívül nehéz feladat, ha nem tudjuk, hogy mit keresünk.
- Event törlésére egyelőre nincs lehetőség.
- A Dashboardunkon keresztül leszűrhetjük az adatokat egy konkrét Audience-re (egy audience lehetnek pl. a “Vásárlók”), de azon belül már nem tudsz további szűrőt beállítani (pl. csak iOS userek), ez csak úgy működik, ha létrehozol egy új, speciális, több feltételt összefogó Audience-t (a fenti példa alapján: “Vásárlók - iOS”). Körülményes.
- Ha véletlenül hibásan implementáljuk a mérőkódot, és nem szeretnénk látni a hibás adatokat, akkor csak az a megoldás, ha a teljes hibás verziót kiszűrjük az összes adat közül. A mérőkódok helyes implementálásának ellenőrzése az első ilyen fiaskó után hirtelen nagyon fontossá válik a Firebase-t használóknak. A tesztelésre szolgáló debug megoldás (az ún. DebugView) egyelőre még sajnos csak zárt bétában érhető el, várhatóan azonban a következő Google I/O-ig mindenki számára elérhetővé teszik — nagy szükségünk is van rá.
A kellemetlenségek mellett nagyon komoly előnye az 5-nél nagyobb event funnel, ami csak a Firebase-ben érhető el egyelőre, valamint a korlátlan adatkeret. Google Analytics esetén ez utóbbi lehetőség csak a prémium ügyfeleknek érhető el — az ingyenes verzióban meghatározott felhasználószám felett a Google Analytics már csak mintavételezésből állítja össze a mutatott adatokat, ami nagy látogatottságú/használatú termékek esetén eléggé pontatlan.
Számunkra a Firebase leginkább napi status reporting eszközként vált be, tehát kvázi dashboardként használtuk. Az ingyenessé tett Data Studio használatával hamarosan lehetőség nyílik majd arra is, hogy egy tényleg nagyon kényelmes, könnyen és gyorsan áttekinthető reporting felületet készíthessünk — a fantáziánk beindítására érdemes megnézni a Data Studio sample galériáját. Persze mielőtt beleszeretünk az iroda egyik falára felfúrt 50-es tévébe, ill. a rajta futó és minden információt stílusosan, valós időben megjelenítő Analytics Dashboard gondolatába, érdemes megnéznünk a Cloud Platform alá tartozó BigQuery szolgáltatás árazását is, mert egy komoly forgalmú Firebase + BigQuery párosítással hamar beleszaladhatunk egy vaskosabb számlába.
Tapasztalataink alapján a Firebase Analytics rendkívül ígéretes termék, azonban egyelőre még nem váltja ki teljesen a klasszikus Google Analytics-et, párhuzamosan érdemes használni a két rendszert, mivel mélyebb elemzésekre még egy darabig biztosan a Google Analytics lesz a megfelelő eszköz. Érdekes kényelmi funkció, hogy a két rendszert összekapcsolhatjuk, és a Firebase Analyticset elérhetjük Google Analytics-ből is, de a praktikumon felül ne várjunk többet, ugyanazt a felületet kapjuk, mint Firebase-ben:
Remote Config
Egy mobil fókuszú A/B teszttel kapcsolatos kutatás során próbáltuk ki először a Firebase Remote Config szolgáltatását, és egyből kiderült, hogy egy igazán komoly kis gyöngyszem rejlik az alapvetően rendkívül egyszerűnek tűnő felszín alatt.
A funkció bemutató videójában idéznek egy példát, ami tökéletesen megvilágítja a Remote Config erejét: készítünk egy játékot, beküldjük a store-ba, a felhasználók elkezdik használni, de kiderül, hogy az egyik pálya túl nehéz. Remote Config nélkül módosítanunk kellene a kódon, buildelni, tesztelni, beküldeni, megvárni a review-t, majd azt, hogy a felhasználók frissítsék a készülékükön az appot. Rengeteg idő, rengeteg energia. A Remote Configgal viszont csak annyi a dolgunk, hogy módosítjuk a paramétereket a szerveren, majd a következő indításkor az app leszedi onnan az értéket, és azonnal életbe lépnek a módosítások.
Tehát lényegében arról van szó, hogy a config egy részét a kódból kiszervezzük a cloudba. És ezt még lehet fokozni: az Analyticsből származó adatok alapján célozni is tudjuk a változtatásokat, akár úgy, hogy csak bizonyos feltételeknek megfelelő userek kapják meg azokat, akár úgy, hogy tágabban, a teljes felhasználói bázisunk x%-ába tartozó userek kapják meg.
Hamar nagy kedvencünkké vált ez a funkció, rendkívül egyszerű és rugalmas a használata, pl. a Koin Android verziójában arra használjuk, hogy futási környezettől függően (dev, staging, prod) másként működjön az app, más API elérési útvonalat és más limiteket használjon. Zseniális, hogy ehhez ráadásul külön filter van a felületen:
Képességei alapján evidens hogy a Remote Config kiváló A/B tesztek futtatására, de további előnyöket is találtunk:
- Míg az Play Store már jó ideje támogatja a staged release intézményét (az applikáció kiengedése nem rögtön a teljes userbázist, hanem annak csak egy részét célozza, ami segít egy-egy kritikus hiba által okozott kár minimalizálásában), addig az iTunes Connectben ennek még sajnos nyomát sem látni, ami az amúgy is hagyományosan körülményes iOS platformon lévő appok kezelését még nehezebbé teszi. Remote Configot használva bizonyos mértékig kiváltható ez a hiányosság.
- Igazából csak máshogy kell felfogni az A/B tesztet, és egyből perszonalizációra is használhatjuk a Remote Configot — ha az appunk felhasználója megfelel bizonyos feltételeknek, akkor mondjuk kiírhatunk neki más szöveget, mint a többieknek, vagy akár kedvezményt adhatunk neki a szolgáltatásunk használatához stb.
Ha már perszonalizáció és tesztek, a közeljövőben érkezik a Firebase-be a StreamView szolgáltatás is, ami a már említett DebugView egy különleges variációja, amellyel főleg kutatási célokat fog szolgálni egy előre kiválasztott célcsoport anonim példányának in-app viselkedésének pontos megmutatásával — ezzel részlegesen kiváltva a hagyományos userteszteket.
Database
Meglepő, hogy a Firebase core funkciójának, lényegében genezisének számító Realtime Database kapja a legvegyesebb fogadtatást a szakmától. Talán a legtöbbet idézett mondat ezzel kapcsolatban jól fogja meg a problémát:
Dealing with relations with NoSQL is hard, dealing with relations with Firebase is pain in the ass. — Baptiste Jamin
Egyszerűbb alkalmazásoknál és adatszerkezeteknél azonban rettenetesen kényelmes haszálni a rendszert, valamint a teljes körű online-offline syncet is profin megoldották több eszközön és platformon átívelően.
Azonban, amint bonyolultabb struktúrára van szükségünk, egyből kiderül, hogy a Firebase sajnos közelében sincs (még) a konkurenciának, pl. a MongoDB-nek, és így rákényszerülünk arra, hogy több a többhöz kapcsolatok implementálásánál duplikációkat kelljen létrehozni és utólag karbantartani. Azt is érdemes megjegyezni, hogy a webes felület lényegében egy JSON editor, azért itt még bőven lenne mit fejleszteni.
Fontos funkció, hogy a Firebase jogosultságkezelésével korlátozhatjuk, kinek és mikor van joga írni a kliensoldalon tárolt adatbázisba, amivel nagyban csökken a jogosulatlan hozzáférés és módosítás biztonsági kockázata. Ezen felül viszont a sajnos szokásos, közismert kliensoldali logikával járó problémák megmaradnak. Így ha például változik az adatbázis-struktúránk, akkor sajnos változtatni kell a mobilappunk kódját is, erre nem tud megoldást adni a Firebase. Ebből következik, ha egy felhasználó nem frissíti az appunkat, de közben változtattunk az adatbázis sémánkon, akkor az alkalmazás rövid úton összeomlik. Ezért is érdemes egyébként minden alkalmazásunkba lehetőség szerint még a projekt legelején belerakni egy olyan funkciót, amivel az app elindítása után közvetlenül tudunk kommunikálni a felhasználónak verzióváltás vagy egyéb vis maior történés esetén (természetesen ezt egyébként a legegyszerűbb Firebase-re építve megoldani).
Crash reporting
Mito ❤ Fabric, ez már az egyik előző posztunkból is kiderülhetett. Természetesen rajtunk kívül a fél világ imádja a Twitter ingyenes szolgáltatását, és mivel tökéletesen passzol a Firebase univerzumba, így nem csoda, hogy nemrég a Google fel is vásárolta.
A Firebase-ben lévő crash reporting eszköz most még jóval butább és egyszerűbb, mint a Fabric, de azért vannak benne hasznos részek, mint például, hogy analitikában lemérheted egy-egy crash hatását a userek viselkedésére, vagy ha használod a notification szolgáltatást, akkor crash áldozatokra célozva tudsz üzenni (good PR tool).
Kíváncsian várjuk, hogy fogják összevarrni a két rendszert a Google mérnökei a következő hónapokban, de addig is a két szolgáltatást — az analitikához hasonlóan — párhuzamosan érdemes használni.
További funkciók
A fentieken kívül rengeteg egyéb funkció van még, amikre most nem térünk ki részletesen, de mindegyik nagyon ígéretes és bizonyos esetekben hasznos:
- Fájlokat tárolhatunk a Hosting és Storage modulban, ehhez a Google elképesztően gyors és nagy lefedettségű CDN-t biztosít a háttérben.
- Az Authentication modullal login funkciót lehet könnyedén rakni az alkalmazásba. Alapból ismeri a nagy szolgáltatókat (Facebook, Google, Twitter, Github), de engedélyezhetünk anonim belépést, vagy mezei user/jelszavas regisztrációt is. Még arra is van lehetőség, hogy a már meglévő azonosítási megoldásunkat húzzuk be a háttérben. Nagyszerűen működik, sajnos egy komoly hiányosságot találtunk: a kimenő e-mailek (pl. elfelejtett jelszó) tartalmát személyre lehet szabni, de a sablont egyáltalán nem. Ráadásul nyelvesíteni sem lehet, ha ilyen terved van, akkor egyedi megoldást kell készítened rá.
- A Cloud Messaging kapott végre egy felhasználóbarát notification felületet.
- Egészen hasznos lett a Dynamic Links és az Invites modul is — a segítségükkel olyan linket lehet készíteni, amin keresztül az appon belül egy konkrét helyre tudjuk mozgatni a usert (pl. emailből vagy webről), illetve, ha nincs telepítve neki az appunk, akkor megnyílik az App Store/Google Play, majd telepítés után a felhasználó odaugrik egyből az először elindított alkalmazáson belül, ahova szerettük volna, tehát a link túléli a telepítési folyamatot. Ez leírva lehet, hogy bonyolult, de a valóságban user szempontból nagyon gördülékeny a folyamat.
- Reklámok megjelenítéséhez használhatjuk az eddig különálló szolgáltatásként futó AdMob-ot is, és a közvetlen kötés lehetséges AdWords-zel is.
Árazás
A Firebase három csomagban érhető el:
- Spark — Ingyenes tier, alapvetően normális korlátokkal.
- Flame — Fix havi díjas csomag, ha fontos, hogy tervezni tudj.
- Blaze — A legnagyobb appokhoz, limit nélkül, pay as you go.
A belépő szintű Spark csomag szerintünk erősen ajánlott ezután minden mobilalkalmazásba, mert a rendkívül hasznos szolgáltatások többsége korlátozás nélkül elérhető:
Analytics, App Indexing, Authentication, Cloud Messaging, Crash Reporting, Dynamic Links, Invites, Notifications & Remote Config
A következő szolgáltatásoknál pedig csomagtól függően különböző korlátokba ütközhetünk:
Database, Storage, Hosting, Test Lab, Cloud Platform
Alapvetően az ingyenes csomagban lévő limitek is bőven elegendők úgy általában a mindennapokhoz, kisebb userbázist és felhasználási módot feltételezve.
Fontos kiemelni, hogy az adatbázisok backupjait csak a Blaze csomagban lehet elérni (mondjuk a backup is csak akkor ér valamit, ha visszatölthető, lsd. GitLab szomorú példája múlt hétről) és habár az árak barátiak, és csak annyit fizetsz, amennyit használod a rendszert, de egy komolyabb peak (tegyük fel egy Google Play feature kiemelés) után igazán vastag lehet a számla. Ez persze más szolgáltatás esetén is igaz, tehát mindenképpen érdemes egy worst case scenariót is felvázolni az alkalmazások tervezése során, és megvizsgálni egyéb alternatívákat is még azelőtt, hogy mindent egy lapra (a Firebase-re) teszünk fel.
Jövőkép
Sajnos nem egyszer láttunk már olyat, hogy a nagyvállalatok a kisebb, de sikeres termékek felvásárlása után egyszerűen csak az embereket veszik át, a terméket nem. A Firebase-re is sokáig - a Google kommunikációjának ellenére - aggódva nézett a mobilfejlesztő közösség, mivel elég kellemetlen tud lenni, ha egy 3rd party szolgáltatást felvásárló új tulajdonos kihúzza alólad a rendszert és a támogatást. Ez a rizikó természetesen mindig fennáll, hiszen ma már nehezen képzelhető el app külső library-k és szolgáltatások használata nélkül, de azért egészen más a helyzet akkor, ha egy logging szolgáltatást beszántanak, mint amikor a teljes backend és adatbázis kiszolgálód szól, hogy van pár hónapod átmenni máshova.
Teljesen korrekt és jogos felvetés, hogy vajon mennyire tehetjük magunkat kiszolgáltatottá a Google belső üzleti érdekeinek, de minden jel arra mutat, hogy az Amazonhoz hasonlóan egy rendkívül összetett, egyre több mindent lefedő, előremutató és a piac elvárásainak megfelelő (fizetős!) szolgáltatás-birodalmat épít a cég. Biztató az is, hogy több, eddig önálló szolgáltatást tereltek be a Firebase ernyője alá, mint pl. a Channel API, az AdMob ill. a Cloud Messaging.
Az is megnyugtató, hogy a Google rendkívül sok energiát rak a platform támogatásába:
- Youtube-on egy dedikált profil alatt kiemelkedően aktív tartalomgyártás zajlik,
- a hivatalos dokumentáció gazdagon el van látva példákkal,
- a Firebase blogját heti rendszerességgel frissítik, és láthatóan odafigyelnek a visszatérő látogatókra is — kedves gesztus volt, ahogy a fentebb már említett zárt DebugView bétájára is egy blogpost végén ingyenjegyeket osztogattak:
Neither of these are yet available to the general public, but as your reward for making it this far into the blog post, here’s a link to sign up for the DebugView closed beta.
See? Reading has its advantages!
Verdikt
Minden arrafelé mutat, hogy a Google Firebase egy előbb-utóbb megkerülhetetlen, iparági standard megoldásként lesz pozícionálva, és olyan fejlesztéseket, funkciókat raknak bele, amivel még kényelmesebbé válik a mobilapp fejlesztés. Ezt úgy is lehet persze érteni, hogy több idő jut majd a konkrét fejlesztésre, sok, és egyre több kapcsolódó területet érintő feladatot levesznek majd a vállunkról.
Az elmúlt 9 hónapban rengeteg pozitív és negatív élményünk volt a Firebase-zel, sokszor csettintettünk elismerően a nyelvünkkel, azonban az tisztán látszik, hogy a platform minden részét nem ajánlanánk és használnánk nyugodt szívvel.
Az alábbi funkcióknak és irányoknak például kifejezetten örülnénk:
- A Crashlytics integrálása mellett megmaradhatna a crash csoportra célzás lehetősége is, valamint esetleg kiegészülhetne egy közös nevezőt kiemelő modullal (API level korlátok, eszközparaméterben mutatott hasonlóságok stb.).
- Hogy teljesen leválthassuk a klasszikus Google Analyticset, szükség lenne egy profibb felületre az analitikához, akár annak az árán is, hogy így komplexebbé válik a felület.
- Sajnos kiemelt fontosságú, hogy legyen lehetőség elszeparálni a különböző futási környezeteket (development, staging, prod) — a Facebook is nagyon sokáig képtelen volt megoldani ezt a dolgot, aminek az eredménye átláthatatlan, minden környezethez és fejlesztőhöz külön-külön létrehozott appok voltak, most itt is kicsit hasonló a helyzet.
- Izgatottan várjuk a Beta és Fastlane bevezetését, mert így egy olyan egyplatformos, etalon CI megoldás születhetne, amit jelenleg csak háztáji módon, különböző szoftvereket egyedileg összelegózva lehet kialakítani (pl. beépülhetne a QA folyamatokba a Google Test Cloud, az ingyenes része egy-egy regressziós tesztet futtatna, a fizetős része pedig szélesebb eszközparkot fedne le, kiváltva a saját device farmos tesztelési megoldásainkat).
Használnánk éles projektben a Firebase-t? Igen, mindenképpen (de csak bizonyos részeit).
Vannak modulok, amiknek a bevezetését már most kifejezetten ajánljuk és támogatjuk. Az, hogy a Firebase minden esetben kiváltson egy teljes mobil backendet, az már erősen véleményes és fenntartásokkal kezelendő — de nem tartjuk elképzelhetetlennek, hogy kisebb projekteknél, kis csapatnál, üzletileg kevésbé kritikus funkciók esetén ez működőképes terv lehet. Okos tervezéssel kiválthatjuk a backend fejlesztést és az ehhez szükséges infrastruktúrát, azonban nagyobb projekteknél érdemesebb csak a platform néhány, viszont rendkívül hasznos részeit bevezetni.
Mi már elkezdtük.
További olvasnivaló
Ha még jobban érdekel a téma, a következő linkeket ajánljuk:
Rólunk
Áron a Mito Technical Project Managereként a Wizz Air Android és iOS mobil alkalmazásának fejlesztéséért felel.
A Mitóban az ügynökségi munkák mellett komoly fejlesztéseket is végzünk, büszkék vagyunk rá, hogy többek közt az OTP Bank, a Magyar Telekom, a Deutsche Telekom, a Wizz Air, a Szerencsejáték Zrt., valamint az izlandi lottótársaság számára szállíthatunk webes és mobil megoldásokat.
http://mito.hu és http://mito.hu/jobs
