Nápad na bakalářskou práci se Spring

[Arthnon]

A ještě jedna věc:

3.) Je nějak možné nechat běžet tu frontendovou část, která běží na IIS na Tomcatu?

[Reklama]

[Filip Jirsák]

Používají se všechny tři varianty:

• Máte aplikační webový server, na kterém běží API, a u něj je přibalen i statický web.
• Máte webový server, který servíruje statický web, a část adresního prostoru je přesměrována na „backend“ server, kde běží API. To API pak vlastně není přímo vystavené do internetu (i když ten web server tvoří jen velmi tenkou obálku, obvykle HTTP požadavky přeposílá bez větších změn – ale může třeba dělat terminaci SSL).
• Máte dva samostatné webové servery na samostatných doménách, jeden servíruje statické soubory, druhý poskytuje API.

Vše má svá pro a proti. Na úvodní konfiguraci je nejjednodušší 1. varianta, ale pak musíte i při změně webové části dělat nový deploy aplikace. Ve variantě 2 nemusíte řešit CORS (oproti variantě 3), aplikační server je trochu schovaný. Ve variantě 3 máte vše nezávislé, můžete mít klidně k API víc frontendů a klidně můžete statický web servírovat třeba z CDN od Cloudflare a a API mít na AWS, aniž by bylo nutné něco nějak konfigurovat (zrovna s Cloudflare to jde i ve variantě 2, ale pak všechny požadavky půjdou přes Cloudflare, ve variantě 3 půjdou z prohlížeče přímo do AWS).

[Arthnon]

Děkuji za odpověd. Ta moje varianta, co jsem poslal: frontend (JS, HTML/CSS) na webovém serveru IIS (443 a 80 porty) a REST api běží na stejném PC, ale jako služba na portu 8443. Dá se toto zařadit do bodu toho bodu 1.), co jste Vy poslal? Může to takhle být navrženo, jak to mám popsané?

Děkuji

[Arthnon]

I když 1.) to být asi nemůže, jak nad tím přemýšlím, protože to nesplnuje to, co jste poslal... spíše mi to sedí do toho bodu 2.), ale já jsem musel řešit stejně CORS...

Lze ten můj model zařadit do té dvojky spíše zní otázka tedy?

[Filip Jirsák]

Ona je to vlastně ještě jedna varianta, příbuzná variantě 3, ale v produkci se obvykle nepoužívá. Z hlediska CORS se za shodnou adresu považuje trojkombinace protokol, hostname a port – jsou to dva nezávislé servery. Kdybych u toho bodu 3 škrtnul to upřesnění „na samostatných doménách“, to vaše řešení by tomu plně odpovídalo.

Důvod, proč se tohle řešení v produkci nepoužívá, je ten nestandardní port. U API by to teoreticky nemuselo vadit, uživatel to nevidí a v aplikaci je ten port zadaný. Jenže ve spoustě sítí se na nestandardní port nedostanete, takže by z nich ta vaše aplikace nebyla funkční (načetla by se statická stránka, ale API by bylo nedostupné). Proto se to v takovém případě nahradí variantou 2, kdy byst požadavky třeba na /api/* směřoval z webového serveru (IIS) na ten váš aplikační server (Tomcat na portu 8443). Uživatel by tedy vždy komunikoval jen s IIS na standardním HTTPS portu, a váš Tomcat pak nemusí být vůbec vystaven do internetu, bude se k němu přistupovat vždy jen prostřednictvím IIS. (Akorát tedy nevím, jak se takovéhle přeposílání požadavků na IIS konfiguruje – hledejte spojení „reverzní proxy“ / „reverse proxy“.) Je pak potřeba, aby to API mělo svůj jmenný prostor, abyste dokázal rozlišit, zda jde požadavek na statickou stránku nebo na API. Dobré je mít tam nějaký společný prefix, třeba právě to /api/.

[Reklama]

[luvar]

Ahojte vospolok. Vydrzal som citat len dopolovice cca. Skusim ale pridat moje skusenosti a postrehy k povodnej otazke a teme:

• bakalarka -> stiha sa menej ako myslis. Otazka je, ci si bol v praxi zamestany uz (popri skole). To moze pracu posunut o stipku k realizovatelnosti aspon jednej veci
• spring je obrovsky framework. Je tazke si uvedomit jeho velkost, skusim na priklade s hashovanim hesiel. V skratke po tyzdni googlenia, studovania a nakonice debugovania a citania zdrojakov zistis, ze nic nemusis robit. Staci nakonfigurovat PasswordEncoder a ak pouzivas (nevedome) DaoAuthentificationProvider, tak ten ti riesi aj update zahashovaneho hesla, ak nova verzia frameworku usudi, ze security uz nie je dostatocna. Staci nakonfigurovat UserDetailsPasswordManager a podhodit mu instanciu UserDetailsPasswordService. Napriklad. Skus si pozriet taky zaklad fungovania spring security pri http aplikaciach (deep dive v nadpise je prehnane) https://www.youtube.com/watch?v=8rnOsF3RVQc
• Daj si v zadani bakalarky minimalne ciele, ktore su postacujuce. Ak ich prekonas, nie je problem v abstraktu prace a aj do posledneho odseku v zavere, napisat, ze toto a toto som spravil pomimo a navyse. Opacne to je blbe (toto a toto som nespravil/odflakol)
• Dolezitejsi (pre obhajobu bakalarky) je samotny dokument bakalarky, ako produkt. Cesta k produktu je zase dolezitejsia pre knowledge. Najde sa malo oponentov, ktori si pozvu (a trvaju na tom) studenta k sebe a chcu vidiet ako to funguje a vramci predvadzacky sa pytaju na "internals" produktu. Imho je to ale vyhodou, lebo student bude vediet presne na com je u oponenta a co od neho cakat pri obhaobe.
• Naozaj sa priprav na to, ze spring je obrovsky a vyriesit len Oauth2 (prihlasovanie facebookom/githubom/googlom/...) je tak praca na mesiac fulltime (hovorim ako clovek s 10+ rocnou java praxou, ktory doteraz robil backend-y a backend processing. Teraz som zacal s backend-om pre frontend. Je to rozdiel, ked clovek riesi web transportnu i aplikacnu zvyklost/standard) Teda ak nepoznas danu cast spring-u
• Pre quick start odporucam investovat tak do 40 euro a na udemy.com si kupit 3 kurzy k teme, ktore ta prevedu rychlo k cielu. Skoda, ze bez vacsieho informovani o pozadi veci.
• tema bakalarky -> osobne by som pri podmienke "nech je tam spring" zvazil napriklad implementaciu "testovacieho" projektu. Teda, ze sa pozries na tie existujuce na https://github.com/spring-projects/spring-data-examples/ napriklad a skusis spravit nejaky krajsi, obsiahlejsi a vyuzivajuci viac ako len "hello world". Z toho sa da spravit pekny "kurz pre studentov" ako nejaky bonus naviac. Cielom bakalarky moze byt kludne, ze napises testy na ukazkovu dummy aplikaciu a zvysis tym pokrytie testov v spring frameworku. To by ti mohli zobrat i ako pullrequest.

PS: ak si sialenec (mas rad napriklad mechanical sympathy manifesto), tak odporucam aspon pozriet na reaktivnu vlnu hipsteriny. Je to pouzivane/lakave, ale financny zmysel to ma cca pre netflix a spol. Napriklad https://r2dbc.io/, je reaktivny a non-blocking drajver pre rozne databazy. IMHO to nahradi jdbc v dalekej buducnosit (10 rokov?).

PS2: dalsia moznost sialenca hodna je napriklad pohrat sa s vecami z novych "jáv". Napríklad inline class. Osobne by ma lákalo mať šas aj na GrallVM, či https://quarkus.io/ (šialenosť, kde počas kompilácie sa vlastne aplikácia spustí, hybernate si zrieši svoje reflexné potreby z detstva a následne sa spraví "snapshot" pamäte a to sa uloží do "jar-ka". Potom spustenie aplikácie je "rýchle")

PS3: Vsimol si si, ze v mojom prispevku som nespomenul javascript, ani frontend? IMHO by si ho nemal v zadani bakalarky spomenut ani ty...

[Arthnon]

Ona je to vlastně ještě jedna varianta, příbuzná variantě 3, ale v produkci se obvykle nepoužívá. Z hlediska CORS se za shodnou adresu považuje trojkombinace protokol, hostname a port – jsou to dva nezávislé servery. Kdybych u toho bodu 3 škrtnul to upřesnění „na samostatných doménách“, to vaše řešení by tomu plně odpovídalo.

Důvod, proč se tohle řešení v produkci nepoužívá, je ten nestandardní port. U API by to teoreticky nemuselo vadit, uživatel to nevidí a v aplikaci je ten port zadaný. Jenže ve spoustě sítí se na nestandardní port nedostanete, takže by z nich ta vaše aplikace nebyla funkční (načetla by se statická stránka, ale API by bylo nedostupné). Proto se to v takovém případě nahradí variantou 2, kdy byst požadavky třeba na /api/* směřoval z webového serveru (IIS) na ten váš aplikační server (Tomcat na portu 8443). Uživatel by tedy vždy komunikoval jen s IIS na standardním HTTPS portu, a váš Tomcat pak nemusí být vůbec vystaven do internetu, bude se k němu přistupovat vždy jen prostřednictvím IIS. (Akorát tedy nevím, jak se takovéhle přeposílání požadavků na IIS konfiguruje – hledejte spojení „reverzní proxy“ / „reverse proxy“.) Je pak potřeba, aby to API mělo svůj jmenný prostor, abyste dokázal rozlišit, zda jde požadavek na statickou stránku nebo na API. Dobré je mít tam nějaký společný prefix, třeba právě to /api/.

Já úplně nechápu, v čem ten reverzní server zde pomáhá. Řekněme, že uživatel spustí odeslání dotazu docmanager.com/documents, na IIS dojde ke směřování na docmanager.com:8443/api/documents. CORS předpokládám, že bude stejně muset být nastaven a tenhle nestandartní port (8443) bude stálen používán?

[Ziktofel]

Pro klienta ten request prijde ze standardniho portu 443, to, ze to IIS preposle na port 8443 klienta vubec nezajima, o existenci toho tomcata nic nevi, s tim se vubec nebavi, proto CORS bude na port 443. Jinak HTTPS se obvykle resi na tom serveru, se kterym se bavi klient (IIS) a mezi IIS a tomcatem uz jde jenom obyc HTTP.

Jinak reverse proxy hlavne umoznuje jednomu serveru reagovat na vice ruznych URI, ktery muzou zpracovavat ruzne aplikacni servery, tj vice sluzeb na jedny IP adrese a na jednom portu

Mam-li napriklad domeny foo.example.com a bar.example.com, ktery smerujou na stejnou IP adresu, tak diky reverse proxy muzu mit pod kazdou z techto domen jinou sluzbu (s ruznejma aplikacnima serverama), coz kdybys toho tomcata vystavil primo ven, tak toho (jednoduse, aby jedna sluzba nemusela nic vedet o druhy) nedosahnes

[Ziktofel]

Jinak zminuju IIS, protoze jste se tu bavili o IIS, ale nejcasteji v roli reverzni proxy vidim pouzityho prave Apache, doporucuju se naucit to delat prave s nim

[Arthnon]

Díky, mrknu na to...
Ještě jedna taková maličkost - trošku plavu v tom, jak správně pojemenovat ten můj Spring Boot "REST server". Jaká je správná terminologie? Měl bych to popisovat jako "REST server" nebo jako "REST api" do té práce?

"Na REST serveru jsou používány tyto technologie..." nebo "Na REST api jsou používány tyto technologie..."

[Filip Jirsák]

Já úplně nechápu, v čem ten reverzní server zde pomáhá. Řekněme, že uživatel spustí odeslání dotazu docmanager.com/documents, na IIS dojde ke směřování na docmanager.com:8443/api/documents. CORS předpokládám, že bude stejně muset být nastaven a tenhle nestandartní port (8443) bude stálen používán?

Webový prohlížeč pak komunikuje jenom se standardním portem 443 a pro něj se tváří, že je vše na jednom serveru (takže CORS není potřeba řešit, v rámci jednoho serveru je komunikace povolená automaticky). To, že vy máte API implementováno pomocí jiného serveru, je pak jenom váš implementační detail.

nejcasteji v roli reverzni proxy vidim pouzityho prave Apache

I Apache je na tohle docela bumbrlíček, podle mne nejčastěji se pro tohle používá nginx (pokud chcete servírovat i statický obsah). Případně se dají použít specializovanější varianty, jako HAproxy, Varnish, Traefik, Istio apod.

[Arthnon]

Díky a co se týká toho REST serveru vs REST api, prosím?

[Filip Jirsák]

V tomhle kontextu (použité technologie) bych psal o REST serveru, týká se to implementace. O REST API bych psal v případě, kdy není podstatná konkrétní implementace, ale jde o to samotné rozhraní (např. při popisu jednotlivých metod).

[Arthnon]

"Na straně serveru bude použita technologie Spring Boot a programovací jazyk Java 12. Na tomto serveru bude používáno REST API."

"První částí aplikace je založena na frameworku Spring Boot a programovacím jazyku Java 12. Tato část aplikace vystavuje různé REST služby. "

Připadají Vám tyto věty v pořádku z hlediska té terminologie REST server/API? Snažil jsem se o tom googlit a pořád mi úplně není jasné, jestli to je takto správně nazváno...

Mnohokrát děkuji

[Filip Jirsák]

Nemyslím si, že by „REST server“ nebo „REST API“ byly nějaké všeobecně používané termíny, takže záleží na vás, jak si je definujete. Ale pod „používáno REST API“ bych si představil klienta, ne server. Pokud tam chcete mít „API“, napsal bych např. že server vystavuje API v podobě REST služeb.