App Engine vs Firebase - laipni lūgti bizzaro pasaulē

Ir pagājis gandrīz 2018. gads, un jūs meklēsit jauna gada izšķirtspēju. Šīs ir dažas no tām:

  • Atzīšos, ka man nevar uzticēties lietotāju akreditācijas dati
  • Es pārtraukšu rakstīt savas lietotāja autentifikācijas plūsmas

Lietotāju akreditācijas dati tagad ir tik lieli, ka, ja vien jums nav speciālas komandas izveides un autentificēšanas sistēmu analīzes, identitāšu pārvaldīšanas un iespējamo pārkāpumu uzraudzības reālā laikā, jūs atklātā jūrā dodaties izplūdušā netīrumā, tikai gaidot lielu vilni, lai jūs sagrautu aizmirstībā.

Man, tāpat kā lielākajai daļai no jums, ir jātiek galā ar esošajām sistēmām, kurās tiek glabāti akreditācijas dati, un jā, jā, ko jūs darīsit. Bet tas, ko es varu darīt, ir pārtraukt to padarīt vēl sliktāku.

Autentifikācija - vai to nevar izdarīt kāds cits?

Vai kāds cits to nevar izdarīt?

Google, Facebook, Twitter, Github, tur ir daudz publisku autentifikāciju sniedzēju. Viņu visu atbalstīšana ir sarežģīta, taču, lai to izdarītu, varat izmantot trešo pušu pakalpojumus, piemēram, Auth0.

App Engine projektu gadījumā mums ir lieliska iebūvēta opcija Google Cloud Platform.

Vai, labi, gandrīz Google Cloud platformā. Tas atrodas bizarro pasaules mākoņu platformā, kas citādi pazīstams kā Firebase.

Firebase - Bizarro lietotņu dzinējs

Kāpēc jums ir kaut kas tāds, kad jums var būt divas vai vairākas smalki nesaderīgas iespējas? Google to ļoti patīk darīt ar operētājsistēmām, sociālajām un tērzēšanas lietotnēm, kāpēc gan ne ar mākoņa platformām?

Tie no jums, kuri pārzina App Engine, būs pieraduši to izmantot standarta klienta-servera veidā, ti: platforma kā pakalpojums:

Lietotņu dzinējs, platforma kā pakalpojums (PAAS)

Firebase, tāpat kā Google Cloud Platform, ir pilns ar mākoņa pakalpojumiem sarežģītām programmatūras sistēmām. Tomēr atšķirībā no standarta GSP (un it īpaši App Engine) tā saknes ir tikpat aizmugures kā pakalpojums, kas nāk no mobilajām pasaules, un mobilo pakalpojumu izstrādātāju īpaša attieksme pret aizmugures sistēmu rakstīšanu. Arhitektūra izskatās šādi:

Firebase, aizmugure kā pakalpojums (BaaS)

Ņemiet vērā, ka klienti tieši sarunājas ar Firebase pakalpojumiem, izmantojot īpašus SDK Web un mobilajai videi, un jūsu JavaScript aktivizē mākoņu funkciju kodu (boo! Kas par pienācīgu valodu!), Ko aktivizē šie pakalpojumi, pamatojoties uz notikumiem, kas notiek citos pakalpojumos ; klienti nekad nezvana uz jūsu kodu, jūs nevarat izveidot API.

Tas ir pretstatā App Engine, kur jums ir jāraksta API, lai klienti varētu piezvanīt, un pēc tam klienta vārdā jārunā ar citiem GSP pakalpojumiem.

Patiešām pozitīvā lieta par Firebase savādajā pasaules arhitektūrā ir tā, ka tā dažas lietas izdara labāk. Maniem nolūkiem visievērojamākie ir autentifikācija un izmaiņu paziņošana (attiecīgi caur Firebase autentifikāciju un Realtime datu bāzi).

Firebase + App Engine - kaķu suņa arhitektūra

Grūti ir tas, ka, lai arī App Engine un Firebase īsti necīnās kā Supermens un Bizzaro, viņi arī nav viegli sašūti kopā. Tas ir mazliet kaķu suns. Apskatīsim arhitektūru:

Firebase + AppEngine - kaķu suns kā pakalpojums (CDaaS)

Šī ir pamata arhitektūra, kuru es papildināšu ar kodu nākamajos pāris rakstos. Pamati ir šādi:

1 - klients autentificējas, izmantojot Firebase autentifikāciju.

2 - tam būs autentifikācijas pilnvara, kas jāizmanto, runājot ar App Engine.

3 - Kad App Engine notiek nozīmīgi notikumi, par kuriem mēs vēlamies, lai klients zina, mēs ievadīsim informāciju Firebase Realtime datu bāzē.

4 - Firebase reāllaika datu bāze pieprasa izmaiņas klientam. Klients var arī pieprasīt reāllaika datu bāzi pēc vēlēšanās.

Jūs pamanīsit, ka esmu atteicies no mākoņa funkcijām no attēla; mēs šeit tos parasti neizmantojam. Es vēlos, lai šī iestatīšana joprojām justos kā vienkārša, uz Python balstīta App Engine lietotne, tāpēc neiedomāsimies rakstīt javascript vietnei node.js.

Ņemiet vērā arī to, ka mēs parastā daudz neliekam reāllaika datu bāzē; tas ir dārgi (USD 5 / GB!). Mēs to izmantosim tikai paziņojumu par izmaiņām veikšanai un reālu datu ievietošanai Cloud Datastore.

Ko tālāk?

Nākamajā rakstā mēs iepazīsimies ar faktisko kodu, kad es veicu iepriekšminēto 1. un 2. darbību, izmantojot FirebaseUI. Mēs galu galā izveidosim noderīgu skeletu, kas nodarbojas ar pierakstīšanos / izrakstīšanos vienas lapas tīmekļa lietotnē, izmantojot Firebase autentifikāciju, iespējams, runājot ar Python Flask aizmugurējo daļu.

Post Script: Kā ar Cloud Firestore?

Esmu pametis jauno karsto vietu - Cloud Firestore. Lai arī mani tas interesē, es nevaru līdz galam izdomāt, kā to izmantot.

Firebase's Cloud Firestore ir GCP Cloud Datastore (ti, Megastore) ar dažām ļoti stilīgām izmaiņām:

  • Tas ir vienkāršāk; nav lieku atslēgu struktūru, nav klašu, vienkārši vienkārša kolekcija + priekšmetu struktūras
  • Tajā ir klientu reāllaika paziņojumi, piemēram, Firebase reāllaika datu bāze
  • Tas mērogojas kā Cloud Datastore.

Diemžēl tam ir arī daži trūkumi:

  • Tam trūkst darījumu varenības mākoņu datu krātuvē.
  • Kad mākoņu Firestore izmantojat lietotnē App Engine, jūs nevarat izmantot Cloud Datastore
  • Pielāgošanai ir jāizmanto mākoņa funkcijas (un pat tad tām nav, teiksim, iepriekš sagatavota apstrādātāja ndb modeļa klasē). Jūs varētu uzrakstīt vispārīgu mākoņa funkciju, kas, manuprāt, tikai nonāk pie python appengine lietotnes.

Bet lielākais trūkums man ir tas, ka arhitektūra izskatās šādi: tā ir daļa no Firebase:

Mana problēma ar to ir, tā vēlas, lai es ievietoju savu datu bāzi starp ārējiem zvanītājiem un manu gala kodu. Kas, manuprāt, ir patiesi cockamamie arhitektūra.

Es saprotu, kāpēc tā vēlas darboties šādi; darīts šādā veidā, jūs varat pareizi veikt klientu paziņojumu maiņu reāllaikā, un labāka ir integrācija ar pārējo Firebase. Bet es vienkārši neredzu, kā jūs šajā konfigurācijā veidojat patiešām nopietnu aizmugurējo lietotni, un, ja nevēlaties izveidot kaut ko nopietnu, kā jūs plānojat izmantot uz megastore balstītu risinājumu (kas ir vareni spēcīgs, bet prasa rūpīgu apiešanos)?

Dokumentos ir skaidrs, ka Web (pārlūka puses javascript), Android un iOS bibliotēkas ir pirmās klases pilsoņi, un servera puses vide ir otrās klases pilsoņi. Python ir nepieciešama firebase-admin bibliotēka, kas ir mazliet blēdis, lai sāktu lietotni App Engine (lai gan šī problēma ir saistīta arī ar citiem firebase pakalpojumiem).