Best practices for Firebase Realtime Database Development

News Rush har brukt Firebase i 4 måneder nå, og selv om det er ting vi ønsker å bli forbedret (kan du nevne et "perfekt produkt?"), Har det vært et verdifullt supplement til stakken vår for kravene til synkronisering av mobildata.

Underveis har vi lært noen leksjoner om hvordan vi best kan bruke plattformen til å dekke våre behov. Firebase er en dokumentorientert / NoSQL-database, og deler dermed mange av egenskapene til disse plattformene, men har også noen unike egenskaper å lære seg. Her er en rask hjernedump av det vi oppdaget underveis.

RTFM!

SDK-dokumentasjon er vanligvis forferdelig, så mange av oss har en tendens til å skumme etter høydepunktene og komme tilbake til den senere (eller aldri).

Det motsatte er sant her. Guidene og prøvene er enkle å følge, og referansedokumentene er både grundige og villedende korte. Nesten hver gang teamet vårt hadde spørsmål eller spørsmål, fant vi løsningen i noe vi savnet i dokumentene. Til slutt satte vi oss ned og leste hvert ord rett igjennom, og det ble brukt 3 timer godt.

Det er også en blogg som er en skattekiste for å finne løsninger på problemer i den virkelige verden. Her er noen av innleggene vi fant mest kritiske i News Rush:

  • Gruppesikkerhet i branndatabasen
  • Spørringer, del 1: Vanlige SQL-spørringer konvertert for brannbane
  • Beste praksis: Arrays i Firebase

Resultat: “Skjemaløs” betyr ikke hjerneløs!

Det er en vanlig misforståelse at dokumentorienterte databaser planlegger planlegging om hvordan data vil være strukturert mindre viktig. Dette er en myte. Hvis noe, har vi funnet det motsatte: de krever mer.

Det er ikke noe uvanlig med å si at god planlegging kan hjelpe deg med å skvise mest mulig ytelse fra enhver programvarekomponent. Men i SQL-databaser er det vanligvis greit å fikse planleggingsfeil enten ved bare å bli med i flere tabeller, gjøre undersøkelser eller gjøre bulkdataoppdateringer. Siden Firebase ikke har disse konseptene, må du ta deg tid til å sette deg ned og modellere dataene dine og tilgangsmønstrene på forhånd. Du vil være glad for at du gjorde det.

Og RTFM!

Support er forvirrende

Det finnes en rekke støttealternativer, men det kan være frustrerende å prøve å bruke feil i en viss situasjon. Våre erfaringer har vært:

  • Slakk: Samfunnsorientert selvhjelp og idédugnad ikke egnet for andre arenaer. Ikke egnet for "noe er nede."
  • Støtteskjema: Det "offisielle" supportstedet. Rapporter “noe er nede” her. Funksjonsforespørsler som sannsynligvis vil få et hermetisk svar "vi vil vurdere det, men ingen løfter".
  • Google Groups: Aktivt engasjement fra kjerneteamet med de vanlige advarslene om behandlingstid i gruppeorienterte postsystemer. Beste stedet for svært tekniske diskusjoner om internasjonale apper og "rare" problemer.
  • StackOverflow: Sakte / uforutsigbare responstider, men best sted for referansemateriale for sikkerhetskopiering. Hvis du har lest en spørsmål og spørsmål om StackOverflow, vet du hvilken type spørsmål det er best å legge ut der også.

Refs og enkle hentninger er “billig”

I Firebase er en "ref" som en peker til data. Det er instinktivt å ønske å cache eller på annen måte administrere dem, men i de nåværende Firebase-klientbibliotekene bør du aldri gjøre dette. De er egentlig bare innpakket rundt URL-referanser til dataobjekter, og tilbakekallingen av hendelser de gir tilgang til, kan bare ha en lytter av gangen. Hvis du trenger å referere til et objekt fra to forskjellige steder, kan du ta to refs til det. Det koster ikke mer å gjøre dette.

En lignende regel gjelder datainnsamling. De som kommer fra SQL-databaser, er vant til å prøve å hente større objekter i så få spørsmål som mulig for å eliminere rundturstid og spørsmålskostnader. Når du flater ut datastrukturer, er det fristende å kopiere "sammendrag" -data til flere steder for å tillate at ett enkelt henting får alt det som kreves.

I Firebase er dette nesten helt feil beslutning. For en ting er enkle nøkkel- / ref-baserte hentninger kraftig optimalisert og Firebase tilbyr massiv horisontal skala for dem. I vår ytelsestesting på News Rush fant vi også at Firebase gjør det mye bedre med flere, mindre objekter. Selv å fjerne noen unødvendige felt kan gi en målbar ytelsesøkning.

Akkurat som med Redis 'optimaliserte mønstre for strukturer som hasjer og sett, er Firebase sin massive horisontale skalerbarhet en av de viktigste funksjonene. Det skal ikke bare være et hyggelig å ha. Det bør utnyttes selv som et verktøy i appdesignene dine.

Unngå matriser

Firebase-dokumentasjonen dekker allerede dette emnet. Det stemmer. Unngå dem.

Ingen datoer

Firebase har ingen datoobjekttype og tillater ikke synkende sortering. Vi skrev nettopp en hjelper "oppdatering" -funksjon som tar innfødte objekter med Datofelt og konverterer dem til millisekunder-siden-epokeverdier, og legger også til tilsvarende negative tallvarianter av disse verdiene. Sortering stigende på en tidsverdi med negativt tall gir den ønskede fallende rekkefølgen.

Én størrelse passer ikke for alle

Det virket som en så god idé den gangen ...

Utnytt styrkene til Firebase. Ikke prøv å få det til å gjøre hver jobb du har. Her er noen ting Firebase ikke er:

  • En søkemotor. Den har noen få grunnleggende operasjoner som prefiks-matching, men det er det. Bruk ELK, Algolia, osv. Hvis du trenger fulldrevet søk.
  • En API-stabel. Cloud Functions for Firebase ser veldig lovende ut, men er fremdeles i Beta. Hvis appen din er noe mer enn en oppgaveliste, kan du planlegge hvordan du gjør kjøringen på serversiden / klarert kode.
  • En rapporteringsmotor. Det kan hende du fortsatt ønsker å utnytte en relasjonsdatabase når du trenger å skive / terning / filtrere / mutere / munge / etc dataene dine.
  • Selvhostet eller fullt brukbar offline. Frakoblet funksjonalitet tilbys via synkronisering / utholdenhet, men Firebase-skyen må være involvert med det første.

Angi oppdatering

Det er en stor forskjell mellom SET og UPDATE-operasjoner. Det påvirker hva som skjer hvis en nøkkel ikke eksisterer ennå, spesielt nøkler i komplekse objekter. Vær oppmerksom på det!

FirebaseUI er kjempebra!

Å jeg må nevne, det er FirebaseUI ledsagerprosjekter for mange plattformer. Bruk dem. De er utrolig nyttige for ting som å sette opp en tabellvisning for å vise en liste over objekter i en Firebase-samling.

Dette biblioteket inneholder FUICollectionViewDataSource og FUITableViewDataSource klasser (og deres ekvivalenter på Android) som gjør at du kommer i gang på en mobil plattform bare noen få kodelinjer. Den løpende starten var veldig fin da vi først evaluerte Firebase. Vi var i stand til å sette sammen et bevis på konsept på noen få timer med veldig lite læring involvert sammenlignet med andre alternativer på bordet.

Når du er klar for mer sofistikering og kontroll, er FirebaseUI fremdeles nyttig fordi det også inneholder datainnsamlingsklassene FUIArray og FUIIndexArray på lavere nivå, som lar deg kjøre ting som faneoverskrifter og andre oddball-skjermer.

Savnet jeg noe? Del dine egne!