Univerzální API selže na tom, že žádný klient není univerzální
Jedno API pro všechny klienty je přirozený první krok a spolehlivě se rozpadne. Mobil má jinou obrazovku, jiný datový tarif a jiný rozpočet na baterii než desktop; potřebuje míň polí a míň volání. Web potřebuje jiný řez týchž dat. Univerzální backend se snaží vyhovět oběma a stane se z něj prostředník — kus systému, na kterém se každá změna v rozhraní zastaví a čeká, až na ni bude mít čas cizí tým.
Backend-for-Frontend, pojmenovaný Philem Calçadem podle praxe ze SoundCloudu, řeší přesně tenhle organizační zádrhel. Ne technický.
Vlastnictví je celý ten vzor
Klientská aplikace se rozdělí na dvě části: to, co běží u uživatele, a serverovou půlku, kterou vlastní tentýž tým. BFF agreguje volání downstream služeb, ořezává data do tvaru, který ta obrazovka potřebuje, a mění se ve stejném rytmu jako UI nad ním.
Tím se BFF liší od API brány, se kterou se plete. Brána je sdílená infrastruktura, kterou provozuje někdo jiný a která má zůstat obecná. BFF je naopak úmyslně těsně svázaný s jednou zkušeností a nikdo jiný ho nesmí používat. Ve chvíli, kdy si na něj napojíš druhého klienta, jsi si vyrobil zpátky univerzální API i s jeho prostředníkem.
Pravidlo zní jedna zkušenost, jeden BFF. Hranici ale nekreslí technologie, kreslí ji tým. Když iOS a Android dělají dva různé týmy, patří jim dva BFF. Když je dělá jeden tým a jde o tutéž třídu rozhraní, jeden společný dává smysl — přesně to na SoundCloudu udělali.
Duplicita mezi BFF není chyba
Tady se vzor nejčastěji poruší. Dva BFF dělají podobnou práci, někoho to začne rušit a vytáhne z nich sdílenou knihovnu. Tou knihovnou právě spojil zpátky dva týmy, které měl vzor rozpojit — a udělal to hůř, protože ta vazba je teď schovaná.
Duplicita je proto cena, kterou vzor vědomě platí. Newman doporučuje pravidlo tří: abstrakci vytahovat až u třetího výskytu, ne u druhého. A když už duplicity je opravdu moc, jsou lepší cesty než sdílená knihovna — vytáhnout doménovou službu, která tu logiku vlastní, nebo posunout agregaci dolů do existujících služeb.
Nesdílej kód mezi BFF. Sdílej službu.
Za co se platí
Vzor není zadarmo a stojí za to znát jeho účet. Přibude ti kód navíc a víc nasazovaných služeb, tedy víc provozu, monitoringu a koordinace. Věci, které patří na obvod systému — autentizace, logování, rate limiting — se teď musí dělat konzistentně na několika místech, což je přesně ten druh práce, kde konzistence tiše uteče.
Proto se BFF vyplatí hlavně tam, kde je co agregovat, tedy nad opravdovou hromadou downstream služeb, a kde máš mobilní nebo cizí klienty. U aplikace, která je jen webová a mluví se třemi službami, je to náklad bez protihodnoty.
Co si z toho odnést
Když uvažuješ o BFF, netestuj to otázkou, jestli by se hodila jiná odpověď pro mobil. Testuj to otázkou, jestli tvůj tým dneska čeká na cizí tým, aby mohl změnit obrazovku. Vzor řeší tohle čekání; když ho nemáš, řešíš neexistující problém.
Hranice mezi BFF veď podle týmů, ne podle platforem. Struktura organizace se do architektury propíše tak jako tak, tady se z toho jen dá udělat záměr místo nehody.
A když z BFF začneš vytahovat sdílený kód, ber to jako signál, že vzor přestává platit. Buď mají ty dvě zkušenosti společnou doménovou logiku, která patří do vlastní služby, nebo jde ve skutečnosti o jednu zkušenost a jeden tým — a pak stačí jeden BFF.