Filtrowanie danych z bazy - spring boot + react

Question

Hej, piszę aplikację full-stackową kotlin + spring boot + react. Jednym z use-case`ów jest filtrowanie danych.

Po stronie backendu chciałbym użyć Criteria Api, co da mi większą elastyczność w budowaniu zapytań. I teraz zastanawiam się jak zbudować controller. Czy użyć request params do każdego możliwego filtra (jest ich około 7), czy zrobić jeden obiekt FilterBody jako @RequestBody i tam wrzucać wszystkie filtry jakie użytkownik wyklika na frontendzie. 

Jakie są wady i zalety tych rozwiązań? Jeśli macie jakieś doświadczenia produkcyjno/devowo to chętnie wysłucham.
 

Answer 1

Totalnie nie w tą stronę poszedłeś: 
Filtry - które ktoś wybiera np. użytkownik (jak napisałeś) po stronie interfejsu i tzw. stronie klienckiej, twoja aplikacja - traktuje jako DANE tylko i wyłącznie, tzn. są to "funkcje", dane obiektu, elementy zapytania które potem mają być przetwarzane.

Bez znaczenia czy przekażesz je jako RequestParam, czy jako RequestBody etc. dalej masz do czynienia z oczekiwanym obiektem"  który ma mieć, oczekiwane, wybrane właściwości".

Teraz jedyna rola jaka spoczywa na Controlerze ( zależy od architektury ) to VALIDACJA czy obiekt jest zgodny z oczekiwanym ( czy posiada wymagane pola, odpowiedni format itd). I teraz jeśli  zależnie od architektury- korzystasz z podziału na Controlery i Serwisy - to wtedy LOGIKA BIZNESOWA - czyli walidacja dokładnie tych danych powinna mieć miejsce w Serwisach, natomiast sam Controler może walidować tylko parametry zapytania ( czy posiada odpowiedni obiekt i wypełnione pola, bez wglądu na to czy pola sa prawidlowe czy nie), oraz Controler moze sprawdzać czy - nagłówki są okej, czy klient ma takie i nie inne funkcje ( czyli autoryzacja i identyfikacja uzytkownika sesji).

Dalej ... idąc ostatnim punktem który realizujesz to walidacja filtrów czy są takie i wybrane w Serwisie a dalej jedynie to już kwestia  przesłania ich i zbudowania odpowiedniego zapytania do bazy z poziomu Serwisu ( logiki biznesowej).

Baza danych ma miec juz w calosci przygotowane zapytanie i nie potrzebuje walidacji a wręcz nie powinna. 

To jak zbierzesz filtry, czy wykorzystasz  Criteria Api,( które jest okej, ale nie jest bez wad), czy może skorzystasz z Natywnych Query i sam będziesz budował czy nawet spróbujesz użyć SPECYFIKACJI, które są bardzo wadliwe jeśli nie są dobrze przygotowane dane i dobrze zbudowana struktura Encji 
https://spring.io/blog/2011/04/26/advanced-spring-data-jpa-specifications-and-querydsl/.

Wady i zalety są każdych rozwiązań, nie ma lepszego i gorszego jak na razie rozwiązania o ile nie powoduje ono dodatkowych implementacji funkcji ( komplikowania kodu, tworzenia SILNYCH POWIĄZAŃ MIEDZY KLASAMI ITP).
A co do doświadczenia: to wszystko zależy od FLOW projektu i architektury którą zastosowałeś: tak aby trzymać się jednolitych rozwiązań i spójności.

Istotnie niewielkie różnice w implementacji rzeczy Controler vs Swerwis mogą mieć istotny wpływ na jakość/trudność i performance pisania testów w przyszłości