El marco de Quarkus: cómo se implementa la arquitectura limpia en él

¡Hola, Habr!



A medida que continuamos con nuestra exploración de nuevos marcos de Java y su interés en el libro Spring Boot, estamos analizando el nuevo marco de Quarkus para Java. Puede encontrar una descripción detallada del mismo aquí , y hoy le proponemos leer la traducción de un artículo sencillo que demuestra lo conveniente que es adherirse a una arquitectura limpia usando Quarkus .



Quarkus está ganando rápidamente el estatus de un marco que no se puede evitar. Por eso, decidí repasarlo una vez más y comprobar en qué medida está dispuesto a adherirse a los principios de Arquitectura Pura.



Como punto de partida, tomé un proyecto simple de Maven que tiene 5 módulos estándar para crear una aplicación CRUD REST siguiendo principios de arquitectura limpia:

• domain: objetos de dominio e interfaces de puerta de enlace para estos objetos
• app-api: interfaces de aplicación correspondientes a casos prácticos
• app-impl: implementación de estos casos a través del área temática. Depende de app-apiy domain.
• infra-persistence: Implementa puertas de enlace que permiten que el dominio interactúe con la API de la base de datos. Depende de domain.
• infra-web: Abre los casos considerados para interactuar con el mundo exterior mediante REST. Depende de app-api.

Además, crearemos un módulo main-partitionque servirá como un artefacto de aplicación desplegable.



Cuando planee trabajar con Quarkus, el primer paso es agregar la especificación BOM al archivo POM de su proyecto. Esta lista de materiales administrará todas las versiones de las dependencias que utilice. También deberá configurar complementos estándar para proyectos maven en su herramienta de administración de complementos, como el complemento seguro . Mientras trabaja con Quarkus, también configurará aquí el complemento del mismo nombre. Por último, pero no menos importante, aquí debe configurar un complemento para que funcione con cada uno de los módulos (en <build> <plugins> ... </plugins> </build>), es decir, el complemento Jandex... Dado que Quarkus usa CDI, el complemento Jandex agrega un archivo de índice a cada módulo; el archivo contiene registros de todas las anotaciones utilizadas en este módulo y enlaces que indican dónde se utiliza qué anotación. Como resultado, el CDI es mucho más fácil de manejar, con mucho menos trabajo que hacer después.



Ahora que la estructura básica está lista, puede comenzar a crear una aplicación completa. Para hacer esto, debe asegurarse de que la partición principal cree la aplicación ejecutable de Quarkus. Este mecanismo se ilustra en cualquier ejemplo de "inicio rápido" proporcionado en Quarkus.



Primero, configuramos la compilación para usar el complemento de Quarkus:

<build>
  <plugins>
    <plugin>
      <groupId>io.quarkus</groupId>
      <artifactId>quarkus-maven-plugin</artifactId>
      <executions>
        <execution>
          <goals>
            <goal>build</goal>
          </goals>
        </execution>
      </executions>
    </plugin>
  </plugins>
</build>

A continuación, agreguemos dependencias a cada uno de los módulos de la aplicación, donde estarán junto con las dependencias quarkus-resteasyy quarkus-jdbc-mysql. En la última dependencia, puedes reemplazar la base de datos por la que más te guste (considerando que luego vamos a ir por la ruta de desarrollo nativo, y por lo tanto no podemos usar una base de datos embebida, por ejemplo H2).



Alternativamente, puede agregar un perfil para poder construir la aplicación nativa más adelante. Para hacer esto, realmente necesita un soporte de desarrollo adicional (GraalVM native-imagey XCode si está usando OSX).

<profiles>
  <profile>
    <id>native</id>
    <activation>
      <property>
        <name>native</name>
      </property>
    </activation>
    <properties>
      <quarkus.package.type>native</quarkus.package.type>
    </properties>
  </profile>
</profiles>

¡Ahora, si ejecuta mvn package quarkus:devdesde la raíz del proyecto, tendrá una aplicación Quarkus en funcionamiento! Todavía no hay mucho que ver, ya que aún no tenemos controladores ni contenido.

Agregar un controlador REST

En este ejercicio, vayamos de la periferia al núcleo. Primero, creemos un controlador REST que devolverá los datos del usuario (en este ejemplo, este es solo el nombre).



Para usar la API JAX-RS, se debe agregar una dependencia al POM de infra-web:

<dependency>
  <groupId>io.quarkus</groupId>
  <artifactId>quarkus-resteasy-jackson</artifactId>
</dependency>

El código de controlador más simple se ve así:

@Path("/customer")
@Produces(MediaType.APPLICATION_JSON)
public class CustomerResource {
    @GET
    public List<JsonCustomer> list() {
        return getCustomers.getCustomer().stream()
                .map(response -> new JsonCustomer(response.getName()))
                .collect(Collectors.toList());
    }

    public static class JsonCustomer {
        private String name;

        public JsonCustomer(String name) {
            this.name = name;
        }

        public String getName() {
            return name;
        }
    }

Si ejecutamos la aplicación ahora, podemos llamar a localhost : 8080 / customer y verla Joeen formato JSON.

Agregar un caso específico

A continuación, agreguemos un caso y una implementación para este caso práctico. Vamos a app-apidefinir el siguiente caso:

public interface GetCustomers {
    List<Response> getCustomers();

    class Response {
        private String name;

        public Response(String name) {
            this.name = name;
        }

        public String getName() {
            return name;
        }
    }
}

El app-implcrear una implementación sencilla de esta interfaz.

@UseCase
public class GetCustomersImpl implements GetCustomers {
    private CustomerGateway customerGateway;

    public GetCustomersImpl(CustomerGateway customerGateway) {
        this.customerGateway = customerGateway;
    }

    @Override
    public List<Response> getCustomers() {
        return Arrays.asList(new Response("Jim"));
    }
}

Para que CDI vea el componente GetCustomersImpl, necesita una anotación personalizada UseCasecomo se define a continuación. También puede usar el ApplicationScoped estándar y la anotación Transactional, pero al crear su propia anotación, obtiene la capacidad de agrupar el código de manera más lógica y separar su código de implementación de marcos como CDI.

@ApplicationScoped
@Transactional
@Stereotype
@Retention(RetentionPolicy.RUNTIME)
public @interface UseCase {
}

Para usar anotaciones CDI, debe agregar las siguientes dependencias al archivo POM app-implademás de las dependencias app-apiy domain.

<dependency>
  <groupId>jakarta.enterprise</groupId>
  <artifactId>jakarta.enterprise.cdi-api</artifactId>
</dependency>
<dependency>
  <groupId>jakarta.transaction</groupId>
  <artifactId>jakarta.transaction-api</artifactId>
</dependency>

A continuación, necesitamos modificar el controlador REST para usarlo en los casos app-api.

...
private GetCustomers getCustomers;

public CustomerResource(GetCustomers getCustomers) {
    this.getCustomers = getCustomers;
}

@GET
public List<JsonCustomer> list() {
    return getCustomers.getCustomer().stream()
            .map(response -> new JsonCustomer(response.getName()))
            .collect(Collectors.toList());
}
...

Si ahora ejecuta la aplicación y llama a localhost : 8080 / customer, lo verá Jimen formato JSON.

Definición e implementación del dominio

A continuación, nos centraremos en el dominio. La esencia aquí es domainbastante simple, consiste en Customeruna interfaz de puerta de enlace a través de la cual recibiremos a los consumidores.

public class Customer {
	private String name;

	public Customer(String name) {
		this.name = name;
	}

	public String getName() {
		return name;
	}
}
public interface CustomerGateway {
	List<Customer> getAllCustomers();
}

También necesitamos proporcionar una implementación para la puerta de enlace antes de que podamos comenzar a usarla. Proporcionamos dicha interfaz en formato infra-persistence.



Para esta implementación, usaremos el soporte JPA disponible en Quarkus, y también usaremos el framework Panache , que nos hará la vida un poco más fácil. Además del dominio, tendremos que agregar la infra-persistencesiguiente dependencia:

<dependency>
  <groupId>io.quarkus</groupId>
  <artifactId>quarkus-hibernate-orm-panache</artifactId>
</dependency>

Primero, definimos la entidad JPA correspondiente al consumidor.

@Entity
public class CustomerJpa {
	@Id
	@GeneratedValue
	private Long id;
	private String name;

	public String getName() {
		return name;
	}

	public void setName(String name) {
		this.name = name;
	}
}

Cuando trabaje con Panache, puede elegir una de dos opciones: sus entidades heredarán PanacheEntity o usará el patrón de repositorio / DAO. No soy un fanático del patrón ActiveRecord, así que me detendré en el repositorio yo mismo, pero lo que trabajará depende de usted.

@ApplicationScoped
public class CustomerRepository implements PanacheRepository<CustomerJpa> {
}

Ahora que tenemos nuestra entidad y repositorio JPA, podemos implementar la puerta de enlace Customer.

@ApplicationScoped
public class CustomerGatewayImpl implements CustomerGateway {
	private CustomerRepository customerRepository;

	@Inject
	public CustomerGatewayImpl(CustomerRepository customerRepository) {
		this.customerRepository = customerRepository;
	}

	@Override
	public List<Customer> getAllCustomers() {
		return customerRepository.findAll().stream()
				.map(c -> new Customer(c.getName()))
				.collect(Collectors.toList());
	}
}

Ahora puedes cambiar el código en la implementación de nuestro caso, para que use la puerta de enlace.

...
private CustomerGateway customerGateway;

@Inject
public GetCustomersImpl(CustomerGateway customerGateway) {
    this.customerGateway = customerGateway;
}

@Override
public List<Response> getCustomer() {
    return customerGateway.getAllCustomers().stream()
            .map(customer -> new GetCustomers.Response(customer.getName()))
            .collect(Collectors.toList());
}
...

No podemos iniciar nuestra aplicación todavía, porque la aplicación de Quarkus aún debe configurarse con los parámetros de persistencia requeridos. En src/main/resources/application.propertiesel módulo, main-partitionagregue los siguientes parámetros.

quarkus.datasource.url=jdbc:mysql://localhost/test
quarkus.datasource.driver=com.mysql.cj.jdbc.Driver
quarkus.hibernate-orm.dialect=org.hibernate.dialect.MySQL8Dialect
quarkus.datasource.username=root
quarkus.datasource.password=root
quarkus.datasource.max-size=8
quarkus.datasource.min-size=2
quarkus.hibernate-orm.database.generation=drop-and-create
quarkus.hibernate-orm.sql-load-script=import.sql

Para ver los datos originales, también agregaremos el archivo import.sqlal mismo directorio desde el cual se agregan los datos.

insert into CustomerJpa(id, name) values(1, 'Joe');
insert into CustomerJpa(id, name) values(2, 'Jim');

Si ahora ejecuta la aplicación y la llamada localhost : 8080 / cliente, verá Joeque Jimen el formato JSON también. Entonces, tenemos una aplicación completa, desde REST hasta la base de datos.

Opción nativa

Si desea crear una aplicación nativa, debe hacerlo con el comando mvn package -Pnative. Esto puede tardar unos minutos, dependiendo de cuál sea su soporte de desarrollo. Quarkus es bastante rápido al inicio y sin soporte nativo, comienza en 2-3 segundos, pero cuando se compila en un ejecutable nativo usando GraalVM, el tiempo correspondiente se reduce a menos de 100 milisegundos. Para una aplicación Java, eso es increíblemente rápido.

Pruebas

Puede probar la aplicación Quarkus utilizando el marco de prueba de Quarkus correspondiente. Si anota la prueba @QuarkusTest, JUnit primero iniciará el contexto de Quarkus y luego ejecutará la prueba. Una prueba de toda la aplicación main-partitionse verá así:

@QuarkusTest
public class CustomerResourceTest {
	@Test
	public void testList() {
		given()
				.when().get("/customer")
				.then()
				.statusCode(200)
				.body("$.size()", is(2),
						"name", containsInAnyOrder("Joe", "Jim"));
	}
}

Conclusión

En muchos sentidos, Quarkus es un feroz competidor de Spring Boot. En mi opinión, algunas cosas en Quarkus están aún mejor resueltas. Aunque app-impl tiene una dependencia del framework, es solo una dependencia para las anotaciones (en el caso de Spring, cuando agregamos spring-contextpara obtener @Component, agregamos muchas dependencias centrales de Spring). Si no le gusta esto, también puede agregar un archivo Java a la sección principal, usando la anotación @Producesde CDI y creando el componente allí; en este caso, no necesita ninguna dependencia adicional en app-impl. Pero por alguna razón, jakarta.enterprise.cdi-apiquiero ver la adicción menos que la adicción spring-context.



Quarkus es rápido, muy rápido. Es más rápido que Spring Boot con este tipo de aplicación. Dado que, según la Arquitectura limpia, la mayoría (si no todas) de las dependencias del marco deben residir en el exterior de la aplicación, la elección entre Quarkus y Spring Boot se vuelve obvia. En este sentido, la ventaja de Quarkus es que se creó de inmediato teniendo en cuenta el soporte de GraalVM y, por tanto, a costa de un mínimo esfuerzo, permite convertir la aplicación en nativa. Spring Boot todavía está por detrás de Quarkus en este sentido, pero no tengo ninguna duda de que se pondrá al día pronto.



Es cierto que experimentar con Quarkus también me ayudó a darme cuenta de las muchas desgracias que aguardan a quienes intenten utilizar Quarkus con los servidores de aplicaciones clásicos de Jakarta EE. Si bien todavía no se puede hacer mucho con Quarkus, su generador de código admite una variedad de tecnologías que aún no son fáciles de usar en el contexto de Jakarta EE con un servidor de aplicaciones tradicional. Quarkus cubre todos los aspectos básicos que necesitarán las personas familiarizadas con Jakarta EE, y el desarrollo es mucho más sencillo. Será interesante ver cómo el ecosistema Java puede manejar este tipo de competencia.



Todo el código de este proyecto está publicado en Github .