Když se instituce rozhodne vytvořit mobilní aplikaci, první otázka se jen zřídka týká samotné aplikace. Jde spíše o to, odkud bude pocházet obsah. Katalogy kurzů, oznámení, profily akademických pracovníků, seznamy akcí, novinky — tento obsah už žije v systému pro správu obsahu a aplikace potřebuje spolehlivý způsob, jak se k němu dostat. Přesně zde přichází na řadu přístup API-first pro Drupal: místo toho, aby byla mobilní aplikace pojímána jako samostatný projekt s vlastním úložištěm obsahu, se Drupal stává jediným backendem, který obsluhuje web, aplikaci i jakýkoli budoucí kanál prostřednictvím jedné konzistentní sady API.
Tento článek vysvětluje, jak vybudovat mobilní aplikaci nad Drupalem pomocí architektury API-first. Vyjasníme rozdíl mezi „API-first" a „headless", podíváme se na to, proč se tento model tak dobře hodí pro mobilní zařízení, projdeme si API a autentizační vrstvy, pokryjeme mobilně specifické otázky, které většina průvodců vynechává, a nastíníme jasný rámec pro rozhodování, jak daleko s decouplingem zajít.
API-first vs. headless: vyjasnění zmatku
Tyto dva pojmy se často používají zaměnitelně, popisují však odlišné věci, a pochopení tohoto rozdílu formuje způsob, jakým projekt plánujete.
Headless popisuje architekturu: front-end (to, co vidí uživatel) je oddělen od back-endu (kde žije obsah), a oba spolu komunikují přes API. V headless konfiguraci Drupal přestává sám vykreslovat stránky a místo toho předává surový obsah samostatné front-endové aplikaci.
API-first popisuje designovou filozofii: obsah je od samého počátku modelován a zpřístupňován jako API, takže je připraven napájet libovolný počet kanálů najednou — web, aplikaci pro iOS, aplikaci pro Android, chytré hodinky, kiosek, hlasového asistenta. Headless se týká oddělení jednoho front-endu; API-first se týká připravenosti na všechny. Mobilní aplikace je často spouštěčem přechodu k API-first, ale skutečným přínosem je, že stejný backend dokáže obsloužit každý kanál, který instituce později přidá, aniž by se pokaždé musela znovu budovat obsahová vrstva.
Drupal se dobře hodí pro oba přístupy, protože jeho API schopnosti jsou součástí jádra, nikoli doplňkem. Od Drupalu 8, a dále vyzrálé v Drupalu 9, 10 a 11, platforma přichází s vrstvou webových služeb, která bez vlastního kódu proměňuje strukturovaný obsah v API odpovědi. To je základ, na kterém staví vše ostatní v tomto článku.
Proč je API-first správným základem pro mobilní aplikaci
Volba API-first Drupal backendu pro mobilní aplikaci přináší výhody, které se projevují po celou dobu životnosti projektu, nejen při spuštění.
- Jeden zdroj obsahu, mnoho kanálů: stejné oznámení, kurz nebo profil se v Drupalu zadá jednou a doručí se současně na web, do mobilní aplikace i na jakýkoli jiný kanál. Redaktoři nemusí obsah udržovat dvakrát a aplikace se nikdy nedostane mimo synchronizaci s webem.
- Strukturovaný obsah, připravený pro jakékoli rozhraní: protože Drupal ukládá obsah jako strukturovaná data, nikoli jako vykreslené stránky, tento obsah se čistě promítá do mobilního rozhraní. Kurz není blok HTML — je to sada polí (název, kredity, vyučující, rozvrh), které si aplikace může uspořádat podle potřeby.
- Nezávislý vývoj front-endu a back-endu: tým aplikace může vydat novou verzi, aniž by se dotkl backendu, a obsahový tým může backend restrukturalizovat, aniž by aplikaci poškodil, pokud zůstane zachována API smlouva. Aktualizace na jedné straně si nevynucují přestavbu na straně druhé.
- Investice odolná vůči budoucnosti: když se objeví další kanál — nová aplikace, systém obrazovek na kampusu, integrace s jinou platformou — obsah je již zpřístupněný a čeká. Instituce staví nový front-end, nikoli nový backend.
- Podnikové řízení obsahu v pozadí aplikace: aplikace dědí redakční workflow Drupalu, detailní oprávnění, vícejazyčnou podporu a správu médií — schopnosti, které by účelově vytvořený mobilní backend musel vymýšlet znovu od nuly.
API vrstva: JSON:API, REST a GraphQL
Drupal může zpřístupňovat obsah prostřednictvím tří hlavních specifikací. Nejsou to ani tak konkurenti, jako spíše odlišné nástroje, a správná volba závisí na potřebách aplikace.
| Specifikace | Co to je | Nejlépe se hodí pro |
|---|---|---|
| JSON:API | Standardizovaná specifikace, v jádru Drupalu aktivní bez jakékoli konfigurace. Automaticky zpřístupňuje každou obsahovou entitu jako přehledně strukturovaný endpoint. | Výchozí volba pro většinu mobilních aplikací — konzistentní, předvídatelná, bez nutnosti nastavení. |
| REST (RESTful Web Services) | Klasický přístup, rovněž součást jádra. Endpointy se konfigurují podle jednotlivých zdrojů s větší mírou ruční kontroly. | Jednoduché integrace nebo situace, kdy je potřeba konkrétní vlastní podoba endpointu. |
| GraphQL | Dotazovací jazyk (prostřednictvím contributed modulu), který klientovi umožňuje v jediném volání vyžádat přesně ta pole, která potřebuje. | Komplexní aplikace, které potřebují minimalizovat počet požadavků a získávat přesné datové sady. |
Pro většinu mobilních projektů je JSON:API přirozeným výchozím bodem. Je součástí jádra, k zapnutí nevyžaduje žádnou konfiguraci a řídí se přísnou specifikací, což znamená, že mobilní vývojář přesně ví, jak budou odpovědi vypadat. Jeho struktura navíc předvídatelným způsobem řeší vztahy mezi obsahem — kurz a jeho vyučující, akce a její místo konání —, což je v institucionálních aplikacích častá potřeba. GraphQL se stává atraktivním, když obrazovka aplikace potřebuje najednou natáhnout mnoho různých kusů dat a chcete se vyhnout vícenásobným cestám tam a zpět; kompromisem je dodatečné nastavení a složitost. Obecným pravidlem je začít s JSON:API a přejít na GraphQL pouze tehdy, když to ospravedlní konkrétní požadavek na výkon.
Autentizace: proč se mobilní aplikace nemohou spoléhat na cookies
Autentizace je první skutečnou technickou překážkou při decoupled mobilním vývoji a mnoho týmů jí bývá zaskočeno. Tradiční web na Drupalu autentizuje uživatele pomocí relačních cookies spravovaných prohlížečem. Nativní mobilní aplikace nemá žádný prohlížeč ani úložiště cookies, takže tento mechanismus jednoduše neplatí. Aplikace se musí autentizovat jiným způsobem.
Standardním řešením je autentizace založená na tokenech. Uživatel jednou zadá své přihlašovací údaje; aplikace je odešle Drupalu; Drupal je ověří a vrátí token; a aplikace tento token uloží a připojuje jej ke každému dalšímu požadavku. Dominují dva přístupy:
- OAuth 2.0 (modul Simple OAuth): doporučený přístup pro většinu decoupled aplikací. Vydává přístupové a obnovovací tokeny, podporuje moderní postupy včetně PKCE pro veřejné klienty, jako jsou mobilní aplikace, a čistě se integruje s centrálními systémy identity. Touto cestou se ubírá většina institucionálních projektů.
- JWT (JSON Web Token): odlehčená alternativa, kde samotný token nese identitu uživatele. Je jednoduchý a bezstavový a dobře se hodí pro jednoduché aplikace bez komplexních požadavků na autorizaci.
Pro instituce, které již provozují jednotné přihlašování, může vrstva OAuth propojit aplikaci se stejným centrálním poskytovatelem identity, který se používá všude jinde, takže se studenti a zaměstnanci přihlašují do aplikace pomocí údajů, které již mají. Na správném nastavení autentizace hned na začátku záleží — je mnohem obtížnější dodatečně vestavět bezpečný tokenový postup do aplikace postavené kolem jednoduššího předpokladu, než jej navrhnout tak od samého počátku.
Mobilně specifická vrstva: offline, push a média
Většina průvodců k decoupled Drupalu končí u API a autentizace. Ale mobilní aplikace žije na zařízení s přerušovanou konektivitou, omezenou šířkou pásma a vlastním systémem notifikací, a tyto reality vyžadují plánování, které web nikdy nevyžaduje.
- Offline přístup a cachování: mobilní uživatel očekává, že aplikace bude fungovat ve vlaku nebo v přednáškovém sále se slabým signálem. Aplikace by měla obsah cachovat lokálně a synchronizovat s Drupalem, jakmile se připojení obnoví. API vrstva to podporuje poskytováním cachovatelných, strukturovaných odpovědí, které si aplikace může uložit a obnovit — logika cachování a synchronizace však leží na straně aplikace a musí být navržena záměrně.
- Push notifikace: notifikace jsou jedním z hlavních důvodů, proč instituce vůbec chtějí nativní aplikaci — nová známka, změna rozvrhu, nouzové upozornění. Drupal funguje jako zdroj spouštěče: když je publikován obsah nebo nastane událost, Drupal zavolá push službu (například Firebase Cloud Messaging), která doručí notifikaci na zařízení. Obsah a spouštěč žijí v Drupalu; doručení zajišťuje notifikační infrastruktura platformy.
- Optimalizace médií a obrázků: mobilní obrazovky a mobilní datové tarify dělají zacházení s obrázky kritickým. Systém médií a stylů obrázků v Drupalu dokáže generovat vhodně dimenzované verze každého obrázku, takže si aplikace vyžádá verzi optimalizovanou pro mobilní zařízení namísto stahování souboru v plném rozlišení určeného pro desktop. To přímo ovlivňuje dobu načítání a spotřebu dat.
- Progresivní webové aplikace jako střední cesta: ne každá instituce potřebuje plnohodnotnou nativní aplikaci. Progresivní webová aplikace (PWA) přináší velkou část nativního zážitku — instalaci na plochu, offline podporu, push notifikace — z jediné webové kódové báze, a Drupal to podporuje prostřednictvím vyhrazeného modulu PWA. Pro mnoho kampusů představuje PWA levnější cestu k zážitku podobnému aplikaci, než se zaváže k nativnímu vývoji.
Nekompromisně, nebo progresivně nekompromisně, nebo kompromisně?
Přejít k plné dekonstrukci je skutečným závazkem a automaticky to není správná odpověď. Být upřímný ohledně toho, kdy nedekonstruovat, je stejně důležité jako vědět, kdy ano. Existují tři široké modely:
- Kompromisní (tradiční Drupal): Drupal se stará jak o obsah, tak o prezentaci. To zůstává správnou volbou pro standardní web bez samostatné aplikace nebo front-endového frameworku. Pokud neexistuje mobilní aplikace ani druhý kanál, dekonstrukce přidává náklady bez přínosu.
- Progresivně dekonstruovaný: Drupal vykresluje většinu stránky, ale konkrétní interaktivní komponenty předává JavaScriptovému frameworku. To udržuje redakční a rozvržovací nástroje Drupalu netknuté a zároveň přidává bohatou interaktivitu tam, kde je potřeba — užitečný střední bod pro web, který chce určité aplikaci podobné chování bez plné přestavby.
- Plně dekonstruovaný: Drupal je čistě backend a jeden nebo více nezávislých front-endů (mobilní aplikace, samostatná webová aplikace) konzumuje jeho API. To je model, který vyžaduje nativní mobilní aplikace, a je správnou volbou, když skutečně obsluhujete více kanálů — znamená to však, že front-endový tým přebírá odpovědnosti, které dříve zajišťoval Drupal, od routování přes SEO až po přístupnost.
Rozhodujícím faktorem je, kolik front-endů musí obsah obsluhovat. Jediný web je nejlépe ponechat kompromisní. Web plus nativní mobilní aplikace ukazuje na dekonstruovanou nebo hybridní architekturu. Chybou je dekonstruovat pro dekonstrukci samotnou — plně dekonstruovaný projekt pro potřebu, která vždy vyžadovala jen jeden web, přidává složitost a náklady, které bude instituce udržovat po léta. Širší kompromisy mezi platformami jsme se zabývali v našem srovnání Drupalu, WordPressu a Joomly.
Volby front-endu: React Native, Flutter a nativní vývoj
Protože API-first backend Drupalu je nezávislý na front-endu, funguje s jakoukoli mobilní technologií, kterou tým preferuje. API je jedno, co jej konzumuje, což umožňuje, aby rozhodnutí spočívalo na požadavcích aplikace a dovednostech týmu.
- React Native: oblíbená multiplatformní volba, která z jediné JavaScriptové kódové báze vytváří aplikace pro iOS i Android. Přirozeně se páruje s JSON:API Drupalu a stojí za ním rozsáhlý ekosystém a pool talentů.
- Flutter: multiplatformní framework od Googlu využívající jazyk Dart, známý plynulým výkonem a konzistentním vzhledem napříč platformami. Konzumuje API Drupalu stejně ochotně jako jakýkoli jiný klient.
- Nativní (Swift / Kotlin): samostatný vývoj pro iOS (Swift) a Android (Kotlin) poskytuje nejhlubší integraci s platformou a nejlepší výkon, za vyšší náklady na vývoj. Backend Drupalu obsluhuje všechny identicky.
Klíčovým bodem je, že jde o skutečně otevřenou volbu. Protože backend zpřístupňuje standardní API, instituce není vázána na žádnou konkrétní front-endovou technologii a může ji dokonce později změnit, aniž by se dotkla obsahové vrstvy.
Časté nástrahy při stavbě mobilní aplikace v přístupu API-first
- Dekonstrukce, i když nebyla potřeba: nejčastější chyba. Pokud neexistuje druhý kanál, je kompromisní web na Drupalu jednodušší, levnější a snáze udržovatelný. Dekonstruujte proto, že máte mobilní aplikaci, ne proto, že to zní moderně.
- Odkládání autentizace na později: tokenová autentizace formuje celou architekturu aplikace. Navrhněte postup OAuth nebo JWT hned na začátku, ne až poté, co je aplikace už postavena kolem předpokladů relace.
- Zapomínání na to, co nyní vlastní front-end: v dekonstruovaném projektu přebírá front-endový tým routování, SEO, přístupnost a metadata — věci, které dříve automaticky zajišťoval Drupal. Je třeba je explicitně naplánovat, jinak se prostě nestanou.
- Ignorování mobilně specifické vrstvy: offline chování, push a optimalizace obrázků nejsou dodatečnou myšlenkou. Aplikace, která nezvládá slabou konektivitu nebo poskytuje obrázky ve velikosti pro desktop, bude působit rozbitě bez ohledu na to, jak čisté je API.
- Přetahování zbytečně velkého množství dat: vyžadování více, než obrazovka potřebuje, plýtvá šířkou pásma a baterií. Použijte filtrování polí v JSON:API, nebo GraphQL tam, kde se hodí, abyste získali jen to, co je nutné.
- Přistupování k API jako k dodatečné myšlence: celý smysl API-first spočívá v tom, navrhnout model obsahu a jeho API záměrně a předem. Naroubování API na obsahovou strukturu, která nikdy nebyla určena pro externí konzumaci, vede k neohrabaným a neefektivním endpointům.
Při promyšlené realizaci dává API-first backend Drupalu instituci jediný, dobře strukturovaný zdroj obsahu, který dokáže pohánět web, mobilní aplikaci i cokoli, co přijde příště — bez duplikování obsahu nebo opětovného budování základu pokaždé znovu. Přirozeně se hodí pro organizace, které se již spoléhají na strukturovaný obsah Drupalu a chtějí jej rozšířit na nové kanály. Chcete-li vidět širší škálu toho, co platforma podporuje, náš přehled co lze udělat s Drupalem mapuje související scénáře, a průvodce co je Drupal pokrývá základy jeho modelu strukturovaného obsahu.
Časté dotazy o Drupalu a mobilních aplikacích
Je Drupal dobrým backendem pro mobilní aplikaci?
Ano, zejména pokud aplikace potřebuje sdílet obsah s webem nebo dalšími kanály. Schopnosti Drupalu v oblasti API-first jsou zabudovány přímo v jádru, takže dokáže poskytovat strukturovaný obsah pro iOS, Android nebo jakýkoli front-end prostřednictvím standardních API bez vlastní infrastruktury. Obzvlášť dobře se hodí, když aplikace těží z podnikové úrovně správy obsahu v pozadí — redakčních workflow, detailních oprávnění, vícejazyčného obsahu a robustní správy médií. Pro samostatnou aplikaci bez sdíleného obsahu a bez potřeby správy obsahu může stačit lehčí backend; argument pro Drupal roste se složitostí obsahu.
Musím znát PHP, abych mohl(a) vytvořit mobilní aplikaci na Drupalu?
Ne, pro samotnou aplikaci ne. V decoupled architektuře je mobilní aplikace postavena pomocí mobilních technologií — React Native, Flutter, Swift nebo Kotlin — a s Drupalem komunikuje čistě prostřednictvím API. Mobilní vývojáři pracují ve svém vlastním jazyce a s PHP se nikdy nesetkají. Znalost PHP je relevantní pouze na straně Drupalu, pro konfiguraci backendu, modelování obsahu a přizpůsobení API vrstvy, což typicky zajišťuje tým Drupalu, nikoli tým aplikace.
JSON:API nebo GraphQL pro mobilní aplikaci?
Začněte s JSON:API. Je zapnuté v jádru Drupalu bez jakékoli konfigurace, řídí se přísnou a předvídatelnou specifikací a hned po instalaci pokrývá potřeby většiny mobilních aplikací. GraphQL stojí za zvážení, když obrazovky aplikace potřebují v jediném požadavku natáhnout mnoho různých kusů dat a chcete minimalizovat počet cest tam a zpět — přináší ale dodatečné nastavení a složitost prostřednictvím contributed modulu. Praktickou cestou je JSON:API jako výchozí volba, GraphQL až tehdy, kdy jej ospravedlní konkrétní požadavek na výkon.
Může jeden backend Drupal pohánět zároveň web i mobilní aplikaci?
Ano, a to je jeden z nejsilnějších důvodů, proč zvolit přístup API-first. Jeden backend Drupal dokáže současně obsluhovat web i mobilní aplikaci ze stejného obsahu. Oznámení nebo kurz zadaný jednou se objeví na obou místech, vždy synchronizovaně, bez zdvojeného úsilí. Přesně to v praxi znamená „jeden zdroj obsahu, mnoho kanálů" a je to hlavní výhoda budování architektury API-first od samého počátku.