App Engine vs Firebase - Velkominn í Bizzaro World

Það er næstum 2018 og þú munt leita að upplausn nýs árs. Hér eru nokkrar góðar:

  • Ég ætla að viðurkenna að mér er ekki hægt að treysta með persónuskilríki notenda
  • Ég ætla að hætta að skrifa eigin auðkenningarstraum notenda

Hitinn á skilríkjum notenda er svo mikill núna að nema þú hafir fengið sérstaka hópefli og greini auðkenningarkerfin þín, stýrir auðkenni og fylgist með hugsanlegum brotum í rauntíma, þá siglir þú á úthafinu í lekandi druslu, bara að bíða eftir stórri bylgju til að mölva þig í gleymskunnar dá.

Eins og flest ykkar verð ég að takast á við núverandi kerfi sem hafa skilríki og yada yada, hvað ætlarðu að gera. En það sem ég get gert er að hætta að gera það verra.

Sannvottun - Getur enginn annar gert það?

Getur enginn annar gert það?

Google, Facebook, Twitter, Github, það er til fullt af opinberum sannvottunaraðilum þarna úti. Það er flókið að styðja þá alla, en til að gera það geturðu notað þjónustu frá þriðja aðila eins og Auth0.

Þegar um er að ræða App Engine verkefni höfum við frábæran innbyggðan valkost í Google Cloud Platform.

Eða jæja, næstum því á Google Cloud platform. Það er í Bizarro heimskýjapallinum, annars þekktur sem Firebase.

Eldhólf - Bizarro forritavélin

Af hverju að hafa eitthvað af þessu þegar þú getur haft tvo eða fleiri lúmskur ósamrýmanlega valkosti? Google elskar að gera þetta með stýrikerfum, félagslegum og spjallforritum, svo af hverju ekki með skýjapalla?

Þið ykkar sem þekkið App Engine munu vera vanir því að nota það á venjulegan viðskiptavinamiðlara á einhvern hátt, þ.e .: Platform as a Service:

App Engine, pallur sem þjónusta (PAAS)

Firebase, eins og Google Cloud Platform, er fullt af skýjaþjónustu fyrir flókin hugbúnaðarkerfi. Hins vegar, ólíkt venjulegu GCP (og sérstaklega App Engine), eru rætur þess eins stuðningur og þjónusta, sem kemur út úr farsímaheiminum, og veitir sérstaka andúð farsímaþróunaraðila á því að skrifa afturendakerfi. Arkitektúrinn lítur svona út:

Eldhólf, stuðningur sem þjónusta (BaaS)

Taktu eftir að viðskiptavinirnir tala beint við þjónustuna í Firebase, nota sérstök SDK fyrir vef- og farsímaumhverfi, með JavaScript-aðgerðakóðakóðanum þínum (boo! Hvað með ágætis tungumál!) Sem kveikt er á þeim þjónustu sem byggist á atburðum sem eiga sér stað í annarri þjónustu ; viðskiptavinirnir hringja aldrei í kóðann þinn, þú getur ekki byggt API.

Þetta er öfugt við App Engine, þar sem þú verður að skrifa API fyrir viðskiptavini þína til að hringja og þú talar síðan við aðrar GCP þjónustu fyrir hönd viðskiptavinarins.

Það sem er mjög jákvætt við arkitektúr Firebase bizarro heimsins er að það gerir hluti betur. Það sem vekur mest athygli mína er staðfesting og breyting tilkynninga (í gegnum Firebase Staðfesting og Realtime gagnagrunn, hvort um sig).

Firebase + App Engine - Cat Dog arkitektúrinn

Það erfiða er að þó að App Engine og Firebase berjist ekki raunverulega eins og Superman og Bizzaro, þá sauma þeir ekki sérstaklega auðveldlega saman. Þetta er svolítið köttur-hundur. Við skulum skoða arkitektúrinn:

Firebase + AppEngine - Kötturhundur sem þjónusta (CDaaS)

Þetta er grundvallararkitektúrinn sem ég mun fara yfir með kóða í næstu greinum. Grunnatriðin eru:

1 - Viðskiptavinurinn mun staðfesta með Firebase Auðkenning.

2 - Það verður síðan að nota auðkennismerki til að nota þegar hann talar við App Engine.

3 - Þegar verulegir atburðir eiga sér stað í App Engine sem við viljum að viðskiptavinurinn viti um, munum við ýta upplýsingunum yfir í Firebase Realtime gagnagrunn.

4 - Firebase Realtime gagnagrunnurinn mun ýta breytingum upp á viðskiptavininn. Viðskiptavinurinn getur einnig fyrirspurn Realtime gagnagrunninn eftir því sem óskað er.

Þú munt taka eftir því að ég hef eytt skýjaðgerðum úr myndinni; við munum ekki nota þau hér. Ég vil að þessi skipulag liti enn eins og einfalt Python byggð App Engine forrit, svo við skulum ekki komast í að skrifa JavaScript fyrir node.js.

Athugaðu líka að við ætlum ekki að setja mikið inn í Realtime gagnagrunninn; það er dýrt ($ 5 / GB!). Við munum bara nota það til að breyta tilkynningum og setja raunveruleg gögn í Cloud Datastore.

Hvað er næst?

Í næstu grein munum við komast í raunverulegan kóða, þar sem ég takast á við skref 1 og 2 hér að ofan, með FirebaseUI. Við munum enda með gagnlegt beinagrind sem fjallar um innskráningu / útskráningu í einni blaðsíðu vefforriti með því að nota Firebase Authentication og tala líklega við Python Flask bakhliðina.

Eftir skrift: Hvað með Cloud Firestore?

Ég hef skilið eftir nýja hitann, Cloud Firestore. Þó að ég sé að heilla mig af því, get ég bara ekki alveg fundið út hvernig ég á að nota það.

Cloud Firestore í Firebase er Cloud Datastore GCP (þ.e.: Megastore), með nokkrum mjög flottum breytingum:

  • Það er einfaldara; engin bogagengd lykilvirki, engir flokkar, bara einfalt safn + hlutamannvirki
  • Það hefur tilkynningar um rauntíma fyrir viðskiptavini, eins og raunverulegur gagnagrunnur Firebase
  • Það mælist eins og Cloud Datastore.

Því miður hafa það nokkra galla líka:

  • Það vantar eitthvað af krafti viðskipta í Cloud Datastore.
  • Þegar þú notar Cloud Firestore í App Engine forriti geturðu ekki notað Cloud Datastore
  • Sérsniðin krefst notkunar Cloud Aðgerðir (og jafnvel þá hafa þeir ekki vald til að segja fyrirfram settan stjórnanda á ndb módelflokki). Þú gætir skrifað almenna skýjaaðgerð sem fer bara í python appengine app sem ég geri ráð fyrir.

En mesti gallinn hjá mér er sá að þar sem það er hluti af Firebase lítur arkitektúrinn svona út:

Vandamál mitt við þetta er, það vill að ég setji gagnagrunninn á milli ytri hringjanna minna og afturendakóðans míns. Sem er mjög cockamamie arkitektúr, að mínum huga.

Ég skil hvers vegna það vill vinna svona; gert með þessum hætti, þú getur sent tilkynningar til viðskiptavina í rauntíma á réttan hátt og samþættingin við restina af Firebase er betri. En ég sé bara ekki hvernig þú byggir virkilega alvarlegt afturendaforrit í þessari uppstillingu, og ef þú vilt ekki byggja eitthvað alvarlegt, hvernig ætlarðu að nota megastore-lausn (sem er sterklega öflugur, en krefst vandaðrar meðferðar)?

Í skjölunum er ljóst að vefurinn (javascript við vafra), Android og iOS bókasöfn eru fyrsta flokks borgarar og umhverfi netþjónanna eru annars flokks borgarar. Python krefst þess að bókasafnsstjórnandinn, sem er svolítið ógnvekjandi, geti farið í gang á App Engine (þó að þetta sé vandamál með aðrar þjónustur eldhúss líka).