Avatar billede kim-allan Praktikant
09. maj 2019 - 20:56 Der er 9 kommentarer

Java kode Best practice

Hej

Hvis man skal kode et projekt med en webfrontend som er kodet i java script og funktionaliteten i java. Hvad er så Best practice? At det hele ligger samlet i et stort projekt i fesk itellij. Eller laver man webdelen for sig selv, og java delen for sig selv?
Bryder man også java delen op i flere små projekter? Vi kan kalde det små services, eller har man java delen samlet i et stort projekt?

Hvad er smartest at gøre og hvorfor?

// Kim-Allan
Avatar billede kim-allan Praktikant
09. maj 2019 - 20:58 #1
Det kan lige sige, at det skal kunne deployes på en tomcat eller wildfly..
Avatar billede arne_v Ekspert
09. maj 2019 - 21:25 #2
Spredte tanker.

Helt sikkert separate projekter for JS frontend and Java backend.

Jeg antager at kommunikationen er RTESTful web services med JSON/HTTP(S).

Og enten JAX-RS eller Spring paa Java siden.

Hvorvidt Java skal splittes op i flere projekter  boer afhaenge af deployment modellen:

single war with N services => 1 projekt

multiple war with 1 service each => multiple projekter

Valget mellem de to deployment modeller er mere et spoergsmaal om stil end om best practice.
Avatar billede arne_v Ekspert
09. maj 2019 - 21:27 #3
Jeg formoder at I bruger:

IDE---source control---build tool---officielle war filer

og ikke bruger IDE til at lave de officielle builds med.
Avatar billede arne_v Ekspert
09. maj 2019 - 21:29 #4
En war file som kun bruger java.* og javax.* klasser boer deploye fint paa baade Tomcat og WildFly.
Avatar billede simonvalter Praktikant
09. maj 2019 - 21:30 #5
Jeg synes det kan give god mening at have en seperation mellem frontens og backend så du kan bygge og deploye og skalere dem uafhængigt af hinanden.

Det er lidt afhængigt af hvad din java kode laver om det giver mening at bryde det ned i individuelle services. Det kan give fordele som at kunne skalere uafhængigt af hinanden men det kan også tilføre kompleksitet. Det ihvertfald en god skik at benytte forskellige packages til forskellige områder. Der er massere af enterprise patterns der beskriver løsninger for JEE og applikations serveren tilfører en del features du kan benytte til en solid arkitektur omend det kan være komplekst. Men man ser mange der idag benytter spring boot eller lign og bygger små services. Personligt kan jeg gode lide der er isolation mellem applikationer og de feks har hvert deres runtime/applikations server/container så de ikke påvirker hinanden men det kræver en større investering i automatisering.

Der er mange veje idag synes jeg. Mange er i de senere år gået mod microservices, serverless osv men man ser også dem der går tilbage mod en monolit.  Hvad der passer best til dig er afhængig af dine behov og din organisations muligheder.
Avatar billede kim-allan Praktikant
10. maj 2019 - 10:23 #6
Hej Arne

Tak for svaret. Så det er mere en stil end best practice.

Ja, det er spring på java siden. Og ja, det laves med rest calls..

//Kim-Allan
Avatar billede kim-allan Praktikant
10. maj 2019 - 10:28 #7
Hej Simon

Tak for dit fine svar.

Det med skalerhed, det er også det vi diskutere. Jeg er personlig mere af den holding, at det er fint med et stort project. Men min makker, er mere til micro services. Og snakker om skalerhed. Og det hele ikke skal väre rodet sammen i en stor pärevälling. Men jeg synes, så ved man hvor det er fejlen er. Når det hele er samlet. Og ikke i alverdens små micro services. Er der ikke også alt for meget ekstra der skal laves for at have så mange små micro services?

Det skal lige siges, at vi koder ikke meget selv. Men vil godt styre hvordan retningen skal väre.

Fordelen for microservices som vi ser det er, at det er nemmere at få lavet en lille komponent. Men synes det er alt for svärt at få det til at snakke sammen.

//Kim-Allan
Avatar billede arne_v Ekspert
10. maj 2019 - 14:51 #8
Micro-services er ikke automatisk mere skalerbare. Men de er uafhængigt skalerbare.

Hvis du bundler services A, B og C i en single war og deployer paa N servere saa har du N instances af A, N af B og N af C. Hvis der er load paa A og du oeger N, saa er noedt til ogsaa at have flere B og C.

Hvis de er i separate war (eller standalone SE apps med embedded Tomcat/Jetty) og du deployer NA, NB og NC instances af A, B og C respektive, saa kan du oege NA uden at oege NB og NC.

Men for de fleste Java EE applikationer er skalerings problemerne ikke i app tier men i database tier.
Avatar billede simonvalter Praktikant
10. maj 2019 - 15:04 #9
Der kommer hurtigt en masse ting som man skal tage højde for for kommunikation mellem services så de opfører sig ordenligt i forhold til hinanden så måske er mere overskueligt for en enkelt service end sizing af de enkelte i forhold til hinanden . Det derfor man ser feks sidecars på kubernetes som håndterer ting som ratelimiting, circuit breakers eller api gateways for det tilsvarende og ting som at apply sikkerheds policies. Ting som logging og tracability igennem services skal håndteres så det ikke bliver uoverskueligt. Det alt sammen sjovt men man skal være en organisation der kan håndtere det. Og så vi ikke engang startet på governance delen.
Avatar billede Ny bruger Nybegynder

Din løsning...

Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.

Loading billede Opret Preview
Kategori
Kurser inden for grundlæggende programmering

Log ind eller opret profil

Hov!

For at kunne deltage på Computerworld Eksperten skal du være logget ind.

Det er heldigvis nemt at oprette en bruger: Det tager to minutter og du kan vælge at bruge enten e-mail, Facebook eller Google som login.

Du kan også logge ind via nedenstående tjenester