Azure Functions with RESTEasy Reactive, Undertow, or Reactive Routes
The quarkus-azure-functions-http extension allows you to write microservices with RESTEasy Reactive (our Jakarta REST implementation),
Undertow (servlet), Reactive Routes, or Funqy HTTP and make these microservices deployable to the Azure Functions runtime.
One azure function deployment can represent any number of Jakarta REST, servlet, Reactive Routes, or Funqy HTTP endpoints.
|
This technology is considered preview. In preview, backward compatibility and presence in the ecosystem is not guaranteed. Specific improvements might require changing configuration or APIs, and plans to become stable are under way. Feedback is welcome on our mailing list or as issues in our GitHub issue tracker. For a full list of possible statuses, check our FAQ entry. |
| Only text based media types are supported at the moment as Azure Functions HTTP Trigger for Java does not support a binary format |
Prerequisites
To complete this guide, you need:
-
Roughly 15 minutes
-
An IDE
-
JDK 11+ installed with
JAVA_HOMEconfigured appropriately -
Apache Maven 3.8.8
-
Optionally the Quarkus CLI if you want to use it
-
Optionally Mandrel or GraalVM installed and configured appropriately if you want to build a native executable (or Docker if you use a native container build)
-
An Azure Account. Free accounts work.
-
Azure Functions Core Tools version 4.x
Solution
This guide walks you through running a maven project that can deploy a Resteasy Reactive endpoint to Azure Functions. While only Jakarta REST is provided as an example, you can easily replace it with the HTTP framework of your choice.
Creating the Maven Deployment Project
You can download the example code from Quarkus’s application generator at this link.
You can also generate this example with the Quarkus CLI:
quarkus create app --extension=quarkus-azure-functions-httpQuarkus dev mode
Quarkus dev mode works by just running your application as a HTTP endpoint.
./mvnw clean package quarkus:devRun locally in Azure Functions simulated environment
If you want to try your app with a simulated local Azure Functions environment, you can use this command
./mvnw clean package azure-functions:runNote that you must have the Azure Functions Core Tools installed for this to work!
Deploy to Azure
The pom.xml you generated in the previous step pulls in the azure-functions-maven-plugin. Running maven package
generates config files and a staging directory required by the azure-functions-maven-plugin. Here’s
how to execute it.
./mvnw clean package azure-functions:deployIf deployment is a success, the azure plugin will tell you the base URL to access your function.
i.e.
[INFO] HTTP Trigger Urls:
[INFO] QuarkusHttp : https://{appName}.azurewebsites.net/api/{*path}The URL to access the service would be
Extension maven dependencies
You must include the quarkus-azure-functions-http extension as this is a generic bridge between the Azure Functions
runtime and the HTTP framework you are writing your microservices in.
Azure Deployment Descriptors
Templates for Azure Functions deployment descriptors (host.json, function.json) are within
the base directory of the project. Edit them as you need to. Rerun the build when you are ready.
Configuring Root Paths
The default route prefix for an Azure Function is /api. All of your Jakarta REST, Servlet, Reactive Routes, and Funqy HTTP endpoints must
explicitly take this into account. In the generated project this is handled by the
quarkus.http.root-path switch in application.properties
