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?
0
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
{{ osoba.waga/(osoba.wzrost*osoba.wzrost) }}
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.
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.
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ć.
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.
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.
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 :)
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)