Bedste fremgangsmåder til udvikling af Firebase Realtime Database

News Rush har brugt Firebase i 4 måneder nu, og selvom der er ting, vi gerne vil have forbedret (kan du navngive et "perfekt produkt?"), Har det været en værdifuld tilføjelse til vores stak til vores krav til mobildatasynkronisering.

Undervejs har vi lært nogle lektioner om, hvordan vi bedst bruger platformen til at imødekomme vores behov. Firebase er en dokumentorienteret / NoSQL-database, og deler dermed mange af egenskaberne ved disse platforme, men har også nogle unikke egenskaber, som de kan lære. Her er en hurtig hjernedump af det, vi opdagede undervejs.

RTFM!

SDK-dokumentation er normalt forfærdelig, så mange af os har tendens til at skumme efter højdepunkterne og vende tilbage til dem senere (eller aldrig).

Det modsatte er sandt her. Guiderne og prøverne er lette at følge, og referencedokumenterne er både grundige og vildledende korte. Næsten hver gang vores team havde et spørgsmål eller et problem, fandt vi løsningen i noget, vi gik glip af i dokumenterne. I sidste ende satte vi os ned og læste hvert ord lige igennem, og det var 3 timer, der blev brugt godt.

Der er også en blog, der er en skattekiste til at finde løsninger på problemer i den virkelige verden. Her er et par af de indlæg, vi fandt mest kritiske i News Rush:

  • Gruppesikkerhed i Firebase-databasen
  • Forespørgsler, del 1: Almindelige SQL-forespørgsler konverteret til ildbase
  • Bedste fremgangsmåder: Arrays i Firebase

Korollar: "Skema-mindre" betyder ikke hjerne-mindre!

Det er en almindelig misforståelse, at dokumentorienterede databaser planlægger planlægning af, hvordan data bliver struktureret mindre vigtige. Dette er en myte. Hvis noget, har vi fundet det modsatte: De kræver mere.

Der er intet usædvanligt ved at sige, at god planlægning kan hjælpe med at skubbe den mest ydelse ud af enhver softwarekomponent. Men i SQL-databaser er det som regel ligetil at løse planlægningsfejl enten ved blot at slutte sig til flere tabeller, udføre undespørgsler eller foretage bulkdataopdateringer. Da Firebase ikke har disse koncepter, skal du tage dig tid til at sidde ned og faktisk model dine data og adgangsmønstre forud for tiden. Du vil være glad for, at du gjorde det.

Og RTFM!

Support er forvirrende

Der er en række supportmuligheder, men at forsøge at bruge den forkerte i en bestemt situation kan være frustrerende. Vores oplevelser har været:

  • Slack: Fællesskabsorienteret selvhjælp og brainstorming ikke egnet til andre spillesteder. Ikke egnet til "noget er nede."
  • Supportform: Det "officielle" supportsted. Rapporter "noget er nede" her. Funktionsanmodninger, der sandsynligvis får en dåse, "vi overvejer det, men ingen løfter" -svar.
  • Google Groups: Aktivt engagement fra kerneteamet med de sædvanlige advarsler om behandlingstid i gruppeorienterede postsystemer. Bedste sted for meget tekniske diskussioner om app-internals og "underlige" problemer.
  • StackOverflow: langsomme / uforudsigelige responstider, men det bedste sted for backup-referencemateriale. Hvis du har læst en spørgsmål og spørgsmål om StackOverflow, kender du også den type spørgsmål, der er bedst at stille der.

Refs og enkle hentninger er “billige”

I Firebase er en "ref" som en markør til data. Det er instinktivt at ønske at cache eller på anden måde administrere dem, men i de nuværende Firebase-klientbiblioteker skal du aldrig gøre dette. De er virkelig bare indpakket rundt om URL-referencer til dataobjekter, og de tilbagekaldte begivenheder, de giver adgang til, kan kun have en lytter ad gangen. Hvis du har brug for at henvise til et objekt fra to forskellige steder, skal du tage to refs til det. Det koster ikke mere at gøre dette.

En lignende regel gælder for dataindhentning. De, der kommer fra SQL-databaser, er vant til at forsøge at hente større objekter i så få forespørgsler som muligt for at eliminere rundrejsetid og forespørgselsoverhead. Når man udflader datastrukturer, er det fristende at kopiere “resume” -data til flere placeringer for at give en enkelt hentning mulighed for at få alt det nødvendige.

I Firebase er dette næsten udelukkende den forkerte beslutning. For det første er enkle nøgle- / ref-baserede hentninger stærkt optimeret, og Firebase tilbyder massiv vandret skala til dem. I vores ydelsestest på News Rush fandt vi også, at Firebase klarer sig meget bedre med flere, mindre objekter. Selv fjernelse af et par unødvendige felter kan give en målbar ydelsesforøgelse.

Ligesom med Redis 'optimerede mønstre til strukturer som hash og sæt, er Firebase's massive vandrette skalerbarhed en af ​​dens vigtigste funktioner. Det skal ikke bare være et dejligt at have. Det skal være gearet som et værktøj i dine appdesign.

Undgå matriser

Firebase-dokumentationen dækker allerede dette emne. Det er helt korrekt. Undgå dem.

Ingen datoer

Firebase har ingen datoobjekttype og tillader ikke faldende sortering. Vi skrev lige en hjælper “opdatering” -funktion, der tager indfødte objekter med Datofelter og konverterer dem til millisekunder-siden-epoke-værdier og tilføjer også tilsvarende negative talvarianter af disse værdier. Sortering stigende på en tidsværdi med negativt tal giver den ønskede faldende rækkefølge.

Én størrelse passer ikke alle

Det virkede som en sådan god idé på det tidspunkt ...

Udnyt brandstyrkens styrker. Forsøg ikke at få det til at gøre hvert job, du har. Her er nogle ting Firebase er ikke:

  • En søgemaskine. Det har et par basale operationer som præfiks-matching, men det er det. Brug ELK, Algolia osv., Hvis du har brug for fuld-drevet søgning.
  • En API-stak. Cloudfunktioner til firebase ser meget lovende ud, men er stadig i Beta. Hvis din app er noget mere end en opgaveliste, skal du planlægge, hvordan du udfører serversiden / pålidelig kodeudførelse.
  • En rapporteringsmotor. Du ønsker muligvis stadig at udnytte en relationsdatabase, når du har brug for at skive / terning / filtrere / mutere / munge / osv. Dine data.
  • Selvhost eller fuldt anvendelig offline. Offline-funktionalitet leveres via synkronisering / vedholdenhed, men Firebase-skyen skal være involveret i starten.

Indstil vs. opdatering

Der er en stor forskel mellem SET og UPDATE-operationer. Det påvirker, hvad der sker, hvis der ikke findes en nøgle endnu, især taster inde i komplekse objekter. Vær opmærksom på det!

FirebaseUI er fantastisk!

Åh, jeg skal nævne, der er FirebaseUI ledsagerprojekter til en masse platforme. Brug dem. De er utroligt nyttige til ting som at opsætte en tabelvisning til at få vist en liste over objekter i en Firebase-samling.

Dette bibliotek indeholder FUICollectionViewDataSource og FUITableViewDataSource klasser (og deres ækvivalenter på Android), der gør det muligt at komme i gang på en mobil platform blot et par kodelinjer. Den løbende start var meget flot, da vi oprindeligt vurderede Firebase. Vi var i stand til at sammensætte et bevis på koncept på få timer med meget lidt læring involveret sammenlignet med andre muligheder på bordet.

Når du er klar til mere sofistikering og kontrol, er FirebaseUI stadig nyttigt, fordi det også indeholder klasserne til lavere dataindsamling FUIArray og FUIIndexArray, der giver dig mulighed for at køre ting som faneoverskrifter og andre uligholdskærme.

Gik jeg glip af noget? Del dine egne!