@PrzegrywWykopek: i komercyjnie robi to się ręcznie? Albo każdy pisze skrypty w bashu, które będą to kopiować? Nie ma jakiego ładnego rozwiązania?

Jak mam front i backend na jednym serwerze, to łatwiej o zabezpieczenia. Wszystkie CORS-y itd. mają być dostępne tylko "od siebie" i z głowy. Jak mam dwie maszyny (np. S3) to już muszę myśleć skąd można strzelić, a skąd nie (i przy zmianie maszyny backendowej zmieniać konfigurację na frontendowej).

Przy dużych aplikacjach (i dużej liczbie użytkowników) tak, przy małych niepotrzebna komplikacja.


Przy okazji, cache frontu nie będzie mi działać jak statyczne pliki będą lecieć z backendu?
Czy na AWS coś dodatkowo konfigurujesz (coś w stylu CDN-a) czy po prostu wrzucasz na S3 i tyle?

@Enviador: ale po co ma być oddzielnie?

Robię bardzo małe aplikacje, których używa kilka osób. Odpalam jar-a i aplikacja stoi. Po co mam to komplikować jak nic mi to nie daje?

@Kuriozal: no tak, mogę zbudować ręcznie front, wrzucić do static, zbudować backend, pilnować, żeby w folderze static git ignorował tylko te wrzucone pliki (bo przecież mogą być inne)... Tylko czy muszę robić to ręcznie?

Istnieje plugin do Mavena, który niby to robi automatycznie. Ale czy to dobre podejście? Ten plugin jest mało popularny, rozwijamy głównie przez jedną osobę, więc w każdej chwili może już nie być wspierany.

Nie wiem jak inni to robią. Jakoś mi się nie chce wierzyć, że nagle wszyscy trzymają dwie oddzielne aplikacje jak do niedawna wszyscy trzymali w jednej.

Chociażby przejście z AngularJS na Angular 2 wymagało trzymania frontu w osobnym projekcje i budowania npm-em...
Czy tylko z tego powodu musiała zmieniać się infrastruktura i środowisko produkcyjne, bo frontewdowcom zachciało się o jedną wersję podbić bibliotekę?

@PrzegrywWykopek: nie używam Gradle tylko Maven. Może czas wreszcie się przerzucić. Ale myślałem że na jedno wychodzi (też tylko do pobierania zależności i odpalania pluginów). Tylko Gradle niby szybszy, bo robi równolegle (ale też słyszałem o problemach z szybkością budowania względem Mavena). Były też problemy z Gradle i Javą 11 w Springu. Wychodzi, że Maven jednak nadal stabilniejszy.

Miałem na myśli, że jak mam front i backend w jednym jar, to żeby dostać front to użytkownik nadal strzela do backendu (tylko że do embedded Tomcat/Jetty). I że może przez to nie działa cache (bo wspomniałeś o cache). No ale przecież co za różnica... Backendowe GET-y też mogą być cachowane...

Czyli na S3 cache jest włączony z automatu i nie trzeba nic konfigurować?
Jak wrzucam coś nowego, to chyba jakoś da się wyczyścić cache?

cały czas miałem na myśli cloud front

@PrzegrywWykopek: a czyli oddzielna "usługa" AWS, tak jak pisałem, ze takie CDN (nawet sami tak to opisują na stronie: https://aws.amazon.com/cloudfront/ ).

cache ustawiasz na tomcatcie, czy tam jetty

@PrzegrywWykopek: jak mam Spring Boota to na Tomcat/Jett embedded raczej dużo nie ustawiam. A ten cache w Springu to chyba całkiem co innego niż cache na poziomie sieci.

po czym tak twierdzisz

@Kuriozal: po tym co pisałem dwie linijki wyżej. Jeśli Spring (Pivotal) nie radził sobie z Javą 11 w Gradle, to znaczy, że jest coś nie tak (jak widać z Mavenem sobie poradził od razu). Pewnie sytuacja się nie powtórzy, ale wolałbym nie czekać tygodniami na fixa... Czy problem z Gradle był ze względu na większe skomplikowanie czy na niższy priorytet, to dla mnie nieistotne. Dodatkowo problem z wydajnością, o którym pisałem - sam go nie doświadczyłem, ale czytałem. Po tym tak twierdzę, o czym napisałem. Nie powiedziałem też, że Gradle jest w ogóle niestabilny. Wyrwałeś zdanie z kontekstu.

możesz rozszerzyć łatwo builda dodając do tego odpalenie npm i wrzucenie w odpowiedni folder

Napisanie taska, który wywoła npm i skopiuje wynik do resourceów to ledwie kilka linijek kodu

@globalbus: @PrzegrywWykopek: plugin Mavenowy o którym wspomniałem instaluje node/npm w lokalnym folderze, a nie tylko odpala ten z systemu. Dzięki temu np. Jenkins czy ktoś kto tylko chce zbudować sobie aplikację nie musi instalować sobie node'a. Wadą jest to, że musi się to ściągnąć do folderu przed zbudowaniem.

Ale może stąd wynika mniejsza niż zakładałem popularność tego pluginu.
- Ci co robią duże aplikacje dzielą na dwie aplikacje.
- Ci co robią małe i mają w jednej i używają Gradle, to nie muszą używać pluginu.
- Zostają tylko ci co robią małe, maja w jednej i używają Mavena. Ale nadal wydaje mi się to za mało i mam podejrzenie, że ludzie robią to jeszcze inaczej.

to jakas mala p-------a gdzie uzycie AWS jest sporym overkillem

@Kuriozal: dokładnie, robię małe pierdółki/toole dla kilkunastu/kilkudziesięciu osób (które kiedyś mogą się rozrosnąć). AWS rozważam jedynie jako zwykły serwer: wrzucić JAR-a i uruchomić. Nie używać żadnych usług AWS-owych.

@htfhere: @LazyInitializationException: dzięki.

Właśnie o ten plugin mi chodziło: com.github.eirslett:frontend-maven-plugin
(nie chciałem sam podawać, żeby nie sugerować odpowiedzi)

Czyli jednak po prostu się go używa.