Vzor back-endů pro front-endy

Tento model popisuje, jak oddělit back-endové služby od front-endových implementací a přizpůsobit prostředí pro různá klientská rozhraní. Tento model je užitečný, když se chcete vyhnout přizpůsobení back-endu, který obsluhuje více rozhraní. Tento vzor vychází ze vzoru Backends pro Frontends od Sama Newmana.

Kontext a problém

Představte si aplikaci, která je původně navržená s desktopovým webovým uživatelským rozhraním a odpovídající back-endovou službou. S tím, jak se obchodní požadavky v průběhu času mění, se přidá mobilní rozhraní. Obě rozhraní komunikují se stejnou back-endovou službou. Možnosti mobilního zařízení se ale výrazně liší od desktopového prohlížeče z hlediska velikosti obrazovky, výkonu a omezení zobrazení.

Diagram má dvě části: back-endovou službu a desktopového klienta a mobilního klienta. Dvě oboustranné šipky ukazují z back-endové služby na desktopového klienta i mobilního klienta.

Back-endová služba často čelí konkurenčním požadavkům z více front-endových systémů. Tyto požadavky vedou k častým aktualizacím a potenciálním kritickým bodům vývoje. Konfliktní aktualizace a potřeba udržovat kompatibilitu vede k nadměrné poptávce po jednom nasaditelném prostředku.

Oddělení týmu, který spravuje back-endovou službu, může vytvořit odpojení mezi front-endovými a back-endovými týmy. Toto odpojení může způsobit zpoždění při získávání konsensu a vyrovnávání požadavků. Například změny požadované jedním front-endovým týmem musí být před integrací ověřeny s ostatními front-endovými týmy.

Řešení

Zavádí novou vrstvu, která zpracovává pouze požadavky specifické pro rozhraní. Tato vrstva, označovaná jako back-endová služba pro front-end (BFF), se nachází mezi front-endovým klientem a back-endovou službou. Pokud aplikace podporuje více rozhraní, jako je webové rozhraní a mobilní aplikace, vytvořte pro každé rozhraní službu BFF.

Tento model přizpůsobí prostředí klienta pro konkrétní rozhraní, aniž by to mělo vliv na jiná rozhraní. Také optimalizuje výkon tak, aby splňoval požadavky front-endového prostředí. Vzhledem k tomu, že každá služba BFF je menší a méně složitá než sdílená back-endová služba, může usnadnit správu aplikace.

Front-endové týmy nezávisle spravují vlastní službu BFF, která jim dává kontrolu nad výběrem jazyka, tempem vydávání verzí, stanovením priorit úloh a integrací funkcí. Tato autonomie jim umožňuje efektivně pracovat bez závislosti na centralizovaném vývojovém týmu back-endu.

Mnoho služeb BFF tradičně spoléhalo na rozhraní REST API, ale implementace GraphQL se objevují jako alternativa. Díky GraphQL eliminuje dotazovací mechanismus potřebu samostatné vrstvy BFF, protože umožňuje klientům požadovat data, která potřebují, aniž by museli spoléhat na předdefinované koncové body.

Diagram znázorňuje tři části. První část se skládá z desktopového klienta a mobilního klienta. Druhá část se skládá ze služby BFF desktopového klienta a služby BFF mobilního klienta. Desktopový klient má šipku, která jasně ukazuje na službu BFF desktopového klienta. Mobilní klient má pevnou šipku, která ukazuje na službu BFF mobilního klienta. Každá služba BFF má tečkovanou šipku, která odkazuje na oddíl back-endové služby.

Další informace najdete ve vzoru Backends pro Frontends od Sama Newmana.

Problémy a důležité informace

• Vyhodnoťte optimální počet služeb v závislosti na přidružených nákladech. Údržba a nasazení dalších služeb znamená vyšší provozní režii. Každá jednotlivá služba má vlastní životní cyklus, požadavky na nasazení a údržbu a potřeby zabezpečení.

• Při přidávání nové služby zkontrolujte cíle na úrovni služby. Může dojít ke zvýšení latence, protože klienti nekontaktují vaše služby přímo a nová služba zavádí další síťový skok.

• Pokud různá rozhraní dělají stejné požadavky, vyhodnoťte, jestli je možné požadavky konsolidovat do jedné služby BFF. Sdílení jedné služby BFF mezi několika rozhraními může vést k různým požadavkům pro každého klienta, což může komplikovat růst a podporu služby BFF.

  Duplikace kódu je pravděpodobným výsledkem tohoto modelu. Vyhodnoťte kompromis mezi duplikací kódu a lépe přizpůsobeným prostředím pro každého klienta.

• Služba BFF by měla zpracovávat pouze logiku specifickou pro klienta související s konkrétním uživatelským prostředím. Průřezové funkce, jako je monitorování a autorizace, by měly být abstrahovány, aby se zachovala efektivita. Typické funkce, které se můžou zobrazit ve službě BFF, se zpracovávají samostatně pomocí vzorů Gatekeeping, Rate Limiting a Routing .

• Zvažte, jak učení a implementace tohoto modelu ovlivňuje vývojový tým. Vývoj nových back-endových systémů vyžaduje čas a úsilí, což může vést k technickému dluhu. Udržování stávající back-endové služby do této výzvy přidává.

• Vyhodnoťte, jestli tento vzor potřebujete. Pokud například vaše organizace používá GraphQL s překladači specifickými pro front-end, nemusí služby BFF do vašich aplikací přidávat hodnotu.

  Dalším scénářem je aplikace, která kombinuje bránu rozhraní API s mikroslužbami. Tento přístup může být dostatečný pro některé scénáře, kdy se obvykle doporučují služby BFF.

Kdy použít tento vzor

Tento model použijte v těchto případech:

• Sdílená back-endová služba nebo back-end pro obecné účely vyžaduje značné režijní náklady na vývoj, které je potřeba udržovat.

• Chcete optimalizovat back-end pro požadavky konkrétních klientských rozhraní.

• Přizpůsobení back-endu pro obecné účely provedete tak, aby vyhovovalo více rozhraním.

• Programovací jazyk je vhodnější pro back-end konkrétního uživatelského rozhraní, ale ne pro všechna uživatelská rozhraní.

Tento vzor nemusí být vhodný v těchto případech:

• Rozhraní posílají stejné nebo podobné požadavky do backendu.

• S back-endem komunikuje pouze jedno rozhraní.

Návrh úloh

Vyhodnoťte, jak používat back-endy pro front-endy v návrhu úlohy k řešení cílů a principů zahrnutých v pilířích architektury Azure Well-Architected Framework. Následující tabulka obsahuje pokyny, jak tento model podporuje cíle jednotlivých pilířů.

Pilíř	Jak tento model podporuje cíle pilíře
Spolehlivostní rozhodnutí o návrhu pomáhají vaší pracovní zátěži stát se odolná proti poruchám a zajistit, aby se po selhání obnovila do plně funkčního stavu.	Když izolujete služby na konkrétní rozhraní frontendu, omezíte poruchy. Dostupnost jednoho klienta nemá vliv na dostupnost přístupu jiného klienta. Pokud pracujete s různými klienty jinak, můžete určit prioritu úsilí o spolehlivost na základě očekávaných vzorů přístupu klientů. - RE:02 Kritické toky - RE:07 Sebezáchování
Rozhodnutí o návrhu zabezpečení pomáhají zajistit důvěrnost, integritu a dostupnost dat a systémů vaší úlohy.	Oddělení služeb zavedené v tomto vzoru umožňuje přizpůsobení zabezpečení a autorizace ve vrstvě služby pro konkrétní potřeby jednotlivých klientů. Tento přístup může snížit plochu API a omezit přesuny mezi back-endy, které by mohly odhalovat různé možnosti. - SE:04 Segmentace - SE:08 Posílení zabezpečení prostředků
efektivita výkonu pomáhá vašim úlohám efektivně splňovat požadavky prostřednictvím optimalizací škálování, dat a kódu.	Oddělení back-endu umožňuje optimalizovat způsoby, které nemusí být možné s vrstvou sdílené služby. Když zpracováváte jednotlivé klienty jinak, můžete optimalizovat výkon pro omezení a funkčnost konkrétního klienta. - PE:02 Plánování kapacity - PE:09 Kritické toky

Pokud tento model představuje kompromisy v rámci pilíře, zvažte je proti cílům ostatních pilířů.

Příklad

Tento příklad ukazuje případ použití pro vzor, ve kterém dvě odlišné klientské aplikace, mobilní aplikace a desktopová aplikace, pracují se službou Azure API Management (brána roviny dat). Tato brána slouží jako abstrakční vrstva a spravuje obvyklé záležitosti průřezové povahy, jako jsou:

• Autorizace Zajišťuje, že pouze ověřené identity se správnými přístupovými tokeny můžou volat chráněné prostředky pomocí služby API Management s ID Microsoft Entra.

• Monitorování. Zaznamenává a odesílá podrobnosti žádosti a odpovědi do služby Azure Monitor pro účely pozorovatelnosti.

• Ukládání požadavků do mezipaměti Optimalizuje opakované požadavky tím, že obsluhuje odpovědi z mezipaměti pomocí integrovaných funkcí služby API Management.

• Směrování a agregace Směruje příchozí požadavky na příslušné služby BFF.

Každý klient má vyhrazenou službu BFF spuštěnou jako funkci Azure, která slouží jako zprostředkovatel mezi bránou a podkladovými mikroslužbami. Tyto služby BFF specifické pro klienta zajišťují přizpůsobené prostředí pro stránkování a další funkce. Mobilní aplikace upřednostňuje efektivitu šířky pásma a využívá ukládání do mezipaměti ke zvýšení výkonu. Naproti tomu desktopová aplikace načítá více stránek v jednom požadavku, což vytvoří imerzivní uživatelské prostředí.

Diagram je strukturovaný do čtyř částí, které znázorňují tok požadavků, ověřování, monitorování a zpracování specifické pro klienta. Dvě klientská zařízení iniciují požadavky: mobilní aplikace optimalizovaná pro uživatelské prostředí efektivní šířky pásma a webový prohlížeč, který poskytuje plně funkční rozhraní. Šipky se rozšiřují z obou zařízení směrem k centrálnímu vstupnímu bodu, což je brána služby API Management, aby bylo patrné, že všechny požadavky musí projít touto vrstvou. V druhé sekci, která je uzavřená v obdélníku s přerušovanou čárou, je architektura rozdělena do dvou vodorovných skupin. Levá skupina představuje API Management, která zpracovává příchozí požadavky a určuje, jak je zpracovat. Dvě šipky se rozšiřují směrem ven z této brány roviny dat. Jedna šipka ukazuje nahoru na ID Microsoft Entra, které spravuje autorizaci. Další šipka směřuje dolů na Azure Monitor, který zodpovídá za protokolování a pozorovatelnost. Šipka se vrátí z brány do mobilního klienta, což představuje odpověď uloženou v mezipaměti, když se opakuje stejný požadavek, což snižuje zbytečné zpracování. Pravá skupina v přerušovaném obdélníku se zaměřuje na přizpůsobení serverových odpovědí na základě typu klienta, který žádost zadává. Nabízí dva samostatné back-endové klienty pro front-end, oba hostované pomocí Azure Functions pro bezserverovou architekturu. Jeden je vyhrazený pro mobilního klienta a druhý pro desktopového klienta. Dvě šipky směřují z brány ke klientům typu backend pro frontend, což ilustruje, že každý příchozí požadavek je předán příslušné službě podle typu klienta. Kromě této vrstvy přerušované šipky rozšiřují a propojují back-endové klienty s různými mikroslužbami, které zpracovávají skutečnou obchodní logiku. Obrázek znázorňuje tok zleva doprava, kde se požadavky klientů přesouvají z mobilních a webových klientů na bránu. Tato brána zpracovává jednotlivé požadavky při delegování ověřování směrem nahoru na zprostředkovatele identity a protokolování do monitorovací služby směrem dolů. Odtud směruje požadavky na příslušného back-endového klienta pro front-end na základě toho, jestli požadavek pochází z mobilního nebo desktopového klienta. Nakonec každý klient backend pro frontend předává požadavek specializovaným mikroslužbám, které provádějí požadovanou obchodní logiku a vrací potřebnou odpověď. Pokud je k dispozici odpověď uložená v mezipaměti, brána zachytí požadavek a odešle uloženou odpověď přímo mobilnímu klientovi, což brání redundantnímu zpracování.

Tok A pro požadavek na první stránku z mobilního klienta

1. Mobilní klient odešle GET žádost o stránku 1, včetně tokenu OAuth 2.0 v hlavičce autorizace.

2. Požadavek dosáhne brány služby API Management, která ji zachytí a:

   1. Zkontroluje stav autorizace. SLUŽBA API Management implementuje hloubku ochrany, takže kontroluje platnost přístupového tokenu.

   2. Streamuje aktivitu žádosti jako protokoly do služby Azure Monitor. Podrobnosti o požadavku se zaznamenávají pro auditování a monitorování.

3. Zásady se vynucují a poté nástroj API Management směruje požadavek k mobilní BFF službě funkce Azure.

4. Mobilní služba BFF funkce Azure Pak komunikuje s potřebnými mikroslužbami k načtení jedné stránky a zpracování požadovaných dat za účelem zajištění jednoduchého prostředí.

5. Odpověď se vrátí klientovi.

Flow B pro požadavek na první stránku uloženou v mezipaměti z mobilního klienta

1. Mobilní klient znovu odešle stejný GET požadavek na stránku 1 včetně tokenu OAuth 2.0 v autorizační hlavičce.

2. Brána pro správu API rozpozná, že tento požadavek byl již dříve proveden a:

   1. Zásady se vynucují. Brána pak identifikuje odpověď uloženou v mezipaměti, která odpovídá parametrům požadavku.

   2. Vrátí odpověď uloženou v mezipaměti okamžitě. Tato rychlá odpověď odstraňuje potřebu předávat požadavek na mobilní BFF službu funkce Azure.

Flow C pro první požadavek z desktopového klienta

1. Desktopový klient odešle GET žádost poprvé, včetně tokenu OAuth 2.0 v autorizační hlavičce.

2. Požadavek se dostane do brány služby API Management, kde se zpracovávají různé aspekty.

   1. Oprávnění: Ověření tokenu je vždy povinné.

   2. Streamování aktivity žádosti: Podrobnosti žádosti se zaznamenávají pro pozorovatelnost.

3. Po vynucování všech zásad služba API Management směruje požadavek do desktopové služby BFF funkce Azure, která zpracovává zpracování aplikací náročných na data. Desktopová služba BFF agreguje více požadavků pomocí volání podkladových mikroslužeb před reagováním na klienta s více stránkovou odpovědí.

Návrh

• Microsoft Entra ID slouží jako cloudový zprostředkovatel identity. Poskytuje přizpůsobené deklarace identity cílové skupiny pro mobilní i desktopové klienty. Tyto deklarace identity se pak použijí k autorizaci.

• SLUŽBA API Management slouží jako proxy server mezi klienty a jejich službami BFF, která vytváří hraniční síť. Služba API Management je nakonfigurovaná se zásadami pro ověření webových tokenů JSON a odmítá požadavky, které neobsahují token nebo obsahují neplatné deklarace identity pro cílovou službu BFF. Také streamuje všechny protokoly aktivit do služby Azure Monitor.

• azure Monitor funguje jako centralizované řešení monitorování. Agreguje všechny protokoly aktivit, aby se zajistila komplexní komplexní pozorovatelnost.

• Azure Functions je bezserverové řešení, které efektivně zpřístupňuje logiku služby BFF napříč několika koncovými body, což zjednodušuje vývoj. Azure Functions také minimalizuje režijní náklady na infrastrukturu a pomáhá snížit provozní náklady.

Další kroky

• Backends for Frontends pattern od Sam Newmana
• Ověřování a autorizace pro rozhraní API ve službě API Management
• Integrace služby API Management s Application Insights

Související prostředky

• Model Agregace pomocí brány
• Model Snižování zátěže pomocí brány
• Model Směrování prostřednictvím brány
• referenční architektura bezserverové webové aplikace