Java kode Best practice

Det kan lige sige, at det skal kunne deployes på en tomcat eller wildfly..

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.

Jeg formoder at I bruger:

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

og ikke bruger IDE til at lave de officielle builds med.

En war file som kun bruger java.* og javax.* klasser boer deploye fint paa baade Tomcat og WildFly.

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.

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

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

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.

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.