Paradygmat architektury front-end

Czy jest jakiś paradygmat architektury front-end obecnie który mówi, że front-end (przeglądarka) nie komunikuje się z backend-em bezpośrednio, ale przez "komponenty serwerowe"?

Np. NextJS + FastAPI, przeglądarka nie gadała by bezpośrednio do FastAPI tylko albo zbierała dane na serwerze (komponenty serwerowe), albo za pośrednictwem Server Actions*

Pracowałem ostatnio z FastAPI i zaskoczyła mnie bardzo mała popularność bibliotek "anty-CSRF", jak próbowałem to poruszyć na ich Discordzie dostałem informację, że często ludzie robią tak, że dopiero "komponenty serwerowe" kontaktują się z FastAPI i dzięki temu można ją schować przed użytkownikami, a ochrona przed CSRF przenosi się na te komponenty wtedy. Faktycznie jest to teraz najpopularniejsze rozwiązanie i idzie się w tym kierunku - całkowite schowanie API backendu przed przeglądarką?

*co do Server Actions nie jestem pewien, bo nie używałem tego, ale jak rozumiem jest jakiś mechanizm który pozwala klientowi (przegladarce) odpytać proces Next-a na serwerze który może w jego imieniu zrobić zapytanie do jakiś innych API (w tym przypadku np. naszego back-endu w FastAPI)

Czy mówisz o BFF (backend for frontend)?

slsy napisał(a):

Czy mówisz o BFF (backend for frontend)?

wrzuciłem cały pierwszy post do czata gpt i chat mi powiedział iż chodzi o BBF co generuje htmla. trochę jak serwery webowe JSF w javie EE gdzie serwer JSF generował HTMLa a logica była w serwerze aplikacyjnym e EJB. Ale czy moje zrozumienie OPa jest poprawne?

BTW i uważam iż generowanie htmla po stronie serwera było lepsze bo google i inni nie mieli problemu z indeksowaniem tego

KamilAdam napisał(a):

wrzuciłem cały pierwszy post do czata gpt i chat mi powiedział iż chodzi o BBF co generuje htmla. trochę jak serwery webowe JSF w javie EE gdzie serwer JSF generował HTMLa a logica była w serwerze aplikacyjnym e EJB. Ale czy moje zrozumienie OPa jest poprawne?

Z tego co ogarniam to technolgie jak NextJS działają w sposób hybrydowy tj. część generowana jest przez serwer a część w przeglądarce. Dlatego w tym zastosowaniu BFF to nie wybór a konieczność, bo musisz mieć tego JSa po stronie serwera jeśli "prawdziwy" backend jest np. w Pythonie

Oczywiście nie zmienia to faktu, że niezależnie od przymusu BFF to i tak dobry pomysł:

• mniejszy syf w backendzie
• frontendasy mogą sobie sobie zmieniać co im się podoba bez gadania z backendowcami
• możliwość zaaplikowania specyficznych technologii np. cachowanie tylko dla frontendu albo agregujące api GraphQL używające resta pod spodem

BTW i uważam iż generowanie htmla po stronie serwera było lepsze bo google i inni nie mieli problemu z indeksowaniem tego

Zależy co to za strona/co to ma robić.
Bo o ile to jest typowa strona firmowa, albo takie 4p to owszem, dostęp do treści powinien być dla każdego - w tym dla botów indeksujących.
Ale jak piszesz jakiś system ticketowy albo jakąś apkę w stylu exela, która robi jakieś obliczenia, to raczej nie ma sensu tych treści indeksować (a nawet się nie powinno) to to są moje treści będące danymi, na których pracuję w tej webowej apce.

cerrato napisał(a):

BTW i uważam iż generowanie htmla po stronie serwera było lepsze bo google i inni nie mieli problemu z indeksowaniem tego

Zależy co to za strona/co to ma robić.
Bo o ile to jest typowa strona firmowa, albo takie 4p to owszem, dostęp do treści powinien być dla każdego - w tym dla botów indeksujących.
Ale jak piszesz jakiś system ticketowy albo jakąś apkę w stylu exela, która robi jakieś obliczenia, to raczej nie ma sensu tych treści indeksować (a nawet się nie powinno) to to są moje treści będące danymi, na których pracuję w tej webowej apce.

oczywista oczywistość, jak ktoś robi apkę wewnątrz firmową albo taką która jest używalna dopiero po zalogowaniu się itd to można wszystko składać po stronie frontendu. Pamiętam iż oglądałem nawet prezentacje jednego gościa co zastąpił WP za pomocą reacta i był wszoku iż teraz ruch mu spadł 10 razy. Nawet był programistą frontendu dużo używajacym reacta ale nigdy wcześniej nie potrzebował tworzyć treści które może czytać google

Z tego co ogarniam to technolgie jak NextJS działają w sposób hybrydowy tj. część generowana jest przez serwer a część w przeglądarce. Dlatego w tym zastosowaniu BFF to nie wybór a konieczność, bo musisz mieć tego JSa po stronie serwera jeśli "prawdziwy" backend jest np. w Pythonie

Można pójść jeszcze dalej i wszystko mieć w nest.js. Miałem okazję używać nesta przez rok. I nawet dobrze się pisze (jak na język dynamicznie typowany). Nest.js : Jeden, by wszystkimi rządzić, Jeden, by wszystkie odnaleźć, Jeden, by wszystkie zgromadzić i w ciemności związać

slsy napisał(a):

Z tego co ogarniam to technolgie jak NextJS działają w sposób hybrydowy tj. część generowana jest przez serwer a część w przeglądarce. Dlatego w tym zastosowaniu BFF to nie wybór a konieczność, bo musisz mieć tego JSa po stronie serwera jeśli "prawdziwy" backend jest np. w Pythonie

Oczywiście nie zmienia to faktu, że niezależnie od przymusu BFF to i tak dobry pomysł:

• mniejszy syf w backendzie
• frontendasy mogą sobie sobie zmieniać co im się podoba bez gadania z backendowcami
• możliwość zaaplikowania specyficznych technologii np. cachowanie tylko dla frontendu albo agregujące api GraphQL używające resta pod spodem

ja właśnie się bardziej wdrażam w Next-a dopiero, wcześniej głównie Django SSR i React

jest tak faktycznie, że w ogóle w tym momencie front-end z Nexta nie powinien rozmawiać z back-endem z Pythona i ta komunikacja powinna właśnie iść jedynie przez "backend Next-a"? tak się teraz robi i do tego dąży też w innych frame-workach JS-owych - obecny "paradygmat" dla web-u?:P

slsy napisał(a):

Czy mówisz o BFF (backend for frontend)?

nie wiem czy można by to uznać jako BFF. BFF czasem nie odnosi się do sytuacji gdzie robimy osobne backe-ndy dla osobnych domen, czyli web/mobile dostają dedykowane zamiast korzystać z tego samego?

B.Eng napisał(a):

*co do Server Actions nie jestem pewien, bo nie używałem tego, ale jak rozumiem jest jakiś mechanizm który pozwala klientowi (przegladarce) odpytać proces Next-a na serwerze który może w jego imieniu zrobić zapytanie do jakiś innych API (w tym przypadku np. naszego back-endu w FastAPI)

Server actions w next.js używa się głównie do operacji typu POST/PUT/DELETE. Do komunikacji żądań typu GET z zew. API po stronie komponentu serwerowego używany jest fetch.
Dla niektórych typów aplikacji taki podział jest dość wygodny bo aplikacja napisana w next.js sama odpowiada za uwierzytelnianie i autoryzacje, a komunikacja z jednym lub więcej API może odbywać się poprzez klucze API.

@slsy rozwinę to co napisałam w komentarzach:
jeżeli robisz do każdego fontendu osobny backend to w rezultacie musisz powtarzać kod który tworzy dane mające być wyświetlane na tych frontendach, będące być efektem pobierania i agregowania danych z kilku źródeł, według różnych kryteriów
być może efektem skomplikowanych i długotrwałych obliczeń
być może dane od użytkownika mają przechodzić walidację przed wykorzystaniem dalej/zapisem
te czynności powinien wykonać backend, znam też takich kozaków którzy wszystko na froncie robią, ale pomińmy tę patologię
i teraz będą one albo w każdym backendzie zrobione metodą copy&paste, czyli w razie jakieś zmian lub błędów znalezionych w kodzie poprawkę należy też skopiować do fafnastu serwerów, pamiętając że w każdym z nich reszta pliku się różni, więc nie wystarczy go nadgrać, trzeba skopiować inteligentnie tylko kawałek kodu nie psując całości, nie powodując kolizji z nazwami zmiennych czy funkcji, które w każdym pliku będą inne.....
Ale to i tak jest lepszy przypadek. Gorszy polega na tm że funkcjonalność opisaną przez nietechnicznego PM każda ekipa tworząca serwer będzie próbowała napisać na nowo, według tego co im się wydaje, przyjmując inne założenia. W rezultacie np. walidacja danych od użytkownika raz będzie przepuszczała jakiś przypadek a raz nie, punkt widzenia będzie zależał od punktu siedzenia
Ponieważ próby bardziej zorientowanych osób uporządkowania tego bajzlu, przez np. akcję wyodrębnienia wspólnych części backendu do wspólnych modułów, będą skazane na porażkę przez opór koderów którzy chcą się stać niewyrzucalnymi pracownikami więc porządek w kodzie jest ich wrogiem ;) najważniejsze kawałki zostaną przeniesione, albo powtórzone w głównej bazie danych, do których vibe-codarzy od wielu backendów na szczęście nie zostaną dopuszczeni.
Żeby nie było - ja byłam takim analitykiem co próbował wprowadzić w jednym miejscu zebranie regexów używanych do walidacji w kilku ściśle powiązanych ze sobą systemach pisanych w C#. Poniosłam sromotną porażkę :(

jeżeli robisz do każdego fontendu osobny backend to w rezultacie musisz powtarzać kod który tworzy dane mające być wyświetlane na tych frontendach, będące być efektem pobierania i agregowania danych z kilku źródeł, według różnych kryteriów
te czynności powinien wykonać backend, znam też takich kozaków którzy wszystko na froncie robią, ale pomińmy tę patologię

W tym wypadku trzymasz tą logikę w osobnym backendzie, który jest wołany przez BFF. IMO BFF nie powinień robić żadnych walidacji biznesowych, bo to czy jest dobrze czy źle zależy od serwisu, który zarządza tym kawałkiem domeny.

Oczywiście zgadzam się, że może to powodować patologie takie jak mówisz, ale generalnie żadna architektura nie jest odporna na to, że ludzie robią syf