Firebase: den store, den meh og den grimme

Vi sprang lige ind i Firebase, da Google annoncerede det ved Google I / O i maj 2016.

Vi startede en React-applikation på en enkelt side, der havde brug for at arbejde på mobil via Cordova og desktop via Electron. Så Firebase virkede som en magisk løsning for os.

Nu, efter 7 måneders arbejde med Firebase næsten dagligt, er jeg klar til at dele vores oplevelse med det.

Den store

Realtidsdata

Ja, det er fantastisk. Med lidt VVS og noget databindende trolldom kan du forbinde dine synspunkter med dine data, og de ændres magisk, når dataene ændres.

Efter vores erfaring var ydeevnen konsekvent god, selvom Firebase er designet med millioner af brugere i tankerne, så vi ikke engang ridsede på dyrets overflade.

Vores brugere er stadig imponeret over, hvor hurtigt alt kører.

Statisk hosting på steroider

Firebase-hosting leveres med gratis CDN og SSL - alt sammen kører på Google Cloud-platformen. Dette betyder, at du ikke skal have problemer med at servere filer til et hvilket som helst antal brugere over hele kloden.

Hvis du leder efter nulkonfigurationshosting til din næste app med en enkelt side eller et statisk websted, vil jeg virkelig overveje Firebase som en mulighed, selvom du ikke bruger nogen af ​​Googles andre tjenester.

Superkræfter

Firebase giver dig også et antal tjenester og SDK'er, der er super nemme at integrere som:

  • OAuth-godkendelse
  • Filopbevaring
  • Database sikkerhedskopier
  • Automagisk skalering
  • CLI til implementering og andre opgaver
  • Gratis niveau

Meh

Konsollen

Det er smukt, og det giver dig mulighed for at gøre en række ting, men det er ikke nyttigt.

Databasemanageren er virkelig en forherliget JSON-editor. Fantastisk til hvad det er, men det er ikke den fulde løsning, jeg forventede at være. Hvis du kommer fra WorkBench, Postico, Mongotron eller endda PHPMyAdmin, kommer dette som et dejligt legetøj.

Et andet meget begrænsende aspekt af konsollen er manglen på detaljerede logfiler eller analyser. I betragtning af at det er data-besat-Google , taler vi om dette, virker bizart. Sikker på, at du får en god graf til brug af databasen, men der er ingen måde at vide, hvor mange gange en fil er blevet downloadet fra lageret, medmindre du selv implementerer en løsning.

Serverløs?

Firebase er statisk hosting + API, ikke mere. Denne begrænsning er ikke verdens ende. Du kan nemt løse dette ved at bruge en Node.js-server som en anden klient af Firebase, som du sandsynligvis har brug for til mange almindelige opgaver såsom at oprette miniaturebilleder, sende e-mails til dine brugere osv.

Det vil tilsyneladende være muligt at bruge Google Cloud-funktioner (stadig i Alpha) med Firebase, men hvem ved hvornår. Måske vil dette blive annonceret på Google I / O 2017.

(Rediger marts 2017 : Firebase annoncerede netop Google Cloud-funktioner til Firebase)

( Rediger maj 2018 : Tjek min anmeldelse af Firebase Cloud-funktioner)

Definition af sikkerhedsregler

Firebase bruger en JSON-fil med Javascript-kode i strenge til at definere regler over databasen og opbevaring.

{ "rules": { "users": { "$uid": { ".write": "$uid === auth.uid" } } }}

Dette er ikke så slemt som det lyder, da du kan bruge Bolt til at gøre denne proces mindre smertefuld. Selvom du bruger Bolt, bliver denne fil, når du går ud over nogle få dusin regler, uholdbar italiensk mad ™.

Tjenester som Dream Factory og Graph Cool giver dig et ordentligt værktøj til at gøre det uden at miste din sundhed.

Proprietær teknologi

Da Facebook besluttede at lukke Parse, befandt mange projekter sig i en vanskelig position. Jeg tvivler ærligt på, at dette vil ske med Firebase, men jeg kan forstå modviljen mod at parre din tech-stack med en tredjeparts platform-as-a-service.

Ingen måde at udvikle sig lokalt

Hvis du rejser ofte eller bor i et land med dårlig forbindelse, skal du overveje at du ikke kan arbejde med en lokal installation. Du kan ikke bare bruge Docker eller Node og starte din API.

Det grimme

Begrænset Javascript SDK

Der er en række funktioner i Firebase, der kun er implementeret i deres iOS- og Android-SDK'er.

Den mest iøjnefaldende er manglen på offline vedholdenhed, når du arbejder med Javascript. Din web-, hybrid- eller ReactNative-applikation fortsætter med at fungere, hvis enheden mister forbindelsen et øjeblik. Men når du lukker applikationen eller fanen, forsvinder dine data. Det er op til dig at implementere en cache med vedholdenhed. Dette kan virkelig være en seriøs bestræbelse, især på mobil.

Javascript SDK har ikke engang en måde at cache data på (ikke sikker på iOS eller Android). Hvis du indlæser /productsog derefter har brug for disse data igen senere, bliver du nødt til at genindlæse dem, medmindre du manuelt holder en forbindelse i baggrunden. Det er ikke svært at implementere dette, men igen, hvorfor giver Firebase ikke en magisk måde at gøre det på?

Ingen måde at spørge korrekt til dine data

Du kan lave nogle meget grundlæggende filtrering og paginering, men bortset fra det er du alene.

Virkelig? Google leverer en datatjeneste uden søgnings- eller filtreringsfunktioner?

Ja. Virkelig.

Hvis du vil implementere søgefunktionalitet, skal du enten downloade alle dataene og gøre det i klienten, bruge en server som beskrevet tidligere eller implementere en tredjepartstjeneste som Elastic.

Firebase's udviklere har sagt, at dette er ved design, så de kan sikre høj ydeevne. OKAY. Men hvorfor ikke lade os brugere beslutte, om vi har råd til at betale præstationsprisen for vores brugssag?

Ja, og glem alt om at gøre sammenføjninger eller andet, der er fjernt fancy med dine data. Hvilket bringer mig til ...

Dum datamodellering

Det er svært at håndtere forholdet til NoSQL, det er smerte i røven at beskæftige sig med forholdet med Firebase. - Baptiste Jamin

Hvad han sagde.

Firebase-databasen er stort set kun en enorm JSON-fil. Der er ingen måde at erklære en for mange eller mange for mange relationer. I praksis betyder det, at du ender med at duplikere dine data overalt.

Dette virker først ikke så slemt. Når alt kommer til alt er det praktisk at placere brugerens navn i en chatbesked, nej?

{ “author”:”Pepito Flores”, “message”:”I want a taco!”, “time”: 1484269756951}

Problemet kommer, når du faktisk skal redigere Pepitos navn, da du bliver nødt til at ændre det overalt, hvor du har brugt det og ikke kun i /users.

At fortælle dine brugere, at de ikke kan redigere deres navn, er normalt ikke en levedygtig mulighed, så:

  1. Din klientkode til at skrive og redigere data til Firebase bliver i mange tilfælde Italian Food ™.
  2. Det er mildt sagt svært at dokumentere, hvor du har duplikeret dine data.

Da mange NoSQL-databaser som MongoDB eller RethinkDB har fundet veje omkring dette problem, finder jeg det vanskeligt at tro, at Google ikke kan løse dette med i det mindste rimelig ydeevne.

TL; DR

Firebase er fantastisk til enkle projekter eller til at udvikle små funktioner, der kræver realtidsdata. For eksempel en chat eller et notifikationssystem. Det er de imponerende 30 minutters demoer, du ser på YouTube. Det fungerer også rigtig godt, hvis dine data er strømme af ting med en simpel struktur såsom en service til et online multiplayer-spil.

Alt med mere komplekse datakrav bliver vanskeligt eller endog umuligt med Firebase. Regelmæssig kørsel af mølledatabaseforespørgsler er i de fleste tilfælde mere værdifulde end realtidsdata, og så imponerende som at se ting ændre sig er det sandsynligvis ikke noget, du har brug for.

Ligesom alt, vælg det rigtige værktøj til jobbet.

Tillæg: hvad Firebase skal være fantastisk

  1. Reelle forespørgselsfunktioner. Søg, slutter sig til, hele enchiladaen.
  2. En slags referencer kan lide MongoDB eller RethinkDB.
  3. Ægte offline vedholdenhed med Javascript.
  4. Giv mig moar analytics.
  5. En cache-API.

Det er alt.

Tillæg 2: info om moar

Hvis du læser dette, evaluerer du muligvis Firebase som udvikler eller CTO. Her er nogle andre artikler, der kan hjælpe dig med at afgøre, om Firebase måske fungerer for dig, og om det er værd at investere ekstra tid til evaluering.

Firebase: Det gode, dårlige og grimme - RaizException - Raizlabs Developer Blog

Som en del af vores arbejde som softwareudviklere hos Raizlabs vurderer vi konstant de nyeste udviklingsværktøjer, der er brugt ... www.raizlabs.com Årsager til ikke at bruge Firebase

Opbygning af realtidsapplikationer er i dag standard. Hos Crisp brugte vi Firebase i produktion over 9 måneder, startende fra ... crisp.im