SpringBoot With Angular 4 Integration and Social Authentication

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.

Tech Stack

  • Angular 4
  • SpringBoot
  • Gradle


Let’s start creating an application

  • Create a simple spring boot application using Spring.io
    • Project Type with gradle and Java
    • Add necessary description, group, and artifact
    • Add following dependencies to it.

compile 'org.springframework.cloud:spring-cloud-starter-config'
compile 'org.springframework.security:spring-security-web'
compile 'org.springframework.security:spring-security-config'
compile 'org.springframework.security.oauth:spring-security-oauth2'
compile 'org.apache.httpcomponents:httpclient'

compile group: 'org.slf4j' , name: 'slf4j-api' , version: '1.7.22'
compile group: 'io.jsonwebtoken' , name: 'jjwt' , version: '0.7.0'
compile group: 'commons-io' , name: 'commons-io', version: '2.5'
compile group: 'org.projectlombok' , name: 'lombok' , version: '1.16.12'

These dependencies will allow us to enable the google authentication on the top of normal spring boot application.

  • Create the property file application-local.yml in the java main resources.

clientId: ******.apps.googleusercontent.com
clientSecret: ********
accessTokenUri: https://www.googleapis.com/oauth2/v4/token
userAuthorizationUri: https://accounts.google.com/o/oauth2/v2/auth
clientAuthenticationScheme: form
- openid
- email
- profile
userInfoUri: https://www.googleapis.com/oauth2/v3/userinfo
preferTokenInfo: true

role: test-role

We have created a property file to enable google authentication against the particular client.Replace the * with your actual data.

  • Create bootstrap.yml with following data.
    name: frontend
    active: local
      uri: http://localhost:8888
      enabled: true</pre>

It will help us to give the name to our application and will activate “LOCAL” profile.

  • Create a Security Config java file “SpringConfig” on the same level as of the main file.

package com.test.practise;

import org.springframework.boot.autoconfigure.security.oauth2.client.EnableOAuth2Sso;
import org.springframework.context.annotation.Configuration;
import org.springframework.security.config.annotation.web.builders.HttpSecurity;
import org.springframework.security.config.annotation.web.configuration.WebSecurityConfigurerAdapter;

public class SecurityConfig extends WebSecurityConfigurerAdapter {

    protected void configure(HttpSecurity http) throws Exception {

                .antMatchers( "/login","/public/**", "/resources/**","/resources/public/**")

It will apply authentication to all the path accept /login,  /public,  /resources/public/.

  • Add controller for logout “SecurityController”
<pre>package com.test.practise.controller;

import org.springframework.security.core.Authentication;
import org.springframework.security.core.context.SecurityContextHolder;
import org.springframework.security.web.authentication.logout.SecurityContextLogoutHandler;
import org.springframework.stereotype.Controller;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RequestMethod;

import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;

public class SecurityController {

    @RequestMapping(value="/logout", method = RequestMethod.GET)
    public String logoutPage (HttpServletRequest request, HttpServletResponse response) {
        Authentication auth = SecurityContextHolder.getContext().getAuthentication();
        if (auth != null){
            new SecurityContextLogoutHandler().logout(request, response, auth);
        return "redirect:/";

It will enable the logout URL, which will delete the session.

  • We are not pretty much done with the spring side coding, but we have not added any view or frontend related code yet. We will create the angular project now.
  • Go to the root of the project and create the angular project angular-cli.

ng new webui

It will create a new project directory for frontend inside our current project directory.

  • Navigate to a webui directory which you have created, and make 3 testing controller using the following command.

ng g component landingComponent

ng g component homeComponent

ng g component settingComponent

These are the dummy component to show the routing.

  • Now we will mention our routes in the angular project in file app.module.ts

<pre>import {RouterModule, Routes} from "@angular/router";</pre>

const appRoutes: Routes =[





  • Add routing module in Imports in the same file.
  declarations: [
  imports: [
  providers: [],
  bootstrap: [AppComponent]

  • replace the code of app.component.html the main page of ui with following code.

<pre>&lt;!–The content below is only a placeholder and can be replaced.–&gt;
&lt;div style="text-align:center"&gt;
Welcome to {{title}}!!
&lt;img width="300" src="data:image/svg+xml;base64,PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0idXRmLTgiPz4NCjwhLS0gR2VuZXJhdG9yOiBBZG9iZSBJbGx1c3RyYXRvciAxOS4xLjAsIFNWRyBFeHBvcnQgUGx1Zy1JbiAuIFNWRyBWZXJzaW9uOiA2LjAwIEJ1aWxkIDApICAtLT4NCjxzdmcgdmVyc2lvbj0iMS4xIiBpZD0iTGF5ZXJfMSIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDAvc3ZnIiB4bWxuczp4bGluaz0iaHR0cDovL3d3dy53My5vcmcvMTk5OS94bGluayIgeD0iMHB4IiB5PSIwcHgiDQoJIHZpZXdCb3g9IjAgMCAyNTAgMjUwIiBzdHlsZT0iZW5hYmxlLWJhY2tncm91bmQ6bmV3IDAgMCAyNTAgMjUwOyIgeG1sOnNwYWNlPSJwcmVzZXJ2ZSI+DQo8c3R5bGUgdHlwZT0idGV4dC9jc3MiPg0KCS5zdDB7ZmlsbDojREQwMDMxO30NCgkuc3Qxe2ZpbGw6I0MzMDAyRjt9DQoJLnN0MntmaWxsOiNGRkZGRkY7fQ0KPC9zdHlsZT4NCjxnPg0KCTxwb2x5Z29uIGNsYXNzPSJzdDAiIHBvaW50cz0iMTI1LDMwIDEyNSwzMCAxMjUsMzAgMzEuOSw2My4yIDQ2LjEsMTg2LjMgMTI1LDIzMCAxMjUsMjMwIDEyNSwyMzAgMjAzLjksMTg2LjMgMjE4LjEsNjMuMiAJIi8+DQoJPHBvbHlnb24gY2xhc3M9InN0MSIgcG9pbnRzPSIxMjUsMzAgMTI1LDUyLjIgMTI1LDUyLjEgMTI1LDE1My40IDEyNSwxNTMuNCAxMjUsMjMwIDEyNSwyMzAgMjAzLjksMTg2LjMgMjE4LjEsNjMuMiAxMjUsMzAgCSIvPg0KCTxwYXRoIGNsYXNzPSJzdDIiIGQ9Ik0xMjUsNTIuMUw2Ni44LDE4Mi42aDBoMjEuN2gwbDExLjctMjkuMmg0OS40bDExLjcsMjkuMmgwaDIxLjdoMEwxMjUsNTIuMUwxMjUsNTIuMUwxMjUsNTIuMUwxMjUsNTIuMQ0KCQlMMTI1LDUyLjF6IE0xNDIsMTM1LjRIMTA4bDE3LTQwLjlMMTQyLDEzNS40eiIvPg0KPC9nPg0KPC9zdmc+DQo="&gt;
&lt;a href="/setting"&gt;Direct Setting&lt;/a&gt;
&lt;a href="/welcome"&gt;Direct Welcome&lt;/a&gt;
&lt;a routerLink="/" routerLinkActive="active"&gt;Landing Page&lt;/a&gt;
&lt;a routerLink="/welcome" routerLinkActive="active"&gt;Welcome Page&lt;/a&gt;
&lt;a routerLink="/setting" routerLinkActive="active"&gt;Setting Page&lt;/a&gt;


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.
  • Add following task to build.gradle


task removeWebui(type: Delete) {
delete "${sourceSets.main.resources.srcDirs[0]}/webui"

task copyWebui(type: Copy) {
from "webui/dist"

into "${sourceSets.main.resources.srcDirs[0]}/webui"
exclude "*.gz"
//eachFile { println it.name }

task downloadRedoc(type: Download) {
src "https://rebilly.github.io/ReDoc/releases/latest/redoc.min.js&quot;
dest "${sourceSets.main.resources.srcDirs[0]}/public/redoc"
overwrite true

task var &lt;&lt; {
sourceSets {
main {
println "java.srcDirs = ${java.srcDirs}"
println "resources.srcDirs = ${resources.srcDirs[0]}"
println "output.classesDir = ${output.classesDir}"
println "output.resourcesDir = ${output.resourcesDir}"

compileJava.dependsOn downloadRedoc
copyWebui.dependsOn removeWebui
compileJava.dependsOn copyWebui</pre>

  • Create controller for APIs “WebRestController

package com.test.practise.controller;

import org.springframework.cloud.context.config.annotation.RefreshScope;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RestController;

public class WebRestController {

public String test(){
return "test api data";

  • Create a view controller for enabling angular routes
<pre>package com.test.practise.controller;

import lombok.extern.slf4j.Slf4j;
import org.springframework.stereotype.Controller;
import org.springframework.web.bind.annotation.RequestMapping;
import springfox.documentation.annotations.ApiIgnore;

public class ViewController {

    @RequestMapping({ "/","/welcome" })
    public String views() {
        return "forward:/index.html";


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.

For reference, you can check the GIT REPO with sample working code.



How to fail with MicroServices



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 in Java Using Annotation

What is AOP? 

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.

To read more about the AOP, read here.

How to use Annotation with 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.

Here is an example of the same of how to use annotation for logging.




What Yagni Is?

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.

Try to solve problems in generic ways, that can be used in future.