Produkcja oprogramowania

Dobry wieczór, nurtuje mnie kilka pytań dot. wytwarzania oprogramowania webowego w Javie.

1. Jak wygląda podział zadań pomiędzy front-end a back-end?, Chodzi mi między innymi o np. formularze, robi się je w Javie/Springu(Validation) a potem 'podrasowuje' w JS czy raczej tylko w jednym albo drugim?, powiedzmy, że mamy sklep internetowy gdzie backendem jest Java a frontendem React, które funkcję należą do jednego a które do drugiego(np. koszyk, menu, kalkulator, wyszukiwanie produktów, zegarek)?

2. Jak wygląda komunikacja pomiędzy backiem Javy a frontem np Reacta?, wiem, że wykonuję się to za pomocą RestAPI, ale chciałbym zobaczyć jakiś trywialny podgląd jak do tego dochodzi, że np React ma odwołania do zmiennych/czynności w Javie i na odwrót.

3. Jak wygląda praca z bazami danych? Chodzi mi o technologie których się używa, Spring-JPA(czy samo JPA jest szeroko używane?), Spring-Data, Hibernate i w jakmi stopniu każdy z nich. Dodatkowo, robione jest cokolwiek jeszcze przez JDBC? JPQL, HQL nadalw użyciu czy jedynie czysty SQL by była odpowiednia szybkośc?

4. W jakich technologiach buduję się Web serwisy dzisiaj, w 2019/20? Potrzebny mi cały stack, zarówno front jak i back-end.

5. Servlety jeszcze istnieją?

6...

7...

Jak coś mi się przypomni to dodam jeszcze w nowym poście.

Dziękuje za wszystkie wnoszące 'coś' do tematu odpowiedzi.

Ludzie piszą całe książki próbując odpowiedzieć na zadane przez ciebie pytania. Zresztą większość odpowiedzi to to zależy.

1. Nie ma reguły, zależy jak to chcecie zaklepać. Możesz mieć koszyk po stronie serwera, a możesz go mieć tylko po stronie klienta. Generalnie front to front, a back to back. Backendu nie obchodzi jak wygląda (i czy w ogóle istnieje jakiś) formularz. Przujmuje dane odpowiedniego formatu i tyle.
2. Nie bardzo rozumiem pytanie. Backend przyjmuje jakieś requesty i odpowiada na nie.
3. Co to w ogóle za pytanie. Nie ma reguły. Zwykle technologie dobiera się do problemu i tyle. Pracuje juz trochę lat i widziałem na produkcji każdą z wymienionych przez ciebie technologii. W ogóle ciekawe że nie dotarły do ciebie informacje o istnieniu NoSQL który sprawia ze twoja lista jeszcze się powiększa...
4. Nie ma reguły. Potencjanych stacków jest pewnie tysiące. Ba, zaryzykuje że weźmiesz 100 losowych firm i w każdej stack będzie trochę inny. I to nawet jakbyś patrzył na sam front albo na sam backend osobno. A jak zrobisz jeszcze przecięcie obu to już w ogóle.
5. Tak, są podstawą pewnie połowy frameworków webowych. Ale jeśli nie planujesz pisać takiego frameworka, to raczej nie musisz się na nich jakoś szczegółowo znać.

Twoje pytania są mniej więcej na poziomie Jakim samochodem się dziś jeździ? Potrzebna mi marka, model i rocznik.

Jak wygląda komunikacja pomiędzy backiem (...) a frontem np Reacta?,

Nijak, bo React nie ma opcji komunikacji z backendem XD :P :) React to biblioteka do renderowania widoku, a nie do komunikacji z backendem.

Możesz co najwyżej za pomocą JS nawiązać jakieś połączenie z backendem. A więc w grę wchodzi zwykle jakiś protokół HTTP czy WebSocket (piszę ogólnie od strony przeglądarki, niezależnie od tego, co jest na backendzie) i dane są przesyłane przez sieć, często w formacie JSON (no i często się to określa buzzwordem AJAX: . Asynchronous JavaScript and XML - , ponieważ pierwotnie miało to służyć do XML. Chociaż kto wie, jak to Java, to kto wie, czy dalej nie jest używany. No ale jak napisałem - piszę ogólnie i od strony przeglądarki/JavaScriptu).

Obecne przeglądarki mają wbudowaną funkcję fetch do ciągnięcia danych. Są też JSowe biblioteki typu axios. Są biblioteki do Websocketów (np. Socket.io) Różne są metody.

1. Dalej trwają niekończęce się kłótnie co lepsze SPA czy podejście klasyczne z renderowaniem stron po stronie serwera
2. Do komunikacji dorzucę jeszcze to że powstała biblioteka do ProtocolBuffer w JavaScripcie, więc jest możniwa binarka komunikacja między frontem a backendem
   3-5 Ogólnie dominuje Hibernate i Spring, Spring Boot w nowszych projektach. Ale oczywiście zdarzają się projekty oparte na Juice, Dropwizard, Akka-Http itd. Co do Spring Data programiści z którymi rozmawiałem często mówili że to bezsensowna nakładka.

Co do Spring Data programiści z którymi rozmawiałem często mówili że to bezsensowna nakładka.

Olivier Gierke się w grobie na Twitterze przewraca :) Jest w tym jednak ziarno prawdy - bez sensu (a nawet szkodliwe) jest udawanie, że findByName na Postgresie i Cassandrze działa tak samo. Z drugiej strony, jeśli używa się świadomie, to pozwala zaoszczędzić czasu powielając kod oparty o QueryBuildery i inne abstrakcje niższego poziomu.

Kamil Żabiński napisał(a):

1. Dalej trwają niekończęce się kłótnie co lepsze SPA czy podejście klasyczne z renderowaniem stron po stronie serwera

To mnie dziwi. Nawet jakbym miał pisać w JS i to pod IE 6.0 to wolę to niż wszystkie powalone webowe frameworki javowe i rendering po stronie servera.
Nie mówiąc już typowych zblaszczeniach architektonicznych jakie są z tym powiązane.

Shalom napisał(a):

Twoje pytania są mniej więcej na poziomie Jakim samochodem się dziś jeździ? Potrzebna mi marka, model i rocznik.

Mogą i tak być, bo są trochę źle sformułowane, ale głównie chodziło mi o to by wytłumaczyć trochę jak przebiega produkcja, jakie technologie dominują etc.

1. Frontend zajmuje się wyświetlaniem. Backend całą resztą.
   Koszykiem zajmują się obie części:
   Frontend pobiera z backendu dane co się znajduje w koszyku i ładnie to wyświetla. Wyświetla też przyciski i inne kontrolki, które pozwalają coś dodać do koszyka czy usunąć. Rolą tych kontrolek jest zebrać dane od użytkownika i wysłać żądanie do backendu "EJ, DODAJ LODÓWKĘ DO KOSZYKA". Po czym backend odpowiada "SPOKO, TUTAJ MASZ AKTUALNY KOSZYK". I front odświeża się, żeby wyświetlać najnowszy stan. Tak samo jest z resztą ficzerów (menu, kalkulator, wyszukiwanie produktów).

2. Wyobraź sobie, że wszedłeś na stronkę z koszykiem.
   Pod spodem jest siedzi taki kodzik, który wysyła magiczne żądanie http do czegoś co się znajduje pod hostem example.com. Oczekuje, że w odpowiedzi dostanie aktualny stan koszyka. Jak owy stan wróci, to odświeża komponent.

ajax.get("https://example.com/cart")
      .then(cart => this.refreshCart(cart));

Zanim dostaniesz aktualny stan koszyka, to żądanie wlatuje do example.com, gdzie siedzi twoja aplikacja w springu. W tejże masz taką klasę:

@RestController
class CartController {

    private cartRepository;

    @RequestMapping("/cart")
    Cart findCart() {
        return cartRepository.find();
    }

}

Spring kmini sobie, że skoro końcówka adresu to "/cart", to trzeba wywołać metodę findCart (bo findCart ma adnotację z taką samą końcówką). Więc Spring wywołuję tą metodę, a jej rezultat zwraca w odpowiedzi http. Metoda cartRepository.find powiedzmy, że pobiera aktualny stan koszyka z bazy danych.

1. Jednocześnie używasz wszystkich i nie używasz wszystkich.
   Wszystkie podane przez ciebie technologie korzystają z siebie wzajemnie:
   Spring Data -> JPA (Hibernate) -> JPQL (HQL) -> JDBC -> SQL
   Czyli ty używając tylko i wyłącznie Spring Data i tak pod spodem używasz JDBC. Tylko tego nie widzisz.
   Generalnie używa się wartwy najwyższej, bo wtedy trzeba się najmniej naklepać. Problem zaczyna się w wtedy gdy warstwa wyżej (Spring Data) czegoś nie wspiera (albo nie umiesz/nie chce ci się tego robić), bo robisz coś bardziej skomplikowanego. Wtedy używasz warstwy niższej (JPA). Albo jeszcze niższej. Albo jeszcze niżej. I tak dalej.

Frontend (nie znam się):
React, Angular, Vue, npm

Backend:
Spring, Spring Data, Spring Security, Oauth2, JPA, PostgreSQL, MongoDB, JUnit, mockito, jackson/gson, javax.validation, lombok, swagger, logback, git, maven/gradle, docker

1. Patrz punkt 3. Spring pod spodem używa servletów. Natomiast nikt normalny bezpośrednio ich nie używa.

Szybkie pytanie, warto uczyć się thymeleafa? i dlaczego tak lub nie?

Ciężko odpowiedzieć bez kontekstu, np. co już umiesz, co chcesz w życiu robić etc. Generalnie odchodzi się już od tego na rzecz frameworków/bibliotek javascriptowych - Angular, React czy Vue.

Co boskie, Bogu. Co cesarskie, cesarzowi.
Brak rozdziału państwa od front-endu prędzej czy później źle się kończy.

Charles_Ray napisał(a):

Ciężko odpowiedzieć bez kontekstu, np. co już umiesz, co chcesz w życiu robić etc. Generalnie odchodzi się już od tego na rzecz frameworków/bibliotek javascriptowych - Angular, React czy Vue.

Interesuje mnie tylko backend, front oddaje - na razie - w całości front-endowcy, w takim wypadku raczej nie ma sensu ogarniać thymeleafa (czy jsp) oprócz cech i jedynie zostawiać enpointy pod reacta czy angulara?

kiowa72 napisał(a):

Szybkie pytanie, warto uczyć się thymeleafa? i dlaczego tak lub nie?

A znasz już jakiś inny system szablonów? Bo wszystkie są mniej więcej do siebie podobne chociaż każdy twierdzi że jest wyjątkowy

Kamil Żabiński napisał(a):

kiowa72 napisał(a):

Szybkie pytanie, warto uczyć się thymeleafa? i dlaczego tak lub nie?

A znasz już jakiś inny system szablonów? Bo wszystkie są mniej więcej do siebie podobne chociaż każdy twierdzi że jest wyjątkowy

Do tej pory w żadnym bo kompletnie mnie one nie obchodziły, no chyba, ze zaliczymy do nich jsp :P