Tworzenie endpointów REST API pod konkretny FrontEnd - jaką przyjąć strategie?

Question

Witam, sytuacja jest taka: Chcę stworzyć todolistę.
Chcę rozdzielić frątasia od bakusia. Front jako projekt MVC, backend jako .net 6 Web API w architekturze cebuli, wykorzystujące biblioteke MediatR.
Mamy takie entity:

TodoTask - pojedyńcze zadanie;

TodoList - lista zadań (TodoLista w todo liscie brzmi dziwnie ale myślę że każdy rozumie).
Pytanie: Mamy powiedzmy stronę główną apki MVC. Chce by pokazywała ona:

class TodoList {string name, int id, ICollection<TodoTask> Tasks}
class TodoItem {string taskDescription, int id}

Zawartość ostatniej stworzonej listy, samą nazwe tej listy w H1, i select htmlowski do wyboru innych list jakie możemy wybrać.
Widzę dwa podejścia do stworzenia mojego api:
1. Robie tylko i wyłącznie podstawowe endpointy dla moich entity
/api/todolists/newest/populated/- takie query zwróci TodoListName, i kolekcje TodoTask'ów najświeższej listy, które są przypisane do takowej listy.
/api/todolists - takie query zwróci wszystkie todolisty usera, bez include'ów na todoitemy tej listy, pomińmy teraz kwestie userów.
Controller apki MVC, przy zapytaniu na jego Homepage View, zrobi dwa requesty do api, /api/todolists by mieć id/name dla selecta list, oraz /api/todolist/newest/populated, by móc pokazać wszystkie taski usera w najnowszej liście.

Oczywiście endpointów by było o wiele więcej ale myślę że wiadomo o co chodzi.

Kolejny sposób który mam w głowie na ten problem:
stworzyć w api endpoint GET:

/api/home

jako że mamy MediatR w API, stworzymy ViewModel:
GetHomeVm{ ICollection<TodoListDto> Lists; TodoListDto NewestList}
GetHomeTodoListDto{ICollection<GetHomeTodoListTodoItemDto> ListItems, int id, string name}
GetHomeTodoListTodoItemDto{int id, string taskDescription}

Tworzymy w tym podejściu jeden endpoint per jeden View MVC. Wtedy controller mvc wykonuje tylko jeden request do api, by dostać dane dla tego view, dla jakiego potrzebuje

Które podejście powinienem obrać? Jak się rozwiązuje takie problemy w dużych aplikacjach w firmach?

Pozdrawiam, smacznego jajka w te wielkanoc wszystkim :)

Answer 1

Przede wszystkim nie wiem jaki masz problem, bo front-end i backend zwykle jest sam z siebie rozdzielony, jeśli tworzysz tym bardziej REST api, to w naturze rest api, powinieneś być stateless, jeśli nie jesteś i dalej potrzebny Ci jest stan, to mamy problem.

Front jako projekt MVC, MVC to nie jest model front endowy tylko model aplikacji webowej, więc wyobraź sobie że modelem jest backend.
Co to za podejście 1do1, to przeczy samej logice MVC gdzie to właśnie rolą Kontrolera jest dostosowanie tego co pośredniczy między modelem a widokiem, aby w odpowiedzi z widoku do modelu, i z modelu do widoku być wstanie konkretnie kontrolować przepływ aplikacji.

Endpoint powinien jednoznacznie być związany z ZASOBEM, to nie jest coś co powinno mieć określony stan czy zachowanie, powinno być związane z tym konkretnym i jednym resource, bez względu na pozostałe. 
 

Controller apki MVC, przy zapytaniu na jego Homepage View, zrobi dwa requesty do api, /api/todolists by mieć id/name dla selecta list, oraz /api/todolist/newest/populated, by móc pokazać wszystkie taski usera w najnowszej liście.

takie coś mógłbyś rozwiązać w ramach 1 REQUESTA do jakiegoś load-balancera albo w postaci też API Gateway ( przyczym API Gatwey, jeśli zalezy Ci na tym, aby integralność i bezpieczeństwo pomiędzy resource została zachowana i nie można było odpytać z niepoprawnej ścieżki do wskazanego modelu), która na podstawie "ścieżki, path" bez względu na domenę po konkretnym resourec będzie  rozdzielać request do odpowiedniego modelu itd, skąd potem zwrócone zostaną dane i jednocześnie 1 request do strony widoku, użytkownika końcowego.
Samo też api gatewey może byc jako dyrektywna rozdzielać i równoważąc 2 OSOBNE ENDPOINTY do 2 osobnych MODELi, natomiast load balancer sam w sobie równoważyć requesty dla pojedynczego endpointu. 


Możesz pomyśleć o np. stream processing i wtedy  jesteś wstanie to robić równolegle, jeśli np zależy Ci na czasie reakcji względem klienta.

 Dlaczego load-balancer? Wybraź sobie, że ktoś zrobi 3-4, 10 razy zaraz po sobie request na 1 twój model z 2 requestami jak wspomniałeś? Dla 1-2-3 to jakies 2-4-6 requestów, natomiast dla 10, to już 29... dlatego load balancer pomoże Ci np wykorzystać cache dla requestów. 

Comments

Bardzo wartościowa odpowiedź, dzięki. Niby rzeczy z pierwszych trzech rzeczy są oczywiste ale mimo wszystko jak się za mało wie i za dużo myśli to jakoś to ucieka. Natomiast trzy ostatnie akapity to dużo nowych tematów do ogarnięcia, których mimo wszystko nigdzie wcześniej nie zauważyłem. Dzięki śliczne jeszcze raz!