Co backend ma zwracać na frontent

Baza wygląda tak:

dbo.book
| id | title           | price | genre_id |
|----|-----------------|-------|----------|
| 1  | Scary book      | 52    | 2        |
| 2  | Game of thrones | 70    | 1        |


dbo.genre
| id | name    |
|----|---------|
| 1  | Fantasy |
| 2  | Horror  |

Mam podział na BE/FE. Chciałbym wyświetlić na froncie listę:

• nazwa książki
• cena
• nazwa kategorii

Czy w takim razie BE powinien zwrócić coś takiego:

/api/books
[
    {
		"title": "Scary book",
		"price": 52
        "genre": "Horror"
    },
    {
		"title": "Game of thrones",
		"price": 70
        "genre": "Fantasy"
    }
]

Czy może FE powinien osobno odpytać o książki i gatunki, i złączyć dane dopiero na froncie?

/api/books
[
    {
		"title": "Scary book",
		"price": 52
        "genreId": "2"
    },
    {
		"title": "Game of thrones",
		"price": 70
        "genreId": "1"
    }
]

/api/genres
[
    {
		"id": 1,
		"name": "Horror"
    },
    {
		"id": 2,
		"name": "Fantasy"
    }
]

Nie wiem co chcesz osiągnąć, ale łączenie zapytań po stronie backendu w SQL albo innym ORM-ie jest zwykle wydajniejsze, choć czasem stosuje się takie zabiegi optymalizacyjne jak pracujemy na ogromnych zbiorach danych co w twoim przypadku nie występuje, więc zrób jak cywilizowany człowiek INNER JOINa dwóch tabel Book i Genres, zmapuj na DTO i będzie git.

Co backend ma zwracać na frontent

Jak najmniej w jak najmniejszej ilości requestów. Najlepiej żeby wszystko łaczyła baza

Jeśli zwracasz tylko w celu wyświetlenia to lepiej pierwsza wersja. Ale jeśli np chcesz edytować i potrzebujesz jakieś Comboboxy i mieć tam dane to wersja 2 ale bez łączenia tylko osobno dane do edycji a osobno dane (genres) do comboboxa

Z punktu widzenia:

• Dependency inversion: Front nawet nie powinien wiedzieć że jest coś takiego jak baza, więc powinien dostać gotowe sklejone rzeczy
• Performance: Mniej zapytań jest lepsze niż więcej, więc jeśli możesz to zrobić w jednym zapytaniu - to zrób to
• Separation of concerns: jeśli mówisz że masz podział na BE i FE, to jakim niby cudem jesteś w stanie wysłac dane i połączyć je na froncie? Żeby móc to zrobić, to właśnie musiałbyś je mieć nie oddzielone. Ergo - jeśli faktycznie chcesz mieć je oddzielone, to musisz to sklepić na backendzie - informacje domenowe. Jeśli musisz zrobić jakieś transformacje frontowe, jak np formatowanie daty, to zrób to na froncie

Swoją drogą

Co backend ma zwracać na frontent

"frontent" to jakaś nowa libka o której nie słyszałem?

Czy chodzi o to że Drzewiec samo w niej programuje,

Podział na front i backend to warstwy w rozumieniu Layered Architecture. Tutaj najważniejsza korzyść jaka jest i jakiej w przypadku tego projektu nie będzie Ci dane poczuć to fakt, że warstwa dolna nie jest zależna od warstwy górnej.

To podejście jest zabójczo skuteczne, gdy warstwa dolna jest abstrakcją/infrastrukturą i nie ma logiki biznesowej. Znany przykład model sieciowy ISO i mniej znany np. couchdb, który jest serwerem na http, wystawiający usługę z restowym api do bazy danych. Obie te rzeczy działają niezależnie czy dziś kodujesz intragrama wioślarzy, czy apkę do sprzedawania bułek.

Jeśli jednak warstwa dolna ma biznesową logikę to naturalnie masz tracisz najważniejsze korzyści, ponieważ każda zmiana takiej logiki w warstwie dolnej niesie ryzyko popsucia kompatybilności z górnymi warstwami. Dopóki nie opracujesz metody na pisanie logiki biznesowej (w dolnej warstwie), która w przyszłości się w ogóle nie zmienia, to ciągle będziesz na straconej pozycji.

Jeśli nie masz wyboru i musisz w tym trwać. To jedyne co możesz zrobić to wyłącznie ograniczać poniesione straty poprzez ograniczenie interakcji z endpointami. Inaczej mówiąc, im więcej masz interakcji tym więcej punktów zapalnych prowadzących do rozjazdu. Tu rozdrobnienie Ci nie służy, bo to co podzielisz to wciąż będą modele jakie nadal mają prawo się zmieniać pod wpływem zmiany wymagań.

Koszty interakcji/komunikacji najłatwiej jest zniwelować nie doprowadzając do niej.

Czyli jak masz dwie części kodu A (na serwerze) i B (w przegladarce), to postaraj się, aby nie było długiej wymiany ping-ponga miedzy A i B, lecz niech B zleci robotę dla A i niech A udostępni B tylko te wyniki, które rzeczywiście B rzeczywiście wymaga.

Zalezy od przypadku uzycia - jak napisal @szydlak. Dodam jedynie ze jesli konkretne przypadki uzycia sa nie znane lub bardzo ogolne (np. bedzie to API dla wielu klientow) to tym bardziej przemawia to za opcja 2 bo jest bardziej elastyczna.

znowutosamo4 napisał(a):

Podział na front i backend to warstwy w rozumieniu Layered Architecture. Tutaj najważniejsza korzyść jaka jest i jakiej w przypadku tego projektu nie będzie Ci dane poczuć to fakt, że warstwa dolna nie jest zależna od warstwy górnej.

.. i ...

To podejście jest zabójczo skuteczne, gdy warstwa dolna jest abstrakcją/infrastrukturą i nie ma logiki biznesowej. Znany przykład model sieciowy ISO i mniej znany np. couchdb, który jest serwerem na http, wystawiający usługę z restowym api do bazy danych. Obie te rzeczy działają niezależnie czy dziś kodujesz intragrama wioślarzy, czy apkę do sprzedawania bułek.

Jeśli jednak warstwa dolna ma biznesową logikę to naturalnie masz tracisz najważniejsze korzyści, ponieważ każda zmiana takiej logiki w warstwie dolnej niesie ryzyko popsucia kompatybilności z górnymi warstwami. Dopóki nie opracujesz metody na pisanie logiki biznesowej (w dolnej warstwie), która w przyszłości się w ogóle nie zmienia, to ciągle będziesz na straconej pozycji.

Dosłowne czytanie tego co napisałeś daje jasny wniosek: zasady biznesowe koduj we frontendzie.
Chcesz coś skorygować?

Trafnie ujęte i tak byłoby najlepiej, ale na ten moment jesteśmy jeszcze w średniowieczu. Na plus jest to, że to coraz bardziej widać i mamy technologiach próby, aby chociaż dostęp do danych zrzucić na front przez graphql lub pouchdb, lub by bazować na izomorficznym kodzie, ale w tym wszystkim nadal jest pełno limitów i nie można obiema nogami być na jednej ze stron. Na razie najbardziej obiecującą pracę widzę tutaj: https://github.com/hyperfiddle/electric