Azure Functions (Serverless) with RESTEasy Reactive, Undertow, or Reactive Routes
quarkus-azure-functions-http extension allows you to write microservices with RESTEasy Reactive (JAX-RS),
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 JAX-RS, 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|
To complete this guide, you need:
Roughly 15 minutes
JDK 11+ installed with
Apache Maven 3.8.1+
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.
This guide walks you through running a Maven Archetype to generate a sample project that contains three http endpoints written with JAX-RS APIs, Servlet APIs, Reactive Routes, or Funqy HTTP APIs. After building, you will then be able to deploy to Azure.
Create the Azure Maven project for your Quarkus application using our Maven Archetype.
mvn archetype:generate \ -DarchetypeGroupId=io.quarkus \ -DarchetypeArtifactId=quarkus-azure-functions-http-archetype \ -DarchetypeVersion=2.13.0.Final
Running this command will run maven in interactive mode and it will ask you to fill in some build properties:
groupId- The maven groupId of this generated project. Type in
artifactId- The maven artifactId of this generated project. Type in
version- Version of this generated project.
package- defaults to
appName- Use the default value. This is the application name in Azure. It must be a unique subdomain name under
*.azurewebsites.net. Otherwise, deploying to Azure will fail.
appRegion- Defaults to
westus. Dependent on your azure region.
function- Use the default which is
quarkus. Name of your azure function. Can be anything you want.
resourceGroup- Use the default value. Any value is fine though.
The values above are defined as properties in the generated
pom.xml you generated in the previous step pulls in the
azure-functions-maven-plugin. Running maven install
generates config files and a staging directory required by the
how to execute it.
./mvnw clean install azure-functions:deploy
If you haven’t already created your function up at azure, then build an uber-jar, package it, create the function at Azure, and deploy it.
If deployment is a success, the azure plugin will tell you the base URL to access your function.
Successfully deployed the artifact to https://quarkus-demo-123451234.azurewebsites.net
The URL to access the service would be
The sample project includes the RESTEasy Reactive, Undertow, Reactive Routes, Funqy HTTP extensions. If you are only using one of those
APIs (i.e. jax-rs only), respectively remove the maven dependency
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.
Templates for Azure Functions deployment descriptors (
function.json) are within
azure-config directory. Edit them as you need to. Rerun the build when you are ready.
NOTE: If you change the
path attribute or if you add a
your jax-rs endpoints won’t route correctly. See Configuring Root Paths for more information.
The default route prefix for an Azure Function is
/api. All of your JAX-RS, 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
If you modify the
path or add a
routePrefix within the
deployment descriptor, your code or configuration must also reflect any prefixes you specify for your path.