Multitenancy with Spring Boot

For those who are not familiar with the term Multitenancy, let me start answering some questions that may be come to your mind.

What is multitenancy?

It is a software architecture where the same instance of the software serves multiple tenants. You can see a tenant as an organization. For example, if I have a software platform to sell TV's, my tenants could be Samsung, Philips and Sony. The good thing is that with this approach you are sharing resources, and if you work with cloud platforms this could be a good idea. On the other hand, as you know nothing is free, you have to be aware about the security and the isolation of the data and other things. Before you decide if this kind architecture matches with your requirements, you have to study in deep your requirements.

How to implement that?

I will not delve into the details that motivate the choice of a strategy or another. There are three approaches to do that:

• Separate database per tenant (picture 2).
• Separate schema per tenant.
• Share database and schema.

Ok, we are ready to start. In this example, I am going to implement the first option (separata database per tenant). Note that in this example, the tenants will be added dynamically, this means that only adding the configuration of the tenant in the application.yml will be enough for the application be aware of the new tenant.

I remember you, that this example is using Spring Boot and Hibernate.

First of all we have to add in the application.yml the multitenancy configuration we want. In this case, I have two tenants.

Also we have to exclude the default data source configuration that provides Spring Boot.

The next step, is to provide a mechanism to determine, in runtime, which tenant is accessing to the application instance. To do that, Spring provides an interface to implement it.

RequestContextHolderUtil is a class which determines the tenant based on a pattern contained in the Uri of the request.

Now we need a mechanism to select the correct database (DataSource object) based on the current tenant which is accessing to the application. Once you have the tenant id (above step), you only have to extend the class AbstractDataSourceBasedMultiTenantConnectionProviderImpl provided by Spring.

Note that the object Map (attribute of class AbstractDataSourceBasedMultiTenantConnectionProviderImpl) is configured when the Spring context is loaded reading the multitenancy properties from application.yml. This configuration is performed in a class annotated with @Configuration. You can see the code below.


The last step is to implement a Rest controller to access to the data. Note that the Uri of the endpoint contains the 'tenantId' pattern. Of course, there are different ways to do that. For example using domains or subdomains and so on.

Finally, you can find all the implementation in my GitHub profile here

Feel free to contact me for questions or any doubt.

Happy codying

Template method and Builder pattern using lambdas

Today I want to show you how easy is to implement a Template method pattern using lambdas and Consumer functional interface in Java 8. To illustrate our example, we are going to develop a software to send commands to a robot.

 Before the command is sent, it is required to establish the connection with the robot and set the robot to status ready (ready to receive commands). Finally after the command execution the robot must be set to idle status. Then each command execution requires 4 steps listed below.

1. Establish connection with the robot.
2. Set the robot to ready status.
3. Execute the command.
4. Set the robot to idle status.

Take a look how to implement this, with Java 8 using lambdas.

As you can see in the above code, the client is not worried about how to obtain a robot connection, it only sends the command it want to execute on the robot. At the same time, we are using the lambda to provide a fluent interface to configure the command (Builder pattern).

The method 'executes' acts as template method, and you can see how the RobotCommand object is instantiated locally. Then using the method 'accept', the created RobotCommand is passed to the lambda context.

You can find the complete code here

Decorator pattern using lambdas

The patterns mentioned in the book Gang of Four, persist over the time. In fact, although every days appear a lot new tools and frameworks, the base or the principles of the software engineering don't change so often like it seems (fortunately :P ).

Most of the frameworks and tools you are using right now, are an abstraction of the design patterns and concepts that maybe are more old than you. They introduce you another face of the design pattern, usually intending to hide some complexity.

Today, I want to show you guys what shape (face) takes the decorator pattern  when it is implemented with the lambda functionality provided by Java 8. Maybe I think that the key is thinking in the functions like objects.

Let's start. I like so much pizza, specially those days you don't want to cook, which it is quite often.
So you take the phone and call to order a pizza. Your pizza have a price (a base price), for each complement your are adding to your order, the price is increasing.

Take a look to this approach to implement a Order pizza software.



Here is the interesting part. Note that the reduce method is combining all the complements in a chain of calls with the method AndThen.



As you can see this solution has more expressiveness and also avoids the boilerplate code of the traditional way to implement the decorator pattern.

You can find the complete code in my Github profile here
Thank you very much, we keep sharing knowledge.

Avoiding denied of service with rate limits

There is a lot of guides to help us to define a good Restful services. Mainly they talk about the following points:

• Restful URLs and actions
• Usability
• Security
• Versioning
• Hateoas
• Documentation
• Cache
• Pagination
• Filtering
• Response envelopes
• Rate limit
• ...... and so on

In this case we are going to focus on rate limit aspect. In the next screencast, it is presented an approach to implement a rate limit by IP client, based on RateLimiter class provided by guava library.

See you in the next post!