Co je webová aplikace a čím se liší od webu

Řešíte, jestli vám stačí obyčejný web, nebo potřebujete něco, do čeho se dá přihlásit a s čím lidé opravdu pracují? Ten rozdíl rozhoduje o rozpočtu, o termínu i o tom, koho si na projekt najmete. Pojďme si to ujasnit bez zbytečných termínů, ať víte, do čeho jdete.

Web ukazuje, aplikace pracuje

Klasický web je vizitka. Ukáže, co nabízíte, kde vás najdou a proč vám mají zavolat. Návštěvník si přečte obsah a odejde. Webová aplikace naopak něco umí — přihlásíte se, zadáváte data, systém počítá, ukládá a reaguje na to, co právě děláte. Rozdíl je zhruba jako mezi vývěskou a pokladnou.

• Web: prezentace firmy, blog, kontaktní formulář.
• Aplikace: rezervace, objednávky, klientská zóna, interní evidence.
• Hranice je tenká — e-shop je vlastně aplikace, i když mu tak neříkáme.

V praxi to poznáte podle jediné otázky: musí si web něco pamatovat o konkrétním člověku a podle toho se chovat? Pokud ano, bavíme se o aplikaci. Prostý web ukazuje všem totéž, kdežto aplikace se přizpůsobuje tomu, kdo je přihlášený a co už udělal. A právě z téhle jedné vlastnosti plyne skoro všechno ostatní — vyšší cena, delší termín i nutnost aplikaci dál udržovat.

Co běží pod povrchem

U aplikace se do hry dostává víc pohyblivých částí. To, co vidíte v prohlížeči, se odborně nazývá frontend — barvy, tlačítka, formuláře. Logika, která zpracovává data a hlídá pravidla, běží na serveru a říká se jí backend. A všechno, co si aplikace pamatuje, leží v databázi. Právě tahle vrstva odlišuje aplikaci od statického webu a tvoří větší část práce.

• Uživatelské účty a různá oprávnění pro různé role.
• Automatické e-maily, potvrzení a notifikace.
• Napojení na další systémy přes rozhraní, které pracuje na pozadí.

Zjednodušeně si to představte jako restauraci. Frontend je jídelna, kam přijde host — hezky prostřeno, jídelní lístek, obsluha. Backend je kuchyně, kde se doopravdy vaří a kam host nevidí. A databáze je spíž, ze které se bere a do které se ukládá. Host vidí jen jídelnu, ale bez kuchyně a spíže by si nic neobjednal.

Na čem aplikace stavím

Nástroje nejsou to hlavní, ale klienti se často ptají, na čem jejich systém poběží — a je fér mít v tom jasno. Backend píšu ve frameworku Laravel, který stojí na jazyce PHP. Data ukládám do databáze MySQL a administraci, ve které klient obsluhuje obsah, stavím nad nástrojem Filament. Kde je potřeba, aby stránka reagovala okamžitě bez přenačtení, sáhnu po Livewire. Nejde o módu — jsou to prověřené technologie, ke kterým seženete i jiného programátora, kdybych vám jednou přestal vyhovovat. Tím se vyhnete situaci, kdy vás dodavatel drží jako rukojmí kvůli vlastnímu uzavřenému systému.

Tři příklady z praxe

Aby to nebyla jen teorie, ukážu tři typické projekty, které jsem stavěl, a čím se liší od běžného webu.

• Rezervační systém. Zákazník vidí volné termíny, vybere si a rezervaci potvrdí. Aplikace hlídá, aby se dva lidé nesešli na jednu hodinu, a sama pošle připomínku. Statický web tohle nezvládne — neumí si pamatovat, který termín je obsazený.
• Klientská zóna. Po přihlášení každý zákazník vidí své faktury, dokumenty nebo stav zakázky. Obsah se liší člověk od člověka, což je přesně to, co obyčejný web neumí.
• Interní evidence. Firma přestane přepisovat data z papíru do tabulek a má je na jednom místě, dohledatelná a jištěná proti přepsání.

Ve všech třech případech je vidět stejný vzorec: data se zadávají, ukládají a systém s nimi dál pracuje. To je jádro každé aplikace. Jakmile tenhle vzorec ve svém nápadu poznáte, přestanete se ptát „web, nebo aplikace?" a začnete řešit tu správnější otázku — co přesně má systém umět.

Kdy do aplikace jít a kdy ne

Aplikace dává smysl, když opakovaně řešíte tutéž činnost ručně — přepisujete rezervace z papíru, hlídáte objednávky v tabulce, posíláte pořád stejné e-maily. Software to udělá za vás, rychleji a bez překlepů. Buďme ale upřímní: když potřebujete jen slušně vypadající prezentaci, aplikaci nekupujte. Přeplatíte pořízení a budete zbytečně platit i za údržbu něčeho, co nevyužijete. Sám v takové situaci klientovi radím levnější cestu, i když bych na aplikaci vydělal víc — protože nespokojený zákazník, který platí za nevyužitý systém, se nevrátí.

Rozhodování si můžete usnadnit několika otázkami. Čím víckrát odpovíte „ano", tím spíš míříte k aplikaci:

• Potřebují se lidé na web přihlašovat?
• Dělá web něco automaticky, i když u toho nikdo nesedí?
• Ukládají se data, se kterými pak dál pracujete?
• Přepisujete dnes tutéž věc ručně na několika místech?
• Má se web chovat jinak pro různé lidi?

Co si připravit před zadáním

Nejlepší nabídku i termín dostanete tehdy, když přijdete s jasnou představou. Nemusíte umět nic technického — stačí popsat, jak věci fungují dnes a co vás na tom zdržuje. Než mi napíšete, projděte si tenhle krátký seznam:

• Sepište, jaký problém má aplikace vyřešit, jednou větou bez techniky.
• Vypište kroky, které dnes děláte ručně, hezky za sebou.
• Zamyslete se, kdo bude systém používat a jaké role budou potřeba.
• Poznamenejte si, s čím se má aplikace propojit — účetnictví, e-mail, platby.
• Rozdělte funkce na „bez toho to nespustím" a „hezké mít později".

Tenhle půlden příprav vám ušetří desítky tisíc. Čím jasnější zadání, tím míň se během vývoje předělává, a předělávky jsou to nejdražší, co na projektu je.

Co to znamená pro rozpočet

Cena aplikace roste hlavně s počtem funkcí, ne s počtem stránek. Zatímco běžnou prezentaci naceníte skoro na pevnou částku, u aplikace platíte za logiku, testování a napojení na další systémy. Proto se vyplatí začít menší verzí, ověřit ji v reálném provozu a teprve pak přidávat další funkce podle toho, co se osvědčí. Ušetříte tím peníze i čas a vyhnete se placení za nápady, které nakonec nikdo nevyužije.

• Začněte tím, co vám ušetří nejvíc času.
• Rozšiřujte po ověřených krocích, ne všechno naráz.
• Počítejte s provozem a údržbou, ne jen s pořízením.

S rozpočtem souvisí i to, že aplikace není nikdy úplně „hotová". Web-vizitku spustíte a roky se k ní nemusíte vracet. Aplikace naopak žije — přibývají uživatelé, mění se požadavky, něco je potřeba doladit. To není chyba, ale přirozená vlastnost živého systému, se kterou je dobré počítat od začátku.

Kolik času stavba zabere

Termín se u aplikace odhaduje hůř než u vizitky, právě proto, že se platí za logiku, ne za stránky. Jednoduchou klientskou zónu zvládnu v řádu týdnů, propracovaný systém s napojením na platby a sklad je otázka měsíců. Nejrychleji jsem hotový tam, kde má klient jasno v tom, co má web umět, a kde postupuju po částech — nejdřív spustím jádro, které přináší hodnotu, a zbytek dodělávám za provozu. Snaha mít napoprvé úplně všechno je nejčastější důvod, proč se termíny protahují.

Údržba a bezpečnost, na kterou se zapomíná

U aplikace, do které se lidé přihlašují a která uchovává data, není bezpečnost něco navíc — je součástí zadání. Jakmile začnete zpracovávat objednávky nebo osobní údaje, stáváte se zajímavým cílem a zanedbaný systém se nabourá snáz, než čekáte. Většina rizik se přitom pokryje pár disciplinovanými návyky, ne drahými nástroji.

• Pravidelně aktualizovat framework i knihovny, ať se opravují známé díry.
• Zálohovat databázi tak, aby se dala obnovit i po chybě obsluhy.
• Hlídat, kdo má jaká oprávnění, a odebírat přístupy, které už nikdo nepotřebuje.

Domluvte si proto předem, kdo se o systém po spuštění stará. Menší pravidelný náklad na údržbu vás ochrání před velkým a drahým výpadkem v tu nejméně vhodnou chvíli.

Časté chyby, kterých se vyvarovat

Když firma poprvé zadává aplikaci, vídám pořád stejná zaškobrtnutí. Většině se dá předejít, když o nich víte dopředu.

• Chtít všechno hned. Nejdražší je aplikace, do které nacpete padesát funkcí a půlku z nich pak nikdo nepoužije. Začněte tím podstatným.
• Podcenit zadání. Nejasně popsaná funkce se předělává třikrát. Čas strávený nad tím, co má web umět, se vždycky vrátí.
• Zapomenout na provoz. Aplikace potřebuje údržbu, zálohy a někoho, kdo řeší výpadky. Kdo počítá jen s pořízením, později se diví.
• Plést si web s aplikací u ceny. Očekávat cenu vizitky za systém, který zpracovává objednávky, vede jen ke zklamání na obou stranách.

Jak spolu části mluví

Často stavím aplikace tak, že se dvě části propojují přes API — třeba web s rezervačním systémem nebo s účetnictvím. Díky tomu spolu systémy mluví a data se nemusí přepisovat ručně. Jak vypadá takový projekt v praxi ukazuju v článku o rezervačních systémech.

Nevíte, do které kategorie váš nápad patří? Napište mi — v krátkém hovoru vám férově řeknu, jestli stačí web za pár tisíc, nebo se vyplatí aplikace. Nezávaznou poptávku pošlete přes kontaktní stránku.