Paraqitje
Më XNUMX mars, RedHat (së shpejti IBM)
Qëllimi është ta bëjmë Java platformën kryesore për vendosjen e Kubernetes dhe zhvillimin e aplikacioneve pa server, duke u ofruar zhvilluesve një qasje të unifikuar ndaj zhvillimit si në stilin reaktiv ashtu edhe në atë imperativ.
Nëse shikoni
Premtohet shpejtësi shumë e lartë e nisjes së aplikacionit dhe konsum i ulët i memories. Këtu janë të dhënat nga faqja e internetit e zhvilluesit:
Koha nga fillimi deri në përgjigjen e parë:
konfiguracion
Rest
REST+JPA
Quarkus+GraalVM
0.014
0.055
Quarkus+OpenJDK
0.75
2.5
Stack tradicional i Cloud Native*
4.3
9.5
Konsumi i memories (Mb):
konfiguracion
Rest
REST+JPA
Quarkus+GraalVM
13
35
Quarkus+OpenJDK
74
130
Stack tradicional i Cloud Native*
140
218
Impresionuese, apo jo?
*Nuk gjeta asnjë informacion në lidhje me këtë grumbull teknologjie, mund të supozojmë se kjo është një lloj çizme pranverore me një komplet shtesë trupi.
Përshendetje Botë!
Aplikacioni më i thjeshtë i shkruar në Quarkus do të dukej kështu:
@Path("/hello")
public class GreetingResource {
@GET
@Produces(MediaType.TEXT_PLAIN)
public String hello() {
return "hello";
}
}
Është fjalë për fjalë një klasë dhe mjafton! Mund ta ekzekutoni aplikacionin duke përdorur Maven në modalitetin e zhvillimit:
mvn compile quarkus:dev
…
$ curl http://localhost:8080/hello
hello
Dallimi nga një aplikacion i rregullt është se nuk ka klasë Application! Quarkus mbështet rifreskimin e nxehtë, kështu që ju mund të ndryshoni aplikacionin tuaj pa e rifilluar atë, duke e bërë zhvillimin edhe më të shpejtë.
Ç'pritet më tej? Ju mund t'i shtoni një shërbim një kontrolluesi duke përdorur një shënim
@ApplicationScoped
public class GreetingService {
public String greeting(String name) {
return "Hello " + name + "!";
}
}
Kontrolluesi:
@Path("/hello")
public class GreetingResource {
@Inject
GreetingService service;
@GET
@Produces(MediaType.TEXT_PLAIN)
@Path("/{name}")
public String greeting(@PathParam("name") String name) {
return service.greeting(name);
}
}
$ curl http://localhost:8080/hello/developer
Hello developer!
Vini re se Quarkus përdor shënime standarde nga kornizat e njohura - CDI dhe JAX-RS. Nuk ka nevojë të mësoni asgjë të re nëse keni punuar më parë me CDI dhe JAX-RS, sigurisht.
Puna me bazën e të dhënave
Përdoren shënime hibernate dhe standarde JPA për entitetet. Ashtu si me kontrollorët REST, ju duhet të shkruani një minimum kodi. Mjafton të tregoni varësitë në skedarin e montimit, të shtoni shënime @Entity
dhe konfiguroni burimin e të dhënave në aplikacion.vetitë.
Të gjitha. Nuk ka sesionFactory, persistence.xml ose skedarë të tjerë shërbimi. Ne shkruajmë vetëm kodin që nevojitet. Megjithatë, nëse është e nevojshme, mund të krijoni një skedar persistence.xml dhe të konfiguroni më hollësisht shtresën ORM.
Quarkus mbështet ruajtjen në memorie të entiteteve, koleksione për marrëdhënie një-në-shumë dhe pyetje. Në pamje të parë duket e mrekullueshme, por është lokal caching, për një nyje Kubernetes. Ato. Memoriet e fshehta të nyjeve të ndryshme nuk janë të sinkronizuara me njëra-tjetrën. Shpresoj se kjo është e përkohshme.
Ekzekutimi i kodit asinkron
Siç u përmend më lart, Quarkus gjithashtu mbështet stilin e programimit reaktiv. Kodi i aplikacionit të mëparshëm mund të shkruhet në një formë tjetër.
@Path("/hello")
public class GreetingResource {
@GET
@Produces(MediaType.TEXT_PLAIN)
@Path("/{name}")
public CompletionStage<String> greeting(@PathParam("name") String name) {
return CompletableFuture.supplyAsync(() -> {
return "Hello " + name + "!";
});
}
}
Kodi asinkron gjithashtu mund të transferohet në shërbim, rezultati do të jetë i njëjtë.
Testimi
Testet për aplikimet e Quarkus mund të shkruhen në JUnit4 ose JUnit5. Më poshtë është një shembull testi për një pikë përfundimtare, ai është shkruar duke përdorur RestAssured, por mund të përdoret një kornizë tjetër:
@QuarkusTest
public class GreetingResourceTest {
@Test
public void testGreetingEndpoint() {
String uuid = UUID.randomUUID().toString();
given()
.pathParam("name", uuid)
.when().get("/hello/{name}")
.then()
.statusCode(200)
.body(is("Hello " + uuid + "!"));
}
}
Shënimi @QuarkusTest ju udhëzon të ekzekutoni aplikacionin përpara se të ekzekutoni testet. Pjesa tjetër është kod i njohur për të gjithë zhvilluesit.
Aplikim specifik për platformën
Meqenëse Quarkus është i integruar ngushtë me GraalVM, sigurisht që është e mundur të gjenerohet kodi specifik për platformën. Për ta bërë këtë, duhet të instaloni GraalVM dhe të specifikoni variablin e mjedisit GRAALVM_HOME. Me tutje
mvn package -Pnative
Është interesante se aplikacioni i krijuar mund të testohet. Dhe kjo është e rëndësishme sepse ekzekutimi i kodit vendas mund të ndryshojë nga ekzekutimi në JVM. Shënimi @SubstrateTest ekzekuton kodin e aplikacionit specifik për platformën. Ripërdorimi i kodit ekzistues të testit mund të bëhet duke përdorur trashëgiminë; si rezultat, kodi për testimin e një aplikacioni të varur nga platforma do të duket si ky:
@SubstrateTest
public class GreetingResourceIT extends GreetingResourceTest {
}
Imazhi i krijuar mund të paketohet në Docker dhe të ekzekutohet në Kubernetes ose OpenShift, i përshkruar në detaje në
mjete
Korniza Quarkus mund të përdoret me Maven dhe Gradle. Maven mbështetet plotësisht, ndryshe nga Gradle. Fatkeqësisht, për momentin Gradle nuk e mbështet krijimin e një projekti bosh; ka informacion të detajuar në faqen e internetit
zgjerim
Quarkus është një kornizë e zgjerueshme. Aktualisht ka një porosi
Përfundim
Për mendimin tim, Quarkus është mjaft në përputhje me trendet e kohës. Zhvillimi i kodit të Backend-it po bëhet më i lehtë dhe më i lehtë, dhe kjo kornizë thjeshton dhe shpejton më tej zhvillimin e shërbimit duke shtuar mbështetje vendase për Docker dhe Kubernetes. Një plus i madh është mbështetja e integruar për GraalVM dhe gjenerimi i imazheve të varura nga platforma, i cili lejon shërbimet të fillojnë me të vërtetë shpejt dhe të zënë pak hapësirë memorie. Dhe kjo është shumë e rëndësishme në kohën tonë të pasionit masiv për mikroshërbimet dhe arkitekturën pa server.
Faqja zyrtare -
Burimi: www.habr.com