Manju

Greetings! Efficient performance is a crucial non-functional requirement in modern applications. Customers can become easily frustrated and may seek alternative solutions if performance falls short. As developers, it is our responsibility to ensure that performance meets the required standards. I'd like to highlight a common mistake that developers might make if they are not familiar with the underlying theory. While the focus here is primarily on Node.js, the principles apply more broadly. Microservices leverage diverse technologies, and Node.js is a good candidate for API Gateways/ Proxy servers. These gateways play a key role in routing traffic to the underlying downstream microservices. Understanding this dynamic is both interesting and essential when working with Node.js. Note: In Node.js 19, agent keep-alive is now enabled by default. The Problem When incorporating libraries, developers often stick to default configurations or modify only the apparent settings. This approac...

Greetings! I have been working on this big monolithic application for a few years now. Some people called it a Dinosaur due to it is size and the old technical stack. I have improved my module by applying various modern-day techniques and this is one of those where I restructured all the main REST APIs. The problem When a system gets older without paying attention to technical details, development technologies, tools, hosting, and architecture, everything gets increasingly obsolete. Adding new features becomes very complex. Harder to scale, maintain, and release. In short, it takes months to complete and release a little change. The wrong way "Let's re-write this" is the normal way people think and that is the wrong way. Why? because it is a running business. It will not add value immediately. There are projects done this way and already years late to production. "Let's create a new UI with the latest web technologies" is the other wrong idea. Why do you tak...

Greetings! Microservices are very flexible. We can have multiple microservices for each domain and interact as necessary. But it comes with a price. It becomes very complex when the number of microservices grow. Imagine a situation where you found a bug or slowness in the system. How do you find the root cause by examinig logs? Collect all the logs from related microservices. Pick the starting microservice and find a clue there using some id (userid, businessid, etc). Pick the next microservice and check whether the previous information are there. Keep going until you find which microservice has the bug. I have followed that practise in one of my previous projects. It is very difficult and takes a lot of time to track an issue. This is why we need to use distributed tracing in microservices. One place where we can go and see the entire trace. It helps us by; Asign unique id (correlation id) to all request. Pass unique id across all the microservices automatically. Re...

Greetings! I was too busy past couple of days and lost my way of continuing Microservices series. So I decided to add simple dummy services service-a and service-b. Other than that, there is no change except the github repo. https://github.com/slmanju/simple-microservice In Microservices architecture we are dealing with many apis which work along or work with other services. Imagine that we are going to create a mobiile client using these client it will be very difficult to manage all services by that client. Or, imagine we expose our apis so that anyone can create their own client. This is a good place to introduce a another service which act as a gateway to all other services. Third party clients will know only about this api. Not only this, we can solve some other problems using Api Gateway. Single entry point to all the services. Common place to log request and responses. Authentication users in single place. Rate limits. Add common filters. Hide internal services. ...

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...

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...