Vytvoří samostatné back-endové služby pro konkrétní front-endové aplikace nebo rozhraní. Tento model je užitečný, pokud se chcete vyhnout přizpůsobování jednoho back-endu pro různá rozhraní. Jako první tento model popsal Sam Newman.
Kontext a problém
Aplikace může být zpočátku zacílená na desktopové webové uživatelské rozhraní. Obvykle se paralelně vytvoří back-endová služba, která poskytuje funkce potřebné pro toto uživatelské rozhraní. Jakmile se rozroste uživatelská základna této aplikace, vytvoří se mobilní aplikace, která musí používat stejný back-end. Back-endová služba se stane back-endem pro obecné použití, který obsluhuje požadavky desktopového i mobilního rozhraní.
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í. Proto se požadavky na back-end mobilní aplikace liší od desktopového webového uživatelského rozhraní.
Tyto rozdíly způsobují, že si požadavky na back-end konkurují. Back-end vyžaduje pravidelné a významné změny, které jsou určeny pro desktopové webové uživatelské rozhraní i mobilní aplikaci. Často se stává, že na každém front-endu pracuje samostatný tým rozhraní. Ve výsledku je pak back-end kritickým místem procesu vývoje. Konfliktní požadavky na aktualizaci a potřeba udržet službu funkční pro oba front-endy můžou způsobit, že se jednomu nasaditelnému prostředku věnuje příliš mnoho úsilí.
Při zaměření vývojových aktivit na back-endovou službu se může vytvořit samostatný tým pro správu a údržbu back-endu. Výsledkem pak je odpojení týmů pro vývoj rozhraní od týmů pro vývoj back-endu, přičemž back-endový tým je zatížen potřebou vybalancovat konkurenční požadavky týmů různých uživatelských rozhraní. Pokud jeden tým rozhraní vyžaduje změny back-endu, musí být tyto změny ověřeny s týmy ostatních rozhraní dříve, než je možné je do back-endu integrovat.
Řešení
Vytvořte jeden back-end na jedno uživatelské rozhraní. Dolaďte chování a výkon každého back-endu tak, aby co nejlépe odpovídal potřebám front-endového prostředí, aniž byste se museli starat o ovlivnění jiných prostředí front-endu.
Vzhledem k tomu, že každý back-end je specifický pro jedno rozhraní, můžete ho pro toho rozhraní optimalizovat. Výsledkem bude back-end menší, méně složitý a pravděpodobně rychlejší než obecný back-end, který se snaží vyhovět požadavkům všech rozhraní. Tým každého rozhraní může samostatně řídit svůj vlastní back-end a nemusí spoléhat na centralizovaný tým pro vývoj back-endu. Tým rozhraní tak získává flexibilitu při výběru jazyka, určování tempa vydávání verzí, stanovení priorit zatížení a integrace funkcí do jejich back-endu.
Další informace najdete v tématu Model: Back-endy pro front-endy.
Problémy a důležité informace
- Zvažte, kolik back-endů chcete nasadit.
- Pokud budou různá rozhraní (například mobilní klienti) vytvářet stejné požadavky, zvažte, jestli je nutné pro každé rozhraní implementovat back-end, nebo zda bude stačit jeden back-end.
- Je velmi pravděpodobné, že při implementaci tohoto modelu dojde k duplikaci kódu napříč službami.
- Back-endové služby zaměřené na front-end by měly obsahovat pouze logiku a chování specifické pro klienta. Obecná obchodní logika a jiné globální funkce by se měly spravovat jinde v aplikaci.
- Zamyslete se nad tím, jak by se tento model mohl promítnout v zodpovědnostech vývojového týmu.
- Zvažte, jak dlouho bude implementace tohoto modelu trvat. Způsobí snaha o vytvoření nových back-endů technický dluh, protože budete dále podporovat stávající obecný back-end?
Kdy se má tento model použít
Tento model použijte v těchto případech:
- Sdílená back-endová služba nebo back-endová služba s obecným použitím se musí udržovat s vysokými náklady na vývoj.
- Chcete optimalizovat back-end pro požadavky konkrétních klientských rozhraní.
- Provádí se přizpůsobení back-endu s obecným použitím tak, aby odpovídal 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 model nebude pravděpodobně vhodný v následujících případech:
- Pokud rozhraní vytvářejí stejné nebo podobné požadavky na back-end.
- Pokud se k interakci s back-endem používá pouze jedno rozhraní.
Návrh úloh
Architekt by měl vyhodnotit způsob použití back-endů pro front-endy v návrhu úloh k řešení cílů a principů popsaných v pilířích architektury Azure Well-Architected Framework. Příklad:
| Pilíř | Jak tento model podporuje cíle pilíře |
|---|---|
| Rozhodnutí o návrhu spolehlivosti pomáhají vaší úloze stát se odolnou proti selhání a zajistit, aby se po selhání obnovila do plně funkčního stavu. | Samostatné služby, které jsou výhradní pro konkrétní rozhraní front-endu, obsahují poruchy, takže dostupnost jednoho klienta nemusí ovlivnit 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. | Vzhledem k oddělení služeb zavedených v tomto modelu může být zabezpečení a autorizace ve vrstvě služby, která podporuje jednoho klienta, přizpůsobena funkcím vyžadovaným tímto klientem, což může potenciálně snížit plochu rozhraní API a laterální přesun mezi různými back-endy, které by mohly zpřístupnit různé možnosti. - SE:04 Segmentace - SE:08 Posílení zabezpečení prostředků |
| Efektivita výkonu pomáhá vaší úloze 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 |
Stejně jako u jakéhokoli rozhodnutí o návrhu zvažte jakékoli kompromisy proti cílům ostatních pilířů, které by mohly být s tímto vzorem zavedeny.