Adoro conversar, se tem uma coisa que gosto de fazer é falar e ouvir… e em uma dessas conversas recentes surgiu a discussão sobre como explicar mais rapidamente as diferenças entre os padrões de Observables e PubSub.

Resolvi então traduzir o fio da conversa em um post aqui, não vou entrar em todos os detalhes, mas apenas tentar ser mais lúcido e prático nas definições.

Então vamos lá!

Observer

O padrão Observer é um padrão de design comportamental em que um objeto, chamado de Subject, permite definir uma ou mais inscrições dos chamados Observers, e os notifica automaticamente sobre quaisquer mudanças de estado, geralmente chamando um de seus métodos.

Vamos a um exemplo do mundo real:

Você trabalha como vendedor em uma loja de calçados, porém a loja está sempre cheia e todos os dias anota diversos contatos por itens que estão em falta em um bloquinho. No dia seguinte ao verificar que um dos calçados já encontra-se em estoque e claro, para não perder sua comissão de venda, resolve ligar para todos todos os contatos do dia específico de procura daquele item que mudou de status.

Agora o exemplo como deve ser:

Simples né? :)

Publish Subscriber

É um padrão para troca de menssagens onde quem as envia são chamados de Publishers, porém eles não enviam as mensagens diretamente para quem os recebe, os Subscribers.

Os publishers não tem conhecimento dos subscribers, e vice versa.. mas então como eles se comunicam? Eles expressam interesses(intents) de envios, e interesses em recepções.

Mas se eles não se conhecem, como é feita a comunicação? Há outro componente, o Message Broker, e ele sim é conhecido tanto pelo publisher quanto pelo subscriber. O publish enviará a mensagem ao message broker e ele por sua vez filtrará e transmitirá a mensagem ao(s) subscriber(s) correto(s).

Existem vários message brokers disponíveis, no exemplo ilustrativo a área em cinza seria a sua representação, lembrando que são bem mais complexos que isso, é claro.

Obrigado

O post foi curto e rápido como previsto, vejo vocês em breve.

Hoje vamos iniciar um tutorial para aprender um pouco como utilizar esse framework java nativo da RedHat, que espera se tornar a plataforma líder em ambientes Serverless e Kubernetes, além de oferecer aos desenvolvedores um modelo unificado de programação reativa e imperativa.

O QuarkusIO aproveita uma série de libs comuns para os desenvolvedores Java, e algumas delas estão muito no hype como a Eclipse MicroProfile, Kafka e Vert.x. A injeção de dependência na framework é baseada no CDI, permitindo que os desenvolvedores usem JPA/Hibernate, JAX-RS/RESTEasy e etc.

Baseado nos melhores padrões, baixo consumo de processamento e tempo de inicialização incrivelmente rápido, o Quarkus permite o uso do Java em ambientes serverless, suportando um ambiente responsivo e escalável.

1 — Nossa primeira aplicação

A forma mais fácil e rápida de criar nossa primeira aplicação Quarkus seria via linha de comando utilizando o Maven.

mvn io.quarkus:quarkus-maven-plugin:0.13.1:create \
 -DprojectGroupId=com.ivanmarreta.quarkus \
 -DprojectArtifactId=quarkus-project \
 -DclassName=”com.ivanmarreta.quarkus.SampleResource” \
 -Dpath=”/sample”

Este comando irá gerar um esqueleto do projeto, com um resource chamado SampleResource e com um endpoint /sample exposto, configurações e Dockerfiles.
Sendo um projeto maven, agora basta fazer o importe para sua IDE favorita, a estrutura será similar a esta:

Na nossa classe SampleResource temos o seguinte código:

@Path(“/sample”)
public class SampleResource {

  @GET
  @Produces(MediaType.TEXT_PLAIN)
  public String hello() {
    return “hello”;
  }
}

E para executar nossa aplicação basta executar no terminal o comando:

./mvnw compile quarkus:dev

Na primeira vez o maven irá efetuar o download dos artefatos necessários e logo a aplicação estará up:

Pronto! Sua primeira aplicação está UP!

Para acessar o endpoint exposto podes testar via browser ou, como gosto de testar, via terminal:

curl -w “\n” http://localhost:8080/sample

Obtemos o resultado esperado: a string “hello”. (clap clap clap)

2 — Hot Reload

No modo de desenvolvimento (./mvn compile quarkus:dev), o Quarkus fornece um recurso de Hot Reload. Com isso, as alterações feitas nos arquivos Java ou nos arquivos de configuração serão compiladas automaticamente assim que o navegador for atualizado ou, uma request for efetuada. O recurso mais impressionante aqui é que não precisamos salvar nossos arquivos. Portanto, dependendo da sua preferência, podes achar isso bom ou ruim.

Agora vamos observar como o Hot Reload age!

Na nossa ide criaremos uma classe chamada SampleService:

@ApplicationScoped
public class SampleService {

  public String hello(String name) {
    return String.format(“Hello %s. This is your first QuarkusIO
                          sample!”, name);
  }
}

E agora vamos injetar essa classe utilizando CDI no nosso resource, criando também um novo endpoint exposto:

@Path(“/sample”)
public class SampleResource {

  @Inject
  SampleService service;

  @GET
  @Produces(MediaType.TEXT_PLAIN)
  public String hello() {
    return “hello”;
  }

  @GET
  @Path(“/{name}”)
  public String hello(@PathParam(“name”) String name) {
    return service.hello(name);
  }
}

E então executamos nossa requisição ao nosso novo endpoint:

curl -w “\n” http://localhost:8080/sample/Ivan

Hello Ivan. This is your first QuarkusIO sample!

Conforme mencionei, podemos também alterar arquivos de configuração.

Vamos adicionar ao arquivo application.properties a linha:

hello=Hello %s. This is your first QuarkusIO sample!

E em nossa classe de serviço SampleService, vamos injetar a propriedade utilizando a anotação @ConfigProperty do Eclipse Microprofile.

Nossa classe ficará simples como isso:

@ApplicationScoped
public class SampleService {

  @ConfigProperty(name = “hello”)
  private String hello;

  public String hello(String name) {
    return String.format(hello, name);
  }
}

Basta repetir a request e verás que o resultado será o mesmo e, podes até brincar alterando a string adicionada ao application.properties.

3 — Json no response dos Rest Services

Agora vamos tornar as coisas um pouco mais divertidas e aumentar um pouco a “dificuldade”.

Vamos adicionar código para retornar uma lista de objetos do tipo Sample.

public class Sample {

  private int order;
  private String name;

  …
}

Na nossa SampleService, adicionamos o método:

public List<Sample> list(){
   Sample sample1 = new Sample(1, “Nossa primeira aplicação”);
   Sample sample2 = new Sample(1, “Hot Reload”);
   Sample sample3 = new Sample(1, “Json no response dos Rest ...”);
   return Arrays.asList(sample1, sample2, sample3);
}

E nossa classe SampleResource, agora completa, ficará assim:

package com.ivanmarreta;

import javax.inject.Inject;
import javax.ws.rs.*;
import javax.ws.rs.core.MediaType;
import javax.ws.rs.core.Response;

@Path(“/sample”)
@Produces(MediaType.APPLICATION_JSON)
@Consumes(MediaType.APPLICATION_JSON)
public class SampleResource {

  @Inject
  SampleService service;

  @GET
  public String hello() {
     return “hello”;
  }

  @GET
  @Path(“/{name}”)
  public String hello(@PathParam(“name”) String name) {
     return service.hello(name);
  }

  @GET
  @Path(“/list”)
  public Response list() {
     return Response.ok(service.list()).build();
  }
}

Ao executar a request:

curl -w “\n” http://localhost:8080/sample/list

Iremos receber a seguinte resposta:

Could not find MessageBodyWriter for response object of type: java.util.Arrays$ArrayList of media type: application/json

Mas não se preocupe, está correto. O que tem de errado então? Precisamos adicionar no pom.xml a seguinte dependencia:

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

JSON-B não é a única forma de desserialização, podes também utilizar o Jackson, depende da sua preferência.

Bom, após adicionar a dependência, enfim, devemos reiniciar a app no nosso terminal, pois o maven precisará adicionar bibliotecas ao projeto. Desta vez verá que em questão de milisegundos a aplicação é started. õ/

Agora podemos testar nossa request e verificar o resultado:

curl -w “\n” http://localhost:8080/sample/list

[{“name”:”Nossa primeira aplicação”,”order”:1},{“name”:”Hot Reload”,”order”:1},{“name”:”Json Rest Services”,”order”:1}]

Nossa, muito complicado não é? :)

4 — Packaging da nossa aplicação

Via terminal, executamos:

./mvnw package

Serão gerados 2 artefactos jar dentro da pasta target:

Jar executável com todas as dependencias:
ivanmarreta-quarkus-project-1.0-SNAPSHOT-runner.jar

Jar contendo classes e resources:
ivanmarreta-quarkus-project-1.0-SNAPSHOT.jar

Agora para executar sua aplicação basta rodar o jar:

java -jar target/ivanmarreta-quarkus-project-1.0-SNAPSHOT-runner.jar

:)

5 — Conclusão

Demonstramos aqui um pouco do Quarkus, e verificamos que é um ótimo framework para levar o Java de maneira mais eficaz à nuvem. Por exemplo, agora é possível imaginar Java no AWS Lambda ou outra plataforma Serverless. Além disso, o QuarkusIO é baseado em padrões como JPA e JAX/RS. Portanto, para desenvolvedores Java experientes, não existe uma barreira de curva de aprendizado.

No próximo post sobre o QuarkusIO iremos explorar recursos mais avançados! õ/

Espero ler o que acham sobre o framework nos comentários e debater sobre o assunto.

Obrigado :)

In the first article of this sequence you saw a new method on our List, the forEach. But, until Java 7 this method didn’t existed… how did it happen?

We know that if this method would be declared in an interface, we could have a big problem!
What?

Everyone who implemented the interface would need to implement it.
Chaos would be installed, work would be immense, the Java community would go insane.
An interface like List would destroy libraries used by most of us, such as Hibernate.

Would be welcome to “NoSuchMethodErrors” Hell!

BUT … we get a new feature in Java 8!

Default Methods

With this feature we can add a method to an interface and ensure that all implementations have it implemented. :)

For example, the forEach method we use is declared inside java.lang.Iterable, which is the parent of Collection, in turn List’s parent.

If we look at the method in the interface we’ll find:

default void forEach(Consumer <? Super T> action) {
   Objects.requireNonNull (action);
   for (T t: this) {
      action.accept (t);
   }
}

Yes, I think you never expected that, method with code inside interfaces..

As ArrayList implements List, which is (indirect) daughter of Iterable,
The ArrayList has this method, whether it wants to or not. It is for this reason that we can do it:

books.forEach(b -> System.out.println(b.getName()));

This reading serves as an explanation for the first article, which used this new feature.

Bye bye, see you!

References:
https://docs.oracle.com/javase/tutorial/java/IandI/defaultmethods.html

I’m looking around and seeing many people working with older versions of Java.. then i will write some articles to estimulate this upgrade, to take doubts or discussions.

Let’s start in my first Medium article with a common practice.. a loop with FOR EACH.

Below you will take the old foreach:

List<Book> books = Arrays.asList(book1, book2, book3);

for(Book u : books){
   System.out.println(b.getName());
}

Arrays.asList is a easy way to create an immutable List.

Now we can do for eachs with the new method of collections, forEach:

books.forEach(…);

This method receive a type java.util.function.Consumer with a unique method accept. This is from the new package java.util.function.

Let’s create this consumer, before use the new forEach:

class Display implements Consumer<Book> {
    public void accept(Book b){
      System.out.println(b.getName());
    }
}

Then we can do it:

Display display = new Display();
usuarios.forEach(display);

But, for this we can use anonymous classes like a good practice to simple tasks like that:

Consumer<Book> display = new Consumer<Book>() {
   public void accept(Book b){
      System.out.println(b.getName());
   }
};

books.forEach(display);

Now it’s better! But, the code is still bigger, let’s change one more time:

books.forEach(new Consumer<Book>() {
   public void accept(Book b){
     System.out.println(b.getName());
   }
});

Yeah! Now we have the same, but not so verbose..

Hello, LAMBDA!

Now let’s know the lambda, this is it the Java simple way to implements an interface with ONLY ONE method. (Remember what we talk about the java.util.function.Consumer) :)

Consumer<Book> display = (Book b) -> System.out.println(b.getName());};

WTF?! yes.. this is the same forEach! :D

(Book b) -> {System.out.println(b.getName());}; 

it’s a Java 8 lambda.

The compiler knows how to infer the type, and if the block have only one instruction we can remove the { }.

Consumer<Book> display = b -> System.out.println(b.getName());

What? A foreach on 1 line? Better… we don’t need a temporary variable.

books.forEach(b -> System.out.println(b.getName()));

It’s this.

Easy? EASY and CLEAN.

I will continue more explanations about Java 8, if you have any idea to share, tell me.
Thank you.