Target Audience

Developers who are familiar with Java and Spring Boot [with maven]

We all are building various applications in Spring Boot. Spring boot is a simple lightweight spring application with the integrated server. We can run java[spring] application without any hassle, with most of the things are driven by application properties. We run single Spring Boot application in the single JVM. Many times we have to run more than one instance of the same application, to manage a large number of requests. We put these instances behind the load balancer, and load balancer will decide which instance should handle the current request.

Simple Pictorial Design

So our request comes to the load balancer. The load balancer is the entry point of the request. Here we have App 1, which have 3 instances.

Instance: Same Application running in the different server [or in there scope].

So, whenever request goes to any of the instances of App 1, it should behave in the same manner. We create multiple instances so that we can handle more requests. Consider these 3 green regions as separate JVM [seperate tomcat sever].

As we all know two JVMs does not tall to each other, We can consider JVM as an isolated boundary to run a Java application.

Problem Statement

Now suppose you want to somehow share data between these 3 different instances running on different JVM. Assume you need to count of the total number of request server by App 1. If we create a single variable in App1, which will be auto incremented each time request comes to application, it will not solve our problem. Lets name variable requestCounter. Now suppose the total number of request come to load balancer be 3.

Flow Of Request

Request 1 goes to instance 1

Request 2 goes to instance 2

Request 3 goes to instance 1

If We request for the total number of requests server by App 1

Instance 1 will return 2

Instance 2 will return 1

Instance 3 will return 0

Though App 1 serves total number 3 request, all instance provide the wrong result. This is because&nbsp; we are saving the requestCounter variable at an individual instance, thus every instance is giving the response of its state. We can either get the count from all the instance and sum it, but assume if you have hundred of instance of the same application, how you will do that.Even if we are ready to call each instance, we need to maintain the IP address of all the instances which can be very difficult.

For the same, we will you Hazelcast. What Hazelcast&nbsp; will do, it will share the state of variable among different instances [JVM].&nbsp; So in this blog, we will create a simple Spring Boot Application with HazelCast support. And try to share a single long variable among the different instances of Application.

Line 8 represents the instance name, it should be different for each instance, in our case Instance 1, Instance 2 and Instance 3

Line 9 represents the group. in our case it will be App 1, Since there can be much application you are running, you want to share hazelcast cluster among instances of the same app. In the code above we have used dev [App1]. On the same line, we have set the password also, as to avoid adding the cluster of different instance among the same group.

As a full stack developer, we need to create an application with both frontend-end and backend.

Today we will create a simple full stack application which will have a social login using Google authentication.The area on which we want to focus is how to integrate google social authentication to spring-boot, with logout functionality. And when angular 4 is used in spring-boot application to build the UI, how we will manage the routes, as we know that both angular and have routes, so how our application will resolve which route it has to call.

It will create the routes .First two route for setting and welcome is using href. normal HTML routes and then we have refined routes using routerLink.

Build the frontend application

ng build

Now we will make changes in spring application to consume this frontend code.First of all, we will add the code in our build.gradle to copy the frontend code and place it in resource so that it can be consume by spring-boot.

This view controller will enable the spring to resolve these URL as angular URL.

Now we are good to go.Run the spring boot application using gradle bootRun.it will start the application.Once you will try to react the application from the browser, it will navigate you to google login first.

On Successful login, you will see the angular page.So till now we are pretty much done with authentication part. Now comes the routing part.

Now try to navigate to welcome page and setting page using above router.In this case, the welcome route will be successful but setting URL will fail, as we have not mentioned it in ViewController.

But when we try the routes which are below one, every route will work fine, as it is using angular routes.

As we all know, microservices is the new god in the tech industry. Yes, we always have old gods and new gods. Surely microservices have been accepted by the many of the companies, without even understanding how the business will be aligned with it.

Let’s not discuss what is microservices, but we should surely discuss what not to do if you don’t want fire on your ass.Today will try to discuss few of the shortcoming which I have felt after I have[NOT]proudly redesigned the system from monolith to microservices.

Domain is Important, But not the same Domain For every one

We all know the domain is very important for every application.Let’s make our code closer to the real-world entity. But does the sharing of domain make sense?Often people debate about how come we can have a different domain for the same entity.For example, let’s have a Flight domain, Flight will be flight, no matter it is in search service or booking service. Flight can have different attributes in both the context.And you will never replicate these attributes.Never create a single jar of domains to share it among different services. If you have to just kill other your services.

How services are talking to each other

Often developers create many microservices, they all the talking to each other in exactly the same way, it has been doing if they were a monolith.Direct interaction with microservice can be dangerous, can create a bottleneck for a process. Try to design a system in such a way that one service should not be waiting because of the action from another service. Utilize the power of asynchronous request using the messaging queue or any other design.Blocking request can be a hassle. Don’t just create distributed monolith

Complete System Design is Important, Microservice alone cannot do anything

When you are designing the microservice, you are not designing it for fun. It will eventually be plugged in the system to complete the bigger task. So know your system design. All the constraints against which your service will be run should be known. Development of microservice can be done in the isolation, but the birth of any microservice should always be an outcome of whole system design.

Be Ready before you start, DevOps if your key

You can ask yourself, why the concept of microservice in a boom these days. This is because now we have such a capability which can handle such a massive complexity. So DevOps is too important. If your DevOps is not ready to support the proper microservice architecture, never ever think to go towards microservices.You can never create a home if your basic structure is not setup first.

Don’t try to clean the mess of other

Your service is not designed to clean the work of any other service. If any service is not doing its task completely, it’s not your duty to do it, ask that service to do it. There was a very simple example which I want to share, I was consuming one of the services whose owner was sitting beside me. Few of the attributes were missing from the result of that service, so I asked the owner to provide me the missing data, but the conversation finally went in a disappointed way. The owner asks me to fill the data by myself as getting those data points were very difficult for that service. And eventually, my service ends up doing a task which was not in the context of its boundary.

Learn from others, but don’t ever replicate their mistakes

We often share code, when a business is trying to solve the same kind of problems they often end up using the same type of approach/code for the different problem statement. There may be a chance good chance you will solve a problem very quickly by just simple copy paste, but you never know the constraints under which that code was written. With the power of that code, your are also copying the weakness of it. Learn from others, but never accept its solution for granted.

Let the services to micro, not the knowledge pool

In the last point, I have discussed how dangerous the code replication. But This point doesn’t say we should blindly learn from other services. What I want to point out here is share the knowledge of other services, either the technical findings or the business constraints. Because in the end every micro service a broken piece of a giant puzzle

Let the code be agile, not just the process

Often people make the process agile but forget that if your code is not agile you cannot achieve agility. Make your services loosely coupled.Each service should be independent, and there should be minimum effort even if we have to rewrite the entire service.

Monolith business with microservices is as bad as Monolith

“This is the way things are done here”. One of the very old statements from old timers or from the business guys. But this will never help a project. If your system is going toward microservice, itis very important your business should also reflect the same, or honor it.At the end business thinking will be reflected on your system.

Common decision for every service is a hazard

Since every service is designed for its own purpose, a single and common solution can be dangerous for the lifecycle of services. It is very similar to the problem of selling shoes in the two very different geographic area.

Frameworks as awesome, but maybe not awesome for every service

Frameworks are awesome, it will hide the complexity from the developers, and magically do a lot of the stuff. But in-house framework can be a risk to the ongoing project. If you add the in-house framework to each and every service of your, you are binding the bugs associated with the framework to every service. It even often delays the release cycles.

Event Sourcing, I will be another Netflix

Don’t just use any of the modern design just for the sake of using it. Understand the business requirement first. Analyse the scope of your problem in terms of the traffic and availability of the system. What I have seen people often used event sourcing even to solve the simple problem stating the reason “We will be next Netflix”.

Different shops, with the same warehouse

Lest assume we have 5 different shops, but all the shops using the resource from a common pool. We have 10 resources in the pool and 5 services.Ideally 2 resources for each service, but if one of the services goes greedy/faulty and consumed 8 resources.Certainly there is a resource crunch for other services. even though other services are related to service one, but it got affected because of it. Same conditions are very common whenever we are using the same Database for the different microservices.Even in normal conditions, we know that database will be the choking point in the high traffic situation. Should implement the seperate database for separate services.

Pool of PolyGlot can be a pool of death

This point is more in the concern of the company.But not just company is affected, even the developers are affected, as it often increases the effort in maintenance. Choosing entirely different tech stack for each service can increase the project cost, as you need the tech specialist for each tech. Sharing of tech knowledge will be limited. And often the company cannot afford many tech specialists for tech, so eventually, it can let to the dependencies on few of the forks.

Anonymous service is a ghost

One of the common design we can see these days is, if few of the task which is not a good fit any of the existing services, developer eventually put all these tasks in the anonymous service, where no one knows what is happing. Service with no boundary, no exact reason. I call these kinds of services as a ghost. Ghost services are dangerous, and they are often the result of poor design or to support existing business for the time being. But remember you can never get rid of the ghost, and they will haunt you from time to time.

All these are the points which are the concern for me, maybe true or not true for you. These can be avoided or can be tackled with different designs, but do consider them before it late for your service.

AOP stands for the Aspect-Oriented Programming. It is an approach to programming that allows global properties of a program to determine how it is compiled into an executable program. AOP can be used with object-oriented programming ( OOP ).It addresses the problem of cross-cutting concern.

All above is the technical definition, but now we will try to understand it in the more simpler term. Let suppose, as a developer you want to log request and response in the database whenever third-party API is called. One simple method is to add the logging code in the method itself. But should we add the code to log in method, as my method is not created for logging? Even if you are OK with adding the code to the method, now think if you have more than one method where you have to perform this logging. Now what? Will we write the logging code in each and every method?

No, what we will do, we will find some magic way, by which our logs should be automatically written to the database. And that magic is AOP.

Since by now we should know that AOP needs pointcut to perform the magic.Now suppose you just want to log whenever any method is called. If you put a simple annotation on any method, and your work is done.

Often developer debates a lot about what YAGNI is actually. Writing any new piece of code bind developer’s hand in the name of YAGNI.

I have worked in both product base company and service based company.I personally feel that YAGNI is more appreciated in the service based company, as in product based any extra feature is helpful.

People back YAGNI by saying “You don’t wipe before you shit.”.So true.We should not increase the scope of the problem as it may open the gates of new bugs.So YAGNI tells us “don’t write any extra/new code unless it is actually required”.

I agree with the last quoted statement.But should we bind our hands in implementing the requirement in a fashion that it should always be open for extensibility, or to write any functionality in a more generic way so that it can be reused any time in near future?

So, what my definition of YAGNI is: – Always write the code in the scope of the current requirement, but don’t cry out YAGNI if you want to solve it in the generic or extensible way.The code should close for modification but open for extensibility.