Ihre Browserversion ist veraltet. Wir empfehlen, Ihren Browser auf die neueste Version zu aktualisieren.

What is Reactive?

The term, “reactive”, refers to programming models that are built around reacting to change, like network components reacting to I/O events, like UI controllers reacting to mouse events. R2DBC(Reactive Relational Database Connectivity) was created out of the need for a non-blocking application stack to handle concurrency with a small number of threads and scale with fewer hardware resource.

You can think of data processed by a reactive application as moving through an assembly line. Reactor is both the conveyor belt and the workstations. The raw material pours from a source (the original Publisher) and ends up as a finished product ready to be pushed to the consumer (or Subscriber). The raw material can go through various transformations and other intermediary steps or be part of a larger assembly line that aggregates intermediate pieces together. 

The core of reactive programming is a data stream that we can observe and react to, even apply back pressure as well. This leads to non-blocking execution and hence to better scalability with fewer threads of execution.

R2DBC Reactive Relational Database Connectivity makes it easier to build Spring-powered applications that use relational data access technologies in a reactive application stack.

Reactive and blocking world

Remember that non-blocking, and asynchronous servers work using a single main thread (or a very small number of them). Blocking that thread blocks the entire web server. Don’t ever do this. The high performance that non-blocking servers like Netty can potentially achieve is largely a product of their not having to perform a lot of context switching between threads. When you want to use a blocking API in a non-blocking context, the only way to handle it is to push it off onto a worker thread. There’s a trade-off here because once you start pushing work off from the main thread onto other threads you start to reduce the efficiency of the non-blocking model. The more you do this, the more you start to look like a traditional web server.

Reactive and Kafka, Server-Sent Events

Reactive Streams

Reactive is a programming model built around the concept of reacting to changes, like network components reacting to I/O

Reactive streams use a push model. This means that items are pushed on the stream at the pace of the publisher, regardless of whether the subscriber can follow or not (no worries, backpressure is a key-feature of reactive streams). reactive streams are lazy, and won’t start as long as there is no subscriber present. That means that a subscriber is always necessary with reactive streams. I’ve mentioned before that publishers are asynchronous in nature, but are they always asynchronous? The answer to that is, no, not always. Whether or not a reactive stream is synchronous or asynchronous, depends on the type of publisher you use.

The key expected benefit of reactive and non-blocking is the ability to scale with a small, fixed number of threads and less memory.

Spring Cloud Stream

Spring Cloud Stream is a framework for building highly scalable event-driven microservices connected with shared messaging systems.

 

Kafka

Monads and Java

Monads come from the functional programming world and is used in many places in many different ways. But the most concrete explanation id say is that a Monad accepts a type of “something” (this could be an int, string or any other type) and returns a new type containing your “something” type.

About PECS - Producer Extends Consumer Super and Lambda's

Wildcards and PECS (term first coined by Joshua Bloch in his book Effective Java): A wildcard is a type argument that uses a question mark, ?, which may or may not have an upper or lower bound. Type arguments without bounds are useful, but have limitations. If you declare a List of unbounded type, as in A List with an unbounded wildcard, you can read from it but not write to it.

Functional Patterns in Java

The release of Lambdas supposed one of the largest quality jumps in the Java language in its history; mainly due to the fact that it opened a wide new range of possibilities to the language. Functional programming is a programming paradigm which has its roots in lambda calculus that uses a declarative approach; instead of the most commonly known imperative paradigm.

2 legged vs 3 legged OAuth

I short 2 legged and 3 legged OAuth refers to the number of players involved in the OAuth dance. 3 legged OAuth is used when you as a user wants to allow an application to access a service on your behalf. 2 legged OAuth is used when an application needs to access a service using a service account. Two-legged OAuth, or "signed fetch", takes advantage of OAuth's signatures to authenticate server-to-server requests. It doesn't need to involve the user nor any access tokens.

Keeping fit on Java - learning points

UML freshup

GIT and Workflows

 CompletableFuture and Async programming

Multi-threading is similar to multitasking, but enables the processing of executing multiple threads simultaneously, rather than multiple processes. The CompletableFuture, introduced in Java 8, provides an easy way to write asynchronous, non-blocking and multi-threaded code. Spring has the ability to implement the Command Pattern extremely well.

SOLID Principles

The SOLID Principles are five principles of Object-Oriented class design. The SOLID principles were first introduced by the famous computer scientist Robert J. Martin (a.k.a Uncle Bob) in his paper in 2000. But the SOLID acronym was introduced later by Michael Feathers.

  • The Single Responsibility Principle
  • The Open-Closed Principle
  • The Liskov Substitution Principle
  • The Interface Segregation Principle
  • The Dependency Inversion Principle
  1. The SOLID Principles of Object-Oriented
  2. SOLID Design Principles Explained: Dependency Inversion Principle with Code Examples – Stackify

 

Gang of Four Design Patterns

As a Java developer using the Spring Framework to develop enterprise class applications, you will encounter the GoF Design Patterns on a daily basis. The GoF Design Patterns are broken into three categories: Creational Patterns for the creation of objects; Structural Patterns to provide relationship between objects; and finally, Behavioral Patterns to help define how objects interact.

Which design pattern to use on Java workflow

The obvious choice to also consider here is Chain of Responsibility. The problem with CoR in cases like this is sometimes you don't really know what the paths will be in advance, and so laying out all the possible paths can be really painstaking. Of course, you could use a builder to construct the chains (remember all the Maze building examples from the Gang of Four).

Command Pattern and Springboot

Command Pattern is one of the design patterns and encapsulates everything required to take any action and allows loosely coupled execution of the action. How does that relate to invoking REST API with Spring boot Java?  

It is always a good practice to develop around established patterns.

Building your own Fluent API Pattern

Reference Data Pattern

By reference types I mean reference data, or lookup values, or – if you want to be flash – taxonomies. Typically, the values defined here are used in drop-down lists in your application's user interface. They may also appear as headings on a report.

As your data model evolves over time and new reference types are required, you don't need to keep making changes to your database for each new reference type. You just need to define new configuration data.

Strategy Pattern leveraging Java 8 Lamda's

Typically, programmers tend to bundle all the algorithm logic in the host class, resulting in a monolithic class with multiple switch case or conditional statements. Such pitfalls in enterprise applications result in rippling effects across the application making the application fragile. You can typically avoid this by introducing the Strategy pattern as demonstrated below.

 

What this does:

  1. Statically define a family of algorithms at one location (interface Strategy)
  2. Follows SOLID Open-Closed Principle (Open for extension, Closed for modification). Adding new algorithms to the Strategy interface lets us add new functionality without touching existing code for the Case Class.

@Data
@NoArgsConstructor
@ToString
public class Case implements Strategy {

    private String phase;
    private String status;

    private Instant dueDate = Instant.now();    

}

 

public interface Strategy {

    default Case thenApply(Consumer<Case> logic) {
        logic.accept((Case)this);
        return (Case)this;

    }

    public static Consumer<Case> kycReview() {
        return c -> c.setPhase(CasePhase.KYC_REVIEW.name());

    }

    public static Consumer<Case> priReview() {
        return c -> c.setPhase(CasePhase.PRI_REVIEW.name());

    }

    public static Consumer<Case> rejected() {
        return c -> c.setStatus(CaseStatus.REJECTED.name());

    }

    public static Consumer<Case> verify(Boolean check) {
        return c -> {
            if (check && c.getDueDate().isBefore(Instant.now())) {
                c.setStatus(CaseStatus.DECLINED.name());

            }
        };
    }

}

// finally

Case myCase = new Case();

myCase.thenApply(rejected()).thenApply(kycReview()).thenApply(priReview()).thenApply(verify(true));

System.out.println(myCase);

source

Liquibase changelogs in SQL format

Hosted by WEBLAND.CH