Exercise - Microservices - Spring Boot Monolithic Application: E-commerce Platform

[akash-coded]

We can begin with a monolithic application that brings out the challenges which microservices aim to solve. This will set the stage for your Part 2, where microservices can address those problems.

---

Spring Boot Monolithic Application Exercise: E-commerce Platform

Objective: Build a basic E-commerce platform using Spring Boot as a monolithic application. As the platform grows, learners will realize the complexities and potential issues that arise, making the need for microservices evident.

Features:

1. User Management:

   • Register a new user.
   • Update user details.
   • Delete a user.
   • View user details.

2. Product Management:

   • Add a new product.
   • Update product details.
   • Delete a product.
   • View product listings.

3. Order Management:

   • Place a new order for a user.
   • Update order status.
   • View order details.
   • List orders for a user.

Technical Requirements:

1. Spring Boot for building the REST API.
2. Spring Data JPA for database operations.
3. H2 or MySQL as the database.
4. Spring Security for authentication and authorization.

Exercise Steps:

1. Setup: Initialize a new Spring Boot project using Spring Initializer. Add Web, JPA, the chosen database, and Spring Security as dependencies.

2. Database Setup: Design a relational database schema that supports all the features. This might involve tables for Users, Products, and Orders, with relationships between them.

3. API Creation: Start by creating endpoints for each feature listed above. Use Controllers, Services, and Repositories in a layered architecture.

4. Security: Implement basic authentication using Spring Security. Users should be able to register and log in.

5. Testing: Create basic unit and integration tests for your endpoints using JUnit and Spring Boot Test.

---

Challenges to Highlight:

1. Scalability Issues: As the application grows, deploying even minor changes can require the entire application to be redeployed. This can be a problem in real-world scenarios where uptime is crucial.

2. Tight Coupling: All the modules are closely interlinked. Any change in one module can have unintended side effects in another module.

3. Database Monolith: As all modules use a single database, any change in the database schema for one module can affect others.

4. Lack of Flexibility: Different modules might have different scaling or technological needs. In a monolithic application, it's challenging to scale or update one module independently.

5. Development Speed: As the application grows, the development process can slow down due to the complexities of the monolithic structure.

6. Failure Propagation: If one feature/module fails, it can bring down the entire application.

---

After completing this exercise, reflect on the above challenges and introspect on questions like:

• How would you scale the Product Management module independently?
• If there's a bug in the Order Management module, how would you deploy a fix without affecting the other modules?
• How can we design the system to ensure one module's failure doesn't bring down the entire application?

By understanding these challenges, you will be well-prepared to see the benefits of microservices in Part 2.

---

Detailed Implementation Guide: E-commerce Monolithic Application

1. Setting up the Monolithic Application:

1.1. Initial Setup:

• Use the Spring Initializer to bootstrap your Spring Boot project.
• Choose dependencies: Spring Web, Spring Data JPA, Spring Security, and your choice of database (H2 or MySQL).

1.2. Database Schema:

• Define the entities: User, Product, and Order.
• The Order entity should have a many-to-one relationship with both User and Product.

2. Building the Application:

2.1. User Management:

Endpoints:

• POST /users - Register a new user.
• PUT /users/{userId} - Update user details.
• DELETE /users/{userId} - Delete a user.
• GET /users/{userId} - View user details.

Link to Microservices:
In microservices, each service typically has a single responsibility. This entire User Management could be a separate service in a microservices architecture.

2.2. Product Management:

Endpoints:

• POST /products - Add a new product.
• PUT /products/{productId} - Update product details.
• DELETE /products/{productId} - Delete a product.
• GET /products - View product listings.

Link to Microservices:
The Product Management can be modularized as its own service, independently scalable based on load.

2.3. Order Management:

Endpoints:

• POST /orders - Place a new order.
• PUT /orders/{orderId} - Update order status.
• GET /orders/{orderId} - View order details.
• GET /users/{userId}/orders - List orders for a user.

Link to Microservices:
Order Management is another candidate for a separate service in a microservices setup. It depends on both User Management and Product Management, demonstrating service-to-service communication in microservices.

2.4. Security:

• Implement basic authentication using Spring Security.
• Store passwords securely using bcrypt or a similar hashing method.
• Generate JWT (JSON Web Tokens) upon successful authentication.

Link to Microservices:
Security would be implemented at the API Gateway level in microservices, ensuring centralized and consistent security policies.

3. Challenges with the Monolithic Approach:

3.1. Scalability:

If the product listing receives a massive amount of traffic, the entire application must be scaled, even if the other parts don't face heavy loads.

3.2. Deployment Complexity:

Any small change requires the entire application to be redeployed.

3.3. Tight Coupling:

Making changes in one section can lead to unintended consequences in another due to interdependencies.

3.4. Single Point of Failure:

If one module fails, the entire application can become inaccessible.

---

Reflecting on the Microservices Principles:

1. Single Responsibility Principle: Each of the management systems (User, Product, Order) could be its own microservice.
2. Loose Coupling: In the monolithic system, changing one system might need changes in others. Microservices decouple these systems.
3. Services as Components: Each microservice is independently deployable, unlike our monolithic app.
4. Hide Internal Details: Microservices expose only what's necessary through their APIs.
5. Decentralized Governance: Different teams can use different databases or technologies for their respective microservices.
6. Automation of Infrastructure: Microservices can be automatically deployed and scaled using container orchestration systems.
7. Failure Isolation: In a microservices setup, if the Product Management service goes down, User Management and Order Management can still function.
8. Continuous Delivery: Each microservice can have its own CI/CD pipeline.

By the end of this monolithic application project, you should understand the challenges of the monolithic architecture and be ready to explore the advantages of microservices in the subsequent exercise.

---

Code Snippets and Configurations: E-commerce Monolithic Application

Let's dive deeper into the monolithic application creation with code snippets, configurations, and thought processes.

---

1. Setup & Configuration

1.1. Initial Setup

Use Spring Initializer or start manually:

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-data-jpa</artifactId>
</dependency>
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-web</artifactId>
</dependency>
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-security</artifactId>
</dependency>
<!-- For H2 database -->
<dependency>
    <groupId>com.h2database</groupId>
    <artifactId>h2</artifactId>
    <scope>runtime</scope>
</dependency>

1.2. Database Configuration

In application.properties:

spring.datasource.url=jdbc:h2:mem:testdb
spring.datasource.driver-class-name=org.h2.Driver
spring.datasource.username=sa
spring.datasource.password=
spring.jpa.database-platform=org.hibernate.dialect.H2Dialect

2. Entities Creation

2.1. User Entity

@Entity
public class User {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;
    private String username;
    private String password;
    // getters, setters, etc.
}

2.2. Product Entity

@Entity
public class Product {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;
    private String name;
    private double price;
    // getters, setters, etc.
}

2.3. Order Entity

@Entity
public class Order {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    @ManyToOne
    private User user;

    @ManyToOne
    private Product product;

    private int quantity;
    // getters, setters, etc.
}

3. Repositories

For each entity, create a respective repository:

public interface UserRepository extends JpaRepository<User, Long> {
}

4. Services

For each entity, create a service. For instance, for User:

@Service
public class UserService {
    @Autowired
    private UserRepository userRepository;

    public User saveUser(User user) {
        return userRepository.save(user);
    }

    // Additional CRUD methods.
}

5. Controllers

Controllers are the REST endpoints. E.g., for User:

@RestController
@RequestMapping("/users")
public class UserController {
    @Autowired
    private UserService userService;

    @PostMapping
    public User createUser(@RequestBody User user) {
        return userService.saveUser(user);
    }

    // Additional endpoints for CRUD operations.
}

6. Security

For security, we can implement a simple authentication. Extend Spring's WebSecurityConfigurerAdapter:

@Configuration
@EnableWebSecurity
public class SecurityConfig extends WebSecurityConfigurerAdapter {
    @Override
    protected void configure(HttpSecurity http) throws Exception {
        http
            .csrf().disable()
            .authorizeRequests()
            .antMatchers("/users/**").permitAll()
            .anyRequest().authenticated()
            .and().httpBasic();
    }
}

Note: For brevity, user registration & password encryption are not included but should be.

---

Thought Process & Future Microservices Refactoring:

1. Single Database Challenge: The monolithic app uses a single database, which becomes a bottleneck as traffic grows. In a microservice architecture, each service would ideally have its own database.

2. Scalability: As traffic grows, you'd have to scale the entire application rather than individual components. With microservices, you could scale only the frequently accessed services, like Product Listing.

3. Complexity: As more features are added, the application becomes more complex and harder to maintain. In microservices, each service is isolated, making it easier to understand and maintain.

4. Decoupling: The tight coupling between different functionalities (like User, Product, and Orders) can be seen. In microservices, these would be completely separated, only communicating through API calls, hence reducing the chances of unintended side-effects.

[arupmukherjee38]

Arup Mukherjee(tcs id :1524555)
https://github.com/arupmukherjee38/ecommerce

[AnuragMishra58]

Hi @akash-coded
Anurag Mishra, Emp id: 550966
Please find below zipped code for above exercise
ecommerce-app.zip

[akash-coded]

Part-2:

Here's a comprehensive exercise designed to help first-time learners understand the need and use of microservices, using Spring Boot in an E-commerce context, and aligned with the 8 principles of microservice design:

---

Spring Boot Microservice Exercise: E-commerce Platform

Objective: Build a basic E-commerce platform using Spring Boot which implements the 8 principles of microservice design.

1. Single Responsibility Principle

Task: Create an Order Service whose only job is to handle customer orders. It should be able to:

• Accept a new order.
• Retrieve details of an order.
• Update an order's status.

2. Loose Coupling

Task: Create separate services for Product Management and User Management. Their responsibilities are:

• Product Management: Add, edit, delete, and view products.
• User Management: Register, update, delete, and view users.

Ensure that when an order is placed in Order Service, it fetches the product details from Product Management service without making the services tightly coupled.

3. Services as Components

Task: Each of these services (Order, Product Management, and User Management) should be independently deployable. Create separate projects for each service.

4. Hide Internal Details

Task: The User Management service should have user passwords, but it should never expose them. When asked for user details, mask or omit the password field.

5. Decentralized Governance

Task: Each service should have its own database. Ensure that the Order Service doesn’t directly access the Product Management service’s database, but instead makes a RESTful call.

6. Automation of Infrastructure

Task: Use Spring Cloud tools to automate the service discovery and configuration. Implement Eureka Server for service discovery and Spring Cloud Config Server for centralized configuration.

7. Failure Isolation

Task: Use Hystrix or Resilience4j for circuit breaking. If the Product Management service goes down, the Order Service should not crash and instead should give a graceful error message.

8. Continuous Delivery through CI/CD

Task: Setup a basic CI/CD pipeline using a tool like Jenkins or TravisCI. Any changes made to a service should trigger a build and deploy the respective service.

---

Technical Requirements:

1. Spring Boot for service creation.
2. Eureka Server for service discovery.
3. Spring Cloud Config Server for centralized configuration.
4. Hystrix or Resilience4j for circuit breaking.
5. Databases (e.g., H2, MySQL) for each service.

Stretch Goals:

1. Implement an API Gateway using Zuul or Spring Cloud Gateway.
2. Secure your services using Spring Security and OAuth2.
3. Monitor your microservices using Spring Boot Actuator and Spring Cloud Sleuth.

---

Upon completion of this exercise, learners should understand the need for microservices in handling complex, scalable systems. They'll also have hands-on experience with the principles of microservice design, including decentralization, continuous delivery, and failure isolation.

[akash-coded]

Building on the monolithic e-commerce application we discussed earlier, let's outline a microservice approach.

Microservices Architecture for E-commerce

1. Breaking Down into Microservices

1. User Service: Manages all operations related to users.
2. Product Service: Manages all operations related to products.
3. Order Service: Manages all operations related to orders.
4. Authentication Service: Manages user authentication, token generation, and validation.

2. Service Interactions

• The Order Service will interact with both User Service and Product Service to ensure a user exists and a product is available when an order is placed.

• Authentication Service provides JWT tokens which are passed in requests to other services for authorization.

3. Implementation & Configuration

1. User Service

• Stores User entity details and provides CRUD operations for it.
• UserController will expose endpoints like /users, /users/{userId} etc.

2. Product Service

• Stores Product entity details.
• ProductController will expose endpoints like /products, /products/{productId} etc.

3. Order Service

• Stores Order entity.
• Will need to call User Service & Product Service to fetch details.
• OrderController will expose endpoints like /orders, /users/{userId}/orders etc.

4. Authentication Service

• Will authenticate users and generate JWT tokens.
• Will also validate tokens on protected endpoints.

4. Gateway Service

• A centralized gateway that routes requests to appropriate services.
• Can be implemented using Netflix's Zuul, Spring Cloud Gateway, or similar tools.
• Provides centralized authentication by integrating with the Authentication Service.

5. Service Discovery

• Use Netflix Eureka or Consul for service registration and discovery.
• Each microservice registers with the discovery server. The Gateway uses the discovery server to route requests.

6. Database per Service

Each microservice will have its own dedicated database:

• User Service: userdb
• Product Service: productdb
• Order Service: orderdb

This ensures that the services are loosely coupled and can evolve independently.

7. Data Consistency

In a microservices architecture, maintaining data consistency across services is challenging. Consider:

• Using Saga Pattern to manage long-running transactions across services.
• Implementing Eventual Consistency: Instead of immediately updating all services, ensure they will eventually reflect the correct data. Use event-driven architectures, like Kafka, to notify services of changes.

8. Deployment & Scalability

Each service can be containerized using Docker, orchestrated, and scaled independently using Kubernetes.

---

Example Flow:

1. User logs in, Authentication Service provides a JWT token.
2. User browses products, requests go to Product Service.
3. User places an order, request goes to Order Service.
4. Order Service ensures product availability with Product Service and user's existence with User Service.
5. Once validated, the order is saved in orderdb.

---

Benefits of Microservices over Monolithic

1. Scalability: If the product listing has high traffic, only the Product Service can be scaled without touching other services.
2. Resilience: If one service fails, others can still operate. The system can degrade gracefully.
3. Faster Releases: Individual teams can develop, test, and deploy their services independently.
4. Technological Freedom: Different services can use different technologies, as they're loosely coupled.

Challenges

1. Data Consistency: Achieving consistency across microservices is challenging.
2. Network Latency: Microservices communicate over the network, which can introduce latency.
3. Service Discovery: As services scale, discovering them becomes complex.
4. Monitoring & Logging: Requires centralized monitoring and logging solutions for a holistic view.

By the end of this microservices project, you should appreciate the granularity, scalability, and independence microservices offer compared to monolithic applications. However, you should also recognize the complexities associated with managing such distributed systems.

[AnuragMishra58]

Hi @akash-coded
Please find below part 2 for monolith to microservices conversion
Name: Anurag Mishra Emp id: 550966
ecommerce-app-part-2.zip

[singhRatan777]

order-management.zip
product-management.zip
user-management.zip
Ratan Singh Dewada

[jay4tech]

Hi @akash-coded
Name: Jay Prakash Kumar [2075419]
user-management.zip
product-management.zip
order-management.zip

[jay4tech]

Hi @akash-coded
Name: Jay Prakash Kumar [2075419]
Updated the code with new java environment - Java 19

order-management.zip
product-management.zip
user-management.zip

[singhRatan777]

[
ecommerce-application.zip
](url)

Ratan Singh Dewada

[naikkushal]

Kushal Naik
Exercise155 Kushal Naik.zip

[zafvirinchi]

Hi @akash-coded
Please find git URL
Zafrul Islam - 1974878
https://github.com/zafvirinchi/monolithApp_29082023/tree/main/momolithicApp/momolithicApp

[elcenninan]

Hi,
Elcen Zachariah
mono.zip

[Prasadpoojary]

Hi
ecommerce.zip

E-commerce
Prasad - 1844193

[HarshDPandya]

Hi Akash, Sharing my code in zip file for Microservices - Spring Boot Monolithic Application: E-commerce Platform
Name: Harsh Pandya
TCS Emp Id: 2066481
ecommerce-project-HarshPandya-2066481.zip

[esubshaik1610]

Hi @akash-coded ,PFA for Monolithic Application for E-Commerce
Name: Esub Shaik
Tcs Emp ID: 2268851
esub-ecomm.zip

[arunsankar172]

Hi @akash-coded
Name: Arunsankar R
Ecommerce.zip

[dhanusha444]

Hi @akash-coded
Name - DHANUSHA KOTTE
Ecommerce-Application.zip

E-Commerce Application

[arupmukherjee38]

Arup Mukherjee (1524555)
microecommerce.zip

[elcenninan]

Elcen Zachariah
microservice.zip

[HarshDPandya]

Hi Akash, Sharing my code in zip file for Microservices: E-commerce Platform
Name: Harsh Pandya
TCS Emp Id: 2066481
microservice-ecommerce-HarshPandya-2066481.zip

[naikkushal]

Hi @akash-coded sharing my code in zip folder
Kushal Naik (TCS EMP ID :- 2267011)
kushal.naik@tcs.com
MicroServices_Ecom_Kushal_Naik.zip

[zafvirinchi]

Hi

@akash-coded Please find the github url
https://github.com/zafvirinchi/E_Commerce_SOA

[Prasadpoojary]

Microservice-ecommerce app.zip

Prasad (1844193 )

[aathira-ps]

pfa for the session 3 assignment
Name :Aathira PS
Employee ID: 2077238
session3_microservices_Aathira_PS.zip

[arfaz9030]

Mohammad Arfaz(2354634)--- Below ecommerce microservices
https://github.com/arfaz9030/ecommerce-microservices

[esubshaik1610]

hi akash,PFA
esub shaik(2268851)--session3
day3-ecomm.zip

[arunsankar172]

Hi @akash-coded
Day - 3 Microservice
day-3-microservices.zip

[Chandrika1999]

Hi @akash-coded
Day - 3 MicroserviceProject
EmpId:2255969,Name:Chandrika Cheerla
Day3_MicroServices_Project.zip

[Devipadala]

Hi @akash-coded
Day - 3 MicroserviceProject
EmpId:2269823,Name:Devi Padala
Day3ProjectMicroServicesEcommerce.zip

[Kiran-Ramesh1]

Hi @akash-coded ,

Name : Kiran Ramesh(1949256)
Please find below zipped code for above exercise

ecom-micro.zip

[Kiran-Ramesh1]

Hi @akash-coded ,
Name : Kiran Ramesh(1949256)
Please find below zipped code for - Spring Boot Microservice Application: E-commerce Platform exercise
ecom-micro.zip