Cursos que formaram meu caráter: Desenvolvimento web com Quarkus - API First com o OpenAPI Generator para APIs reativas
Tags: gradle, openapi, quarkus, async
Published: 2022-12-17 21:12:42

---
title: Cursos que formaram meu caráter: Desenvolvimento web com Quarkus - API First com o OpenAPI Generator para APIs reativas
published: true
description: O que aprendi com cursos realizados e como apliquei outras técnicas conhecidas para evoluí-los
tags: gradle, openapi, quarkus, async
cover_image: https://dev-to-uploads.s3.amazonaws.com/uploads/articles/m8uazy3rfnxc4ha6mn6r.jpg
# published_at: 2022-12-17 15:23 +0000
---

> "Todo ato de criação é, antes de tudo, um ato de destruição" Pablo Picasso

Neste sexto post falaremos sobre geração de APIs reativas.

Esse artigo faz parte de uma série, abaixo é possível encontrar a [lista completa de artigos](#serie_completa).

Estamos nos baseando no curso [Desenvolvimento web com Quarkus](https://www.udemy.com/course/des-web-quarkus) do @viniciusfcf.

O repositório que estamos utilizando é:

{% embed https://gitlab.com/arthurfnsc-udemy/desenvolvimento-web-quarkus/ifood/ %}

---

## OpenAPI Generator e APIs reativas

O segundo módulo ministrado por Vinícius nos apresenta problemas que a solução está mais alinhada com assincronismo.

Como estava seguindo a abordagem de [API First com OpenAPI Generator para endpoints REST](https://dev.to/arthurfnsc/cursos-que-formaram-meu-carater-desenvolvimento-web-com-quarkus-api-first-com-o-openapi-generator-42pm) fui procurar se existia alguma forma de se fazer isso com o plugin.

Vi que a abordagem que estávamos utilizando era o Mutiny, e acabei caindo nessa issue que [tbredzin](https://github.com/tbredzin) abriu um Pull Request:

{% embed https://github.com/OpenAPITools/openapi-generator/pull/10919 %}

> Since version 2.1, JAX-RS server side component has support for returning a CompletionStage to mark the request as eligible for asynchronous processing. The advantage this approach has over the AsyncResponse based API is that it is richer and allows you to create asynchronous pipelines.

> It is also extended by 3rd party libraries such as Reactor, RxJava or Mutiny. All of those allow to convert from/to CompletionStage, examples:

> Reactor

```java
CompletionStage<String> single = Mono.just("something").toFuture();
CompletionStage<List<String>> many = Flux.just("something", "somethingelse")
                .collectList()
                .toFuture()
```

> RxJava3

```java
CompletionStage<String> single = Maybe.just("something").toCompletionStage();
CompletionStage<List<String>> many = Flowable.fromArray("something", "somethingelse")
                .toList()
                .toCompletionStage();
```

> Mutiny

```java
CompletionStage<String> single = Uni.createFrom().item("something").subscribeAsCompletionStage();
CompletionStage<List<String> many = Multi.createFrom().items("something", "somethingelse")
                .collect()
                .asList()
                .subscribeAsCompletionStage();
```

Pensei, porque não? Vamos ver no que isso vai dar...

Podemos ver a configuração utilizando **API-First** em nosso projeto nos arquivos **applications/marketplace/build.gradle**:

```groovy
apply from: "$rootDir/plugins/openapigen_marketplace.gradle"
```

E no arquivo **plugins/openapigen_marketplace.gradle**:

```groovy
import org.openapitools.generator.gradle.plugin.tasks.GenerateTask

buildscript {
    repositories {
        mavenLocal()
        maven { url "https://repo1.maven.org/maven2" }
    }
    dependencies {
        classpath "org.openapitools:openapi-generator-gradle-plugin:$openApiGenVersion"
    }
}

apply plugin: 'org.openapi.generator'

def apiServerOutput = "$buildDir/generated/openapi-code-server".toString()

task generatePratosApiServer(type: GenerateTask) {
    generatorName = "jaxrs-spec"
    inputSpec = "$projectDir/src/main/resources/openapi/pratos_v1.yml".toString()
    outputDir = apiServerOutput
    apiPackage = "org.openapi.server.v1.pratos.api"
    invokerPackage = "org.openapi.v1.pratos.invoker"
    modelPackage = "org.openapi.v1.pratos.model"
    configOptions = [
        "dateLibrary"            : "java8",
        "hideGenerationTimestamp": "true",
        "interfaceOnly"          : "true",
        "supportAsync"           : "true",
        "useOptional"            : "true",
        "useBeanValidation"      : "false",
        "useSwaggerAnnotations"  : "false"
    ]
}

task generateRestaurantesApiServer(type: GenerateTask) {
    generatorName = "jaxrs-spec"
    inputSpec = "$projectDir/src/main/resources/openapi/restaurantes_v1.yml".toString()
    outputDir = apiServerOutput
    apiPackage = "org.openapi.server.v1.restaurantes.api"
    invokerPackage = "org.openapi.v1.restaurantes.invoker"
    modelPackage = "org.openapi.v1.restaurantes.model"
    configOptions = [
        "dateLibrary"            : "java8",
        "hideGenerationTimestamp": "true",
        "interfaceOnly"          : "true",
        "supportAsync"           : "true",
        "useOptional"            : "true",
        "useBeanValidation"      : "false",
        "useSwaggerAnnotations"  : "false"
    ]
}

compileJava.dependsOn(
    generatePratosApiServer, generateRestaurantesApiServer
)

sourceSets.main.java.srcDir "$apiServerOutput/src/gen/java"
```

No [post anterior](https://dev.to/arthurfnsc/cursos-que-formaram-meu-carater-desenvolvimento-web-com-quarkus-api-first-com-o-openapi-generator-42pm) explicamos várias dessas configurações, o que ficou faltando foi só a **supportAsync** que como o próprio nome já diz, habilita ou não o suporte a APIs assíncronas.

Nesse projeto também optei por criar 2 APIs para a geração, uma para pratos (**"$projectDir/src/main/resources/openapi/pratos_v1.yml".toString()**) e outra para restaurantes (**"$projectDir/src/main/resources/openapi/restaurantes_v1.yml".toString()**).

Quando executamos a fase **compileJava** ou tasks que dependem dela podemos ver que a seguinte estrutura foi criada em **applications/marketplace/build**:

![Generated source](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/hwwkt0b7trdphxe3e253.png)

Analisando as classes geradas, temos **PratoAPI**:

```java
package org.openapi.server.v1.pratos.api;

import org.openapi.v1.pratos.model.Prato;
import javax.ws.rs.*;
import javax.ws.rs.core.Response;
import java.util.concurrent.CompletionStage;
import java.util.concurrent.CompletableFuture;
import java.io.InputStream;
import java.util.Map;
import java.util.List;

@Path("/pratos")
@javax.annotation.Generated(value = "org.openapitools.codegen.languages.JavaJAXRSSpecServerCodegen")
public interface PratosApi {

    @GET
    @Produces({ "application/json" })
    CompletionStage<List<Prato>> recuperaPratosRestaurante();
}

```

E **RestaurantesAPI**:

```java
package org.openapi.server.v1.restaurantes.api;

import org.openapi.v1.restaurantes.model.Prato;
import javax.ws.rs.*;
import javax.ws.rs.core.Response;
import java.util.concurrent.CompletionStage;
import java.util.concurrent.CompletableFuture;
import java.io.InputStream;
import java.util.Map;
import java.util.List;


@Path("/restaurantes/{idRestaurante}/pratos")
@javax.annotation.Generated(value = "org.openapitools.codegen.languages.JavaJAXRSSpecServerCodegen")
public interface RestaurantesApi {

    @GET
    @Produces({ "application/json" })
    CompletionStage<List<Prato>> recuperaPratosRestaurante(@PathParam("idRestaurante") Long idRestaurante);
}
```

E seguindo com a nossa configuração, precisamos implementar um classe concreta para definir como o método vai funcionar:

**applications/marketplace/src/main/java/com/gitlab/arthurfnsc/ifood/marketplace/PratoResource**:

```java
package com.gitlab.arthurfnsc.ifood.marketplace;

import io.smallrye.mutiny.Multi;
import java.util.List;
import java.util.concurrent.CompletionStage;
import javax.ws.rs.Consumes;
import javax.ws.rs.Path;
import javax.ws.rs.Produces;
import javax.ws.rs.core.MediaType;
import org.openapi.server.v1.pratos.api.PratosApi;
import org.openapi.v1.pratos.model.Prato;

@Path("/pratos")
@Produces(MediaType.APPLICATION_JSON)
@Consumes(MediaType.APPLICATION_JSON)
public class PratoResource implements PratosApi {

    @Override
    public CompletionStage<List<Prato>> recuperaPratosRestaurante() {
        Multi<Prato> pratos = com.gitlab.arthurfnsc.ifood.marketplace.Prato.recuperaPratosApi();
        return pratos.collect().asList().subscribeAsCompletionStage();
    }
}
```

**applications/marketplace/src/main/java/com/gitlab/arthurfnsc/ifood/marketplace/RestauranteResource**:

```java
package com.gitlab.arthurfnsc.ifood.marketplace;

import io.smallrye.mutiny.Multi;
import java.util.List;
import java.util.concurrent.CompletionStage;
import javax.ws.rs.Consumes;
import javax.ws.rs.Path;
import javax.ws.rs.Produces;
import javax.ws.rs.core.MediaType;
import org.openapi.server.v1.restaurantes.api.RestaurantesApi;

@Path("/restaurantes")
@Produces(MediaType.APPLICATION_JSON)
@Consumes(MediaType.APPLICATION_JSON)
public class RestauranteResource implements RestaurantesApi {

    @Override
    public CompletionStage<List<org.openapi.v1.restaurantes.model.Prato>> recuperaPratosRestaurante(
        Long idRestaurante
    ) {
        Multi<org.openapi.v1.restaurantes.model.Prato> pratos = com.gitlab.arthurfnsc.ifood.marketplace.Prato.recuperaPratosApi(
            idRestaurante
        );
        return pratos.collect().asList().subscribeAsCompletionStage();
    }
}
```

Na classe **Prato**, no mesmo pacote do nosso resource implementamos os seguintes métodos:

```java
package com.gitlab.arthurfnsc.ifood.marketplace;

...

public class Prato extends PanacheEntityBase {

    ...
    public static Multi<org.openapi.v1.pratos.model.Prato> recuperaPratosApi() {
        return findAll()
            .stream()
            .map(p -> (Prato) p)
            .onItem()
            .transform(PratoMapper::paraPratoApi);
    }

    public static Multi<org.openapi.v1.restaurantes.model.Prato> recuperaPratosApi(
        Long idRestaurante
    ) {
        return find("restaurante.id", idRestaurante)
            .stream()
            .map(p -> (Prato) p)
            .onItem()
            .transform(PratoMapper::paraPratoRestauranteApi);
    }
    ...
}
```

Essa minha abordagem de ter 2 **OpenAPIs** gerou um problema que pode ser percebido no código acima. Vocês podem percebem que acabaram sendo geradas 2 classes **Prato**, uma em **org.openapi.v1.pratos.model.Prato** e outra em **org.openapi.v1.restaurantes.model.Prato** o que me deixou 2 métodos muito parecidos, com uma diferença do método de transformação chamado.

No caso da solução do Vinícius as [Resources dele](https://github.com/viniciusfcf/udemy-quarkus/tree/master/marketplace/src/main/java/com/github/viniciusfcf/ifood/mp) retornam **Multi**:

```java
package com.github.viniciusfcf.ifood.mp;

...
import io.smallrye.mutiny.Multi;

public class PratoResource {

    @Inject
    PgPool pgPool;

    @GET
    @APIResponse(responseCode = "200", content = @Content(schema = @Schema(type = SchemaType.ARRAY, implementation = PratoDTO.class)))
    public Multi<PratoDTO> buscarPratos() {
        return Prato.findAll(pgPool);
    }
}
```

```java
package com.github.viniciusfcf.ifood.mp;

...
import io.smallrye.mutiny.Multi;

public class RestauranteResource {

    @Inject
    PgPool client;

    @GET
    @Path("{idRestaurante}/pratos")
    public Multi<PratoDTO> buscarPratos(@PathParam("idRestaurante") Long idRestaurante) {
        return Prato.findAll(client, idRestaurante);
    }
}
```

Como estamos trabalhando com **CompletionStage** ao invés de **Multi**, vamos ver se aquela dica do [tbredzin](https://github.com/tbredzin) funciona:

**PratoResource**

```java
    @Override
    public CompletionStage<List<Prato>> recuperaPratosRestaurante() {
        Multi<Prato> pratos = com.gitlab.arthurfnsc.ifood.marketplace.Prato.recuperaPratosApi();
        return pratos
            .collect()
            .asList()
            .subscribeAsCompletionStage();
    }
```

**RestauranteResource**

```java
    @Override
    public CompletionStage<List<org.openapi.v1.restaurantes.model.Prato>> recuperaPratosRestaurante(
        Long idRestaurante
    ) {
        Multi<org.openapi.v1.restaurantes.model.Prato> pratos = com.gitlab.arthurfnsc.ifood.marketplace.Prato.recuperaPratosApi(
            idRestaurante
        );
        return pratos
            .collect()
            .asList()
            .subscribeAsCompletionStage();
    }
```

{% embed https://giphy.com/gifs/manutd-ronaldo-mufc-crisitano-HMpcgxAZs5YYHsbe8P %}

Você pode ter percebido que não interagimos com o **PgPool** como o Vinícius. Isso se deve ao fato de conseguirmos usar o hibernate em uma solução reativa, o que ainda estava em fase beta quando o Vinícius fez o curso dele. Falaremos mais sobre o **quarkus-hibernate-reactive-panache** adiante.

---

## Considerações finais

Quando estava fazendo essa abordagem fiquei com dúvida se essa era uma boa implementação. Afinal, qual a diferença entre um **Multi** ou **Uni** e um **CompletionStage**? O seguinte link me ajudou um pouco a entender que eles não são a mesma coisa:

{% embed https://smallrye.io/smallrye-mutiny/1.7.0/guides/completion-stage/ %}

> While CompletionStage and CompletableFuture are close to Uni in terms of use case, there are some fundamental differences.

> CompletionStage are eager. When a method returns a CompletionStage, the operation has already been triggered. The outcome is used to complete the returned CompletionStage. On the other side, Unis are lazy. The operation is only triggered once there is a subscription.

> CompletionStage caches the outcome. So, once received, you can retrieve the result. Every retrieval will get the same result. With Uni, every subscription has the opportunity to re-trigger the operation and gets a different result.

Segue também um outro link bem interessante:

{% embed https://smallrye.io/smallrye-mutiny/1.7.0/tutorials/transforming-items-asynchronously/ %}

### Sobre a utilização de OpenAPI Gen para APIs reativas

Bem, essa foi a primeira implementação que fiz, e portanto não consegui abstrair maiores problemas. Como não estressei a solução em vários projetos, não seria algo que eu colocaria em produção em um cliente. Ao meu modo de ver, é importante validar outros cenários mais complexos.

Mas achei bem interessante essa possibilidade do plugin.

No próximo post falaremos sobre uma solução da **OWASP** para validação de vulnerabilidade em nossas bibliotecas.

---

<a name="serie_completa"></a>

Esse post faz parte de uma série sobre **Cursos que formaram meu caráter: Desenvolvimento web com Quarkus**.

A série completa é:

* [Talk is cheap show me the code](https://dev.to/arthurfnsc/cursos-que-formaram-meu-carater-desenvolvimento-web-com-quarkus-talk-is-cheap-show-me-the-code-2k91)
* [Utilizando Gradle ao invés de Maven](https://dev.to/arthurfnsc/cursos-que-formaram-meu-carater-utilizando-gradle-ao-inves-de-maven-1lcn)
* [Plugins do Gradle: Gerenciador de versões de bibliotecas com Versions](https://dev.to/arthurfnsc/cursos-que-formaram-meu-carater-desenvolvimento-web-com-quarkus-gerenciador-de-versoes-de-bibliotecas-com-versions-9na)
* [Plugins do Gradle: Saudades do  Maven, relatórios com Project-report](https://dev.to/arthurfnsc/cursos-que-formaram-meu-carater-desenvolvimento-web-com-quarkus-saudades-do-maven-relatorios-com-project-report-51d6)
* [Plugins do Gradle: API First com o OpenAPI Generator](https://dev.to/arthurfnsc/cursos-que-formaram-meu-carater-desenvolvimento-web-com-quarkus-api-first-com-o-openapi-generator-42pm)
* Plugins do Gradle: API First com o OpenAPI Generator para APIs reativas
* [Plugins do Gradle: Validação de vulnerabilidades de dependências com OWASP Dependency Check](https://dev.to/arthurfnsc/cursos-que-formaram-meu-carater-desenvolvimento-web-com-quarkus-validacao-de-vulnerabilidades-com-owasp-dependency-check-2a2l)
* Plugins do Gradle: Lint com Spotless [não publicado]
* GitLab: Motivação para a escolha [não publicado]
* GitLab: Considerações sobre o Prettier em pipelines [não publicado]
* Gitmoji [não publicado]
* SDK Man [não publicado]
* Pré commit hook [não publicado]
* application.yml: Utilizando YML em propriedades de aplicação [não publicado]
* application.yml: Utilizando variáveis de ambiente [não publicado]
* application.yml: Sobrescrevendo opções em teste [não publicado]
* Mapstruct: Utilizando expressões para mapeamentos [não publicado]
* Microprofile SecurityScheme: Sobrescrevendo tokenUrl [não publicado]
* Prometheus: O problema simples que me custou algumas horas [não publicado]
* quarkus-hibernate-reactive-panache: Utilizando as vantagens do Hibernate em projetos reativos [não publicado]
* Testcontainers: Configuração para projetos reativos [não publicado]