Firebase Cloud-funktioner: det store, det meh og det grimme

Da jeg gennemgik Firebase sidste år, klagede jeg over, at det ikke var helt serverløst. En Node-server var stadig nødvendig for almindelige funktioner såsom at sende e-mails eller oprette miniaturebilleder.

Firebase Cloud-funktioner blev annonceret et par måneder senere. Tjenesten er stadig i beta, men jeg har brugt den lykkeligt i et par måneder i produktionen.

Lad os se, hvordan det klarer sig.

Hvad er Firebase Cloud-funktioner?

Hvis du aldrig har hørt om skyfunktioner før, er konceptet ret ligetil. Implementere kortfattet logik til en server i form af funktioner, og nogle flittige alfer kan magisk påberåbes fra limbo for at udføre en opgave for dig. Alt dette uden at bekymre sig om infrastruktur og kun betale for udførelsesressourcer.

I mange tilfælde kan dette nye paradigme forenkle skrivning, vedligeholdelse og kørsel af backend-kode.

Især Firebase Cloud-funktioner er som Lego-blokke, som du kan oprette forbindelse til enhver Firebase-tjeneste. For eksempel kan en funktion udløses, når et billede uploades til Firebase Storage for at oprette et miniaturebillede, eller måske rense nogle brugerdata, når en node slettes i Realtime Database. Stort set alt, hvad der interesserer sig i Firebase, kan udløse en funktion.

Hvis det ikke er nok, kan du også bruge HTTP til at udløse funktioner med GET, POST osv. Tjek denne fantastiske video om, hvordan du kombinerer Firebase Hosting med Cloud-funktioner for at oprette en komplet Express-app:

Den store

Infrastruktur bliver ikke lettere end dette

Infrastruktur er helt abstraheret fra dig, ligesom resten af ​​Firebase. Hver gang en funktion udløses, kommer en ny virtuel server til live, gør sit job og vender tilbage til limbo. Google Clouds magi fortsætter med at udløse dine funktioner og skalere infrastruktur i henhold til arbejdsbelastningen automatisk.

Priser

Cloudfunktioner generelt er meget omkostningseffektive. Det er svært at sammenligne priser for cloud-udbydere, men jeg kan sige, at baseret på min erfaring har Firebase Cloud-funktioner været latterligt billige. Det er svært at tro, at Google tjener nogen penge på dette.

Let at bruge

Som sædvanligt med Firebase og Google er dokumenterne gode, og du laver ikke mental akrobatik for at få det . Der er også masser af prøver på Github for at komme i gang. Deployment auth håndteres af Firebase CLI, så det er bogstaveligt at få en hej verden til at køre:

firebase init functionsfirebase deploy

Jeg synes, at enkelheden ved at bruge Firebase og Google Cloud generelt bare er fantastisk, specielt sammenlignet med konkurrencen.

Fleksibel

Som jeg skrev før, kan disse funktioner udløses af alle mulige begivenheder. Jeg vedder på, at du ikke løber tør for ideer til, hvordan du integrerer dem med dit Firebase-projekt eller endda resten af ​​din stak.

Her er nogle af de problemer, vi har løst ved hjælp af Firebase Cloud-funktioner:

  • Generer PDF-filer til en online faktureringstjeneste ved hjælp af Phantom.js, og underskriv disse fakturaer med en vis offentlig service
  • Forbind en Go-tjeneste med en tredjeparts SOAP-udbyder (ugh)
  • Send e-mails via HTTP fra hvor som helst i vores stak

Meh

Kold start

Skalerbarhed er stor, men køretid kan svinge vildt. En simpel hej verdensfunktion kan tage 3 ms at udføre sit job, eller en 100 ms.

functions.https.onRequest((request, response) => { response.send(“Hello from Firebase!”);});

Disse udsving skyldes opstartstider for virtuel server. Hvis den virtuelle server, der kører din funktion, er vågen, udløses funktionen med det samme. Men hvis serveren skal bringes op fra limbo, vil det naturligvis have brug for mere tid til at begynde at arbejde. I skyfunktionerne lingo kaldes dette varm og kold start.

I praksis kan du ikke stole på ensartede svartider, medmindre du cachelagrer dine data, som beskrevet i den foregående video, eller bruger hacks til at holde dine funktioner varme.

Desværre er kolde starter et uundgåeligt aspekt ved håndtering af skyfunktioner (fra enhver udbyder). Du bliver nødt til at tage det i betragtning, når du beslutter at bruge en skyfunktion til at løse noget.

Ingen planlægning (cron)

Cloudfunktioner er perfekte til at udføre opgaver med lav trafik som at generere rapporter eller lave periodiske sikkerhedskopier klokken 02, men med Firebase eller Google Cloud er der ingen nem måde at udløse dine funktioner på baggrund af en tidsplan.

Firebase-teamet anbefaler, at du opretter et App Engine-projekt for at orkestrere disse udløsere. Tjenesten beder virkelig om noget som Heroku Scheduler.

Kun JavaScript

Jeg er ok med JavaScript, men både Azure og AWS understøtter mange flere sprog. Det er ironisk, at Google ikke understøtter Go i sin skyfunktionstjeneste, men AWS gør det.

Knude 6

Igen går konkurrencen bedre. Både AWS Lambda og Azure-funktioner kører allerede på Node 8. Den største ulempe her er at vende tilbage til løfter uden asynkronisering / afvente eller at skulle konfigurere Babel til dit projekt.

Den grimme

Dev workflow

Med undtagelse af HTTP-udløste funktioner kan du ikke køre dine funktioner lokalt. Funktioner udløst af en Firebase-tjeneste skal implementeres i skyen.

Dette har mange grimme implikationer:

  • Små fejl ender med at koste meget tid, da nye funktioner tager et par minutter at begynde at arbejde.
  • Implementerede funktioner har ingen indlysende versioner. Alle logfiler med den samme funktion ser ud til at være fra samme version. Det er aldrig klart, hvornår de nye funktioner rent faktisk fungerer, så dit eneste valg er at udløse funktionerne manuelt og See-What-Happens ™.
  • Ingen tilbageslag

Miljøer

Ud over de tidligere punkter er styring af miljøer ... kompliceret.

Du kan tilføje miljøvariabler til dine funktionsprojekter ved hjælp af Firebase CLI, men som andre aspekter af Firebase er dette en naiv tilgang, der ikke skaleres godt.

Du skal bruge legitimationsoplysninger for at få adgang til stort set alt uden for Firebase-sandkassen. For andre Google Cloud-tjenester kommer disse legitimationsoplysninger i form af .jsonfiler. Multiplicer det med ethvert miljø (dev, produktion, iscenesættelse), og du kan ende med et kongeligt rod.

Jeg endte med at manuelt omdøbe legitimationsfiler, før jeg implementerede eller værre, implementerede alle legitimationsoplysninger og valgte den rigtige ved kørsel. Lad mig vide i kommentarerne, hvis du har fundet en vej rundt dette.

Jeg ville elske at se en Miljø fanen i Firebase Console, hvor jeg let kunne administrere disse indstillinger for hele Firebase projektet. Skift mellem miljøer skal være lige så let som firebase use production.

Konklusion

Bortset fra en del friktion under udviklingsfasen, har min erfaring med Firebase Cloud-funktioner været positiv. Når disse ting er implementeret, er de pålidelige og kræver ingen vedligeholdelse som lovet. Så ja, Firebase er endelig helt serverløs. Hurra!

Hvis du allerede bruger Firebase, er det virkelig en no brainer. Firebase Cloud-funktioner er et godt supplement til dit projekt, selvom tjenesten stadig er i beta.

På den anden side er det rimeligt at sige, at konkurrencen har et mere modent produkt. Hvis du ikke investeres i Firebase eller Google Cloud og overvejer at bruge skyfunktioner i din stak, bør du sandsynligvis også undersøge, hvad AWS eller Azure har at tilbyde.

For at være helt ærlig er jeg lidt bekymret for, at tjenesten stadig er i beta. Det er over et år siden det blev annonceret, og fremskridt føles smertefuldt langsomt. Konkurrencen synes langt mere engageret i sine skyprodukter, selvom Google Cloud ifølge Diane Greene, administrerende direktør for Googles skyvirksomheder, er den “hurtigst voksende sky”.

Det er alt.

Bemærk: I en tidligere version af denne artikel hævdede jeg, at det ikke var muligt at skrive tests for ikke-HTTP-funktioner. Dette er forkert, og her er dokumenterne om, hvordan du gør det.