Video: React 01 - Jak začít?

React JS: Jak začít?

V předchozím příspěvku jsem se věnoval drobnému porovnání React a Angular 2. Nyní se pojďme podívat na to, jak začít....

Mnoho nových termínů a technologií

Před tím, než se pustíte do vývoje webové aplikace pomocí Reactu, dostane se Vám do ruky nepřeberné množství technologíí, které s tímto vývojem souvisí.
Jak už jsem zmiňoval, tak i přesto, že Angular 2 nabízí možnost "all in one", tak ani tam se nevyhnete tomu, že se budete muset naučit pracovat s několika novými "pojmy".
Myslím si, že právě to, že postavit funkční dev stack je vcelku alchymie, dochází k tomu, že mnoho lidí skončí dřív, než vůbec začne.
K tomu, jak správně začít se dozvíte z tohoto článku.

React DEV stack

Tento DEV stack vychází z mého vlastního návrhu. Inspiraci jsem čerpal jak z diskuzních fór typu stackoverflow.com, tak i z různých blogů na toto téma. Pojďme to tedy vzít postupně....

https://www.npmjs.com/

I když je React možné provozovat tak, že do index.html vložíte odkaz na js soubory Reactu, tak počítejte s tím, že tento způsob je dobrý maximálně na prototypování, tedy na vyzkoušení si, jak vlastně psát v Reactu komponenty.

V budoucnu se dostanete do fáze, kdy budete potřebovat řešit i jiné knihovny, verzování, spouštění skriptů, apod. K tomuto účelu slouží právě NPM, což není nic jiného, než package manager pro javascript.

Pomocí NPM si nalinkujete vše, co Vaše aplikace bude potřebovat. Ať už je to bootstrap, jQuery či knihovny typu Redux, apod.

NPM se definuje pomocí souboru package.json. V něm definujete jak dané knihovny, tak i samotné skripty, které chcete spouštět. Poté již stačí jen v daném adresáři napsat: "npm install" a všechny Vaše knihovny se automaticky stáhnou a nainstalují do adresáře node_modules.

Spouštění skriptů se provádí pomocí "npm run xxx". Kde za xxx dosadíte název z package.json.

Webpack

Bohužel pouze s NPM si nevystačíte. Sice už víte jak správně přidávat nové knihovny, ale stále před Vámi bude problém ohledně toho, jak správně aplikaci sestavit, jak spustit debug, jak vytvořit produkční build, apod. K tomuto účelu slouží právě Webpack. 

Existují i varianty typu Gulp či Grunt, nicméně věřte, že právě Webpack všechny tyto alternativy překonává.

Důvodem proč, je to, že pokud budete ignorovat Webpack a půjdete cestou třeba Gulpu, Vaše aplikace bude obsahovat šílený Gulp skript, kterým budete ovládat jednotlivé potřeby Vaší aplikace.

Webpack na to jde jinak. Pomocí modulů.

Napadá mě jedna hezká synergie: Gulp = Ant, Webpack = Maven :)

Typescript

Pokud čekáte, že se javascriptové aplikace píší v čistém javascriptu, musím Vás zklamat. Téměř nikdo to nedělá. Tedy alespoň ne ti, kteří to myslí skutečně vážně :)

Asi by se našlo hodně lidí, kteří by předchozí větu zpochybnili a jistě by měli pravdu. Mnoho lidí píše v javascriptu, ale ne v tom, který je aktuálně podporován většinou prohlížečů. Zkusím to trochu více rozvést....

Javascript spadá do specifikace ECMA Scriptu. ECMA Script není javascript a javascript není ECMAScript. ECMAScript je specifikace :)

V současné době je ve vývoji verze 7. I když je verze 6 už více jak rok stará, tak bohužel většina webových prohlížečů stále na 100% nepodporuje všechny její vlastnosti.

Jelikož rádi zkoušíme nové věci a rádi bychom využívali nové možnosti, které daný jazyk nabízí (a v případe specifikace ECMA Scriptu, to jsou skutečně zajímavé vlastnosti), tak hledáme způsob, jak je využít již teď.

Proto mnoho vývojářů začalo používat transformaci, kde aplikaci napíší ve specifikaci ECMA 6 a převedou ji do verze ECMA 5, se kterým si většina webových prohlížečů již poradí.

K tomuto účelu výborně slouží Babel. 

Touto cestou se vydal také React a většinu aplikací, které naleznete na github.com, jsou napsány právě pomocí Babelu.

Bohužel stále zde existuje jeden velký neduh a to je typovost. Psaní v ECMA 6 je sice výrazně lepší varianta, nicméně není to ideální volba.

Microsoft přišel s vlastní specifikací jazyka, který se jmenuje Typescript. Typescript je například výchozím jazykem pro Angular 2. Důvod, proč Google zvolil technologii Microsoftu je to, že i když je Typescript vlastní jazyk, je plně kompatibilní s ECMA specifikací.

Jinými slovy, to znamená, že v typescriptu můžete psát jako v javascriptu a on bude stále validní.

Výhoda Typescriptu je zejména v tom, že jde za hranice ECMA Scriptu 6. Nabízí totiž typovost, která Vám bude zaručovat lepší konzistenci celého projektu.

Jedinou nevýhodou, která je s Reactem spojena, je to, že React na začátku zvolil Babel a proto je většina ukázek práve s ECMA 6 a nikoli v Typescriptu. Nicméně není třeba se bát. Psát pomocí Typescriptu v Reactu je pohodlné a osobně jsem nenarazil na problém, který by neměl řešení. Pro představu, jak psát pomocí v Reactu Typescriptu je zde: React a Typescript. 

Doporučení na závěr: NIKDY NEPIŠTĚ ČISTÝM JAVASCRIPTEM. Pokud Vám Typescript z nějakého důvodu nevyhovuje, zvolte alespoň transformaci pomocí Babelu. Nicméně Typescript je nejlepší volba, kterou můžete nyní zvolit.

Redux

O reduxu jsem psal v minulém přispěvku. Hned po té, co ovládnete React, implementujte Redux. Důvody, proč zvolit Redux je jednoduchá. Budete mít stav své aplikace pod kontrolou.

React Router

Samotnými komponenty Reactu si v aplikaci skutečně nevystačíte. Pokud hledáte, jak správně routovat, existuje jasná volba. 

Možná Vás napadne myšlenka, proč není React Router součástí Reactu. Důvodem je to, že React Router slouží pro webové aplikace a samotný React neslouží jen pro psaní webů. Existuje zde totiž možnost, psát v Reactu i mobilní aplikace. K tomuto účelu slouží React Native. Proto je React Router jako vlastní knihovna a není jeho součástí. React Native je zajímavá alternativa, jak psát mobilní aplikace a v budoucnu o této technologii jistě něco napíši.

Redux Thunk

Pokud použijete Redux, tak se dostanete k jedné zásadní otázce. Tou je, jak se poprat s asynchronním zpracováním. Redux Thunk nedelá nic jiného, než to, že Vám v rámci akce umožňuje získat dispatch instanci, díky které, můžete vyvolat akci i uvnitř asynchronní metody.

To je na Reduxu a Reactu skvělé. Napadlo Vás někdy, že například Facebook umožňuje ukázat návrh bloku, do kterého se vykreslí komentáře, aniž by dané komentáře byly ze serveru již načteny?

Funguje to tak, že například řeknete, že chcete ze serveru stáhnout další položky. Reduceru pošlete informaci o změně a díky tomu se UI komponenta může začít měnit. Nicméně, vedle toho se ptáte serveru a čekáte na skutečnou změnu, která až Vám přijde, tak jí přepíšete v reduxu, pomocí stejného reduceru :)

Fetch

Poslední věcí, o které zde napíší je whatwg-fetch. Jak už jsem minule zmiňoval, tak React neobsahuje knihovnu na volání Vašeho REST (GraphQL) server API. K tomuto účelu můžete využít několik knihoven. Jedna je samozřejmě i přímo v jQuery. Osobně jsem na doporučení zvolil Fetch, což je knihovna doporučována snad všemi.

Fetch se snaží držet standardů a navíc její použití je velmi jednoduché.

V budoucnu se snad dočkáme i toho, že samotný ajax call půjde udělat přímo díky podpoře webových prohlížečů. Firefox a Chrome již dnes totiž podporují možnost window.fetch.

Závěr

Toto byl výčet těch nejdůležitějších technologií a knihoven, které při tvorbě webové aplikace Reactem lze využít. Osobně mám pár dalších technologií, které jsou již dost okrajové a mohou se měnit na základě požadavků na Vaší aplikaci. Tento výčet je ovšem základ, který bych použil vždy, když bych se dostal k vývoji webové aplikace Reactem.

Ještě bych rád zmínil jedno doporučení. Pokud začnete hledat knihovny, které by Vám pomohly při tvorbě aplikace, byl bych obezřetný, abyste svůj projekt příliš nezahltili knihovnami třetích stran, které jsou často tvořeny jednou osobou. Na každý problém totiž v NPM naleznete knihovnu, která by Vám mohla pomoci. Bohužel je problém v tom, že jich je příliš mnoho a některé mají jepičí život. Buďte skutečně opatrní a spíše se koukejte po tom, zda je daná knihovna skutečně využívána a například díky githubu bych si zkontroloval, zda je aktuální a někdo na ní pracuje.

Vývoj webových aplikací: React a Angular 2

Článek je založen na základních zkušenostech Reactu a Angularu 2, ve kterých jsem napsal jednoduchou CRUD aplikaci s reportingem a autorizací. U obou aplikací byl použit stejný backend (Spring REST, JPA repository).

K napsání tohoto příspěvku mě donutila skutečnost, že jsem se v poslední době zaměřil na frontendové technologie a chtěl si vyzkoušet několik cest, které mohou vést k úspěšnému cíli.

V současné době je velmi populární tvorba tzv "single page" webových aplikací, které jsou vykonávány javascriptem na straně klienta.

Doba pokročila a kromě tzv single page aplikací se také objevilo něco, čemu se říká isomorfní aplikace. Tomuto tématu se věnovat nechci, nicméně je to další evoluční krok, který v podstatě říká, že část javascriptové aplikace běží na serveru. Lépe to vystihuje následující článek: What is an isomorphic application?

Ale zpět k single page aplikacím. Proč jsou vlastně tak populární a co mi to přináší z pohledu vývoje?

Tak zejména je to fakt, že webovou část nevnímám jako prezentační vrstvu tvořenou pomocí html, ale fakt, že daná webová stránka je aplikací. Tedy umí pracovat s událostmi a její jednotlivé části jsou měněny bez nutnosti znovunačítat celý kontext či se ptát serveru na změnu. Celá stránka je kontext, ve kterém pracuji a ve kterém provádím i například routování (přechod na jiné stránky, které jsou v podstatě jen změny v blocích).

Nespornou výhodou je to, že vše je zpracováváno na straně klienta, čímž pádem striktně rozděluji aplikaci na backend a frontend. Backend již nemusí nést tolik informací o prezentační vrstvě a soustředí se pouze na svou část.
Na rozdíl od toho je frontend schopný fungovat bez backendu a je velice jednoduché postavit webovou aplikaci bez backendu. Představte si situaci, kdy díky obřímu JSON souboru pošlete do aplikace celý její model a jste schopni ji ukázat zákazníkovi, aniž byste museli napsat čárku v backend systému.

Další nespornou výhodou je to, že většina frameworků, které se pro single page aplikace používají jsou komponentově orientované. Tedy umožňují vytvářet znovupoužitelné komponenty a na konci toho v podstatě jen skládáte aplikaci z Vašich komponent. S tím také souvisí fakt, že máte pod správou i to, jak se dané komponenty generují a jak například pracují v rámci DOMu.
U serverových aplikací jako je Apache Wicket, JSF či ASP.NET máte jen malou kontrolu nad tím, jaké Vaše výsledné komponenty nakonec generují klientský kód. Navíc, pokud budete tímto způsobem tvořit inteligentnější webovou aplikaci, která má reagovat na klientské události a měnit různé komponenty, tak se dostanete do fáze, že se Vám stejně část logiky převede na klienta, ovšem často bez štábní kultury. Nakonec se v aplikaci objeví obří javascriptové skripty, kterým rozumí pouze autor.

Proč React?

Tuhle otázku jsem si pokládal vždy, když jsem zaslechl něco o tom, proč je Angular špatný a proč je React tou pravou volbou. Pojďme si to rozebrat....

V první řadě je třeba říct, že existuje několik frameworků, které se pro single page aplikace používají. Pokud vyřadíme všechny, které hrají spíše druhé housle zůstávají dva kandidáti.

1. Angular 2 (Google)
2. React (Facebook)

Angular 2

Angular 2 se už v mnohém poučil od svého předchůdce a také se dost inspiroval samotným Reactem. Nemám zkušenosti s Angularem 1, ale údajně přináší lepší způsob tvorby komponent a také možnosti, jak tyto komponenty využívat. Současně s tím ovšem stále nese jeden velký problém a tím je závislost na DOMu. Angular 2 používá tzv zones, což v podstatě říká, že když změníte model, tak zones projde celý strom a propaguje danou změnu. Tím ovšem nekončí. Pokud provede změnu, spustí iteraci znovu a zkontroluje znovu ostatní objekty, které by zase mohly reagovat na předešlou změnu. Iterace končí ve chvíli, kdy se žádná další změna nekoná.
Na první pohled se to může zdát jako dobrá volba, nicméně faktem je, že u velkých aplikací dochází k performance problémům.

Další nespornou nevýhodou je také fakt, že Angular 2 ještě stále nevyšel a nese sebou spoustu nedodělků. Jeden příklad za všechny. Dost často narazíte na to, že pokud ve své komponentě máte chybu, tak se jí těžko dozvíte z error message. Angular Vám oznámí obecnou chybu a tím skončí. V budoucnu na tom jistě zapracují, ale v současné době je to skutečně problém.

Dalším negativem je také to, že Angular vytváří Google. Google je velice známý tím, že rád a často zabíjí své produkty a nedělá mu problém přestat podporovat něco, v čem nevidí budoucnost. Stačí se podívat na Angular 1, na kterém je v současné době 0 vývojářů.

Abych nehledal pouze chyby, dá se zde nalézt i spoustu výhod. Tou největší výhodou, oproti Reactu je fakt, že s Angularem 2 dostáváte téměř kompletní stack, který řeší view, eventy, model, http calls, apod. Tedy aplikaci struktualizujete jako template => component => service => model. Tento pattern je podobný backend systémům a pro hodně lidí bude Angular 2 možná i stravitelnější.

Existuje informace, že Angular 2 plánuje integraci JSX z Reactu. O tom, co je JSX se dozvíte níže. Nyní se pojďme podívat na React.

React

Poté, co jsem si vyzkoušel Angular 2 a napsal v něm svou cílovou aplikaci, rozhodl jsem se, že tu samou přepíši Reactem a udělám si porovnání.

V první řadě je nutné říct, že učící křivka je u Reactu velice podobná jako u Angularu. Jednou z nevýhod je fakt, že React nemá tak hezkou a uživatelsky přístupnou dokumentaci jako Angular 2. Osobně jsem měl z učení Angularu 2 lepší pocit, protože jsem vždy přesně věděl, kam se podívat.

Ale pojďme popořadě. React má oproti Angularu 2 jednu ohromnou výhodu, která ho staví do role vítěze (alespoň pro mě). A to je fakt, že není závislý na DOMu. Tedy komponenty, které zde tvoříte nemají s DOMem nic společného a React používá svůj vlastní. Samozřejmě do té doby, než začnete své komponenty svazovat věcmi jako je selector z jQuery apod. Poté se samozřejmě dostáváte do závislosti na DOMu. React komponenta se k DOMu připojuje ve fázi componentDidMount(), nicméně vy spíše využíváte onen virtuální DOM.

Proč je výhodnější virtuální DOM?

Tak za prvé je to fakt, že díky tomu můžete aplikaci renderovat na serveru, protože nejste spojeni s web browserem. A také je to fakt, že v Reactu můžete s klidem psát i mobilní aplikace, kde budete využívat komponenty mobilního SDK. K tomuto účelu slouží React Native.
Další výhodou je to, že virtuální DOM Reactu je mnohonásobně výkonnější než je tomu v případě web browseru. Odpadá tedy nutnost, kterou má Angular 2 a to je zones, tedy nutnost procházet  strom komponent a provádět změny. React to dělá inteligentněji. U větších aplikací to začne být skutečně znát.

React JSX

React pro zápis view používá JSX. Jedná se o extenzi javascript syntaxe, která umožňuje zápis ala html(xml), který je pro lidský mozek čitelnější než zápis pomocí funkcí. Ano, i když to může vypadat divně, tak JSX není xml ale funkce. Vize viz: JSX in Depth.

Věřte mi, že i když na první pohled se může zdát, že se jedná o míchání logiky a view, tak tomu tak není. Důvodem je i fakt, že pro správný návrh aplikace v Reactu stejně budete co nejvíce atomizovat jednotlivé komponenty a tím pádem logiky budou obsahovat jen minimálně.

Redux

Samotný React řeší pouze tvorbu a skládání komponent. Neřeší věci jako je AJAXové volání či service vrstvu. Každa React komponenta obsahuje dva vstupy. Jednak je to props což je model, který definuje rodič a pouze on je vlastníkem, tedy props je immutable (neměnitelný) a state. State je model, který je viditelný a měnitelný pouze v dané komponentě.
Z tohoto pohledu vznikne problém ve chvíli, kdy chcete, aby jedna komponenta reagovala na jinou, která ovšem není rodičem. K tomuto účelu slouží Redux.

Co je Redux?

Zjednodušeně se dá říct, že Redux je storage engine, který udržuje stav, který je měnitelný pomocí tzv Reducers. Reducers jsou jednoduché funkce, které přijímají současný stav a akci. Návratovou hodnotou je opět stav, který se propíše do daného store storage.
Redux udržuje pattern "one way binding". Tedy vy máte pod kontrolou změnu modelu. Více viz: Redux.

Osobně doporučuji Redux využít. Samozřejmě až po tom, co člověk ovládne samotný React.

Redux není přímou součástí Reactu. Tedy Redux můžete využít i například s Angularem 2.

Závěr

Pokud jste na rozcestí a přemýšlíte o tom, kterou cestou se dát, nezapomeňte na React. Psaní komponent v Reactu je zábava a současně také Vás nenutí využívat předem definovaný stack. React za Vás neurčí jak přes http volat API, ani Vám nepředepisuje jak má vypadat model či šlužby. Dělá pouze to, že umožňuje tvořit komponenty, spojovat komponenty a reagovat na události. A věřte, že to dělá zatraceně dobře.

A perlička na závěr. Kolik znáte angular aplikací? Myslím veřejných. V případě Reactu je odpověď jednoduchá: Facebook a Instagram :)

Facebook vs Google - zlo vs zlo

Vždy mě bavilo pozorovat firmy jako je Facebook, Google, Twitter či Amazon. Za poslední dvě dekády se tyto firmy dokázaly dostat na vrchol a ukázat světu, že i při minimálních nákladech lze rozjet miliardový byznys.

V každém desetiletí lze najít firmu, která jako štika propluje kolem zkostnatělých molochů a prodere se na vrchol. Povedlo se to Applu, Microsoftu, Googlu a i Facebooku. Všechny tyto společnosti spojuje to, že jako mladá začínající firma si zvolili novou cestu, kterou do té doby nikdo neprozkoumal. Ať už to byli osobní počítače, operační systém pro všechny či sociální síť. Na začátku vždy vzbuzovali spíše úsměv na tvářích velkých IT gigantů, kteří jejich snahu viděli jako slepou uličku.

V dnešní době snad již nikdo nepochybuje o tom, že v dalším desetiletí se objeví jiná dravá ryba, která se opět prožene kolem velkých žraloků a získá své prvenství. Než k tomu ovšem dojde, budeme si muset vystačit s tím, co zde máme.

I když se dnes dá mluvit o jakési renezanci Microsoftu (díky změně vedení), která je viditelná jak v podobě snahy otevřít .NET či ve snaze začít chápat Windows jako službu, tak spíše se chci zaměřit na další dva velké hráče, které považuji za firmy udávající IT trend.

Facebook a Google

Facebook není jen místo, kde se dá povídat s kamarády. Google není jen internetový vyhledávač. Kdokoli, kdo se kdy více zajímal o IT a o to, co tyto firmy skutečně dělají, tak ví, že jejich snaha dávno převyšuje jejich původní cíl. Facebook, stejně jako Google, mají totiž ambice stát se hlavní entitou internetu a tím v podstatě internet pohltit.

Google k tomuto účelu používá různé služby, které lidem servíruje až pod nos. Díky androidu je to v podstatě ekosystém, ve kterém si lze vytvořit svůj vlastní svět.

Facebook má tuto roli o dost jednodušší. Díky pohlcení lidstva do sociální sítě má k dispozici vlastní univerzum, ve kterém si sám může určovat pravidla.

Temná strana

Každý asi očekává, že zde budu psát o tom, jak jsou tyto firmy nebezpečné z pohledu soukromí. Jistě by to byla pravda, ale jako člověk, který je zaměřen víc technicky si odpustím filozofování o tom, kde je ona míra ztráty soukromí. Osobně si myslím, že tu si každý musí a hlavně stále ještě může (i když už dost pracně), zvolit sám.

Na těchto firmách mi vadí jiná věc.

Temná strana Googlu

Google si za poslední dobu vybudoval dost špatnou pověst, co se týče poskytování nových technologií a služeb. Zvolit si Google jako hlavního technologického vendora je asi to samé jako vsadit na chrtí závody. Mnoho firem by mi jistě dalo za pravdu, když si zvolili Dart, GWT či Angular 1 jako hlavní technologii. Google má totiž tu úžasnou vlastnost, že pro něj není problém "zaříznout" cokoli, co se mu jednoduše nelíbí či nehodí. Stejně jako jejich služby, které mnozí využívali. Buď je Google zruší či změní tak, že se jedná o naprosto jinou věc.

Osobně bych byl více než opatrný v tom, jakou technologii od Googlu použít. A pokud někdo argumentuje: "Ale však za tím stojí velký Google", tak se na to dá odvědit pouze: "No právě proto".

Temná strana Facebooku

Facebook je z pohledu IT o dost mladší firma, která ovšem chytla ještě horší manýry než jaké má Google se svým: "Rušíme službu". Facebook totiž dělá něco mnohem horšího....
Jak jsem již uvedl, Facebook pohltil lidstvo do sociální sítě. Díky tomu získal jednu úžasnou věc a to je "institucionalizace". Všichni jsme díky Facebooku "popsatelní". Tohoto fenoménu začalo využívat mnoho dalších firem, kteří svůj byznys postavili na tom, že mají vše na dlani. Mají možnost získat informaci o tom kdo jste, s kým se přátelíte, co máte rádi, apod.
Jistě si každý dovede představit k čemu se toto dá využít. Cílená reklama, lidské zdroje pro velké společnosti, apod. Aplikací, které využívají Facebook API je dnes snad víc než jakéhokoli jiného softwaru. Jenže to se Facebooku až tolik nelíbilo. Ono by totiž mohlo dojít k tomu, že by někdo mohl získat příliš mnoho informací a vytvořit vlastní službu, která by se teoreticky mohla stát konkurencí pro služby Facebooku. A tak se Mark Zuckerberg, pod trapně výmluvnou větou: "Zlepšujeme bezpečnost", rozhodl, že přestanou poskytovat informace třetím stranám. A to do takové míry, že mnoho společností musí hledat jiný model svého podnikání či úplně skončit. Pokud se někdo domnívá, že lze dnes napsat aplikaci pro Facebook Chat, získat seznam přátel, apod, tak ho musím zklamat. Facebook veškeré toto API zrušil. V případě chatu to vyřešil tak, že ho transformoval do něčeho, co nazývají Messenger, který má vlastní ekosystém a pokud někdo chce využít Messenger, tak už nikoli jako vlastní službu, ale jako službu, která běží uvnitř Messengeru. V případě samotného Facebook API, které poskytovalo mnoho informací pro další služby, tak zde jste omezeni tak, že přestalo dávat smysl psát aplikace využívající jejich API.

Větší zlo

Hledat větší zlo mezi těmito molochy lze asi dost těžko. Nicméně, za mě je to určitě Facebook, protože v případě Googlu má člověk vždy možnost své aplikace dále provozovat či přepsat. V případě Facebooku máte prostě jednoduše smůlu. Facebook má jistě mnohem větší ambice pohltit internet a způsob, kterým se pustili do boje o prvenství je dost barbarské. Pokud chceš využívat Facebook, tak pouze uvnitř jejich světa, nikoli jinde. Doufám, že díky tomuto kroku se dostanou do stavu, kdy vznikne trend opustit tento ostrov a přejít zpět na propojený kontinent. Pokud se ovšem dřív neobjeví nová štika v řece....

Magické slovo REST

V posledních letech jsem se několikrát setkal s tím, že lidé použili toto magické slovo téměř všude, kde se jim to zrovna hodilo. Jenže kolik z nich vlastně ví, co samotný REST znamená a v čem jsou jeho výhody a nevýhody oproti SOAPu?

V první řadě je třeba zmínit, že díky míchání pojmů je dnes dost matoucí se bavit jedním dechem o webových službách, RESTu, SOAPu či WSDL. Takže, jak to vlastně je:

Webová služba je obecný název pro systém na interakci mezi dvěma stroji po síti. Pokud někdo mluví o webové službě, tak tím vůbec nespecifikuje, zda se jedná o SOAP či REST.

SOAP je protokol na výměnu dat pomocí XML. Nejčastější využití je přes HTTP protokol.

WSDL popisuje samotný SOAP. Tedy určuje jak vypadá daná webová SOAP služba.

REST/REST API je architektonický styl, který má jasná pravidla. Nejčastější použití je přes HTTP protokol a jako výměnný formát používá XML, JSON či vlastní formát.

RESTful je označení aplikací, které využívají REST API.

Když jsem se poprvé setkal s pojmem REST, tak jsem nechápal jaké jsou jeho výhody oproti klasickému SOAPu. Díky tomu, že jsem k návrhu aplikací přes REST API přistoupil již před mnoha lety, tak ono zjišťování mám dávno za sebou.

Jak už jsem zmínil, REST je architektonický styl, tedy předem určuje jakou architekturu bude mít mé API. Osobně toto považuji za jeden z největších přínosů tohoto návrhu. Stejně jako v objektově orientovaném programování se používá pojem zapouzdření a programování vůči rozhraní, tak i zde jsem dopředu omezován. Ano správně! Omezován. A to je právě ona výhoda. Není totiž nic horšího, než se prohrabovat cizím API a zjišťovat jakým způsobem autor navrhl klientské volání onoho API.

Uvedu příklad:

Představte si, že máte program, který poskytuje službu pro práci se zaměstnancem. Aplikace je sofistikovaná a nabízí takové věci jako je tvorba nového zaměstnance, editace či mazání. Pokud takovou službu budu volat, tak budu nejspíše hledat názvy jako: Create, Update, Delete. Jenže, co když se autor rozhodl, že půjde jinou cestou? Najednou uvidím metody jako: AddEmployee, Save, Update, DeleteObject, DropEmployee. Asi si každý dokáže představit, co poté nastává. Prohledávání zdrojových kódů, dokumentace, volání na mobil autorovi, apod. Architektura RESTu je předem dána. Takže pokud autor zná alespoň základy dizertační práce pána jménem Roy Fielding, tak ví, jakým způsobem poskytovat jednotlivé služby.

Díky tomu, že je REST nejčastěji využíván společně s HTTP protokolem, tak využívá metody tohoto protokolu k přesně daným účelům:

• GET - získání záznamu
• POST - vytvoření nového záznamu
• PUT - aktualizace záznamu
• DELETE - odstranění záznamu

HTTP protokol obsahuje mnoho dalších metod, nicméně ty nejsou tak často využívány jako výše zmíněné. Existuje ovšem ještě jedna metoda, která je také specifikována a dost často ignorována. Osobně nevím proč, protože její využití spatřuji jako víc než důležitou.

• PATCH - aktualizace záznamu, ale pouze toho, co opravdu chci

Opět uvedu příklad:

Mám složitý objekt, který reprezentuji přes REST API. Při aktualizaci pomocí metody PUT očekávám, že přijdou všechna data a na základě identifikátoru aktualizuji jednotlivé položky. Jenže, co když nechci nutit klienta mého API, aby posílal všechny informace? K tomuto účelu se výborně hodí daná HTTP metoda PATCH.

Další důležitou vlastností RESTu je bezstavovost. Je třeba mít stále na paměti, že každé volání REST API je nový život. Mezi klientem a serverem neexistuje nic takového jako předchozí stav. Existuje spoustu důvodů, proč toto pravidlo porušit, nicméně všechny důvody mají svá řešení a proto bezstavovost API by vždy mělo být něco jako desatero:

• 1. Bezstavovost
• 2. Bezstavovost
• .....

Pokud se Vám podaří zbavit se dinosaura jako je HTTP Session, tak najednou zjistíte jak je svět RESTu úžasný. Volání čehokoli, odkudkoli, kdykoli. Klientské aplikace se zaměří pouze na to co je skutečně důležité a to zpracování Vašich zdrojů. Také škálovatelnost se stane něčím, co nebude nemožný úkol.

Poslední věcí, kterou zde dnes zmíním je verzování.

Každý autor takového API automaticky předpokládá, že jeho systém bude žít věčně a počet konzumentů jeho rozhraní bude vzrůstat. Proto hned od začátku začne počítat s verzováním.

Jak verzovat REST API je popsáno na mnoha místech a v podstatě je tímto i standardizováno. Tedy do URL adresy budu vkládat něco jako /api/v1/zdroj. Ideální varianta. Tedy alespoň na první pohled. Jenže skutečně to vždy potřebujeme? Jak se vypořádáme s verzováním na úrovni samotného kódu? Co zpětná kompatibilita? Otázek, na které nikdo předem nezná odpověď je příliš mnoho. Něco mi mohou pokrýt testy, ale buďme upřímní. Skutečně nás testy spasí od všech problémů? Tak tedy ještě jednou. Opravdu potřebujete své API verzovat? Pokud ano, je třeba mít na paměti několik důležitých pravidel:

• Verzuji vždy celé API, nikdy ne jen jeho část
• Verzování jasně specifikuji buď v URL adrese či pomocí HTTP hlavičky
• Pokud jsem konzumentem svého API pouze já, snažím se verzím spíše vyhnout
• Udržuji zpětnou kompatibilitu jen do té úrovně, do které mi to dovolují zdroje, které pro vývoj mám. Krásně by se mi mohlo totiž stát, že víc času budu trávit řešením zpětných kompatibilit, než se věnovat skutečným problémům.

K verzování se jednou vyjádřil i samotný Roy Fielding. Ve zkratce napsal něco jako: "Verzujte své API pouze pokud je to skutečně nutné. Mnoho lidí totiž zbytečně jde s kanónem na vrabce. A pokud už verzování potřebujete, tak ho fyzicky oddělte. Tedy zdroje budou mít jinou adresu. Je to něco, jako když si představíte, že jste vytvořili nový web na nové adrese."

O RESTu by se dala napsat kniha. Témat, která se kolem tohoto slova točí je skutečně mnoho. V dnešní době se z RESTu stal v podstatě standard pro tvorbu Backend API. Však také vznik věcí jako je AngularJS, ASP.NET MVC, Spring Data REST, apod tomu jen nahrávají.

Příště se pokusím zmínit o tom, co znamená HATEOAS, jak si poradit s autentifikací a autorizací či jaké jsou nevýhody RESTu.

Od Netbeans 6.9 k IntelliJ IDEA 10

Když jsem poprvé začal používat plnohodnotné IDE, nejvíce jsem si zamiloval NetBeans. Důvodem bylo zejména to, že pro začátečníka byl tento nástroj asi nejsnáze pochopitelný. Postupem času si člověk vytvoří určité návyky a jen težko je schopen přejít na jiné prostředí.

NetBeans jsem používal posledních 5 let. Což už je dost dlouhá doba na to, abych věděl co od tohoto nástroje můžu očekávat. Nicméně v poslední době se mi zdá, že více než na práci se vývoj tohoto nástroje soustředí na to, jak vytvořit demo aplikaci. Ta je poté slavnostně prezentována ve formě videotutoriálu na stránkách netbeans.org. Ovšem při práci na větším projektu se často dostávám do potíží se samotnou stabilitou tohoto prostředí. Proto jsem se rozhodl vyzkoušet IntelliJ IDEu, kterou všichni její  uživatelé tak slavně opěvují.

Při prvním spuštění je jasné, že i když oba nástroje použiji na tu stejnou věc (programování Java, PHP), tak přesto jsou dost rozdílné, abych hned věděl kde začít.

Projekty a moduly

První velký zádrhel je mezi porovnání projektů a modulů. v NetBeans vytvořím nový projekt a rovnou můžu pracovat. Onen projekt můžu například zabalit do EAR projektu a přidávat další a další. IDEA na to jde jinak. Projektem je zde spíše něco jako skupina, do které vlkádám dané projekty (ehm, tedy moduly). Modulem je tedy onen projekt a projekt je spíše celé okno IntelliJ IDEy. Trošku zmatek, nicméně se mi podařilo tímto prokousat a pochopit logiku tohoto nástroje. :)

PHP Projekt (nebo modul?)

Projekty a moduly pro Javu jsem vcelku pochopil. Horší je to ovšem s PHP. IntelliJ IDEA má slušnou podporu PHP a proto jsem chtěl vyzkoušet i tu. Problém ovšem je, že neexistuje nabídka jak vytvořit čistě PHP modul. Jediný způsob je vytvořit "projekt ze zdroje" a poté do něj java modul bez vytvoření src adresáře. Tento způsob je přímo popisovaný i v nápovědě tohoto nástroje. Asi nemá příliš cenu komentovat, proč tento způsob vývojáři trošku neupraví. Nicméně, chceš-li pracovat s PHP, vytvoř Java Modul :)

Přenos projektu z NetBeans do IntelliJ IDEy

Po menším prozkoumání tohoto nástroje jsem hledal způsob, jak rozumně převést projekt z NetBeans do IDEy. Jelikož jsem v NetBeans projekt sestavoval pomocí Antu (ano, vím, že už to není moderní :)) nenašel jsem jednoduchý způsob, jak projekt převést. Nezbývalo tedy nic jiného, než použít Maven. Po dvoudenním trápení se mi podařilo sestavovat celý projekt pomocí Mavenu. Kromě toho, že jsem toto měl provést již dávno, tak přenos projektu byl více než snadný. Nyní stačilo otevřít IntelliJ IDEu a pouze projekt "otevřít". Vše začalo fungovat bez problémů.

Nevýhody IDEy

Nemá smysl psát o výhodách tohoto nástroje. Je totiž vážně slušně propracován a navíc splňuje téměř vše, co ke své práci potřebuji. Ovšem i přesto existují určité věci, které stále nejsem schopen překousnout a nutí mě přemýšlet, zda mám tento nástroj skutečně koupit a začít používat.

Logování Glassfish

Při deploy (debugování) aplikace na Glassfish je problém s tím, že nefunguje zobrazování logování v okně. Toto bylo u NetBeans skutečně na mnohem lepší úrovni. Nakonec jsem zjistil, že i když je v nastavení tohoto aplikačního serveru nastavena log console, musím přidat vlastní. Poté základní logování funguje. Ovšem pouze do doby, než se provede "rotate" log, tedy provede se záloha log souboru a vytvoří se nový glassfish log soubor. IDEA ovšem není schopná pokračovat ve výpisu tohoto logu z čistého souboru.

Podpora Mavenu

NetBeans má podporu Mavenu na lepší úrovni. U knihoven je přímo vidět zda se jedná o závislost na jiné, v jaké je "scope", atd. Toto jsem u IDEy opět nenašel v rozumné formě.

Závěrem

Je zde spousta dalších drobností, které potřebuji vyřešit, ale ty považuji spíše za "porodní bolesti" (jako například rozumné formátování kódu, jelikož přes Ctrl+Alt+L se mi formátování provede jen "někdy"). Nicméně dost reálně uvažuji o koupi tohoto IDE. Přeci jen, cena za nástroj, který používám více jak 8 hodin denně je zanedbatelná vůči produktivitě, kterou mi může přinést.

Apache Wicket - verze 1.4

Apache Wicket zdárně dospěl do verze 1.4, která sebou přináší změny zejména na úrovni podpory generických typů. Tato verze je tedy určena pro javu 1.5 či vyšší.

Po zdravé úvaze jsem se rozhodl přejít na tuto verzi a provést úpravy na stávajícím projektu, který byl psán pro verzi 1.3.x.

Hlavní rozdíly oproti starší verzi

Jak jsem již zmínil, hlavní změnou je podpora generických typů. Bohužel došlo i na změnu v API. Metoda "getModel()" či "getModelObject()" byla nahrazena "getDefaultModel...". Směle jsem se tedy pustil do přeměny pomocí hromadného přepisu (cca 50 výskytů). Naštěstí byla tato změna dostatečná a aplikace je plně kompatibilní s verzí 1.4.

Využitelnost generik

Na jedné straně jsem jásal, že je konečne wicket více typově kontrolovatelný a nemusí docházet k ruzným přetypováním. Na druhou stranu je ovšem dobré poznamenat, že jsou pasáže (viz např. DropDownChoice), které jsou dost neštastně navrženy pro využití generických typů. Problém spočívá zejména v tom, že musím napsat tunu kódu navíc, která nepřináší až tak závratné změny.

Po zhruba měsíční migraci jsem omezil použití generických typů jen na místa, kde to skutečně má smysl (viz např. IModel).

Komponenty třetích stran

To, že je ve Wicketu tvorba znovupoužitelných komponent, hračka, je nepopíratelný fakt. Komponenty třetích stran se tedy spíše soustředí na složitejší věci. Bohužel, v současné době jsem nabyl dojmu, že je vývoj dost chaoticky či vůbec neřízen. Použít některou přídavnou vlastnost z WicketStuff je sázka do loterie. Pokud bych toto porovnal s JSF, je na tom Wicket naprosto žalostně.

Osobně využívám následující přídavné vlastnosti:

• wicket contrib javaee 1.1 - podpora pro injectování EJB komponent


• swarm 1.4, wasp 1.4 - pro podporu security management


• grid - jedná se o "rich" tabulky; kdysi byl projekt vystaven na inmethod.com, poté byl zrušen; pohužel jsem musel udělat vlastní úpravy, aby daná komponenta byla vůbec funkční

Zbylé "projekty" jsem po zběžném otestování raději zahodil. Mrzí mě, že například podpora pro jQuery je dost nestabilní a její použití je dost invazivní (viz. nutnost použít pro Application daného předka, což znemožňuje využít zase například Swarm).

Pokud má někdo zkušenosti z dalšími přídavnými vlastnostmi pro Wicket, nechť se o ně podělí v diskuzi.

I přes zmíněné zápory, které jsem zde popsal, je pro mne Wicket tou nejlepší volbou pro tvorbu web aplikací. Je prostě radost s ním pracovat! :)