Workshop de Quarkus revisado

on   in   with No hay comentarios.

 


Quarkus

Quarkus es un marco de Java integral y creado en Kubernetes para las compilaciones originales y las máquinas virtuales Java (JVM), el cual permite optimizar esta plataforma especialmente para los contenedores y para los entornos sin servidor, de nube y de Kubernetes.

Se diseñó para que funcione con las bibliotecas, los marcos y los estándares de Java conocidos, como Eclipse MicroProfile y Spring (ambos se presentaron como parte de una sesión en el evento Red Hat Summit 2020), así como también Apache Kafka, RESTEasy (JAX-RS), Hibernate ORM (JPA), Infinispan, Camel y muchos más.

La solución de inyección de dependencias de Quarkus se basa en la inyección de dependencias y contextos (CDI), e incluye un marco de extensión para ampliar las funciones y configurar, iniciar e integrar un marco en las aplicaciones. Dado que agregar una extensión es tan sencillo como incorporar una dependencia, puede optar por esa opción o utilizar las herramientas de Quarkus.

Además, proporciona la información correcta a GraalVM (una máquina virtual universal para ejecutar aplicaciones escritas con varios lenguajes, incluidos Java y JavaScript) para la compilación propia de las aplicaciones.


Sesión 1 - Setup y Creando REST/HTTP Hero Microservice


El 13 de Diciembre se realizó la primera sesión de Quarkus, donde se instaló el software necesario para trabajar con Quarkus, y se construyó el primer microservicio de héroes. 




Sesión 2 - Transacciones y ORM


El 19 de Diciembre 2020 vimos cómo trabajar la parte de persistencia en Quarkus. Se instaló la dependencia de PostgreSQL, Hibernate con Panache e Hibernate Validator.





Sesión 3 - Open API


El 9 de Enero 2021, vimos cómo configurar OpenAPI y documentar los endpoints de los micro servicios. 





Sesión 4 - Fight Microservice con interface de usuario


El 17 de Enero 2021, se desarrollo el micro servicio de Pelea con su interface de usuario en angular. 





Sesión 5 - Comunicación HTTP con tolerancia a Fallas

El 24 de Enero 2021, se realizó la comunicación entre micro servicios con tolerancia a fallas.




Sesión 6 - Observabilidad

El 31 de Enero 2021, se vio Health Check, Metrics y carga de los micro servicios.



Sesión 7 - Event-driven y Programación Reactiva

El 21 de Febrero 2021, empezamos con el tema de manejo de eventos y uso de Kafka.  Aquí vimos que ya estaba deprecado mucho de la programación Reactiva y tuvimos que decidir hacer una sesión más para usar Mutiny.



Sesión 8 - Uso de Mutiny para programación Reactiva

El 28 de Febrero, vimos que se tenía que cambiar el código deprecado para usar Mutiny.



Sesión 9 - Desplegando a Kubernetes

El 9 de Marzo, por fin, pudimos terminar el Workshop y vimos como desplegar a Openshift Local usando Codeready Containers. 



Gracias a todos los que participaron. Compartanlo con sus amigos. 



Los links los dejo aquí:

Github: https://github.com/joedayz/quarkus-super-heroes-workshop

Youtube: https://youtube.com/playlist?list=PL5sFNOYxsSxQXvNNG8Qg-RfYQeCrF-so3


Enjoy!


Joe








Share:

Trabajando con PubSub de GCP

on   in , ,   with No hay comentarios.

 


En un articulo anterior hablamos sobre CloudKarafka para trabajar con Tópicos, publicadores y subscriptores.  Pero, si tu tienes cuenta en Google Cloud, debes saber que puedes usar PubSub para implementar mensajería basada en eventos.

¿Qué es PubSub?

GCP Pub/Sub es un servicio de mensajería real-time completamente administrable que nos permite enviar y recibir mensajes entre aplicaciones independientes. ¿Y cómo funciona esto, o "como se come"?: 
  1. Tú publicas un mensaje a un tópico,
  2. Una aplicación se suscribe a la subscription de dicho tópico para recibir los mensajes que se publican. 
  3. La aplicación al recibir el mensaje avisa que el mensaje ha sido recibido y el mensaje es eliminado de la cola de mensajes. 
  4. Si el aviso  no es recibido, GCP reenviará el mensaje con un tiempo de delay especificado. De esta manera, la entrega del mensaje es garantizado.

¿Por qué GCP Pub/Sub?

Cuando hay dos micro servicios o aplicaciones que necesitan comunicarse entre ellas para completar una tarea. Tu piensas en resolver esto con:
  1. Request HTTP
  2. GRPC
El problema con HTTP es que hay chance de fallas y por eso el desarrollador implementa lógicas de reintento. HTTP es también "demasiado" si tienes que intercambiar cantidades muy pequeñas de datos. Recordemos también qué hay que proporcionar autenticación, aunque ambos micro servicios pertenecieran a la misma aplicación. 

Y con GRPC habría que aprender su sintaxis y metodologías, así como escribir la lógica de reintento si falla la entrega del mensaje.

Pero, ¿Qué resuelve GCP Pub/sub?

  1. Nos da mecanismo de reintento
  2. Es super ligero y super rápido
  3. Configuración mínima
  4. Es administrado por google, así que ni preocuparse del mantenimiento


A continuación los pasos para su utilización:

Paso 1: Obtener archivo de Recurso

Para poder utilizar los tópicos y subscripciones se necesita generar un service-account.json desde la consola de Google. Yo te muestro como hacerlo de forma sencilla:



Escoger la opción JSON y obtener el archivo JSON que tendrá por defecto el nombre del proyecto en GCP. Renombrarlo a service-account.json.


Este archivo lo vamos a usar mas adelante cuando generemos los proyectos.


Paso 2: Crear el Pub/Sub, Tópico y Subscripción

Primero ubica el Pub/Sub en la barra de servicios a la izquierda de la página de Google Cloud:


Luego crea el tópico testTopic:



Luego creamos la suscripción:



Y mantengo los datos por defecto:







Y listo.  Ahora pasamos a crear los proyectos para enviar y recibir mensajes usando Pub/Sub.

Paso 3: Vídeo tutorial

Explico la implementación con un vídeo paso a paso.





El código fuente lo puedes bajar desde GitHub aquí.


Enjoy!


Joe
Share:

Tutorial for working with CloudKarafka

on   in , ,   with No hay comentarios.

 



I have been looking for a Kafka who does not have to manage it and only worry about growing according to my needs. I found CloudKarafka, which is very easy to use and has a free plan for developers.

I hope you like this material, the source code can be found on github at this link.



And if you want to go deeper into Kafka, there is a good book that the same people from CloudKarafka have written at this link.

Enjoy!

Joe
Share:

Tutorial para trabajar con CloudKarafka

on   in , ,   with No hay comentarios.

 


Estuve buscando un Kafka que no tenga que administrarlo y preocuparme solo en crecer según mis necesidades. Encontré CloudKarafka, que es muy sencillo de usar y tiene un free plan para desarrolladores. 

Espero les guste este material, el código fuente lo encuentran en github en este link.




Y si quieren profundizar más sobre Kafka, hay un buen libro que ha hecho la misma gente de CloudKarafka en este link.


Enjoy!


Joe

Share:

Respeto a la vida

on   with No hay comentarios.

 Todos tenemos distintos puntos de vista, creemos, no creemos, pero, incluso si fuese ateo, para mi la vida se respeta. Un niño es una historia, un pueblo detrás de él, una salvación para el mundo.

Comparto con ustedes amigos lectores, estas 2 bellas oraciones dadas por sus autores para el Respeto a la vida:






Confío en las mujeres de este mundo. Son ellas las únicas que pueden evitar embarazos no planeados o matar al niño que llevan en sus vientres. Fuerza chicas y sigamos orando para que haya más mujeres valientes que defiendan la vida. Dios provee.


Joe

Share:

Connecting our client project using Microprofile JWT

on   in   with No hay comentarios.

 

In the previous article on how to Create Tokens with Microprofile JWT and JDBC Realm, we managed to have a project that provides us with tokens for our users and roles in our database.

It was pending to create a client that uses these tokens and allows them to make use of the APIs that this client exposes.

Source Code: https://github.com/joedayz/fps-ws-ecommerce

Client Project


This is a typical JakartaEE project with Microprofile 3.2. This time, the project will use DeltaSpike, which in the Spring world would be like your Spring Data, Nimbus Jose JWT to work with JSON Web Tokens (JWT), Microprofile Extension for Open API, finally Jakarta XML Binding.


DeltaSpike


This is a module used to simplify the implementation of the repository pattern. It is very similar to Spring Data. To query a database, we need to define a method declaration without implementation with @Query. The implementation will be done for us by the CDI extension.

The module requires an EntityManager to be injected by CDI. To achieve this we use a CDI producer.


The above assumes we have a persistence unit named "concentrador_pu" defined in the persistence.xml file:



If you have read our previous article you will recognize the jdbc/ecommerce that was created to be able to connect to our database in PostgreSQL.

The transaction strategy to use is:

There are 4 strategies:

  • BeanManagedUserTransactionStrategy
  • ResourceLocalTransactionStrategy
  • ContainerManagedTransactionStrategy
  • EnvironmentAwareTransactionStrategy

They all implement org.apache.deltaspike.jpa.spi.transaction.TransactionStrategy. Since I am going to use JTA I have to enable a strategy like BeanManagedUserTransactionStrategy in the beans.xml file according to the information in https://deltaspike.apache.org/documentation/jpa.html.

There is also the apache-deltaspike.properties where we will also establish the same strategy:

The end result is:


Implementing Repository


With the above, we can now implement the repository pattern. Does this implementation seem familiar to you?

Cors Filter


As our Rest APIs will be consumed by a SPA application made with angular or mobile made with Flutter, we are going to define a cors filter.


Controllers


Now is the time to define our controllers.


How can you see so that we can execute the login method, you need to be authenticated and have either the USER role or the ADMIN role.

@POST
@RolesAllowed({ RolesEnum.Constants.ADMIN_VALUE,
      RolesEnum.Constants.USUARIO_VALUE})


Microprofile JWT


Microprofile allows us to do the previous validation in a very simple way. For that we need 2 things:


1. In the payara-mp-jwt.properties file place the accepted.issuer:

2. Place the public key that will allow validating the JWT tokens generated by the microprofile-jwt-provider project that we saw in the previous article.


Postman

In order to test our API, we first have to obtain a token with the JWT token provider project seen in the first article.



We declare that token in the section Authorization - Type: Bearer Token:

With that configuration we can test the API - Login without problems:


And in this way, we have demonstrated the use of Microprofile JWT with JakartaEE to have our APIs in a minimalist way.

Enjoy!


Joe














Share:

Conectando nuestro proyecto cliente usando Microprofile JWT

on   in   with No hay comentarios.

 


En el articulo anterior de como Crear Tokens con Microprofile JWT y JDBC Realm, nosotros conseguimos tener un proyecto que nos provea de tokens para nuestros usuarios y roles de nuestra BD. 

Quedo pendiente crear un cliente que utilice estos tokens y permita hacer uso de las APIS que exponga este cliente. 



Proyecto Cliente


Este es un tipico proyecto JakartaEE con Microprofile 3.2. En esta oportunidad el proyecto usará DeltaSpike que en el mundo Spring vendría a ser como tu Spring Data, Nimbus Jose JWT para trabajar con Json Web Tokens (JWT), Microprofile Extension para Open API, finalmente Jakarta XML Binding. 



DeltaSpike


Este es un módulo usado para simplificar la implementación del patrón repository. Es muy similar a Spring Data. Para consultar una base de datos, nosotros necesitamos definir una declaración de método sin implementación con @Query. La implementación será realizada para nosotros por la extensión CDI. 

El módulo requiere un EntityManager para ser inyectado por CDI. Para conseguir esto usamos un productor CDI. 



Lo anterior asume que tenemos una unidad de persistencia con nombre "concentrador_pu" definido en el archivo persistence.xml:



Si han leido nuestro anterior articulo reconoceran el jdbc/ecommerce que se creo para poder conectarnos a nuestra BD en PostgreSQL.

La estrategia de transacción a utilizar es: 


Existen 4 estrategias:

  • BeanManagedUserTransactionStrategy
  • ResourceLocalTransactionStrategy
  • ContainerManagedTransactionStrategy
  • EnvironmentAwareTransactionStrategy


Todas implementan org.apache.deltaspike.jpa.spi.transaction.TransactionStrategy. Como yo voy a usar JTA tengo que habilitar una estrategia como BeanManagedUserTransactionStrategy en el archivo beans.xml acorde a la información en https://deltaspike.apache.org/documentation/jpa.html.


Existe tambien el apache-deltaspike.properties donde tambien estableceremos la misma estrategia:



El resultado final es:



Implementando Repositorio


Con lo anterior ya podemos implementar el patrón repository. Les parece conocida esta implementación?





Cors Filter


Como nuestros API Rest serán consumidos por una aplicación SPA hecha con angular o móvil hecha con Flutter, vamos a definir un cors filter.





Controladoras


Ahora toca el momento de definir nuestras controladoras.



Cómo se puede apreciar para que podamos ejecutar el método login, se necesita estar autenticado

y tener o el rol USUARIO o el rol ADMIN.


@POST
@RolesAllowed({ RolesEnum.Constants.ADMIN_VALUE,
      RolesEnum.Constants.USUARIO_VALUE})


Microprofile JWT


Microprofile nos permite hacer la validación anterior de una forma muy simple. Para eso necesitamos 2 cosas:

1. En el archivo payara-mp-jwt.properties colocar el accepted.issuer :



2. Colocar la llave pública que permitirá validar los tokens JWT generados por el proyecto microprofile-jwt-provider que vimos en el artículo anterior.



Postman

Para poder probar nuestra API, tenemos primero que obtener un token con el proyecto proveedor de tokens JWT visto en el primer artículo. 


Declaramos ese token en la sección Authorization - Type: Bearer Token:



Ya con esa configuración podemos probar el API - Login sin problemas:




Y de esta manera hemos demostrado el uso de Microprofile JWT con JakartaEE para tener nuestras APIs de una forma minimalista.

Enjoy!


Joe





Share:

Creating Tokens with Microprofile JWT and JDBC Realm

on   in   with No hay comentarios.

 


In these last months of the year, I have started with my team to work with Micprofile, Payara, JakartaEE and the truth everything is more minimalist and works very well.


As I needed a project that provides me with tokens with the above mentioned, I checked the great article by Victor Orozco (@tuxtor) https://vorozco.com/blog/2019/2019-10-02-MicroProfile-JWT-Token-Provider- Servlet.html to not start from scratch and use JDBC Realm.


Source code: https://github.com/joedayz/microjwt-provider


Requirements

1. Have a Payara Server installed. I'm going to use the Payara Server that Jelastic provides us as PAAS, but, you can download and install the payara on your machine.

2. Java 8+ that you can download from https://adoptopenjdk.net/

3. Check and Follow Victor's article to create the private key and public key.



4. Add some dependencies for Logging. Very necessary if problems arise.




Steps to work with a JDBC Realm

1. Add a web.xml and configure the realm, plus the roles that we are going to use.




The location of the web.xml is in the webapp folder:



2. In the glassfish-web.xml file we also add the roles that we are going to use:



Configuring Logging to the project


1. Create a LoggerProducer to be able to later inject the Logger where we need it.



2. Where you need to Logging, you just inject the Logger:



Generating the Token

1. The project is going to look a lot like the original, I have only changed the TokenProviderResource class to use the jdbc realm in this way:


2. A BaseResponse to notify the clients of this service if there was Success or not with a personalized structure.



Creating the Realm on Payara Server

1. Before creating a Realm we have to have the connection to the DB ready. For that, we are going to create a JDBC Connection Pool for Postgres.





The 2 tables are as shown below:





2. Then we create the JDBC Resource






3. Finally, we go to Configurations -> server-config -> Security -> Realms to create the JDBC Realm:






4.  Creamos el JDBC Realm con estos datos:




Realm Name: ecommerce  (Usado en la linea 9 del web.xml)
Class Name: com.sun.enterprise.security.auth.realm.jdbc.JDBCRealm

JAAS Context: jdbcRealm
JNDI:  jdbc/ecommerce  (JDBC Resource)
User Table: usuario
User Name Column: correo
Password Column: contrasenia
Group Table: usuario_role
Group Table User Name Column:  correo
Group Name Column: role_id
Digest Algorithm: SHA-256
Encoding: Hex
Charset: UTF-8


Testing with Postman


1. We test with Postman and voila


What happens after this?


In the next article, we will use a project that can use these generated tokens and we will have the complete figure for our backend that can be used by SPA applications made with Angular or mobile applications such as Android, IOS, Flutter, etc.


Enjoy!

Joe






Share: