Spring es Spark kapcsolat

Fórumok

Sziasztok!

Nehany napja kezdtem tanulni a springet es szeretnek nehany dolgot tisztazni.

Van a spring boot es a spring framework.Talaltam egy (rest) tutorialt, ami a bootot hasznalja. De a dokumentacioban altalanos alkalmazas szerepel, webes alkalmazast a framework oldalan emlitenek.

A boot doksiban ez a dependency szerepel:
org.springframework:spring-context:5.0.5.RELEASE
A rest doksiban ez:
org.springframework.boot:spring-boot-gradle-plugin:2.0.1.RELEASE

Mi a kulonbseg a ketto kozott? Milyen projektre erdemes hasznalni a bootot es milyenre a frameworkot?

Szamomra a rest webes projekt, ezert nem ertem miert a boot kell hozza. Meg azt se hogy miert van gradle es nem gradle.

Ha springet ossze szeretnek kapcsolni egy socket klienssel, az megoldhato message broker nelkul? Tegyuk fel, hogy en klienskent kapcsolodok a springhez 80as porton, a springen nyitva van a 9000-es port, amire egy allando service kapcsolodik es azon a porton ker le adatot, amit a kliensnek (nekem) tovabbit. Ertelem szeruen tobb kliens is lehet, ami ugyanazt a 9000-es portot hasznalna. Erre megoldas a spring szalkezelese, vagy nekem kellene uj szalakat inditani? Vagy pont erre lett kitalalva a message broker?

Hozzászólások

"bootot es milyenre a frameworkot" leegyszerusitve, ha standalone appot akarsz, akkor boot, ha meg sajat web kontenerben szeretned futatni, akkor fw.
"ezert nem ertem miert a boot kell hozza" hogy el tudd inditani anelkul, hogy deployolnad egy web kontenerbe.
"Meg azt se hogy miert van gradle es nem gradle" mert nem mindenki hasznal Gradlet, mi azt hasznalunk igy arrol tudok nyilatkozni. Szamtalan beepitett taskja van a Springnek gradlehoz (bootRun pl)

"a springen nyitva van a 9000-es port, amire egy allando service kapcsolodik" ez valami Spring feature? vagy csak ezt szeretned kivitelezni?
"Erre megoldas a spring szalkezelese" ezt pontositanad plz mire gondolsz?

-
Advanced testing of Golang applications

Koszonom a valaszod!

Szerinted mennyire elegans standalone appot prod kornyezetben futtatni? Ezt nem csak fejleszteshez talaltak ki?

Bootrol web kontenerre atallas csak annyi, hogy atirom a dependencyt, vagy lehet a kod egy resze is megtorik?

A 9000es port nem spring feature, en irnek egy serversocketet hozza, ha nem sci-fi az otlet szerintetek. Ugy tudom, hogy rest api tutorial eseten, ha ket bongeszobe megnyitom a 80as porton, akkor azt ket kulon szal szolgalja ki. Ha figyelne a 9000es porton is a spring es arra csatlakoznek egy masik service-vel, akkor a ket kulon szal biztositana, hogy nem akad ossze az adat forgalom a spring es a service kozott, amit a ket bongeszo kezdemenyezett. A service-re ugy kell gondolni, mint egy adatbazishoz valo kapcsolodasra, csak nem az app kapcsolodik az adatbazishoz, hanem forditva. Ez hulyen hangzik, de ezzel a peldaval talan konyebb elkepzelni.

Kicsit eroltetettnek erzem ezt az elmeletet. Csak gondoltam akkor vetnem el teljesen, ha megerositest kapok nalam tapasztaltabbtol.

"prod kornyezetben futtatni" Mi ugy futtatjuk kontenerben.

"vagy lehet a kod egy resze is megtorik" lehet a bootos appot is forditani hogy menjen a kontenerbe as i know.

"en irnek egy serversocketet hozza" ez esetben neked kell gondoskodni mindenrol, amit kerdeztel.
"akkor azt ket kulon szal szolgalja ki" igen mert az ugy van megirva
"akkor a ket kulon szal biztositana" nagyon implementacio fuggo

-
Advanced testing of Golang applications

A Spring Boot a Spring Framework köré épített varázslat leginkább.

Régen csináltál egy Spring Frameworkös appot, amit belekartál valami konténerbe, majd ez futott.

A Spring Boot meg csinál egy standalone, futtatható jart, amit el lehet indítani, s ad egy rahedli egyéb kényelmességet.

Lehet, hogy erdemesebb lenne szervletekkel kezdened (vagy sot, sima java alkalmazassal, amiben kozvetlenul a socketeket kezeled), es amikor megerted a dolgok mukodeset, akkor szintet lepsz es kiprobalsz egy uj eszkozt/fw-t, ami azokra epit...

----------------------
"ONE OF THESE DAYS I'M GOING TO CUT YOU INTO LITTLE PIECES!!!$E$%#$#%^*^"
--> YouTube csatornám

Aztán jönnek a meglepetések, mondjuk kapsz egy API dokumentációt, és a meghatározott 4 féle hibaválasz mellé még azonosítasz 12 félét, amire a fejlesztő: "ja azt valószínűleg nem mi küldjük, hanem a Spring." wtf?? Vagy skálázni kellene a cuccot, de a senior boot developer már rég nem tudja, hogy mi az a servlet, a request és milyen threading modell működik a háttérben.

Persze, később érdemes ezeket megismerni, megtanulni, tisztában lenni vele.

De tippre kb. ezért az első ismeretsége a webbel mindenkinek a PHP, mert kurva egyszerű elindulni vele. Anno volt WAMP telepítő, exe futtat, a megfelelő helyre .php fájlokat pakol, csoda. Én a JVM-es világban, középiskolában, magamtól Play Frameworköt nyomogattam, mert volt hozzá részletes tutorial, meg egyszerűen indítható volt.

Érdemes összehasonlítani a régi, keress egy alkalmazásszervert, majd csomagolj belőle wart valahogy, majd deployold világot egy .NET-es, vagy djangos (neadjisten a Play Framework) getting started leírásával. Nem gondolnám még, hogy emiatt a senior .NET fejlesztők nincsenek tisztában a .NET threading modelljével, vagy azzal, hogyan lehet .NET-ben skálázható, karbantartható, megbízható dolgokat írni. Cserébe sokkal vonzóbb maga a platform, s sokkal könnyebben akasztanak le utánpótlást az adott platformhoz. (akiket lehet később oktatni tovább)

Nemhiába nem sokan ajánlanak assemblyt kezdésnek, holott szvsz hasznos, ha az ilyen low level szinttel legalább nagyvonalakban tisztában van az ember.

Jó, amiket írsz, azért bátorkodtam beleoffolni az OP-ba (amit egyébként nem értek), mert igenis tapasztalom, hogy nem tanulják meg az emberek. Mintha egy külön világ lenne sokszor a fejlesztő és a Spring fejlesztő. :) Pont a Play Framework (szigorúan 1-es verzió:)), jó példa volt arra, hogyan lehet egyszerűen használható dolgot csinálni úgy, hogy mégsem absztraktálja el előled a fél világot. Természetesen ez nem a Spring/Boot hibája, hanem az alkalmazóké..

De meg kell erteni. Csak nem kell fejbol tudni, es nem kell orakat potyogni a konfigokat, hogy a legegyszerubb REST szervert osszerakd.

De attol meg minden Spring-gel kapcsolatos koncepciot ismerned kell es meg kell ertened, kulonben nagyon hamar elakadsz. (Persze ha egy gyors egyetemi hazi feladatot / beadandot csinalsz, akkor valoban tokmindegy...)

Spring Bootnak pont az egy nagy előnye, hogy a 20+ éves ökoszisztémát nem kell hozzá megérteni.

A Spring tanuláshoz is szükség van az alapokra, mert Spring doksi, és az ilyen-olyan tutorial-ok is építenek arra, hogy az alapok megvannak. Ha az alapok megvannak, és tudja valaki, hogy mit szeretne, milyen lehetőségei vannak a célok eléréséhez, akkor használhat hozzá olyan keretrendszert mint a Spring, ami segít, hogy ne a kályhától kelljen elindulni, és mindent lekódolni nulláról az alap JAVA API-val. (ami ráadásul soha nem is lenne olyan, mint egy sokak által használt+fejlesztett+tesztelt megoldás) A Spring-nek (azt gondolom) nincs olyan előnye, hogy az alapokat ne kelljen tudni, elég legyen később megismerni, mert ez max egy egyszerű hobbi program esetén működhet, amíg valaki az első problémába bele nem fut.

A server socketet es datagram servert mar ismerem. A springbe valo integralas lehetoseget probalom megerteni. Egyaltalan hallott mar valaki olyanrol, hogy egy webes spring projekt, ami a 80as porton figyel, nyit egy masik portot is hatter szolgaltatasok szamara? Mert ha nem, akkor biztosan rossz mezore tevedtem. :)

Hallott. Szerintem ilyesmit keresel:

TcpConncectionService - definialt porton figyel TCP kapcsolatra.

ApplicationRunner - mikor az app indul, inditunk egy kulon szalat a TCP kapcsolatok hallgatasara.

Bocs a kodminosegert, reg nyultam hozza, es sok idom se volt igazabol, illetve tobb kapcsolatra nem teszteltem, a use-case scenario az egy darab terminal kapcsolodasa volt, de hatha segit elindulni.

Szerk:

Itten-e van a terminal oldali kapcsolodas (Spring Shell app). Ahogy latod a package es class nevekbol, ez meg elegge PoC jellegu dolog :)