App Engine vs Firebase - Vítejte v Bizzaro World

Je téměř 2018 a budete hledat novoroční předsevzetí. Zde jsou některé dobré:

  • Přiznám se, že s uživatelskými přihlašovacími údaji nelze důvěřovat
  • Přestanu psát své vlastní toky ověřování uživatelů

Nárok na pověření uživatele je nyní tak vysoký, že pokud nemáte specializovaný týmový tým, který by analyzoval vaše autentizační systémy, spravoval identity a sledoval potenciální narušení v reálném čase, plavíte na volném moři v netěsném, jen čekám, až tě velká vlna rozbije do zapomnění.

Stejně jako většina z vás se musím vypořádat s existujícími systémy, které mají pověření, a yada yada, co budete dělat. Ale to, co mohu udělat, je přestat je zhoršovat.

Ověřování - Nemůže to udělat někdo jiný?

Nemůže to udělat někdo jiný?

Google, Facebook, Twitter, Github, existuje spousta poskytovatelů veřejné autentizace. Je obtížné je všechny podporovat, ale za tímto účelem můžete využívat služby třetích stran, jako je Auth0.

V případě projektů App Engine máme skvělou vestavěnou možnost v Google Cloud Platform.

Nebo dobře, téměř v cloudové platformě Google. Je v Bizarro World Cloud Platform, jinak známé jako Firebase.

Firebase - Bizarro App Engine

Proč máte něco z toho, když máte dvě nebo více jemně nekompatibilních možností? Google to rád dělá, s operačními systémy, sociálními a chatovými aplikacemi, tak proč ne s cloudovými platformami?

Ti z vás, kteří jsou obeznámeni s App Engine, budou zvyklí na jeho používání standardním způsobem typu klient-server, tj .: Platforma jako služba:

App Engine, Platform as a Service (PAAS)

Firebase, stejně jako Google Cloud Platform, je plný cloudových služeb pro komplexní softwarové systémy. Na rozdíl od standardu GCP (a zejména App Engine) však jeho kořeny jsou stejně Backend jako služba, která vychází z mobilního světa, a zvláštní averze mobilních vývojářů k psaní back-end systémů. Architektura vypadá takto:

Firebase, Backend jako služba (BaaS)

Všimněte si, že klienti mluví přímo se službami ve Firebase pomocí speciálních sad SDK pro webové a mobilní prostředí, přičemž váš kód JavaScriptu Cloud Functions (boo! Co slušný jazyk!) Je spouštěn těmito službami na základě událostí, ke kterým dochází v jiných službách. ; klienti nikdy nezavolají váš kód, nemůžete vytvářet API.

To je na rozdíl od App Engine, kde musíte napsat klientům rozhraní API, aby mohli volat, a pak jménem klienta hovořit s dalšími službami GCP.

Opravdu pozitivní věc na bizarní světové architektuře Firebase je, že to dělá některé věci lépe. Nejvýznamnější pro mé účely jsou ověřování a oznámení o změně (prostřednictvím Firebase Authentication a Realtime Database, resp.).

Firebase + Engine Engine - architektura Cat Dog

Obtížné je, že zatímco App Engine a Firebase ve skutečnosti nebojují jako Superman a Bizzaro, nijak zvlášť snadno sešijí. Je to trochu kočičí pes. Pojďme se podívat na architekturu:

Firebase + AppEngine - kočičí pes jako služba (CDaaS)

Toto je základní architektura, kterou budu rozvíjet s kódem v následujících několika článcích. Základy jsou:

1 - Klient se autentizuje pomocí Firebase Authentication.

2 - Poté bude mít ověřovací token, který bude použit při rozhovoru s App Engine.

3 - Pokud dojde v aplikaci App Engine k důležitým událostem, o kterých chceme, aby o nich klient věděl, vložíme tyto informace do databáze Firebase Realtime Database.

4 - Firebase Realtime Database posílá změny klientovi. Klient může také dotazovat Realtime databázi podle potřeby.

Všimnete si, že jsem z obrázku vyloučil funkce cloudu; nebudeme je používat zde. Chci, aby se toto nastavení stále cítilo jako jednoduchá aplikace App Engine založená na Pythonu, takže se nezačneme psát javascript pro node.js.

Také si všimněte, že do databáze v reálném čase nebudeme moc vkládáni; je to drahé (5 $ / GB!). Použijeme jej pouze pro oznámení o změně a vložíme skutečná data do cloudového datového úložiště.

Co bude dál?

V dalším článku se dostaneme do skutečného kódu, protože se zabývám výše uvedenými kroky 1 a 2 pomocí FirebaseUI. Skončíme s užitečnou kostrou, která se zabývá přihlášením / odhlášením v jedné stránce webové aplikace pomocí autentizace pomocí Firebase, mluvíme pravděpodobně se zadním koncem Pythonovy baňky.

Post Script: A co Cloud Firestore?

Vynechal jsem novou žárlivost, Cloud Firestore. I když mě to zajímá, prostě nedokážu vymyslet, jak ji použít.

Cloud Fireestase Firebase je cloudové datové úložiště GCP (tj. Megastore), s několika velmi skvělými změnami:

  • Je to jednodušší; žádné tajemné klíčové struktury, žádné třídy, pouze jednoduchá kolekce + struktury položek
  • Má oznámení v reálném čase pro klienty, jako je databáze Firebase Realtime
  • Měří se jako Cloud Datastore.

Bohužel má také některé nevýhody:

  • Chybí část transakcí v Cloud Datastore.
  • Pokud v aplikaci App Engine používáte Cloud Firestore, nemůžete použít Cloud Datastore
  • Přizpůsobení vyžaduje použití cloudových funkcí (ai poté nemají sílu, řekněme, předem zpracovaného popisovače třídy ndb). Mohli byste napsat obecnou cloudovou funkci, která právě prochází do aplikace python appengine, myslím.

Ale největší nevýhoda pro mě je, že protože je součástí Firebase, architektura vypadá takto:

Můj problém s tím je, že chce, abych vložil svou databázi mezi své externí volající a můj zadní koncový kód. Což je podle mě opravdu architektura cockamamie.

Chápu, proč chce takto pracovat; tímto způsobem můžete provádět oznámení o změnách v reálném čase klientům správně a integrace se zbytkem Firebase je lepší. Ale já prostě nechápu, jak v této konfiguraci sestavíte opravdu seriózní aplikaci, a pokud nechcete stavět něco vážného, ​​jak využijete řešení založené na megastore (což je mocně výkonný, ale vyžaduje pečlivé zacházení)?

V dokumentech je zřejmé, že Web (javascript na straně prohlížeče), Android a iOS jsou prvotřídními občany a prostředí na straně serveru jsou občany druhé třídy. Python vyžaduje knihovnu firebase-admin, která je trochu bastardem, aby se pustila do App Engine (i když se jedná o problém s jinými službami firebase).