Micro Frontend Overview: Single SPA

Reading Time: 7 minutes

Introduction to micro frontend architecture

Micro Frontend is a design pattern which enables splitting large and complex web applications into lightweight web applications. Each of these micro frontends can be managed by a different team with the freedom to choose their own framework (Vue.js, React, Angular, etc.) in the implementation. This allows every micro frontend to have its own git repository, its own package.json file and build tool configuration. The result is having an independent build process and independent deploy / CI, which in general provides fast build times for each repo. All of these loosely coupled web apps are then integrated into a single container or user interface to create a seamless experience. 

Advantages of using micro frontend architecture

Great number of single page applications or isomorphic web apps have been developed and deployed over the years. The size and complexity of these web/apps grew and posed similar challenges to that of monolithic applications. Now, these applications face multiple challenges and issues like performance degradation with each release, non-scalability, and difficulty in making modifications and ensuring maintenance. Micro frontend architecture is the answer to all these issues.

  • Modular, reusable, cohesive and manageable code base
  • Possibility to create technology agnostic solutions that can be developed by independent teams.
  • Web App will be extremely contextual, intuitive and responsive
  • Allows the leveraging of lazy loading to improve the overall frontend performance.
  • Gives the ability to upgrade the sections of the frontend independently
  • Multiple micro frontends could be loaded on the same page without refreshing the page
  • Each micro app could be developed using a different frontend JavaScript framework like Angular, React, Vue.js etc.
  • Offers an easy way to share a common access token between child apps
  • Better control in terms of authentication and authorization
  • Separation of concerns as each micro frontend’s design is based on a specific use case or business need
  • Small bundle size of each micro frontend delivers better performance
  • An independent CI/CD pipeline can be built for each micro frontend and can be deployed without affecting the others
  • It offers a highly scalable architecture
  • Small and structured code base which gives more control on refactor, change and maintenance of the code
  • Speeds up the development process
  • One micro frontend can pass down initialization information, like the rendering target, to another
  • Common event bus reference can be passed between micro frontends to enable them to talk to each other
  • It supports mono-repo architecture as well, meaning all micro frontends can built on top of common reusable libraries/components

Challenges encountered using this approach

  • Debugging across multiple micro frontends can sometimes be challenging and tedious
  • Because every team is working independently, there are high chances of deviation in folder structure and coding standards, there is a possibility of redundant code, duplication of dependencies or references
  • Micro frontends developed using different JavaScript frameworks increase maintainability requirements
  • Not recommended for SEO requirement

Single Spa – Short overview

There are a lot of frameworks out there that can be used to implement this architecture. One of the most popular of these frameworks is Single SPA.
Single SPA is an open source project, for bringing together multiple JavaScript micro frontend applications, by simplifying the composition of multiple front-end applications into a single product.

So it’s basically an NPM package that controls the mounting and unmounting of your micro-frontends. You can think of it as a top level router which when a route is active it will download and execute the code for that particular route.

Micro Frontend Reference Architecture

Elements of Single SPA

Single SPA config (aka root config)

  •  Root HTML file
  •  JavaScript that registers applications
  • Applications

Looking at the different elements that Single SPA consists of, there are two main elements. First is the Single SPA config which is usually referred to as a root config. That is the root HTML file that is shared by all the Single SPA applications.

<!DOCTYPE html>
<html lang="en">
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <meta http-equiv="X-UA-Compatible" content="ie=edge">
  <meta name="importmap-type" content="systemjs-importmap" />
  <script type="systemjs-importmap">
      "imports": {
        "single-spa": "https://cdn.jsdelivr.net/npm/single-spa@5.9.0/lib/system/single-spa.min.js",
        "ht-equipment-desk-frontend": "<%= equipmentDeskUrl %>",
        "ht-skills-portal-frontend": "<%= skillsPortalUrl %>",
        "frontend": "<%= helloTodayUrl %>"
  <script src="https://cdn.jsdelivr.net/npm/import-map-overrides@2.2.0/dist/import-map-overrides.js"></script>
  <script src="https://cdn.jsdelivr.net/npm/systemjs@6.8.3/dist/system.js"></script>
  <script src="https://cdn.jsdelivr.net/npm/systemjs@6.8.3/dist/extras/amd.js"></script>
  <link href='https://fonts.googleapis.com/css?family=Roboto:300,400,500,700|Material+Icons' rel="stylesheet">
  <link rel="stylesheet" href="https://cdn.jsdelivr.net/npm/@mdi/font@latest/css/materialdesignicons.min.css">
  <link href='https://fonts.googleapis.com/css?family=Poppins&display=swap' rel="stylesheet">
    You need to enable JavaScript to run this app.
    <div id="app"></div>
  <import-map-overrides-full show-when-local-storage="devtools" dev-libs></import-map-overrides-full>

and some JavaScript that registers the applications

import { registerApplication, start } from "single-spa";
import { Apps, RegisteredChildApps, ExposedChildAppFunctions } from "./types/config";

const System = (window as any).System;

export const registeredChildApps: RegisteredChildApps = {};

const registerExposedChildAppFunctions = (
  appName: string,
  registry: RegisteredChildApps,
  exposedFunctions: ExposedChildAppFunctions
): void => {
  registry[appName] = exposedFunctions;

const apps: Apps[] = [
    name: "ht-skills-portal-frontend",
    pathName: "skills-portal"
    name: "ht-equipment-desk-frontend",
    pathName: "equipment-desk"
    name: "frontend",
    pathName: "hello-today"

window.addEventListener("register-apps", (e: Event) => {
  apps.forEach(app => {
      name: app.name,
      app: async () => {
        const module = await System.import(app.name);
        if (module.exposedUtilityFunctions) {
          registerExposedChildAppFunctions(app.name, registeredChildApps, module.exposedUtilityFunctions);
          if (module?.exposedUtilityFunctions?.setToken) {
            module.exposedUtilityFunctions.setToken((e as CustomEvent).detail.keycloak.token);
        return module;
      activeWhen: location => location.pathname.includes(app.pathName)
  urlRerouteOnly: false

To go in more detail, you need to register the applications with single-spa, so it knows how and when to initiate, load, mount and unmount them. When you register an application, you need to include three things: give it a name, supply a function that will actually load the applications code, and you need to supply a function that determines when the application is active or inactive. Additionally there should be a start function (that calls the start API) in order for the applications to be mounted. Before calling the start function the applications will be loaded, but they won’t be bootstrapped, mounted or unmounted.

The second main element is the applications, which you can have an N number of. Each application is responsible for implementing the following API:

  • bootstrap()
  • mount()
  • unmount()

The bootstrap function initializes the application, and it’s called only once, right before the registered application is loaded for the first time. And the self explanatory mount/unmount functions. All these functions need to return a promise or be an async function. Once that is defined, single-spa will do the rest.


There are plenty of ways to approach micro frontends these days. The given entry is only a small fragment introducing you to design an application with the use of a micro frontends. My recommendation is to check a variety of patterns and solutions before you start implementing this approach. There isn’t any standard as of today for implementing micro frontends. By choosing this approach you’ll definitely have a lot of advantages when compared to the monolithic approach. Just remember that the monolithic architecture is not necessarily a bad choice. It all depends on the specifications of the project and the team working on it, you should always strive to facilitate and simplify solutions as much as possible.

I hope this article gave you a brief idea about micro frontends, and if you are interested in exploring more about Single SPA, you can refer to their documentation.

Thanks for reading!

Microservice architecture: Using Java thread locals and Tomcat/Spring capabilities for automated information propagation

Reading Time: 13 minutes

Inter-microservice communication has always brought questions and challenges to software architects. For example, when it comes to propagating certain information (via HTTP headers for instance) through a whole chain of calls in the scope of one transaction, we want this to happen outside of the microservices’ business logic. We do not want to tackle and work with these headers in the presentation or service layers of the application, especially if they are not important to the microservice for completing some business logic task. I would like to show you how you can automate this process by using Java thread locals and Tomcat/Spring capabilities, showing a simple microservice architecture.

Architecture overview

Architecture overview

This is the sample architecture we will be looking at. We have a Zuul Proxy Server that will act as a gateway towards our two microservices: the Licensing Microservice and the Organization Service. Those three will be the main focus of this article. Let’s say that a single License belongs to a single Organization and a single Organization can deal with multiple Licenses. Additionally, our services are registered to a Eureka Service Discovery and they pull their application config from a separate Configuration Server.

Simple enough, right? Now, what is the goal we want to achieve?

Let’s say that we have some sort of HTTP headers related to authentication or tracking of the chain of calls the application goes through. These headers arrive at the proxy along with each request from the client-side and they need to be propagated towards each microservice participating in the action of completing the user’s request. For simplicity’s sake, let’s introduce two made up HTTP headers that we need to send: correlation-id and authentication-token. You may say: “Well, the Zuul proxy gateway will automatically propagate those to the corresponding microservices, if not stated otherwise in its config”. And you are correct because this is a gateway that has an out-of-the-box feature for achieving that. But, what happens when we have an inter-microservice communication, for example, between the Licensing Microservice and the Organization Microservice. The Licensing Microservice needs to make a call to the Organization Microservice in order to complete some task. The Organization Microservice needs to have the headers sent to it somehow. The “go-to, technical debt” solution would be to read these headers in the controller/presentation layer of our application, then pass them down to the business logic in the service layer, which in turn is gonna pass them to our configured HTTP client, which in the end is gonna send them to the Organization Microservice. Ugly right? What if we have dozens of microservices and need to do this in each and every single one of them? Luckily, there is a lot prettier solution that includes using a neat Java feature: ThreadLocal.

Java thread locals

The Java ThreadLocal class provides us with thread-local variables. What does this mean? Simply put, it enables setting a context (tying all kinds of objects) to a certain thread, that can later be accessed no matter where we are in the application, as long as we access them within the thread that set them up initially. Let’s look at an example:

public class Main {

    public static final ThreadLocal<String> threadLocalContext = new ThreadLocal<>();

    public static void main(String[] args) {
        threadLocalContext.set("Hello from parent thread!");
        Thread childThread = new Thread(() -> {
            System.out.println("Child thread: " + threadLocalContext.get()); // Prints null
        childThread.join(); // Waiting for the child thread to finish
        System.out.println("Parent thread: " + threadLocalContext.get()); // Prints "Hello from parent thread!"

We have a single static final ThreadLocal<String> reference that we use for setting some information to the thread (in this case, the string “Hello from parent thread!” to the main thread). Accessing this variable via threadLocalContext.get() (no matter in which class we are, as long as we are on the same main thread) produces the expected string we have set previously. Accessing it in a child thread produces a null result. What if we set some context to the child thread as well:

threadLocalContext.set("Hello from parent thread!");
Thread childThread = new Thread(() -> {
    threadLocalContext.set("Hello from child thread!");
    System.out.println("Child thread: " + threadLocalContext.get()); // Prints "Hello from child thread!"
childThread.join(); // Waiting for the child thread to finish
System.out.println("Parent thread: " + threadLocalContext.get()); // Prints "Hello from parent thread!"

We can notice that the two threads have completely separate contexts. Even though they access the same threadLocalContext reference, in the background, the context is relative to the calling thread. What if we wanted the child thread to inherit its parent context:

public class Main {

    private static final ThreadLocal<String> threadLocalContext = new InheritableThreadLocal<>();

    public static void main(String[] args) throws InterruptedException {
        threadLocalContext.set("Hello from parent thread!");
        Thread childThread = new Thread(() -> {
            System.out.println("Child thread: " + threadLocalContext.get()); // Prints "Hello from parent thread!"
            threadLocalContext.set("Hello from child thread!");
            System.out.println("Child thread: " + threadLocalContext.get()); // Prints "Hello from child thread!"
        childThread.join(); // Waiting for the child thread to finish
        System.out.println("Parent thread: " + threadLocalContext.get()); // Prints "Hello from parent thread!"

We only changed the ThreadLocal to an InheritableThreadLocal in order to achieve that. We can notice that the first print inside the child thread does not render null anymore. The moment we set another context to the child thread, the two contexts become disconnected and the parent keeps its old one. Note that by using the InheritableThreadLocal, the reference to the parent context gets copied to the child, meaning: this is not a deep copy, but two references pointing to the same object (in this case, the string “Hello from parent thread!”). If, for example, we used InheritableThreadLocal<SomeCustomObject> and tackled directly some of the properties of the object inside the child thread (threadLocalContext.get().setSomeProperty("some value")), then this would also be reflected in the parent thread and vice versa. If we want to disconnect the two contexts completely, we just call .set(new SomeCustomObject()) on one of the threads, which will turn its local reference to point to the newly created object.

Now, you may be wondering: “What does this have to do with automatically propagating headers to a microservice?”. Well, by using Servlet containers such as Tomcat (which Spring Boot has it embedded by default), we handle each new HTTP request (whether we like/know it or not :-)) in a separate thread. The servlet container picks an idle thread from its dedicated thread pool each time a new call is made. This thread is then used by Spring Boot throughout the processing of the request and the return of the response. Now, it is only a matter of setting up Spring filters and HTTP client interceptors that will set and get the local thread context that will contain the HTTP headers.


First off, let’s create a simple POJO class that is going to contain both of the headers that need propagating:

public class RequestHeadersContext {

    public static final String CORRELATION_ID = "correlation-id";
    public static final String AUTHENTICATION_TOKEN = "authentication-token";

    private String correlationId;
    private String authenticationToken;

Next, we will create a utility class for setting and retrieving the thread-local context:

public final class RequestHeadersContextHolder {

    private static final ThreadLocal<RequestHeadersContext> requestHeaderContext = new ThreadLocal<>();

    public static void clearContext() {

    public static RequestHeadersContext getContext() {
        RequestHeadersContext context = requestHeaderContext.get();
        if (context == null) {
            context = createEmptyContext();
        return context;

    public static void setContext(RequestHeadersContext context) {
        Assert.notNull(context, "Only not-null RequestHeadersContext instances are permitted");

    public static RequestHeadersContext createEmptyContext() {
        return new RequestHeadersContext();

The idea is to have a Spring filter, that is going to read the HTTP headers from the incoming request and place them in the RequestHeadersContextHolder:

public class RequestHeadersServiceConfiguration {

    public Filter getFilter() {
        return new RequestHeadersContextFilter();

    private static class RequestHeadersContextFilter implements Filter {

        public void doFilter(ServletRequest servletRequest, ServletResponse servletResponse, FilterChain filterChain) throws IOException, ServletException {
            HttpServletRequest httpServletRequest = (HttpServletRequest) servletRequest;
            RequestHeadersContext context = new RequestHeadersContext(
            filterChain.doFilter(servletRequest, servletResponse);

We created a RequestHeadersServiceConfiguration class which, at the moment, has a single Spring filter bean defined. This filter is going to read the needed headers from the incoming request and set them in the RequestHeadersContextHolder (we will need to propagate those later when we make an outgoing request to another microservice). Afterwards, it will resume the processing of the request and will give control to the other filters that might be present in the filter chain. Keep in mind that, all the while, this code executes within the boundaries of the dedicated Tomcat thread, which the container had assigned to us.

Next, we need to define an HTTP client interceptor which we are going to link to a RestTemplate client, which in turn is going to execute the interceptor’s code each time before it makes a request to an outer microservice. We can add this new RestTemplate bean inside the same configuration file:

public class RequestHeadersServiceConfiguration {
    // .....

    public RestTemplate getRestTemplate() {
        RestTemplate restTemplate = new RestTemplate();
        List<ClientHttpRequestInterceptor> interceptors = restTemplate.getInterceptors();
        interceptors.add(new RequestHeadersContextInterceptor());
        return restTemplate;

    private static class RequestHeadersContextInterceptor implements ClientHttpRequestInterceptor {

        public ClientHttpResponse intercept(@NonNull HttpRequest httpRequest,
                                            @NonNull byte[] body,
                                            @NonNull ClientHttpRequestExecution clientHttpRequestExecution) throws IOException {
            RequestHeadersContext context = RequestHeadersContextHolder.getContext();
            HttpHeaders headers = httpRequest.getHeaders();
            headers.add(RequestHeadersContext.CORRELATION_ID, context.getCorrelationId());
            headers.add(RequestHeadersContext.AUTHENTICATION_TOKEN, context.getAuthenticationToken());
            return clientHttpRequestExecution.execute(httpRequest, body);

As you might have guessed, the interceptor reads the header values from the thread-local context and sets them up for the outgoing request. The RestTemplate just adds this interceptor to the list of its already existing ones.

A good-to-have thing will be to eventually clear/remove the thread-local variables from the thread. When we have an embedded Tomcat container, missing out on this point will not impose a problem, since along with the Spring application, the Tomcat container dies as well. This means that all of the threads will altogether be destroyed and the thread-local memory released. However, if we happen to have a separate servlet container and we deploy our app as a .war instead of a standalone .jar, not clearing the context might introduce some memory leaks. Imagine having multiple applications on our standalone servlet container and each of them messing around with thread locals. The container shares its threads with all of the applications. When one of the applications is turned off, the container is going to continue to run and the threads which it borrowed to the application will not cease to exist. Hence, the thread-local variables will not be garbage collected, since there are still references to them. That is why we are going to define and add an interceptor to the Spring interceptor registry, which will clear the context after a request finishes and the thread can be assigned to other tasks:

public class WebMvcInterceptorsConfiguration implements WebMvcConfigurer {

    public void addInterceptors(InterceptorRegistry registry) {
        registry.addInterceptor(new RequestHeadersContextClearInterceptor()).addPathPatterns("/**");

    private static class RequestHeadersContextClearInterceptor implements HandlerInterceptor {

        public void afterCompletion(HttpServletRequest request, HttpServletResponse response, Object handler, Exception exception) {

All we need to do now is wire these configurations into our microservices. We can create a separate library extracting the config (and maybe upload it to an online repository, such as Maven Central, or our own Nexus) so that we do not need to copy-paste all of the code into each of our microservices. Whatever the case, it is good to make this library easy to use. That is why we are going to create a custom annotation for enabling it:

@Import({RequestHeadersServiceConfiguration.class, WebMvcInterceptorsConfiguration.class})
public @interface EnableRequestHeadersService {


Let’s see how we can leverage and use this library from inside a microservice. Only a couple of things are needed.

First, we need to annotate our application with the @EnableRequestHeadersService:

public class LicensingServiceApplication {

    public static void main(String[] args) {
        SpringApplication.run(LicensingServiceApplication.class, args);

Second, we need to inject the already defined RestTemplate in our microservice and use it as given:

public class OrganizationRestTemplateClient {

    private final RestTemplate restTemplate;

    public OrganizationRestTemplateClient(RestTemplate restTemplate) {
        this.restTemplate = restTemplate;

    public Organization getOrganization(String organizationId) {
        ResponseEntity<Organization> restExchange = restTemplate.exchange(
        return restExchange.getBody();

We can notice that the getOrganization(String organizationId) method does not handle any HTTP headers whatsoever. It just passes the URL and the HTTP method and lets the imported configuration do its magic. As simple as that! We can now call the getOrganization method wherever we like, without having any sort of knowledge about the headers that are being sent in the background. If we have the need to read them somewhere in our code, or even change them, then we can use the RequestHeadersContextHolder.getContext()/setContext() static methods wherever we like in our microservice, without the need to parse them from the request object.

Feign HTTP Client

If we want to leverage a more declarative type of coding we can always use the Feign HTTP Client. There are ways to configure interceptors here as well, so, using the RestTemplate is not strictly required. We can add the new interceptor configuration to the already existing RequestHeadersServiceConfiguration class:

public class RequestHeadersServiceConfiguration {

    // .....

    public RequestInterceptor getFeignRequestInterceptor() {
        return new RequestHeadersContextFeignInterceptor();

    private static class RequestHeadersContextFeignInterceptor implements RequestInterceptor {

        public void apply(RequestTemplate requestTemplate) {
            RequestHeadersContext context = RequestHeadersContextHolder.getContext();
            requestTemplate.header(RequestHeadersContext.CORRELATION_ID, context.getCorrelationId());
            requestTemplate.header(RequestHeadersContext.AUTHENTICATION_TOKEN, context.getAuthenticationToken());

The new bean we created is going to automatically be wired as a new Feign interceptor for our client.

Next, in our microservice, we can annotate our application class with @EnableFeignClients and then create our Feign client:

public interface OrganizationFeignClient {

    @GetMapping(value = "/v1/organizations/{organizationId}")
    Organization getOrganization(@PathVariable("organizationId") String organizationId);

All that we need to do now, is just inject our new client anywhere in our services and use it from there. In comparison to the RestTemplate, this is a more concise way of making HTTP calls.

Asynchronous HTTP requests

What if we do not want to wait for the request to the Organization Microservice to finish and want to execute it asynchronously and concurrently (using the @EnableAsync and @Async annotations from Spring, for example). How are we going to access the headers that need to be propagated in this case? You might have guessed it: by using InheritableThreadLocal instead of ThreadLocal. As mentioned earlier above, the child threads we create separately (aside from the Tomcat ones which will be the parents) can inherit their parent’s context. That way we can send header-populated requests in an asynchronous manner. There is no need to clear the context for the child threads (side note: clearing it will not affect the parent thread, and clearing the parent thread will not affect the child thread; it will only set the current thread’s local context reference to null), since these will be created from a separate thread pool that has nothing to do with the container’s one. The child threads’ memory will be cleared after execution or after the Spring application exits because eventually, they die off.


I hope you will find this neat little trick useful while refactoring your microservices. A lot of Spring’s functionality is actually based on thread locals. Looking into its source code, you will find a lot of similar/same concepts as the ones mentioned above. Spring Security is one example, Zuul Proxy is another.

The full code for this article can be found here.


Spring Microservices In Action by John Carnell

Automate Processes with Camunda

Reading Time: 5 minutes


Camunda BPM is a light-weight, open-source platform for Business Process Management. It ships with tools for creating workflow and decision models, operating deployed models in production, and allowing users to execute workflow tasks assigned to them. It is developed in Java and released as open-source software under the terms of Apache License.

Modeling your first process

In order to show how Camunda works and looks like I will use this simple process. Let us imagine that you want to introduce a review process on your Twitter account and have every tweet go through this review process.

One way to manage this is to make a web application from scratch for this scenario. But we can also model this process with Camunda Modeler and utilize Camunda for this workflow.

On the following image, it is shown one way to model this process with standard BPMN model using Camunda Modeler:

Business Process Model and Notation (BPMN) for the above process

In this diagram, the process is started when someone writes a new tweet. After that, we have a human task where someone has to review this tweet and decide its approval status. And after that we have two possible options if the tweet is approved, a service task is called that will publish this on Twitter. If rejected we again call a service task, however this time we notify the user that his tweet was rejected.

I will go through all of these steps in more detail.

Starting the process

Camunda processes can be started programmatically using some of their supported SDKs like Java or by using the Camunda Tasklist GUI that comes out of the box. In this case, I will use the Camunda tasklist to start a new tweet.

Working on the human task

Human tasks are tasks that must be manually completed by some users. And this can be something as simple as completing a form or it can be something like actually shipping an item somewhere. They are visible in the Camunda Tasklist GUI and users can assign a certain task to themselves and complete them.

In our Camunda BPMN model, the next step in the process is a human task. In our process, we want to review the tweet in this task. On the following image is shown how the human tasks look like by default in Camunda Tasklist:

Automating service tasks

Service task is used to invoke some service, this can be some Java code or some asynchronous external worker.

After the tweet is reviewed we have ‘conditional flow’ in Camunda, which depends on whatever the tweet was approved or not, decides how the flow should continue. In both cases, our flow continues with a service task.

In our case, we have two separate service tasks. One is called when a tweet is rejected and will send a notification, while the other one is used when the tweet is approved and will publish it on Twitter.

First, let us take a look at the service tasks for sending rejection notification:

public class RejectionNotificationDelegate implements JavaDelegate {

  public void execute(DelegateExecution execution) throws Exception {
    String content = (String) execution.getVariable("content");
    String comments = (String) execution.getVariable("comments");

           + "Unfortunately your tweet has been rejected.\n\n"
           + "Original content: {}\n\n"
           + "Comment: {}\n\n"
           + "Sorry, please try with better content the next time :-)", content, comments);

In this code, we obtain process variables like tweet content and rejection comments and we log them in the console. This logic, of course, can be extended to send actual emails, the important thing here is that in order to model Camunda service we only need to implement JavaDelegate interface and override execute method.

In the next code snippet, we have the snippet for publishing the tweet:

public class TweetContentDelegate implements JavaDelegate {

  public void execute(DelegateExecution execution) throws Exception {
	    String content = (String) execution.getVariable("content");

	    AccessToken accessToken = new AccessToken("token", "secret");
	    Twitter twitter = new TwitterFactory().getInstance();


As in the previous code, we also have to implement JavaDelegate and override execute method.

More Camunda examples can be found on their official GitHub repository: https://github.com/camunda/camunda-bpm-examples


In the above diagram, we have only seen one example of a process, but Camunda offers a lot more features for modeling business processes and a lot of out-of-the-box implementations that save a lot of time. Also, almost everything is customizable.

If your company has a lot of processes that can be modeled as a BPMN process or processes that require human intervention then Camunda can be the right tool for the job.

In my opinion, it’s definitely worth to have a basic understanding of how Camunda works in order to be able to spot a use-case for this tool.

Spring Cloud OpenFeign

Reading Time: 3 minutes

Choosing the microservice architecture and Spring Boot means that you’ll need to pick the cleanest possible way for your services to communicate between themselves. Feign Client is one of the best solutions for this issue. It is a declarative Java web service client initially developed by Netflix. It’s an abstraction over REST-based calls allowing your microservices to communicate cleanly without the need to know REST details happening underneath. The main idea behind Feign Client is to create an interface with method definitions representing your service call. Even if you need some customization on requests or responses, you can do it in a declarative way. In this article, we will learn about integrating Feign in a Spring Boot application with an example for REST-based HTTP calls. An example will be given, in which two microservices will communicate with each other to transfer some data. But, first, let’s get familiar with feign.

What is Feign?

Feign is a declarative web service client that makes writing web service clients easier. We use the various annotations provided by the Spring framework such as Requestmapping, @PathVariable in a Java interface to Feign, a declarative web service client. It makes writing web service clients easier. To use Feign create an interface and annotate it. It has pluggable annotation support including Feign annotations and JAX-RS annotations. Feign also supports pluggable encoders and decoders. Spring Cloud adds support for Spring MVC annotations and for using the same HttpMessageConverters used by default in Spring Web. Spring Cloud integrates Ribbon and Eureka to provide a load-balanced HTTP client when using Feign.

Example Management API simulator

In the following code section, you can see a Feign Client resource example. The interface extends the origin API interface to declare the @FeignClient. The @FeignClient declares that a REST client should be created with this interface.

Setup pom.xml

The following dependency will be added:


Enable Feign Client

Now enable the Eureka Feign by using the @EnableFeignClients annotation in a main Spring Boot application class that is also annotated with the @SpringBootApplication annotation.

package com.example.demo;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.cloud.client.discovery.EnableDiscoveryClient;
import org.springframework.cloud.openfeign.EnableFeignClients;
public class FeignClientApplication {
  public static void main(String[] args) {
    SpringApplication.run(FeignClientApplication.class, args);

Use a Circuit Breaker with a Feign Client

If you want to use the Spring Cloud OpenFeign support for Hystrix circuit breakers, you must set the feign.hystrix.enabled property to true. In the Feign version of the Agency app, this property is configured in application.yml:

    enabled: true
@FeignClient(name = "Validations", url = "${validations.host}")
public interface ValidationsClient {

    @GetMapping(value = "/validate-phone")
    InfoMessageResponse<PhoneNumber> validatePhoneNumber(@RequestParam("phoneNumber") String phoneNumber);


In the application.yml file, we will store the URL of the microservice with which we need to communicate:

  host: "http://localhost:9080/validations"

We will need to add a config for Feign as follows:

package com.demo;

import feign.Contract;
import org.springframework.cloud.openfeign.support.SpringMvcContract;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;

public class FeignClientConfiguration {
    public Contract feignContract() {
        return new SpringMvcContract();

Congrats! You just managed to run your Feign Client application by which you can easily locate and consume the REST service.


In this article, we have launched an example of microservice that communicates with one another. This article should be treated as an introduction to the subject of Feign Client and a discussion of integration with other important components of the microservice architecture.

Microservices vs. Monoliths

Reading Time: 3 minutes

What are microservices and what are monoliths?

The difference between monolith and microservice architecture

The task that microservices perform is quite simple: The mapping of software in modules. Now the statement could be made that classes, packages etc. also fulfill the same task. That’s right, but the main difference lies in deployment. It is possible to deploy a microservice without “touching” the other microservices.

Classic monoliths, on the other hand, force deployment of the entire “project”.

Advantages of microservices and disadvantages of monoliths

1. Imagine that you are working on a project that contains thousands or even tens of thousands of lines of code. With each new function, the lines of code grow. Every DEV loses the overview here. Some a little earlier, the other a little later. Ultimately, it is impossible to keep track.
In addition, with each new feature, strange things are created elsewhere. This makes it very difficult to locate bugs and robs any developer of the last nerve.
Unlike monoliths, microservices are defined in small modules. Each microservice serves a specific task. Thus, the manageability is granted a lot easier.

2. The data for monoliths are located in a pool, to which each submodule can access via the interface. If you make a change to the data structure, you have to adapt each submodule, otherwise you have to expect errors.
Microservices are responsible for their own data, and the structure is absolutely irrelevant. Each service can define its structure. Changes to the structure also have no impact on other services, which saves a lot of time and, above all, prevents errors.

3. Microservices are only dependent on microservices that communicate with each other so that in the event of a bug, not the entire system fails. In the monolithic approach, however, the bug of one module means the failure of the entire system.

4. Another disadvantage arises with an update. All monoliths are overinstalled, which costs an enormous amount of time.
For the microsevices, only the services where changes have been made are installed. This saves time and nerves.

5. Detecting errors in the monolithic approach can take a long time for large projects.
Microservices, on the other hand, are “small” and greatly simplify troubleshooting.

6. The team of a monolithic architecture works as a whole, which makes the technical coordination difficult.
The teams of a microservice architecture, however, are divided into small teams, so that the technical coordination is simplified.


The microservice approach divides a big task into small subtasks. This method greatly simplifies the work for developers because on the one hand the overview is easy to keep in contrast to the monolithic approach and on the other hand the microservices are independent of the other microservices.