Quarkus

Quarkus is a Cloud Native, (Linux) Container First framework designed for writing Java applications. It is optimized for containerized environments and Kubernetes by embracing 12-factor architecture.

Key features include:

• Container First: Minimal footprint applications optimized for containers.
• Fast Startup: Performs more work at build time to ensure rapid startup.
• Dual Runtime Support: Supports the JVM for high throughput and Native (via GraalVM) for constrained environments.
• Unified Programming Model: Unifies imperative and reactive (non-blocking) development styles under one framework.
• Standards-based: Built upon industry standards such as RESTEasy/JAX-RS, Hibernate ORM/JPA, Netty, Eclipse Vert.x, Eclipse MicroProfile, and Apache Camel.

Quarkus Security supports multiple authentication mechanisms, some built-in and others provided via extensions. You can combine mechanisms, and the authentication process completes as soon as the first mechanism produces a SecurityIdentity.

Common Authentication Requirements Mapping

You can deploy Quarkus HTTP frameworks (Quarkus REST, Undertow, Reactive Routes, or Funqy HTTP) to AWS Lambda using either the AWS Gateway HTTP API or the AWS Gateway REST API.

To avoid conflicts, use only one HTTP framework with the corresponding AWS Lambda extension:

• For AWS Gateway HTTP API: Use the quarkus-amazon-lambda-http extension.
• For AWS Gateway REST API: Use the quarkus-amazon-lambda-rest extension.

Deployments can be made as a pure Java JAR or as a native executable (via GraalVM) for reduced memory footprint and faster startup times. Quarkus automatically generates SAM (Serverless Application Model) deployment files.

The io.quarkus:quarkus-azure-functions-http extension acts as a bridge between the Azure Functions HttpTrigger and various Quarkus HTTP frameworks, including Jakarta REST (Quarkus REST), Undertow (Servlet), Reactive Routes, or Funqy HTTP.

One single Azure Function deployment can represent multiple endpoints from your chosen framework.

Note: Currently, only text-based media types are supported because the Azure Functions HTTP Trigger for Java does not support binary formats.

The SmallRye Stork integration in Quarkus supports the following clients:

• REST Client
• gRPC clients (using the Vert.x gRPC client is recommended)

Note: The gRPC client integration does not support statistic-based load balancers.

A Quarkus extension acts as an adapter layer that integrates a library or technology into the Quarkus architecture. This allows developers to leverage Quarkus's performance benefits, such as build-time optimizations and native compilation support, for existing ecosystem libraries.

An extension is composed of two distinct modules:

1. Runtime Module: Contains the actual capabilities exposed to the application developer (e.g., an API, a filter, or a data layer). This is the artifact users add as a dependency in their Maven or Gradle files.
2. Deployment Module: Used during the Augmentation phase of the build. It describes how to 'deploy' the library by applying Quarkus optimizations and preparing metadata for GraalVM native compilation. Users should never add deployment modules as application dependencies.

SmallRye Stork is a service discovery and load-balancing library used in distributed systems to manage interactions between services. It handles two distinct phases:

1. Service Discovery: The process of locating service instances (e.g., finding all instances of a service registered in Consul or Kubernetes). This results in a list of available instances.
2. Service Selection (Load-Balancing): The process of choosing the best single instance from the list provided by discovery (e.g., using a round-robin strategy). This results in a single service instance or an exception if none are suitable.

Stork does not handle the actual network communication with the service; it only provides the location (address/port) of the selected instance. Quarkus integrations then use this location to perform the actual REST calls.

A bean is a container-managed object that supports services like dependency injection, lifecycle callbacks, and interceptors. Instead of controlling the lifecycle directly, you use declarative means like annotations. The container (the environment where your application runs) creates and destroys bean instances, associates them with a context, and injects them into other beans.

Common class-based beans use annotations like @ApplicationScoped to define their context and @Inject to declare dependencies.

import jakarta.inject.Inject;
import jakarta.enterprise.context.ApplicationScoped;

@ApplicationScoped
public class Translator {

    @Inject
    Dictionary dictionary;

    String translate(String sentence) {
      // ...
    }
}