Gdzie obecnie tworzy się więcej logiki? w Back-end czy Front-end ?

Gdzie jest więcej logiki związanej z funkcjonalnością strony/aplikacji? nie chodzi mi o zapytania GET/POST

Oczywiście Backend to sama logika. Jednak logika po stronie backendu skupia się wokół serwera i baz danych, czyli wokół poleceń POST i GET. W pewnym sensie jest to monotonne, poszczególne funkcje nie są jakoś złożone. Najważniejsza jest dobrze zaprojektowana architektura. Natomiast wydaje mi się, że w backend jest mniej logiki związanej z funkcjonalnością aplikacji niż po stronie Front-end. Czy zgadzacie się z tym ?

Coraz więcej logiki umieszczana jest po stronie front-end - Angular, Vue, React. Jak i coraz częściej w ofertach pracy dla Front-end'a wymagana jest znajomość "obiektowego" Javascriptu.
Czy to jest początkowy etap gdzie następuje rozgraniczenie między Webmasterem (koderem html/css) VS Front-end (koderem logiki po stronie front-end) ?

Kluczowa i najardziej złożona logika musi być po stronie backendu, ponieważ do frontu jest dostęp z zewnątrz i ktos może sobie js-y zmienić w przeglądarce. Czasami oczywiście ta "logika" to nie jest za bardzo logika tylko bardziej CRUD, ale nie zmienia to faktu że jak już jakas jest to w backendzie :)

Nie zgadzam się z tym, chyba że omawiamy relatywnie proste aplikacje. Każdy bardziej złożony system ma rozbudowany back end gdzie znajduje się logika biznesowa. Logika frontendu powinna skupiać się na widoku i komunikacji z backendem.

Trzeźwy Ogórek napisał(a):

Natomiast wydaje mi się, że w backend jest mniej logiki związanej z funkcjonalnością aplikacji niż po stronie Front-end. Czy zgadzacie się z tym ?

Masz rację. Wydaje Ci się.

Konieczna logika aplikacji jest po stronie backendu. Wyrzuć kod z frontu to nadal wszystko bedzie działać. Na dobrą sprawę z aplikacji możesz też korzystać wysyłając same requesty np. w terminalu. To po stronie backendu trzymany jest stan oraz operacje zmieniające ten stan - frontend tylko te operacje wywołuje.

Po stronie frontendu też jest logika, jednak jest ona mocno uzależniona od backendu i ogranicza się do boostowania UXa. Jeśli spróbujesz np. wymusić wyświetlenie strony dla zalogowanego usera, samemu będąc niezalogowanym, wtedy backend i tak pokaże kto tu rządzi.

Co innego, jakbyś zapytał o ilość kodu :) Backend prawie zawsze bazuje na frameworkach, ktore ograniczaja potrzebny do przeklepania kod i o ile nie budujesz systemu klasy enterprise to teraz coraz częściej się zdarza, że przy froncie trzeba więcej tego kodu przewalić.

Ostatnio musiałem dorobić do swojej aplikacji wizualizację połączeń za pomocą biblioteki Cytoscape.js. W pierwszym podejściu większość logiki umieściłem w kodzie strony. Ogólne dane były pobierane z programu i obrabiane za pomocą JS. Już podczas pisania kodu w JS stwierdziłem, że będzie źle bo kod szybko stał się mało czytelny i nad nim "nie panowałem". Niby wszystko działało poprawnie, ale jak pomyślałem, że za kilka miesięcy będę musiał coś w nim zmieniać tor robiło mi się słabo. Dlatego całą logikę przeniosłem do aplikacji , a do strony są przekazywane gotowe obrobione dane węzłów i połączeń. W JS zosta 10% poprzedniego kodu.

Logika biz. ze względów bezpieczeństwa nie powinna być na froncie.

Na chłopski rozum to najwięcej logiki będzie tam, gdzie jest najwięcej ifów. Piramidki ifów, switchy, zagnieżdżone wyrażenia or czy and - tam niewątpliwie jest logika XD Więc szukaj projektów ze spaghetti kodem.

Oczywiście Backend to sama logika. Jednak logika po stronie backendu skupia się wokół serwera i baz danych, czyli wokół poleceń POST i GET.

Odwoływania do serwera, baz danych, i polecenia GET, SET często określa się mianem nie logiki, a infrastruktury (warstwa niżej). No bo w końcu to są techniczne detale, a logiką mogą być raczej konkretne reguły, kiedy coś się powinno zapisać do bazy danych (a nie sam akt zapisania).

logiki związanej z funkcjonalnością strony/aplikacji?

Czy to nie jest takie masło-maślane? Wszystko jest jakąś funkcjonalnością (czy jak by chcieli puryści "funkcją") aplikacji. A jeśli za logikę przyjmiemy prawa i mechanizmy rządzące jakimiś zdarzeniami (bo chyba o to znaczenie "logiki" tu chodzi), to tak:

Otwierasz modal na stronie - jest to funkcja otwierania modala. To, że otworzysz ten modal w zdarzeniu onClick przycisku Otwórz Modal - jest to pewna logika, pewien mechanizm, który rządzi wyświetleniem modala.

Robisz efekt przejścia w CSS (np. zmiana koloru tekstu) - i ta zmiana koloru to jakaś funkcja aplikacji. To, że się odpali ten efekt po najechaniu myszą (:hover) jest to logika tej funkcji. Czyli logikę da się robić nawet w CSS, bez programowania.

Więc na froncie również że jest mnóstwo "logiki". Przenika ona wszystko i rządzi uniwersum ;)

Na froncie również będzie tzw. domain logic - załóżmy, że robimy sklep internetowy, to na froncie też będą obiekty typu Koszyk, Klient, Adres, Zamówienie, Faktura. Tyle, że i tak backend to wszystko potem zwaliduje. Na backendzie jest dużo magii, której nie ma na frontendzie (bo pewne rzeczy może zrobić tylko backend). Tak jak tutaj napisane:

Garen_eye napisał(a):

Wyrzuć kod z frontu to nadal wszystko bedzie działać. Na dobrą sprawę z aplikacji możesz też korzystać wysyłając same requesty np. w terminalu. To po stronie backendu trzymany jest stan oraz operacje zmieniające ten stan - frontend tylko te operacje wywołuje.

Myślę, że to zależy od aplikacji, ale w wielu przypadkach to na backendzie może być więcej tego typu logiki dziedzinowej.

Z drugiej strony logika całkowicie nie-dziedzinowa (np. jakieś nieistotne animacje na frontendzie) mogą być faktycznie ciekawsze niż pisanie nudnych reguł biznesowych. Zastanów się więc, o co pytasz.

Dzięki wszystkich za odpowiedzi. @LukeJL moje pytanie rzeczywiście jest troszkę nie jasne :) więc spróbuje doprecyzować swoje wątpliwości ;)

Tworząc projekt w technologii backend, najciekawszą i najbardziej wymagającą częścią jest dla mnie projektowanie samej architektury programu, tak aby wszystko ze sobą współgrało.
Następnie przechodząc do implementacji, następuje nudna część związana z pisaniem "szablonowych" klas, jak np. produkt. Moim zdaniem w backend piszę się dużo kodu w sposób mechaniczny, wręcz szablonowy, jak np. wcześniej wypomniane klasy typu "produkt", klasy połączeń baz danych, większość zapytań post/get, interfaces itp.
Raczej proste funkcje, związane z pozyskiwaniem lub zapisywaniem danych z/do bazy danych i przesyłaniem danych do widoku.
Moim zdaniem złożoność "logiki back-end" zależy od architektury. Natomiast niewiele jest logiki, gdzie trzeba zaprogramować funkcjonalność aplikacji na stronie.

"logika związana z funkcjonalnością aplikacji" - mam tutaj na myśli np. funkcjonalność pomidoro na stronie internetowej.
Wydaje mi się, że takie rzeczy jak pisanie małych/średnich aplikacji na stronie następuje po stronie Front-end, czy mam racje ?

Front-end to tylko sposób korzystania z back-end. To back-end jest podstawą aplikacji. Karoseria samochodu to front-end. Bank-end to cała mechanika wewnątrz samochodu. Równie dobrze na tę mechanikę możesz nałożyć inną karoserię, zmienić koła, a samochód dalej pojedzie. Strona internetowa to tylko jeden z rodzajów front-endu. Możesz przecież zrobić kolejny front - np. aplikacje mobilną lub desktopową. Nie musi działać tak samo jak strona internetowa. Np. na stronie masz formularz rejestracji ze wszystkimi polami od razu renderowanymi. Natomiast aplikacja mobilna może mieć proces rejestracji podzielony na kroki - gdzie w każdym kroku podajesz kolejne dane - no i dopiero w ostatnim kroku będziesz miał buttona wysyłającego request z prośbą o rejestracje użytkownika w takiej samej postaci, jak wysyła strona internetowa. Nie ważne, jaka logika jest po stronie front-endu. Ta po stronie back-endu jest konieczna, ta po stronie frontu nie jest konieczna. A gdzie jest jej więcej? Pewnie zależy od projektu, ale jakie to ma znaczenie?

sintloer napisał(a):

Front-end to tylko sposób korzystania z back-end. To back-end jest podstawą aplikacji. Karoseria samochodu to front-end.

Kolego, a słyszałeś o https://pl.wikipedia.org/wiki/Nadwozie_samono%C5%9Bne ?
:D
Front to tylko farba, kołpaki i antenka ;)

Trzeźwy Ogórek napisał(a):

Backend - funkcje związane z pozyskiwaniem lub zapisywaniem danych z/do bazy danych i przesyłaniem danych do widoku.
Moim zdaniem złożoność "logiki back-end" zależy od architektury. Natomiast niewiele jest logiki, gdzie trzeba zaprogramować funkcjonalność aplikacji na stronie.

"logika związana z funkcjonalnością aplikacji" - mam tutaj na myśli np. funkcjonalność pomidoro na stronie internetowej.
Wydaje mi się, że takie rzeczy jak pisanie małych/średnich aplikacji na stronie następuje po stronie Front-end, czy mam racje ?

Nikt nie odpowiedział na powyższe pytanie, więc rozumiem że się zgadzacie ;D
czyli w technologiach react, vue itd. tworzy się właśnie taką logikę ? czyli takie mini aplikacje na stronie? jak pomidoro

No czasami się zdarza że jest jakas prosta (żeby nie powiedziec prymitywna :D ) logika która można dać na frontendzie, bo zreszta po co ktos miałby kombinowac coś przy pomodoro? Ale na przykład kalkulator ceny w slepie to już musi być na backendzie, bo tak by można było podmienić na 0 zł :P Albo np. jakies obliczenia na takim wolfram alpa to ciężko byłoby w JS zrobić :D

Jeśli chcesz tworzyć logikę po stronie back-end i front-end to najlepszym rozwiązaniem będzie kombinacja Node.js (backend) i React.js (frontend)##

problem z logiką w JS jest jeszcze taki, że język ten związany jest ściśle z przeglądarkami. Aby mieć pewność, że wszystko będzie OK teoretycznie trzeba sprawdzić wyniki we wszystkich przeglądarkach bo czasami JS (i jego biblioteki) potrafią zrobić niemiły dowcip.

Zmieniam swoje pytanie ;D Gdzie jest trudniejsza logika ?
Backend - tak jak pisałem, gównie pobieranie i wysyłanie danych z bazy danych, przy pomocy GET/POST. Prosta funkcjonalność. Jakakolwiek trudność wynika z (niezrozumienia) architektury strony.
Frontend - React, Vue - nadal nie jestem pewny... co tam się robi od strony logiki... ktoś mi wyjaśni ? chodzi mi o popularne technologie frontendowe, jak react czy vue.

Trzeźwy Ogórek, Ty tak na serio z tym backendem od wysyłania danych z bazy? Nawet w prostych crudach backend robi znacznie więcej.
Jjak myślisz, gdzie jest zaimplementowana weryfikacja reguł biznesowych, gdzie odbywa się główny flow programu, gdzie przetwarza się zamówienia, nalicza płatności, generuje faktury, integruje z systemami płatności, z zewnętrznymi serwisami, bankami, gdzie jest security aplikacji? Na froncie?

Na Froncie głównie jesteś odpowiedzialny za to, co, kiedy, gdzie i jak ma się wyświetlić.

Jeżeli masz wyliczyć np. średnio wartość polisy OC z miliona wpisanych do bazy możesz to zrobić bezpośrednio w bazie (najszybciej) lub w "backendzie" , ale raczej tego nie zrobisz na stronie, na niej co najwyżej możesz zaprezentować wynik

Większość splikacji biznesowych, jakie spotykam, ma nudny i prosty backend. Co najwyżej nakonplikowany przez overengineering. Większość logiki jest po stronie klienta, co najwyżej ludzie nie zdają sobie z tego sprawy i uważają, że to nie jest "prawdziwa" logika. Wyciągam dużo obliczeń do klienta (web)i Ma to często sens.

somekind napisał(a):

Trzeźwy Ogórek, Ty tak na serio z tym backendem od wysyłania danych z bazy? Nawet w prostych crudach backend robi znacznie więcej.
Jjak myślisz, gdzie jest zaimplementowana weryfikacja reguł biznesowych, gdzie odbywa się główny flow programu, gdzie przetwarza się zamówienia, nalicza płatności, generuje faktury, integruje z systemami płatności, z zewnętrznymi serwisami, bankami, gdzie jest security aplikacji? Na froncie?

Większość tych funkcji bazuje na danych pobranych od klienta bądź z bazy danych. W dodatku są dość łatwe do zaimplementowania (przy bardzo dobrej znajomości architektury aplikacji).

Na Froncie głównie jesteś odpowiedzialny za to, co, kiedy, gdzie i jak ma się wyświetlić.

i po to powstaje tyle framewroków z JS ? jak vue, ember, react, Backbone itd.

jarekr000000 napisał(a):

Większość splikacji biznesowych, jakie spotykam, ma nudny i prosty backend. Co najwyżej nakonplikowany przez overengineering. Większość logiki jest po stronie klienta, co najwyżej ludzie nie zdają sobie z tego sprawy i uważają, że to nie jest "prawdziwa" logika. Wyciągam dużo obliczeń do klienta (web)i Ma to często sens.

Nadmierne skomplikowanie architektury to inny problem, ale jest wiele rzeczy, których frontend nie wykona. I wiele systemów, które frontendu nie maja i nawet nie potrzebują.

Trzeźwy Ogórek napisał(a):

Większość tych funkcji bazuje na danych pobranych od klienta bądź z bazy danych. W dodatku są dość łatwe do zaimplementowania (przy bardzo dobrej znajomości architektury aplikacji).

Nie i nie. Ale żyj sobie w swoim świecie dalej, wszak ignorancja jest błogosławieństwem.

[somekind napisał(a)]

Nadmierne skomplikowanie architektury to inny problem, ale jest wiele rzeczy, których frontend nie wykona. I wiele systemów, które frontendu nie maja i nawet nie potrzebują.

Raczej: niektóre rzeczy jest bardzo trudno zrobić na froncie, ale niekoniecznie niemożliwe. I też odwrotnie. Wiele rzeczy jest bardzo trudno zrobić na backendzie, choćby odegrać mp3 użytkownikowi. Ale animacje na SQL już widziałem.

jarekr000000 napisał(a):

Raczej: niektóre rzeczy jest bardzo trudno zrobić na froncie, ale niekoniecznie niemożliwe. I też odwrotnie. Wiele rzeczy jest bardzo trudno zrobić na backendzie, choćby odegrać mp3 użytkownikowi. Ale animacje na SQL już widziałem.

A ktoś kiedyś próbował odgrywać mp3 na backendzie? Bo jeśli nie, to trudno tu mówić o przenoszeniu czegokolwiek na klienta. A mnie bardziej interesuje jak wygląda po stronie klienta zatwierdzanie zamówień, naliczanie rabatów, hurtowe generowanie przelewów bankowych, albo jakieś proste SSO.

somekind napisał(a):

A ktoś kiedyś próbował odgrywać mp3 na backendzie? Bo jeśli nie, to trudno tu mówić o przenoszeniu czegokolwiek na klienta. A mnie bardziej interesuje jak wygląda po stronie klienta zatwierdzanie zamówień, naliczanie rabatów, hurtowe generowanie przelewów bankowych, albo jakieś proste SSO.

https://martinfowler.com/articles/serverless.html

jarekr000000 napisał(a):

Raczej: niektóre rzeczy jest bardzo trudno zrobić na froncie, ale niekoniecznie niemożliwe. I też odwrotnie. Wiele rzeczy jest bardzo trudno zrobić na backendzie, choćby odegrać mp3 użytkownikowi.

Na mp3 czy tam nawet mp4 możesz robić streaming audio i wideo a na zdjęciach zamiast ładować je z bezpośrednio jakiejś lokalizacji robić coś co się nazywa static server i też ładować to np. robiąc efekty typu sepia, powiększanie, pomniejszanie itd (i rzecz jasna response jako image/jpeg). A na mp3 to dysponując odpowiednim rozszerzeniem do PHP napisanym w C to można by pewnie np. podbarwiać muzykę dodając trochę basu i tak streamować. Widziałem już co prawda przykłady w JavaScript dotyczące generowania efektów do zdjęć oparte na canvas w html, ciekawe tylko czy JavaScritem w ogóle da się zrealizować podbarwianie tonów muzyki z mp3 albo inne takie rzeczy a jeżeli tak to w jaki sposób? Dodam tylko tyle że chodzi mi też o realizację np. płatnych funkcjonalności serwisów i różne zabezpieczenia np. odtwarzanie tylko 30s muzyki za darmo albo kilka min. filmu. To da się zrealizować po stronie przeglądarki?

To co ja widzę po wielu serwisach to to, że dużo dzieje się po stronie przeglądarki, w rozumieniu okna modalne czy nawet naśladowanie zachowania aplikacji na desktop i to by tłumaczyło stosowanie frameworków w javascript, bo nawet na samym jQuery byłoby to bardzo trudno zrealizować.