feat: enhance documentation for internal operational SPA with detailed BFF layer description

Author: Don-Damiano

src/content/en-case-studies/internal-operational-spa.mdx

@@ -25,7 +25,7 @@ The application acts as a **single-page interface** for day-to-day operational t
 - managing staff members and their roles,
 - browsing and inspecting service points,
 - viewing operational status and assignments,
-- interacting with data exposed by backend systems through a BFF layer.
+- interacting with data exposed by backend systems through **a dedicated BFF layer designed and implemented as part of the project.**
 
 The system was designed from the start as:
 - an **internal tool**, not a public-facing application,
@@ -81,6 +81,9 @@ Key requirements included:
 
 The frontend had to remain **contract-agnostic** while still enforcing strong operational guarantees.
 
+The BFF was treated as a first-class component of the frontend architecture,
+designed and implemented alongside the SPA to provide stable contracts and isolate backend complexity.
+
 ---
 
 ### 4. Long-term evolution under active use
@@ -207,6 +210,7 @@ _UI screenshots shown with anonymized data and removed branding._
 The frontend integrates with backend systems using:
 - REST over HTTP with JSON payloads,
 - same-origin API paths exposed by a BFF layer,
+- a dedicated BFF layer designed and implemented together with the SPA,
 - OAuth2 / OpenID Connect authentication (Authorization Code + PKCE).
 
 Key characteristics:
@@ -218,6 +222,8 @@ Key characteristics:
 
 UI components remain **decoupled from API details**, relying on a centralized integration layer.
 
+The BFF is responsible for shaping backend responses into frontend-oriented contracts and enforcing consistency across multiple backend systems.
+
 ---
 
 ## State management and reliability

src/content/pl-case-studies/internal-operational-spa.mdx

@@ -25,7 +25,7 @@ Aplikacja pełni rolę **interfejsu typu single-page** do codziennych zadań ope
 - zarządzanie pracownikami i ich rolami,
 - przeglądanie i analiza punktów usługowych,
 - podgląd statusów operacyjnych i przypisań,
-- interakcja z danymi udostępnianymi przez systemy backendowe poprzez warstwę BFF.
+- interakcję z danymi udostępnianymi przez systemy backendowe za pośrednictwem ***dedykowanej warstwy BFF zaprojektowanej i zaimplementowanej jako część projektu.**
 
 System od początku projektowany był jako:
 - **narzędzie wewnętrzne**, a nie aplikacja publiczna,
@@ -81,6 +81,10 @@ Kluczowe wymagania obejmowały:
 
 Frontend musiał pozostać **agnostyczny względem kontraktów**, jednocześnie egzekwując silne gwarancje operacyjne.
 
+Warstwa BFF była traktowana jako pełnoprawny element architektury frontendowej,
+projektowana i implementowana równolegle z aplikacją SPA w celu zapewnienia stabilnych kontraktów
+oraz izolacji złożoności systemów backendowych.
+
 ---
 
 ### 4. Długoterminowa ewolucja przy aktywnym użyciu
@@ -207,6 +211,7 @@ _Zrzuty UI prezentowane są z anonimizowanymi danymi i usuniętym brandingiem._
 Frontend integruje się z systemami backendowymi poprzez:
 - REST over HTTP z payloadami JSON,
 - ścieżki API typu same-origin wystawione przez warstwę BFF,
+- dedykowaną warstwę BFF zaprojektowaną i zaimplementowaną równolegle z aplikacją SPA,
 - uwierzytelnianie OAuth2 / OpenID Connect (Authorization Code + PKCE).
 
 Kluczowe cechy:
@@ -218,6 +223,10 @@ Kluczowe cechy:
 
 Komponenty UI pozostają **odsprzężone od szczegółów API**, korzystając ze scentralizowanej warstwy integracji.
 
+Warstwa BFF odpowiada za kształtowanie odpowiedzi systemów backendowych
+do kontraktów dopasowanych do potrzeb frontendu oraz za wymuszanie spójności
+pomiędzy wieloma systemami backendowymi.
+
 ---
 
 ## Zarządzanie stanem i niezawodność