Sortowanie, walidacja, filtrowanie - po stronie serwera czy po stronie klienta (wady i zalety)

Witam.
Ogólnie to nie piszę z pytaniem , która część aplikacji powinna się tym zajmować, ponieważ najprawdopodobniej znam odpowiedź (serwer). Pytam jakie są zalety/wady wymienionych w tytule operacji robiąc je serwerem i/lub klientem? Zauważyłem, że sporo systemów podchodzi do problemu "serwerowo", ale... Na przykład taki Angular Material do swoich tabel daje sortowanie i filtrowanie. Skoro mam narzędzia i odpowiednie funkcje to po co robić to dwa razy? Walidację można ogarnąć korzystając z FormGroup oraz FormControl. Jeśli dobrze to obsłużymy po stronie klienta to nie potrzebuje FluentValidation i innych tego typu bibliotek po stronie serwera? Poszedłbym nawet jeszcze dalej i nie przejmował się nullami w bazie, bo nigdy ich nie będzie :-) tak, wiem, przegiąłem.

Piszę o Angularze, ponieważ tylko w nim mam doświadczenie. Pytanie tyczy się projektów gdzie piszemy klienta do własnego API. Projekty (WebAPI), które są dostępne publicznie muszą obsługiwać te opcje. Jak to jest u was?

A jakbyś wykonał sortowanie na kliencie mając paginacje rekordów?

To nie jest alternatywa wykluczająca, z reguły pożądana jest jakaś kombinacja jednego i drugiego. W szczególności walidacja musi być przeprowadzana zarówno na froncie jak i na backendzie. Na froncie daje natychmiastowy feedback dla użytkownika, który wie co zrobił nie tak, na backendzie zapewnia, że dane są spójne i poprawne.

Brak walidacji na backendzie, bo walidacja jest na froncie to naiwność programisty.

@szydlak Przecież w Angularze to działa. Najprawdopodobniej sortuje całą listę danych i dzieli na strony. Jaki problem?

@Saalin To ja nie mogę zapewnić poprawnych i spójnych danych z frontu, a dodatkowo mieć natychmiastowy feedback dla użytkownika?

Że jak Ci się uzbiera setki rekordów to jest lipa na froncie. Tzn chodzi mi o to, żeby nie zaciągać wszystkiego tylko partiami raczej

AdamWox napisał(a):

@Saalin To ja nie mogę zapewnić poprawnych i spójnych danych z frontu, a dodatkowo mieć natychmiastowy feedback dla użytkownika?

A co jeśli ktoś wyśle goły request pomijając front? Albo JavaScripty wysypią się na jakimś wyjątku i walidacja po prostu nie zadziała?

AdamWox napisał(a):

@szydlak Przecież w Angularze to działa. Najprawdopodobniej sortuje całą listę danych i dzieli na strony. Jaki problem?

@AdamWox co w przypadku jeżeli serwer zwróci Ci dużą ilość rekordów? Po co pobierać wszystko od razu? Wtedy paginacja sprawdza się idealnie.

nie no jasne, możesz nawet nie sprawdzać uprawnień usera, no bo po co dodatkowe zapytania do bazy czy tiki procesora hehe

ale ktoś Ci może zrobić psikusa i trudno Ci się będzie z tego wytłumaczyć

Performance over Security - Intel, 1999 czy jakoś tak :D :D

Podłączę się do wątku:
Czy w takich dwuwarstwowych aplikacjach z angularem są jakieś metody, aby po aktualizacji reguł biznesowych *) (oczywiście w backendzie), na froncie zasady walidacji zaktualizowały się same?
Dwukrotne robienie tego samego, walidacji, to rak. Dziwię się, że tak rzadko dyskutowany. **)

*) rozumianych czy jako nowa wersja (nie powodująca przybywania pół na froncie), czy właściwości z repozytorium, np inna definicja dokumentu A i B.
**) realna scenka z życia: na froncie sklepu formatka kupującego w kilkunastoma polami. Imię nie jest na froncie wymagane. Po zatwierdzeniu leci wyjątek z MySQL że "kolumna imię jest wymagane not null". Pominę, że po wyjątku leci message "operacja zakończona poprawnie" :)
Skasować firmy nie mogę, bo "jej nie ma". Założyć jeszcze raz też nie, bo "już jest taki NIP". Poszedłem do konkurencji

Ja się nie upieram przy swoich spostrzeżeniach. Powiedzmy, że "głośno myślę".

@kobi55 Ilość załadowanych danych na raz może być problemem i tego obawiam się najbardziej. Chociaż zauważyłem, że załadowanie na czysto (bez paginacji) około 2000 rekordów jest sporo wolniejsze od załadowania tych samych 2000, ale z paginacją jaką domyślnie daje angular. Najprawdopodobniej to kwestia przeglądarki i renderowania każdego wiersza.

@WeiXiao Co do uprawnień usera to nie wiem czy dobrze rozumiem, ale jakoś mi to nie pasuje do tego problemu. Możesz rozwinąć?

@Saalin Nie zakładam gołych requestów w tym problemie. Tak jak pisałem na początku, API jest integralną częścią klienta, niedostępne publicznie. Działa tylko z tym frontem. W przypadku publicznych API to pytanie jest głupie. Co do wyjątków w JS, to właśnie to jest, między innymi, temat do dyskusji. Czy lepiej jest w pełni, full wypas, validation pro, obsłużyć po stronie klienta, czy to już strzał w kolano i dlaczego.

@AnyKtokolwiek Nie wiem czy dobrze rozumiem twój przykład. Co masz na myśli mówiąc "reguły biznesowe"? Jeśli na backendzie, na przykład, dodajesz nową kolumne, właściwość modelu, to walidację musiałbyś obsłużyć i napisać na froncie. Na backu to jest tylko nowe pole, kolumna. Zresztą, tak jak w przykładzie podałeś, dopisując tylko pole w klasie na backendzie nie spowoduje magicznie, że pojawi się na twoim froncie. Tzn, pewnie z requestem przyjdzie, ale ty nic z tym polem nie robisz póki tego nie napiszesz.

@AdamWox: Ty nie zakładasz gołych requestów, ale kto broni użytkownikowi zmodyfikować żądanie wysyłane przez Twój front? Np. w celu podniesienia uprawnień. Podejrzewam, że @WeiXiao miał coś podobnego na myśli.

Walidacja Backend + Front
* +Bezpieczna
* +UX
* -Jak zapomnisz przy zmianach zaktualizowac obie, to będzie słabo

Walidacja tylko Front
* +Mniej roboty, mniej mielenia na backendzie
* +UX
* -Szansa na uszkodzone, niespójne dane oraz ewentualnie jakiś leak

Walidacja tylko Backend
* +Mniej roboty na froncie
* +Bezpieczeństwo
* -UX

No chyba, że stosujesz bleeding edge tech. typu Blazor, to mógłbyś mieć te walidację zrobioną w jednym miejscu i korzystałby z niej i front i backend :-) W ogóle przy Blazorze to jest fajne, że możesz mieć modele IO używane przez front i backend

Jakakolwiek akcja wymagająca sprawdzenia uprawnień czy walidacji powinna być wykonywana po stronie serwera - tam gdzie użytkownik nie ma dostępu. Nie można nigdy wykluczyć że trafi się ktoś łebski i zrobi coś złego.

Filtrowanie po stronie frontendu - jakoś nie widzi mi się wysyłanie gigantycznej ilości danych po to, żeby sobie to filtrować i paginować w js.

AdamWox napisał(a):

W jaki sposób mógłby je zmodyfikować? W ogóle po co miałby to robić? Moim zdaniem niczego tym nie osiągnie. On nie ma praw do podnoszenia uprawnień. Mówimy o walidacji modelu, a nie uprawnień użytkownika.

Fiddlerem. Po co? Po nic, żeby popsuć rzeczy. Zmienić kwoty na ujemne na fakturze, whatever. A to czy niczego nie osiągnie to już jest bardzo dyskusyjna kwesta.

AdamWox napisał(a):

Poniosła was fantazja :-D Ktoś kto by potrafił to robić, nie korzystałby z mojego oprogramowania

Odbije Ci się czkawką takie podejście, bo nie trzeba być programistą, żeby nieświadomie wykorzystać błędy na froncie. Przykład z życia:

1. Użytkownik dodaje dokument przyjęcia towaru na magazyn. Dokument może mieć status zatwierdzony lub nie. W momencie zatwierdzania stan magazynu zostaje zwiększony o ilości z dokumentu.
2. Walidacja czy dokument jest zatwierdzony następuje tylko na froncie. Nie da się drugi raz zatwierdzić dokumentu.

Błąd: można otworzyć w dwóch oknach (lub przez dwóch użytkowników) niezatwierdzony dokument i go zatwierdzić. Stan magazynu zwiększa się dwukrotnie. Tak wygląda ta Twoja walidacja na froncie.

Poza tym niektórzy użytkownicy mogą przypadkiem znaleźć błąd i uważać go za hack, tak naprawdę rozwalający dane w systemie.

Znajomy kiedyś opowiadał jak działa walidacja implementowana wyłącznie w js. Pewien sklep sprzedawał elektronikę. Do sprzedaży weszły nowe wersje Playstation, nie pamiętam które ale to nieważne. Pewien sprytny użytkownik odpalił sobie debugger w przeglądarce i przeszedł przez ścieżkę zakupów. Na samym końcu ustawił cenę na 0 i puścił request dalej. Zamówienie przeszło.

Gość wysłał maila do sklepu opisując krok po kroku co zrobił. Właściciel zachował się bardzo słabo bo zamiast podziękować za znalezienie takiego krytycznego błędu (na przykład wysyłając mu tę konsolę) to pozwał go za hakowanie strony. A teraz wyobraź sobie co by się stało gdyby błąd takiego kalibru nie został wyłapany przez system ani człowieka przed wysyłką. Przy obecnym dążeniu do automatyzacji zdarza się, że ścieżka obsługi klienta nie ma praktycznie żadnego kontaktu z człowiekiem siedzącym w firmie jeśli ten sobie tego nie zażyczy albo procesowanie jego zamówienia wymaga jakiejś specjalnej obsługi.

To wcale nie są abstrakcyjne sprawy, ten przykład ze sklepem możesz sobie zamienić na cokolwiek innego - być może ktoś wyciągnie ci całą bazę klientów i sprzeda im swoje oprogramowanie taniej. Albo weźmie na nich wszystkich chwilówki, wyczyści im konta (bo ktoś się złapie na spreparowanego maila). Ciężko sobie wyobrazić każde możliwe zagrożenie, ale niestety ono jest bardzo realne.

Sortowanie i filtrowanie jak najbliżej bazy, więc na pewno nie na frontendzie.
Walidacja też na backendzie, bo to jest część logiki biznesowej. Walidacja na froncie jest w tym samym celu co front w ogólności - wyłącznie dla komfortu użytkownika.

Czyli podsumowując - przezorny zawsze ubezpieczony. Najlepiej postawić "tarczę" najbliżej źródła danych, a front walidować w ramach szybkiego poinformowania użytkownika o błędach podczas uzupełniania danych w formularzu, a nie po naciśnięciu guzika "zapisz".

Sortowanie to akurat w miarę prosta sprawa. Teraz pytanie, co z filtracją. Oczywiście pytam o szukajkę. Mając backendową paginację, po stronie klienta kiepsko szukać jakieś pozycji, ponieważ nie mamy na froncie całych danych. Co jeśli jesteśmy na piątej stronie i mamy posortowane dane po kwocie, a szukamy towarów np. kawa? Dane powinny dalej być posortowane? Skąd wiem, że są?

Przy pobieraniu danych backend powinien przyjmować definicję filtrowania i sortowania, więc jak użytkownik na frontendzie zaczyna filtrować, to frontend może wysłać reguły sortowania do backendu.

to chyba nie ten przypadek, ale walidacja na froncie pozwala uniknąć problemów zwiaznych z dużą liczbą jednoczesnych requestów,
przykład: ruszasz ze sprzedażą produktów, zakończenie sprzedaży wymaga podania imienia (wymagane, min 3 litery), nazwiska (ymagane, min 3 litery) i adresu e-mail (wymagane, adres e-mail)...
zamiast kilku tysięcy requestów w ciągu sekundy masz po kilkadziesiąt requestow na sekundę, rozciagnięte na kilkadziesiąt sekund, bo ludziku muszą wypełnić formularz i poprawic ewentualne błędy, imie "jan" pisze się szybciej niż "maciej" albo "mateusz", kilka osob pominie nazwisko etc etc....