Key Points

1. Micronaut provides a light-weight Java framework for building REST applications
2. compare to SOAP, messaging, event streams, transaction tables
3. event sourcing vs entity state ( see blockchain for event sourcing and current state:  ledger is sourcing, couchdb is current state from ledger )

References

Key Concepts

Micronaut Summary

https://objectcomputing.com/resources/publications/sett/february-2022-iot-microservices-with-micronaut

The Micronaut framework is a modern full-stack toolkit backed by the Micronaut Foundation™. This microservice Framework is designed for building modular, easily testable microservice applications. The Micronaut framework utilizes innovative techniques at compile time to preconfigure much of the application's initialization logic, dramatically decreasing startup time and runtime memory requirements. This is one of the reasons that Micronaut services can be a great fit for edge devices with constrained environments.

The Micronaut framework was  developed by the creators of the Grails® framework and takes inspiration from lessons learned over the years building real-world applications from monoliths to microservices using Spring, Spring Boot, and the Grails framework.

The Micronaut framework aims to provide all the tools necessary to build full-featured microservice applications, including:

• Dependency injection (DI) and inversion of control (IoC)
• Sensible defaults and auto-configuration
• Configuration and configuration sharing
• Service discovery
• HTTP routing
• HTTP client with client-side load-balancing

At the same time, the Framework aims to avoid the downsides of frameworks like Spring, Spring Boot, and Grails by providing:

• Fast startup time
• Reduced memory footprint
• Minimal use of reflection
• Minimal use of runtime proxies
• Easy testing

Historically, frameworks such as Spring and Grails were not designed to run in scenarios such as serverless functions, Android apps, or low memory footprint microservices. In contrast, the Micronaut framework is designed to be suitable for all of these scenarios.

This goal is achieved through the use of Java’s annotation processors, which are usable on any JVM language that supports them, as well as an HTTP Server and Client built on Netty. In order to provide a similar programming model to Spring and Grails, these annotation processors precompile the necessary metadata in order to perform DI, define aspect-oriented programming (AOP) proxies, and configure your application to run in a microservices environment.

Many of the Micronaut APIs are heavily inspired by the Spring and Grails frameworks. This is by design and aids in bringing developers up to speed quickly.

Compare Micronaut to Quarkus, Spring Boot

https://speakerdeck.com/mraible/java-rest-api-framework-comparison-pwx-2021

Java_REST_API_Framework_Comparison_-_PWX_2021.pdf

https://drive.google.com/open?id=1l68fa7OE4iYn9RhZFtuXIGnsGm8mo-gz

For this tutorial, you’ll need a system with Docker installed. You can find the instructions for your computer here.

First, follow the instructions and install Docker.

Then, once you’ve completed the installation, you can download and run our sample REST server.

Finally, start the server with this command:

$ docker run -p 8080:8080 -d -–name tutorial ericgoebelbecker/resttutorial

Microservices Event Sourcing pattern tracks state reliably

https://microservices.io/patterns/data/event-sourcing.html

problem

How to reliably/atomically update the database and publish messages/events?

forces

2PC - 2 phase commit not an option

solution

A good solution to this problem is to use event sourcing. Event sourcing persists the state of a business entity such an Order or a Customer as a sequence of state-changing events. Whenever the state of a business entity changes, a new event is appended to the list of events. Since saving an event is a single operation, it is inherently atomic. The application reconstructs an entity’s current state by replaying the events.

Applications persist events in an event store, which is a database of events. The store has an API for adding and retrieving an entity’s events. The event store also behaves like a message broker. It provides an API that enables services to subscribe to events. When a service saves an event in the event store, it is delivered to all interested subscribers.

Some entities, such as a Customer, can have a large number of events. In order to optimize loading, an application can periodically save a snapshot of an entity’s current state. To reconstruct the current state, the application finds the most recent snapshot and the events that have occurred since that snapshot. As a result, there are fewer events to replay.

example

Customers and Orders is an example of an application that is built using Event Sourcing and CQRS. The application is written in Java, and uses Spring Boot. It is built using Eventuate, which is an application platform based on event sourcing and CQRS.

The following diagram shows how it persist orders

Instead of simply storing the current state of each order as a row in an ORDERS table, the application persists each Order as a sequence of events. The CustomerService can subscribe to the order events and update its own state.

Here is the Order aggregate:

public class Order extends ReflectiveMutableCommandProcessingAggregate<Order, OrderCommand> {

  private OrderState state;
  private String customerId;

  public OrderState getState() {
    return state;
  }

  public List<Event> process(CreateOrderCommand cmd) {
    return EventUtil.events(new OrderCreatedEvent(cmd.getCustomerId(), cmd.getOrderTotal()));
  }

  public List<Event> process(ApproveOrderCommand cmd) {
    return EventUtil.events(new OrderApprovedEvent(customerId));
  }

  public List<Event> process(RejectOrderCommand cmd) {
    return EventUtil.events(new OrderRejectedEvent(customerId));
  }

  public void apply(OrderCreatedEvent event) {
    this.state = OrderState.CREATED;
    this.customerId = event.getCustomerId();
  }

  public void apply(OrderApprovedEvent event) {
    this.state = OrderState.APPROVED;
  }


  public void apply(OrderRejectedEvent event) {
    this.state = OrderState.REJECTED;
  }

Here is an example of an event handler in the CustomerService that subscribes to Order events:

@EventSubscriber(id = "customerWorkflow")
public class CustomerWorkflow {

  @EventHandlerMethod
  public CompletableFuture<EntityWithIdAndVersion<Customer>> reserveCredit(
          EventHandlerContext<OrderCreatedEvent> ctx) {
    OrderCreatedEvent event = ctx.getEvent();
    Money orderTotal = event.getOrderTotal();
    String customerId = event.getCustomerId();
    String orderId = ctx.getEntityId();

    return ctx.update(Customer.class, customerId, new ReserveCreditCommand(orderTotal, orderId));
  }

}

It processes an OrderCreated event by attempting to reserve credit for the orders customer.

There are several example applications that illustrate how to use event sourcing.

Resulting Context

Event sourcing has several benefits:

• It solves one of the key problems in implementing an event-driven architecture and makes it possible to reliably publish events whenever state changes.
• Because it persists events rather than domain objects, it mostly avoids the object‑relational impedance mismatch problem.
• It provides a 100% reliable audit log of the changes made to a business entity
• It makes it possible to implement temporal queries that determine the state of an entity at any point in time.
• Event sourcing-based business logic consists of loosely coupled business entities that exchange events. This makes it a lot easier to migrate from a monolithic application to a microservice architecture.

Event sourcing also has several drawbacks:

• It is a different and unfamiliar style of programming and so there is a learning curve.
• The event store is difficult to query since it requires typical queries to reconstruct the state of the business entities. That is likely to be complex and inefficient. As a result, the application must use Command Query Responsibility Segregation (CQRS) to implement queries. This in turn means that applications must handle eventually consistent data.

Microservices patterns, frameworks

https://microservices.io/

see m Services: SOAP, REST, API

Microservices - also known as the microservice architecture - is an architectural style that structures an application as a collection of services that are

• Highly maintainable and testable
• Loosely coupled
• Independently deployable
• Organized around business capabilities
• Owned by a small team

The microservice architecture enables the rapid, frequent and reliable delivery of large, complex applications. It also enables an organization to evolve its technology stack.

Potential Value Opportunities

Potential Challenges

Candidate Solutions

Simple Test Environment for the Tutorials above

• Local Linux VM or MACOS
• or
• AWS Linux EC2 instance
• open JDK17
• Tomcat
• Data Store - H2, MYSQL, CouchDB, Postgres

Candidate solutions to test

• REST API - HelloName  async
• GRPC - HelloName async
• Message API - send, receive async from a message broker store
• GraphQL test
• Groovy Data Science test

Step-by-step guide for Example

sample code block

Recommended Next Steps

Related articles