Micro-App

Micro-App represents one self-contained system in the Blue Vibes ecosystem.
It is a vertical slice of the big system and deals with one domain.
Micro-App is an extension to traditional micro-services concept, where the GUI is also part of the micro-service itself.
It could be expressed with the following formula:
Micro-App = classical micro-service + GUI.
Micro-App is not a Blue Vibes invention, it is used under different names in the Web community:

• Micro-Frontends
• Self-Contained Systems

Getting started with micro-app in Blue Vibes

Easiest way to create new micro-app is using Blue Vibes Blueprints, which represent skeletons for new micro-applications.

Micro-App configuration

Security

Blue Vibes offers security library which is highly configurable.
If bv-blueprint is used, this library is included out of the box.
See more details under Blue Vibes Spring Security.

Proxying requests to third party API

In some cases, the data for the GUI come from existing back-end or a third party API. This is especially interesting as the digital world is moving in the direction of open APIs (e.g. open banking APIs initiative). In this case, there is usually no need to write own back-end (server-side) logic or have own database. However, we would still like to have the flexibility of adding our own logic (REST endpoints) in the future.

A good approach to achieve this is to route front-end application towards existing back-end, without the boilerplate code and potential redundant serialization/deserialization of requests. We find this a better approach than directly calling external back-end from front-end application, for the reasons listed below.

Benefits of this approach:

1) Structure: The standard structure of Blue Vibes micro-app is maintained (maven multi-module project).

2) Architecture: Spider web syndrome of many requests going everywhere is avoided, because we know exactly where all requests come from and where they go first (own back-end).

3) Flexibility: It is possible to extend business logic and write own back-end logic at any time - one part will remain routing to 3rd party system, the new endpoint will route to internal back-end logic.

4) CORS: Same origin problems (CORS) are avoided, which are typical for these scenarios.

5) Examples and reuse: Our own infrastructure and existing examples can be reused (no need to reinvent the wheel).

Here we are going to describe how to implement this approach using Spring Cloud Zuul routing module.

Dependency

The first step that has to be done is introducing spring-cloud-starter-netflix-zuul by adding it to maven pom, and since the cloud version is defined in bv-spring, there is no need for it.

<dependency>
    <groupId>io.bluevibes</groupId>
    <artifactId>bv-app</artifactId>
</dependency>

Configuration

Once we have the dependency in the class path, next step is enabling ZuulProxy in the micro-application. That can be done by putting the following annotation @EnableZuulProxy on spring-boot Application class or any other configuration class:

@EnableZuulProxy
@SpringBootApplication
public class Application {
    public static void main(String[] args) {
        SpringApplication.run(Application.class, args);
    }
}

The final step is configuring ZuulProxy to redirect certain request to the 3rd-party service and it can be done by configuring the following properties:

zuul:
  routes:
    third-party-api: # represent route id
      path: /third-party/**
      url: "https://api.third-party.com"

With this configuration every request to your application that starts with /third-party will be passed to the third-party, i.e: GET https://your-domain/your-app-context/third-party/v1/user will be passed to https://api.third-party.com/v1/user. Zuul will pass every request that can be matched with route matcher defined in property path (“/third-party/**”), and it will pass it to the location that is defined in property url (https://api.third-party.com).
Notice: Zuul configuration allows defining more than one route if it’s needed. Route id must be unique and in case of multiple routes the first route that match request will be applied.

Passing headers and cookies

Headers will be passed per default, unless they are considered sensitive. sensitiveHeaders=Cookie,Set-Cookie,Authorization.
To pass these as well, you have to override the zuul configuration by setting it to empty value:

zuul:
  sensitiveHeaders:

Additionally, it is possible to disable passing of some specific cookie:

zuul:
  ignoredHeaders: some-header

This is the simplest usage of the Zuul. Generally Zuul provides a lot more features, please check the official documentation to see them all: https://cloud.spring.io/spring-cloud-static/Greenwich.SR5/single/spring-cloud.html#_router_and_filter_zuul