pátek 30. prosince 2016

NoSQL - Život nepodléhá třetí normální formě

BigData, NoSQL...

Asi každý se již setkal s těmito názvy, které jsou často spojovány se jmény jako je Google, Facebook či Amazon.

Co to vlastně znamená?

Díky rozmachu internetu na běžnou část populace, začalo docházet k exponenciálnímu nárůstu dat, které je třeba uchovávat a zároveň v nich "dolovat". Klasické relační databáze, které díky ACID udržují validní stav dat, se staly nevhodnou variantou. Ano, ani MS SQL a ani Oracle není vhodná databáze na Big Data.

Existuje mnoho důvodů, proč relační databáze není ideální variantou pro větší systémy. Zde je pár příkladů:

1. Vertikální škálování - tedy databázový stroj se nedá donekonečna výkonostně nafukovat
2. Pevná struktura - předem definovaná struktura dat, není pro vetší a rychle se měnící systémy, žádoucí
3. Migrace - Pro změnu struktury je často třeba sofistikovaná migrace přes SQL
4. SQL - dotazování pomocí tohoto jazyku je sice jednoduché, ale zároveň dost omezující

 Co tedy znamená NoSQL?

V první řadě by bylo vhodné říct, že označení NoSQL není zrovna vhodný název. Do této rodiny totiž dnes spadá několik typů databází. Pojďme si je v rychlosti projít:

Objektová databáze
První takzvanou NoSQL databází byla objektová. Šlo o to, že v době dominance objektově orientovaných jazyků (ještě stále to platí, nicméne funkcionální přístup ukazuje lepší koncept), se došlo do bodu, kdy mapování tabulek z relační databáze na objekty může být náročné. Vzniklo mnoho ORM knihoven, napříč všemi objektově orientovanými jazyky (C# - Entity Framework, Java - JPA, apod).  Proto vznikl koncept objektové databáze, která se snažila odbourat dané mapování a zvýšit tak výkon. Bohužel nikdy nedošlo k většímu rozmachu těchto databází a dnes se dá v podstatě říci, že se jedná o upadající koncept.

XML databáze
Označení není asi úplně správné, ale koresponduje přesně s tím, co takový typ databáze dělá. Jedná se o to, že data jsou ukládána v podobě XML dokumentů a jejich schématem je v podstatě XSD. Tento typ databází je vhodný zejména v případě složitých struktur jednotlivých dokumentů. Jistě bude stále existovat segment, kde tento druh databází bude využíván.

Key-Value databáze
Toto označení se vztahuje na databáze, které ukladají svá data do jakési hash mapy. Tedy klíč reprezentuje metadata a hodnota je reálná uložená hodnota. Tyto mapy jsou ukládány v blocích, které je unifikováno vlastním klíčem, který je použit pro přístup k daným datům.
První koncept přinesl Google, který dal světu Hadoop. Ten byl poté uvolněn pod Apache a stal se open source projektem. Pro dotazování se využívá přístup Map-Reduce.

Dokumentová databáze
Tento typ databáze vychází z principu key-value, kdy value reprezentuje dokument, což je struktura, nejčastěji reprezentovaná pomocí JSON formátu. Jednotlivé dokumenty mají svůj klíč v rámci celé kolekce a umožňují vazby na další dokumenty. Nejpopulárnější databází tohoto formátu je MongoDB.

Sloupcová databáze
Vychází z principu NoSQL databází s tím, že se nejvíce podobá relačním databázím. Data jsou reprezentována v tabulce se sloupci. Narozdíl od relační databáze je ovšem možné aby jednotlivé řádky obsahovaly jiné sloupce. Tedy nejedná se o pevnou strukturu v rámci celé tabulky.

Grafová databáze
Tento typ databáze je asi nesložitější a zároveň nejnovějším návrhem. Jedná se o to, že jednotlivá data mohou být propojována na další data pomocí vlastních vazeb. V té chvíli vznikají vazby jako: "uživatel vlastní", "role spadá do", apod. Grafová databáze umožňuje navrhnout strukturu tak, aby skutečně kopírovala reálný svět.

Správný výběr
V rámci projektu, na kterém v současné době pracuji, jsem hledal úložiště, které by mi splňovalo několik kritérií:


  1. Úložiště musí mít horizontální škálování. Tedy bude možné přidáváním dalších virtuálních strojů, zvyšovat výkon.
  2. Dostupnost je nejdůležitější vlastnost. Prominu úložišti dočasnou "zastaralost" dat, ale určitě ne výkyv v dostupnosti.
  3. Bude docházet k častým změnám v modelu aplikace. Rád bych tedy úložiště, ve kterém nebudu muset dělat složité migrace.
  4. Rád bych, aby databáze uměla zpracovávat JSON a to přirozenou formou. Nechci nic slyšet o formátech jako XML, apod. Nežijeme v pravěku.
  5. Jelikož server API je GraphQL, tak bych rád databázi, pro kterou bude tento způsob přirozený.
  6. Musí existovat možnost, jak se na databázi napojit přes Node.JS
Po sepsání základních požadavků, jsem se pustil do výběru hledání. Finále je vcelku jasné. MongoDB. I přes některá svá úskalí je to nejlepší varianta, která se dá zvolit. Splňuje základních 6 bodů, které jsem si dal.

Co MongoDB neumí?
Určitě se nedá říct, že tento typ databáze je spásou na vše. Tak například: "Těžko budete zařizovat bulk operace, jako hromadný insert. Dvoufázový commit sice MongoDB má, ale v tomto stavu se rapidně začně snižovat i výkon. Relace mezi daty si musíte hlídat v aplikaci."
Věcí, které při přechodu z klasických SQL databází člověk musí oželet, je více. Buď se s tím smíříte a nebo se vrátíte :)

Závěr
Většině databázistům jistě budou vadit dané nevýhody, které sebou tento princip přináší. Nicméně, kdo kdy navrhnul strukturu v relační databázi tak, aby mohl říci: "Jsem schopen obhospodařit jakýkoli požadavek na má data."? Odpověď je nikdo. A důvodem budiž třeba to, že život nepodléhá třetí normální formě.

Uvedu příklad, který jsem si vypůjčil z knihy "Big Data a NoSQL databáze":
Představte si situaci, že vlastníte stackoverflow.com, kde uživatelé pokládají otázky. V klasické relační databázi byste nejspíše měli tabulky jako otázka, uživatel. Uživatel by například obsahoval sloupec město, což by byla jeho aktuální adresa, kde bydlí. Samozřejmě by se uživatel mohl přestěhovat a tím by se změnilo i jeho bydliště. Vazba mezi uživatelem a otázkou by byla 1:N. Tady je zatím vše v pořádku, do doby, než dojde k požadavku, abyste zjistili, ze kterého města bylo pokládáno nejvíce otázek. V té chvíli by samotný návrh nebyl schopen obhospodařit tento požadavek. Sice jsme strukturu navrhli správně, nicménéně jsme si neuvědomili, že svět se nechová podle normálních forem. Asi by nám nezbylo nic jiného, než u změny bydliště si v čase uchovávat i změnu. Pak by nejspíše existovala tabulka bydliště, která by v podstatě musela udžovat změnu v čase.

Líbí se mi tento příklad. Ukazuje přesně to, že dopředu nikdy nemůžeme vědět, jaký bude požadavek na naše data. V dokumentové databázi se často data ukládají tak, že vazby jsou sice možné, ale nejsou hlavním stavebním kamenem. Jinak řečeno, v kolekci otázka by se uložila sice reference na uživatele, ale současně s tím i aktuální stav uživatele, tedy jeho jméno, adresa, apod. Ano porušili jsme sice normální formu, ale zároveň jsme umožnili vetší flexibilitu ohledně dolování dat. Navíc jsme se víc přiblížili realitě, tedy tomu, že v daném čase se uživatelka ještě nevdala a nezměnila příjmení a Franta ještě nebydlel v Praze, ale v Brně :)

pondělí 29. srpna 2016

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.

středa 10. srpna 2016

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 :)