Schéma znázorňující architekturu a návrh webových aplikací RIA:
Jak je vidět, logika grafického uživatelského rozhraní (GUI) je přesunuta z webového serveru do prohlížeče. Toto úplné oddělení od logiky serveru má samozřejmě své pozitivní, ale také negativní důsledky pro návrh a architekturu aplikace.
1. Nespornou výhodou je, že GUI mohou být díky technologiím RIA mnohem pokročilejší.
2. V prohlížeči je spuštěna logika GUI což šetří procesorový čas na straně serveru.
3. Stav GUI může být uložen přímo v prohlížeči, čímž se uvolní místo na straně serveru.
4. Oddělení logiky GUI od aplikační logiky umožňuje vyvinout opakovaně použitelné komponenty, které mohou být znovu použity bez ohledu na to, jaký programovací jazyk se používá na straně serveru pro aplikační logiku.
5. Technologie RIA obvykle komunikují s webovým serverem výměnou dat, nikoliv GUI kódu (HTML, CSS a JavaScript). Výměna dat je obvykle prováděna přes HTTP, odesíláním dat ve formátech JSON nebo XML. To vede ke změně strany serveru z "generování stránek" na "poskytování služeb", které provádějí určitou část logiky aplikace (přihlášení, odeslání dat, ukládání úkolů atp.). Když se na straně serveru zbavíme logiky vykreslování GUI, logika aplikace je velmi snadno čitelná a jasná. Strana aplikační logiky (server) pouze přijímá a odesílá data, nemusí se tak starat o nic jiného. Žádné GUI stavy, žádné generování GUI apod. Jedná se o nespornou výhodu při vývoji aplikací.
6. GUI a aplikační logika na serveru obvykle komunikují přes HTTP + JSON nebo HTTP + XML, grafické uživatelské rozhraní je 100% nezávislé na tom, jaký programovací jazyk se používá na serveru. Rozhraní GUI logiky k serveru je pouze volání HTTP. To znamená, že můžete změnit programovací jazyk a nástroje na klientu nezávisle na serveru, stejně jako změnit serverové nástroje bez ovlivnění klienta.
7. Logika GUI a aplikační logika mohou být nezávisle na sobě také vyvíjeny. Vývojář logiky aplikací může implementovat služby a testovat je nezávisle na vývojáři GUI. Stejně tak může vývojář grafického rozhraní vytvořit jen "falešnou" službu, která vrací jemu potřebná data k tomu, aby mohl vyvíjet a testovat grafické uživatelské rozhraní. Jakmile je skutečná služba připravena, může být projekt z vývoje nasazen do ostrého provozu velmi rychle.
8. Protože se strana serveru skládá pouze ze služeb, které odesílají a přijímají data, je mnohem jednodušší přidat jiný typ klienta. Můžete například přidat nativní mobilní iOS nebo klienta aplikace pro Android, který bude také spolupracovat se službami na straně serveru.
9. Server je tvořen pouze jednoduchými službami, které přijímají a odesílají data, je webová aplikace přirozeně připravena pro trend "otevřené aplikace", kde je možné přistupovat k webovým aplikacím jak prostřednictvím GUI, tak prostřednictvím rozhraní API.
10. Služby GUI a server si pouze vyměňují data, zatížení provozu je často menší, než kdyby musel server odesílat jak data, tak veškerý GUI kód (HTML, CSS a JavaScript). Požadavky na šířku pásma mohou tedy klesat. Je ovšem nutné dát si pozor na případ, kdy bude server odesílat velké množství malých datových bloků. To by naopak mohlo mít za následek citelné zpomalení aplikace.
Jak můžete vidět, co "naoko" vypadá jako malá změna v tom, jak vyvíjíme webové aplikace, má skutečně spoustu přínosných vedlejších účinků. Jakmile použijete tyto výhody v reálném projektu, nikdy se nebudete chtít vrátit zpět k webovým aplikacím druhé generace.
Podrobnější schéma architektury RIA:
Kompletní oddělení logiky GUI od aplikační logiky v praxi často znamená, že logika GUI je implementována jiným programovacím jazykem než logika aplikační. Technologie RIA znamenají, že vývojářský tým musí zvládnout více technologií najednou, což může být samozřejmě chápáno jako jistá nevýhoda.
RIA Technologies
Na závěr seznam nejčastěji používaných technologií v RIA aplikacích:
- HTML5 + CSS3 + JavaScript + JavaScript frameworky
- jQuery
- jQuery Mobile
- AngularJS
- Sencha EXT-JS
- SmartClient
- D3
- Dart
- GWT (Google Web Toolkit)
- JavaFX
- Flex (Flash)