Manju

Greetings! In my previous post I introduced Feign REST client with hard coded (or single) URL. We can improve it using Ribbon . Ribbon is a client side load balancer which not only provides load balancing feature but also support caching, fault tolerance. Source code can be found at github. Add Ribbon library <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-netflix-ribbon</artifactId> </dependency> Update properties Update cart-service.yml catalog-service: ribbon: listOfServers: localhost:8010,localhost:8011 Update Fiegn Client @FeignClient(name = "catalog-service") @RibbonClient(name = "catalog-service") public interface CatalogServiceFeign Restart the cart service and test the application. Remember to push the configuration changes to github. References https://github.com/Netflix/ribbon https://cloud.spring.io/spring-cloud-netflix/multi/multi_...

Greetings! In our previous posts we used Spring RestTemplate as our Rest client. Even though it was easy to use, we have lots of boilerplate code. This is why we are going to use Netflix Feign Client. If you have used Retrofit, this looks familiar (or Spring Data JPA). With Feign, we are only creating the interface with few annotations. Then Feign will create the necessary implementation for us. One of the main advantages using Feign is, inbuilt support of Ribbon load balancing and easy to connect with Eureka server. Source code can be found at github Add Feign library <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-openfeign</artifactId> </dependency> Enable Feign client @EnableFeignClients @SpringBootApplication public class ShoppingCartServiceApplication Implement Feign client Create an interface. Annotate it with @FeignClient with url and mandatory name. Add method...

Greetings! There were time we hard coded configuration properties directly into the code. When we get matured we learnt that it is always a better choice to remove hard coded values from the code and add them as configurable properties. That definitely paid off. For an example we add our database configuration in a separate file so that depending on the environment we can easily change it. We when use profiles we go one step further to add file per environment like dev, live, etc. How will this effect to microservices architecture? If we are dealing with small number of microservices it is ok to bundle them with the corresponding jar though it is not the microservices way of doing things. When number of the services are growing how do you maintain your environment? It will be a nightmare to keep a track of all properties in this way. Also, when we automate our release process it will be harder to do so. This is why in microservices architecture we need to segregate all the serv...

Greetings! To explain microservices architecture in coming posts I am going to create a very basic shopping cart. This is very simple set up with shopping cart service which interact with product service to get product details. Get the initial project I have provided necessary postman collection to test the project. Just to brush up, let's see how easy it to create a microservice with modern Java tech stack. Navigate to https://start.spring.io/ Select Web, Actuator, JPA, H2, Lombok dependencies. Generate the project. Import the project into preferred IDE. Run the application. That is within few minutes we have a running skeleton.