Třetí a poslední díl o chytré zasedačce: jak spolu mluví webová stránka a zasedačka — a jak mezi nimi tečou data oběma směry.
Co teda řeší zbytek projektu? A jak? Jak funguje to, že webová stránka pošle něco zasedačce? Jak může zasedačka tlačit data do nějaké webové stránky? Takové otázky jsem dostal — některé odbornější, některé víc z pohledu zvenku. Takže tady je třetí a poslední příspěvek na toto téma.
Celé se to bude točit na dvě strany:
Cesta dat ze zasedačky do webu.
Cesta příkazů z webu do zasedačky.
Jak je?
Minule jsem psal, že zasedačka posbírá data a pošle je na IoT hub. Tomu se říká d2c komunikace (device-to-cloud). Takže data už lítají někde v cloudu (v IoT hubu—v našem příměru z minula by se dalo říct, že data jsou na poště), Tam čekají maximálně 7 dní, než si je někdo vyzvedne (než nás pošťák zastihne). Snadné.
Potřebujeme teda někoho, kdo si data přebere (kdo pošťákovi otevře dveře). To je jen pár řádků kódu, v tomto případě Node.js (ale klidně třeba C#, jestli chcete). Těchto pár řádků nedělá nic jiného, než přebírá všechno od pošťáka—všechno, co zasedačka poslala, dostanu sem. Zprávy chodí v JSONu, proto jsem je v minulém článku rovnou do JSONu formátoval. Co se zprávou? Není nic jednoduššího, než ji zahodit nebo uložit. Zvolil jsem druhou variantu. Protože mě (zatím) příliš nezajímá, jak bylo v zasedačce včera, ukládám si jen tu nejnovější hodnotu. Se samotným ukládáním dat jsem se taky moc nepáral. Prostě zprávy beru a sypu je do Firebase. To je (kdo by to čekal?) JSON databáze, takže se zprávou nemusím nic vymýšlet — jak přijde, tak ji uložím, jedna ku jedné. Snadné².
Kromě toho, ze Firebase mi usnadnila ukládání, usnadnila mi i čtení. Je to realtime databáze — takže když se něco (data) změní, hned se o tom všichni (webová stránka) dozví s může zobrazit nová data. Ano, skutečně to znamená, že pro tyto účely nepotřebuji vůbec žádnou logiku na backendu, vlastně nepotřebuji backend vůbec. Snadné³.
Co chceš?
Když chci třeba rozsvítit, kliknu na tlačítko Zapnout u světel a stane se tohle. Poskládám zprávu (příkaz), napíšu adresu (název zasedačky) a předám to stejnému pošťákovi k doručení. IoT hub to doručí kam je třeba (do zasedačky)—tomu se říká c2d komunikace (cloud-to-device). To je v principu vše.
Akorát jsem nechtěl přímo do webu dávat konkrétní parametry — nechtěl jsem přímo do webu psát, že rozsvícení světel znamená poslat nějakému konkrétnímu počítači, konkrétní kód, pro konkrétní rádio. O tom web vůbec nepotřebuje vědět, nic mu do toho není — potřebuje jen říct chci rozsvítit. Udělal jsem teda ještě jednu malou vrstvu, která slouží jako REST API. Opět je to jen pár řádku v Node.js a Express.js (nebo čemkoliv se vám zachce), nic převratného. Jak to funguje? Tato vrstva dostane od webu co (zapnout) a komu (světla) má provést. Podle toho si najde, jaký konkrétní kód, pro jaké rozhraní (rádio nebo infradioda) a kde (v které zasedačce) by se měl provést. Odkud to zjistí? Psal jsem, kde ukládám data, že?
Takže web něco požaduje (a neví co to konkrétně znamená) a druhém konci počítač něco provede (a taky neví, co to znamená). Mezi tyto dva konce je nacpána ta vrstva z předchozího odstavce. Tím se to celé stalo navzájem nezávislé — když budu vrtat do webu/API/počítače, dalo by mi hodně práce, aby se mi podařilo rozbít si ostatní dvě komponenty.
Co vidíme?
Nakonec pár řádků k webu — k tomu, jak to vypadá pro uživatele. Jasně, že by to mohlo být kus kódu v HTML a JavaScriptu, ale to by mě nebavilo. Chtěl jsem trochu proniknout do Reactu. Když už, tak pořádně. Takže celé je to jedna Reactová komponenta, která je složena ze dvou dalších komponent — stavu a ovladače. Chvíli trvalo do toho proniknout a přemýšlet o webu jinak. Celé je to tak nějak ucelenější a čistější (objektové), než změť HTML/JS.
Stav je ta horní část na předchozím obrázku, kde se zobrazuje…no stav. Samo se to dozvídá o aktuálních hodnotách (už jsem říkal ze Firebase je realtime?), samo se to zvládne překreslit, když dorazí nová data.
Zbytek jsou tři stejné komponenty za sebou. Říkám jim ovladač. Je to úplně jednoduché, ovladač má název, tlačítko Vypnout, tlačítko Zapnout. Navíc může mít ještě sadu dalších voleb, to je třeba u klimatizace — Tepleji, Chladněji. Tady se fantazii fakt meze nekladou.
No a úplně dole je ještě něco, co dokáže vypnout nebo zapnout vše najednou — no a není to nic jiného, než zase ten stejný ovladač, akorát vyrenderována maličko jinak.
Důležité je, že celá ta Reactová věc se stará jen UI — vůbec neřeší, co zobrazuje a kde se to vzalo. Vlastně ani neví, kolik, čeho v naší zasedačce máme a jak se to dá ovládat. To je nedefinováno jinde — furt stejná pohádka, na úložišti mám definici zasedačky, což zase není nic jiného, než kus JSONu. Vypadá to asi takto.
Celý ten Reactový kód se pak hodí do parní mlátičky, která to přemlátí do HTML a JavaScriptu, provede nějaké ty optimalizace, vyhází debugovací informace a celé to zminifikuje. Výsledek je pak jedna stránka, kterou stačí hodit někam na hosting (třeba zase na Azure, ale je to fuk) a provozovat.
Hodilo by se dodělat nějakou formu autorizace/autentizace, protože teď můžu z druhého konce republiky blikat světlem v Brně, nebo nechat lidi v zasedačce vymrznout. (A to jsem ještě neuvažoval, že bych na dálku otáčel klíčem ve dveřích). Taky jsem zvažoval ukládat a zobrazovat historii naměřených hodnot a poslaných příkazů — ale koho dneska zajímají včerejší novinky. O napojeni na kalendář zasedačky už jsem se zmiňoval v prvním příspěvku — tím bychom snadno mohli všechno vypnout, když víme, že dnes už se nic až do večera dít nebude.
Snažil jsme se osvětlit celou architekturu, infrastrukturu, technologie i logiku příkladu. Přijde vám to složité nebo jednoduché?
Projekt nikdy není hotový, jen vydány. Tady chybí ještě kus práce, než to bude, jak se patří, ale princip je snad zřejmý.
Pomohlo vám to ve všech těch úvahách, co a jak postavit? Napadají vás další projekty? Mně jo…a baví mě to,..a rozhodne to není nudná CRUDárna… :-)