# 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. In other words, this extension is a bridge from the Azure Functions HttpTrigger and the Quarkus family of HTTP APIs. 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_HOME` configured appropriately

- Apache Maven 3.9.3

- 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

- Azure CLI Installed

## 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/Gradle Project

You can generate the example code from Quarkus’s online application generator at this link.

You can also generate this example with the Quarkus CLI:

    quarkus create app --extension=quarkus-azure-functions-http

Add the `--gradle` switch if you want to generate a gradle project.

## Login to Azure

If you don’t log in to Azure you won’t be able to deploy.

    az login

## Quarkus dev mode

Quarkus dev mode works by just running your application as a HTTP endpoint. In dev mode there is no special interaction with the Azure Functions local runtime.

    ./mvnw clean package quarkus:dev

## Examining the project

If you open the `pom.xml` or `build.gradle` build file of the generated project you’ll see that the project is similar to any other Quarkus project. The `quarkus-azure-functions-http` extension is the integration point between Quarkus and Azure Functions.

The current implementation of the `quarkus-azure-functions-http` extension no longer requires the `azure-functions-maven-plugin` or gradle equivalent. Local development and Azure Functions packaging and deployment is now all done by Quarkus.

Build configuration is now all within `application.properties`. The only required configuration switch is `quarkus.azure-functions.app-name`.

## Azure Deployment Descriptors

The Azure Functions `host.json` deployment descriptor is automatically generated, but if you need to override it, declare it in the root directory of the project and 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`

## Login to Azure

If you don’t log in to Azure you won’t be able to deploy.

    az login

## Quarkus dev mode

Quarkus dev mode does not work currently with Azure Functions.

## Run locally in Azure Functions local environment

If you want to try this example within the local Azure Functions environment, you can use this command

    ./mvnw quarkus:run

or

    ./gradlew --info --no-daemon quarkusRun

Gradle is a bit quirky with process management, so you need the `--no-daemon` switch or control-c will not destroy the process cleanly and you’ll have open ports.

Note that you must have the Azure Functions Core Tools installed for this to work!

The URL to access the example would be:

http://localhost:8081/api/hello

## Quarkus Integration Testing

You can implement integration tests using `@QuarkusIntegrationTest` functionality. When these integration tests run, the local Azure Functions environment will be spun up for the duration of integration testing.

For maven:

    ./mvnw -DskipITs=false verify

Make sure any integration tests you execute with maven use the `*IT.java` file pattern so that regular builds do not execute the test.

For Gradle:

    ./gradlew --info quarkusIntTest

Make sure any integration tests you execute with Gradle are located within `src/integrationTest/java`. Integration tests that exist in `src/test` will run with normal build and fail.

## Deploy to Azure

The `quarkus-azure-functions-http` extension handles all the work to deploy to Azure. By default, Quarkus will use the Azure CLI in the background to authenticate and deploy to Azure. If you have multiple subscriptions associated with your account, you must set the `quarkus.azure-functions.subscription-id` property in your `application.properties` file to the subscription you want to use. For other authentication mechanisms and deployment options see our config properties here.

To run the deploy, after you build your project execute:

    ./mvnw quarkus:deploy

or

    ./gradlew --info deploy

If deployment is a success, Quarkus will output the endpoint URL of the example function to the console For Gradle, you must use the `--info` switch to see this output!

i.e.

    [INFO] HTTP Trigger Urls:
    [INFO]          HttpExample : https://{appName}.azurewebsites.net/api/{*path}

The URL to access the service would be something like

https://{appName}.azurewebsites.net/api/hello