Rozdzielenie front-endu od back-endu

Rozdzielenie front-endu od back-endu
TJ
  • Rejestracja:ponad 9 lat
  • Ostatnio:ponad 5 lat
  • Postów:35
0

Witam

Chciałbym połączyć Spring Boot + Angular i zastanawiam się nad jedną rzeczą:

Zakładamy, że mamy jakiś tam mapping, który zwraca Usera w postaci JSON. I czy funkcja np. obliczająca BMI powinna być robiona po stronie Spring Boot czy Angular?

edytowany 1x, ostatnio: toJaMichal
CountZero
  • Rejestracja:prawie 8 lat
  • Ostatnio:12 miesięcy
  • Postów:262
0

Wzór na BMI to:
BMI = masa ciała (kg) / wzrost (m)². I specjalnie po to będziesz robił oddzielne zapytania by to liczyć?

W Angularze to przecież można nawet policzyć wyrażeniem

Kopiuj
{{ osoba.waga/(osoba.wzrost*osoba.wzrost) }}
edytowany 1x, ostatnio: CountZero
TJ
  • Rejestracja:ponad 9 lat
  • Ostatnio:ponad 5 lat
  • Postów:35
0

Wiem jaki jest wzór :) Chodziło mi bardziej o to, jak bardzo powinniśmy się trzymać tego co robi back-end, a co robi front-end. Większość obliczeń można zrobić w angularze, ale czy się tak robi? Chodzi mi o ogólne zasady typu:
Co można zrobić w angularze, rób w angularze albo na odwrót.

edytowany 1x, ostatnio: toJaMichal
Shalom
  • Rejestracja:ponad 21 lat
  • Ostatnio:około 3 lata
  • Lokalizacja:Space: the final frontier
  • Postów:26433
0

Wszystko we froncie! A potem sie człowiek dziwi ze jedna zakładka w FF zjada 3GB i muli tak ze jeden klik wykonuje się 5 minut, a cała stronka pobiera 100MB javascriptu zanim wyświetli cokolwiek.


"Nie brookliński most, ale przemienić w jasny, nowy dzień najsmutniejszą noc - to jest dopiero coś!"
CountZero
  • Rejestracja:prawie 8 lat
  • Ostatnio:12 miesięcy
  • Postów:262
0
toJaMichal napisał(a):

Wiem jaki jest wzór :) Chodziło mi bardziej o to, jak bardzo powinniśmy się trzymać tego co robi back-end, a co robi front-end. Większość obliczeń można zrobić w angularze, ale czy się tak robi? Chodzi mi o ogólne zasady typu:
Co można zrobić w angularze, rób w angularze albo na odwrót.

Takich zasad to wątpię by było dużo, bo to wszystko zależy. Akurat według mnie przykład który podałeś jest tak mało znaczący, że możesz to w backendzie policzyć i wysłać, lub zrobić to na stronie. Chociaż Shalom ma o tyle racji, że im mniej liczenia na stronie tym lepiej. Na początku myślałem, ze chciałbyś robić osobne zapytanie by to liczyć.

shagrin
  • Rejestracja:około 17 lat
  • Ostatnio:ponad 6 lat
  • Lokalizacja:Norwegia, Stavanger
1

Wg mnie, jeśli masz dane, żeby tę informację przesłać razem z danymi użytkownika, zrób to w backendzie. Trochę bez sensu (jeśli w danych użytkownika masz wzrost i wagę) wysyłać to do frontu i tam liczyć.
Jeśli użytkownik wprowadzi nową masę ciała, wysyłasz PUT do backendu i w odpowiedzi możesz zwrócić zaktualizowane dane użytkownika.

Jeśli to miałoby być na zasadzie zwykłego kalkulatora, gdzie nie zapisujesz danych, wtedy raczej rozsądne byłoby robić to obliczenie we froncie.


Wibowit
  • Rejestracja:około 20 lat
  • Ostatnio:około 9 godzin
0
toJaMichal napisał(a):

Wiem jaki jest wzór :) Chodziło mi bardziej o to, jak bardzo powinniśmy się trzymać tego co robi back-end, a co robi front-end. Większość obliczeń można zrobić w angularze, ale czy się tak robi? Chodzi mi o ogólne zasady typu:
Co można zrobić w angularze, rób w angularze albo na odwrót.

Rzadko kiedy prostymi zasadami da się rozwiązać upierdliwe problemy. Jednak jeśli chodzi o rozdział backendu i frontendu to jest pewna bardzo ważna i prosta zasada - nie wolno wysyłać do użytkownika danych do których nie powinien mieć dostępu. A więc jeśli np backend zwraca listę tajnych kontraktów to filtrowanie ich powinno zostać zrobione na serwerze przed wysłaniem do użytkownika. Gdyby filtrowaniem zajmował się kod po stronie przeglądarki to jakiś sprytniejszy użytkownik mógłby obejść zabezpieczenia i dostać się do cudzych prywatnych danych.

Kwestia wydajnościowa powinna grać rolę wtedy kiedy jest oczywista i/ lub kiedy nie zwiększa kosztów utrzymania. W twoim przykładzie policzenie BMI w miejscu (tzn za pomocą JavaScripta) będzie dużo tańsze niż robienie zapytania do serwera. Jednocześnie uniknięcie zapytania do serwera oznacza też tutaj znacznie mniej kodu do napisania. Wniosek jest więc oczywisty - opłaca się liczyć BMI po stronie przeglądarki. W innych przypadkach rachunek zysków i kosztów mógłby być jednak zupełnie inny.


"Programs must be written for people to read, and only incidentally for machines to execute." - Abelson & Sussman, SICP, preface to the first edition
"Ci, co najbardziej pragną planować życie społeczne, gdyby im na to pozwolić, staliby się w najwyższym stopniu niebezpieczni i nietolerancyjni wobec planów życiowych innych ludzi. Często, tchnącego dobrocią i oddanego jakiejś sprawie idealistę, dzieli od fanatyka tylko mały krok."
Demokracja jest fajna, dopóki wygrywa twoja ulubiona partia.
edytowany 2x, ostatnio: Wibowit
W0
  • Rejestracja:ponad 12 lat
  • Ostatnio:6 minut
  • Postów:3613
0

Tak jak tutaj napisano - wszystko rozbija się o skalę.

Jeśli twoja apka ma tylko jeden taki wskaźnik to pomysł @shagrin jest jak najbardziej na miejscu.
Jeśli twoja apka ma osiemdziesiąt różnych wzorów na liczenie wskaźników w zależności od masy ciała i wzrostu to tutaj bym się zastanowił dwa razy jak do tego usiąść.

0

W czasach SPA z middleware'u można zrobić taką cienką warstwę integracyjną pomiędzy HTTP i bazą danych :)

Wibowit
  • Rejestracja:około 20 lat
  • Ostatnio:około 9 godzin
0

O ile dobrze zrozumiałem ideę https://en.wikipedia.org/wiki/GraphQL to w zasadzie jest to biblioteka, która pozwala sklejać zapytania do bazy już na poziomie GUI. Teoretycznie można by więc zastąpić każdy backend jednym gotowcem i pchać całą logikę do frontendu. Ale pewnie czegoś nie zrozumiałem... (nie wgłębiałem się w tego GraphQLa)


"Programs must be written for people to read, and only incidentally for machines to execute." - Abelson & Sussman, SICP, preface to the first edition
"Ci, co najbardziej pragną planować życie społeczne, gdyby im na to pozwolić, staliby się w najwyższym stopniu niebezpieczni i nietolerancyjni wobec planów życiowych innych ludzi. Często, tchnącego dobrocią i oddanego jakiejś sprawie idealistę, dzieli od fanatyka tylko mały krok."
Demokracja jest fajna, dopóki wygrywa twoja ulubiona partia.
edytowany 1x, ostatnio: Wibowit
shagrin
Klient definiuje co chce (jakie dane) pobrac, to nie jest to samo co pchanie wszystkiego do frontu o.O
Wibowit
No więc teoretycznie można zrobić kilka szablonów zapytań zwracających całe tabele, a potem na podstawie GraphQLa wywalać wyciągane pola z zapytania SQL. Backend się wtedy odchudza.

Zarejestruj się i dołącz do największej społeczności programistów w Polsce.

Otrzymaj wsparcie, dziel się wiedzą i rozwijaj swoje umiejętności z najlepszymi.