Czy filtrować dane wyszukiwarki po stronie frontu czy na serwerze?

Czy implementując wyszukiwarkę na froncie najlepiej pobrać na starcie wszystkie dane i potem to filtrować czy lepiej po wpisaniu frazy w wyszukiwarce robić strzał do api ?

1. Jeśli chce zrobić wyszukiwarkę na froncie to czy lepiej najpierw pobrać wszystkie dane i jeśli użytkownik wpiszę jakąś frazę w wyszukiwarce to po prostu filtrować po tych danych na froncie ?
2. Czy może jeśli chce zrobić wyszukiwarkę na froncie to po wpisaniu jakiejś frazy przez usera w wyszukiwarce robić za każdym razem strzał do api i pobierać przefiltrowane dane ?

A co ta wyszukiwarka ma robić?
Przykład 1) - mamy 50 wierszy do przeszukania, każdy zawiera jedno słowo i szukamy dokładnego odwzorowania. Wtedy łatwiej pewnie pobrać wszystkie i filtrować na froncie.
Przykład 2) Mamy 2000 wierszy z tekstem po 100 słów każdy i szukamy wystąpień kliku słów w jednym wierszu.

sajek587 napisał(a):

Czy implementując wyszukiwarkę na froncie najlepiej pobrać na starcie wszystkie dane i potem to filtrować (...) ?

XD A jak masz 10GB danych to co zrobisz XD A 10GB to nie są największe bazy jakie widziałem w życiu. Co powiesz o bazie wszystkich PESELi w urzedzie? Też będziesz pchać na front dane 38 milionów żyjących obywateli?

Oczywiście jak masz 10 zwierzątek do odfiltrowania to możesz zrobić to sobie na froncie. Może nawet będzie szybciej :P

Ok, czyli jak malo danych to filtrowac na froncie, a jak dużo to po backendzie. Dzięki.

Front jest od wyświetlania danych. Backend jest od obliczen.

sajek587 napisał(a):

Czy implementując wyszukiwarkę na froncie najlepiej pobrać na starcie wszystkie dane i potem to filtrować czy lepiej po wpisaniu frazy w wyszukiwarce robić strzał do api ?

1. Jeśli chce zrobić wyszukiwarkę na froncie to czy lepiej najpierw pobrać wszystkie dane i jeśli użytkownik wpiszę jakąś frazę w wyszukiwarce to po prostu filtrować po tych danych na froncie ?
2. Czy może jeśli chce zrobić wyszukiwarkę na froncie to po wpisaniu jakiejś frazy przez usera w wyszukiwarce robić za każdym razem strzał do api i pobierać przefiltrowane dane ?

Zrób najprostsze rozwiązanie, a potem je aktualizuj względem potrzeb.

Pewnie tworzysz małą aplikację, więc zacznij od wczytania po prostu wszystkich danych, najprościej jak się da. Jak zaczniesz zauważać problemy z wydajnością - dane się zbyt długo ładują, i aplikacja potem wolniej działa, wtedy zacznij dzielić te dane, najpierw na pól, potem na strony, etc.

KISS.

Ostatecznie, jedyny powód czemu miałbyś nie wysłać wszystkich danych do klienta na raz to performance. Jeśli nie masz problemu z nim, to wyślij na raz.

ledi12 napisał(a):

Front jest od wyświetlania danych. Backend jest od obliczen.

To chyba za duże uproszczenie, i poza nielicznymi wyjątkami raczej nie ma sensu.

Front to po prostu część aplikacji działająca u klienta, a backend to część aplikacji działająca u dostawcy (czyt. "na serwerze"). Takie uproszczenia jak "jedno jest od tego, a drugie od tego" nie są specjalnie ani pomocne ani prawdziwe.

Jeśli przyjmiemy tezę "Backend jest od obliczeń", to SSR nie ma sensu. Jeśli przyjmiemy że "Frontend jest od wyświetlania danych", to edytory, IDE, i edytory 3d na froncie nie mają sensu, front-only kalulatory nie mają sensu, prawda?

Jak mówiłem, takie upraszczanie bez kontekstu to zła droga.

To jest dość skomplikowane, to zależy jak backend zbudujesz.

Wiesz możesz jakimś hashem wyszukiwać lub możesz po literze i każda litera wprowadza do innego wiaderka.

każde rozwiązanie ma swoje problemy.

sajek587 napisał(a):

Ok, czyli jak malo danych to filtrowac na froncie, a jak dużo to po backendzie. Dzięki.

Acha.
A jak jest mało danych, ale często się zmieniają to co wtedy?
Będziesz za każdym razem pobierał wszystko z API a potem filtrował na froncie?

wloochacz napisał(a):

sajek587 napisał(a):

Ok, czyli jak malo danych to filtrowac na froncie, a jak dużo to po backendzie. Dzięki.

Acha.
A jak jest mało danych, ale często się zmieniają to co wtedy?
Będziesz za każdym razem pobierał wszystko z API a potem filtrował na froncie?

Jest jakiś powód żeby tego nie robić, oprócz performance?

Filtrowanie po stronie wyszukiwarki ma dużo sensu, bo działa dużo szybciej. Do tego odciąża backend. Przykładowo jak masz 100 produktów w sklepie a klient bawi się mocno różnymi filtrami to możesz mieć sytuację, gdzie masz 1 zapytanie po 100 elementów vs 10 zapytań, gdzie łącznie zwrocono ich 500.

Nie ma reguły, do każdego przypadku najlepiej podejść z osobna.

Jest jeszcze jeden aspekt, o którym chyba nikt nie wspomniał (albo przeoczyłem) - kwestia bezpieczeństwa danych.

Jak filtrujesz na serwerze to można niektóre rzeczy usunąć bo dany user nie ma uprawnień - np. wyświetlając listę pracowników, pokazujesz tylko z danego działu/firmy, a nie wszystkich ludzi, których masz w bazie. Czy zamówienia - dajesz tylko zamówienia, które są aktywne, albo przypisane do danego klienta.
Robiąc filtrowanie 100% na froncie, pomijając kwestie wydajnościowe, może się zdarzyć, że do przeglądarki trafią jakieś rzeczy, które nie powinny. Wprawdzie powinny one zostać przed użytkownikiem ukryte jakimś skryptem, który te dane obrobi i pokaże tylko to, co user ma widzieć, ale nie da się wykluczyć, że ktoś się do nich dobierze. Bo wszystko, co trafia do przeglądarki, da się (z mniejszym lub większym kłopotem) odczytać/pobrać.

Także i tak, nawet jeśli chcesz przesyłać pakiet danych do przeglądarki i tam je obrabiać, jest duża szansa, że i tak jakieś filtrowanie po stronie serwera musi zostać zastosowane.