introduction
Le XNUMX mars, RedHat (bientôt IBM)
L'objectif est de faire de Java la plate-forme leader pour le déploiement de Kubernetes et le développement d'applications sans serveur, offrant aux développeurs une approche unifiée du développement dans des styles à la fois réactifs et impératifs.
Si vous regardez
Une très grande vitesse de lancement des applications et une faible consommation de mémoire sont promises. Voici les données du site Web du développeur :
Délai entre le début et la première réponse :
Configuration
REST
REST+JPA
Quarkus+GraalVM
0.014
0.055
Quarkus+OpenJDK
0.75
2.5
Pile native cloud traditionnelle*
4.3
9.5
Consommation mémoire (Mo) :
Configuration
REST
REST+JPA
Quarkus+GraalVM
13
35
Quarkus+OpenJDK
74
130
Pile native cloud traditionnelle*
140
218
Impressionnant, n'est-ce pas ?
*Je n'ai trouvé aucune information sur cette pile technologique, on peut supposer qu'il s'agit d'une sorte de Spring Boot avec un kit carrosserie supplémentaire.
Bonjour le monde!
L'application la plus simple écrite en Quarkus ressemblerait à ceci :
@Path("/hello")
public class GreetingResource {
@GET
@Produces(MediaType.TEXT_PLAIN)
public String hello() {
return "hello";
}
}
C'est littéralement un cours et ça suffit ! Vous pouvez exécuter l'application à l'aide de Maven en mode développement :
mvn compile quarkus:dev
…
$ curl http://localhost:8080/hello
hello
La différence avec une application classique est qu’il n’y a pas de classe Application ! Quarkus prend en charge le rechargement à chaud, vous pouvez donc modifier votre application sans la redémarrer, ce qui rend le développement encore plus rapide.
Et après? Vous pouvez ajouter un service à un contrôleur à l'aide d'une annotation
@ApplicationScoped
public class GreetingService {
public String greeting(String name) {
return "Hello " + name + "!";
}
}
Manette:
@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!
Notez que Quarkus utilise des annotations standard provenant de frameworks familiers - CDI et JAX-RS. Il n'est bien sûr pas nécessaire d'apprendre quoi que ce soit de nouveau si vous avez déjà travaillé avec CDI et JAX-RS.
Travailler avec la base de données
Les annotations Hibernate et JPA standard pour les entités sont utilisées. Comme pour les contrôleurs REST, vous devez écrire un minimum de code. Il suffit d'indiquer les dépendances dans le fichier assembleur, d'ajouter des annotations @Entity
et configurez la source de données dans application.properties.
Tous. Pas de sessionFactory, persistence.xml ou autres fichiers de service. Nous écrivons uniquement le code nécessaire. Toutefois, si nécessaire, vous pouvez créer un fichier persistence.xml et configurer plus finement la couche ORM.
Quarkus prend en charge la mise en cache des entités, les collections pour les relations un-à-plusieurs et les requêtes. À première vue, ça a l'air génial, mais c'est locale mise en cache, pour un nœud Kubernetes. Ceux. Les caches des différents nœuds ne sont pas synchronisés entre eux. J'espère que c'est temporaire.
Exécution de code asynchrone
Comme mentionné ci-dessus, Quarkus prend également en charge le style de programmation réactif. Le code de l'application précédente peut être écrit sous une forme différente.
@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 + "!";
});
}
}
Le code asynchrone peut également être transféré au service, le résultat sera le même.
Test
Les tests pour les applications Quarkus peuvent être écrits en JUnit4 ou JUnit5. Vous trouverez ci-dessous un exemple de test pour un point de terminaison, il est écrit en utilisant RestAssured, mais un autre framework peut être utilisé :
@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 + "!"));
}
}
L'annotation @QuarkusTest vous demande d'exécuter l'application avant d'exécuter les tests. Le reste est du code familier à tous les développeurs.
Application spécifique à la plateforme
Puisque Quarkus est étroitement intégré à GraalVM, il est bien sûr possible de générer du code spécifique à la plateforme. Pour ce faire, vous devez installer GraalVM et spécifier la variable d'environnement GRAALVM_HOME. Plus loin
mvn package -Pnative
Fait intéressant, l'application générée peut être testée. Et ceci est important car l’exécution du code natif peut différer de l’exécution sur la JVM. L'annotation @SubstrateTest exécute le code d'application spécifique à la plateforme. La réutilisation du code de test existant peut être effectuée en utilisant l'héritage ; par conséquent, le code pour tester une application dépendante de la plate-forme ressemblera à ceci :
@SubstrateTest
public class GreetingResourceIT extends GreetingResourceTest {
}
L'image générée peut être empaquetée dans Docker et exécutée dans Kubernetes ou OpenShift, décrite en détail dans
Инструментарий
Le framework Quarkus peut être utilisé avec Maven et Gradle. Maven est entièrement pris en charge, contrairement à Gradle. Malheureusement, pour le moment, Gradle ne prend pas en charge la génération d'un projet vide ; des informations détaillées sont disponibles sur le site Web.
expansion
Quarkus est un framework extensible. Il y a actuellement une commande
Conclusion
Quarkus s’inscrit selon moi tout à fait dans la tendance de l’époque. Le développement de code backend devient de plus en plus facile, et ce framework simplifie et accélère encore le développement de services en ajoutant la prise en charge native de Docker et Kubernetes. Un énorme avantage est la prise en charge intégrée de GraalVM et la génération d'images dépendantes de la plate-forme, qui permettent aux services de démarrer très rapidement et d'occuper peu d'espace mémoire. Et cela est très important à notre époque de passion massive pour les microservices et l’architecture sans serveur.
Site officiel -
Source: habr.com