Manju

Greetings! Unlike Java, Kotlin uses special keywords to declare variables. var - for the values that change, mutable. val - for the values that do not change, immutable. Java String name = "Java"; int age = 20; Kotlin val name = "Kotlin" val age = 4 It is best practice to use val because immutability guarantees safety. We can use variable type when we declare it. If we initialize it, we can remove the type. But if we do not initialize, we should declare the variable type. val name = "Jon Snow" val role: String role = "King in the north" Constant If the value is a truly constant we can const keyword when declaring. Though this needs to use companion object. const val THE_END = "All men must die" Type inference Kotlin is a strongly typed language. Compiler can deduce the type by the context eliminating boilerplate code. Compiler is smart enough to identify the variable type. val helpUs = "Save Wilpattu&

Greetings! I'm going to talk about Kotlin as a Java developer. There are many languages looming and Kotlin is one of them. Since it is another JVM based language it will be easier to grasp. Why another language? Java is more than 20 years old mature, widely used language. The problem of being old is it lacks modern techniques. Even though Java adapted to functional programming with Java 8, I believe it is somewhat late for the game. Considering modern day language features, difficulties they have faced using Java, Jetbrains created Kotlin. Being the one of the best IDE providers they know what they are doing. With InteliJ Idea Kotlin has the best IDE support with it. What is Kotlin Kotlin is a cross-platform, statically typed, general-purpose programming language with type inference. Kotlin is designed to interoperate fully with Java, and the JVM version of its standard library depends on the Java Class Library, but type inference allows its syntax to be more concise.

Greeting! In a monolithic architecture we have all our business logic in one place. We can directly use relevant service through the respective component. When it comes to microservices our business logic is in multiple places working independently. This introduces new problems. How does a service find another service? (hard code url hah?) How do we monitor health conditions? Maintaining address, port How to load balance for dynamic IPs. How about another microservice to handle all these problems? Get the complete source code. Service Registry And Discovery Pattern Service registry is like your address book. It has all the address' you need. When you need to find a place, you get the address book to locate it. Service registry is doing exactly the same thing. It maintains other microservices names, addresses, ports, health. Other microservices register themselves with the registry with necessary information. Discovery service relying on the heartbeat for serv

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 signatur

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.

Greetings! In the past we used to pack all our services into a single bundle and deploy it. This monolithic applications have it's own pros and cons. Massive code bases are difficult to maintain. To deliver a single feature we have to deploy full application. If something fail, whole system fail. Difficult to scale. Domains are tightly coupled. Everything in a single database. Quick deliveries are difficult. This does not mean monolithic systems are bad. It is depending on the system we build. Above mentioned disadvantages will become advantages on those situations. In addition to that a monolithic system; Easy to monitor Have one code base to maintain Easy to trace any error Easy transaction handling. Ideally, if your company is not willing to bear the initial cost (specially start ups), CI/CD pipelines, server costs, etc go with monolithic. On the other hand microservices are here to solve these kind of problems although it is not a one fit for all solu