DEV Community: araf

AI Coding Agents 2025: GitHub Copilot vs Rovo Dev vs Cursor vs Claude vs Gemini vs Codeium

araf — Mon, 22 Dec 2025 09:49:18 +0000

Autocomplete is dead. Context, refactoring, and agentic workflows are the new battleground.

I tested GitHub Copilot, Rovo Dev, Cursor, Anthropic Claude, Google Gemini Code Assist, and Codeium in real dev workflows: Java, TypeScript, backend APIs, refactoring, debugging.

Here’s a developer-focused, side-by-side comparison.

🧠 Quick Comparison

Tool	Best For	Strengths	Limitations	Price
GitHub Copilot	Teams & general devs	IDE support, autocomplete, GitHub integration	Paid, small free tier	~$10/mo
Rovo Dev	Terminal-centric & enterprise	CLI automation, Jira/Bitbucket integration	Newer, niche	Enterprise pricing
Cursor	Power users	Multi-file refactors, deep repo understanding	VS Code–centric	~$20/mo
Claude	Complex reasoning	Architecture & logic understanding	Weak IDE integration	~$20+/mo
Gemini Code Assist	Free tier & cloud devs	Large context, free tier	Less polished	Free/$19+
Codeium	Budget developers	Free, basic autocomplete	Weak deep context	Free

✅ GitHub Copilot — All-Rounder

Pros: Works in VS Code, JetBrains, Neovim; strong autocomplete; GitHub PR/chat integration
Cons: Paid; context window smaller than others
Best for: Production dev, team workflows

🧑‍💻 Rovo Dev — Terminal & Enterprise

Pros: Automates tasks in CLI; deep Jira/Bitbucket/Confluence integration
Cons: Niche, CLI-focused; enterprise pricing
Best for: Teams using Atlassian tools

⚡ Cursor — Deep Codebase

Pros: Multi-file refactors; deep context understanding
Cons: VS Code fork; some CI integrations weaker
Best for: Senior devs, large repos

🤖 Claude — Complex Reasoning

Pros: Architecture, reasoning, explanations
Cons: IDE integration weaker
Best for: Designing complex systems, logic review

🆓 Gemini Code Assist — Free & Generous

Pros: Free tier, large context, CLI support
Cons: Less polished suggestions
Best for: Hobbyists, learners, free experimentation

💸 Codeium — Free Basic Help

Pros: Free forever, basic autocomplete, IDE plugin support
Cons: Weak for deep context or multi-file logic
Best for: Students, beginners, free users

🧠 Verdict

Balanced & mainstream: GitHub Copilot
Deep VS Code refactoring: Cursor
Complex reasoning: Claude
Best free tier: Gemini
Free basics: Codeium
Enterprise automation: Rovo Dev

Most serious devs in 2025 use 2+ agents: Copilot/Cursor for coding, Claude/Gemini for reasoning, Rovo Dev for enterprise workflow.

📌 Strategy

Try Codeium + Gemini to test AI in your flow.
Evaluate Copilot or Cursor on real projects.
Enterprise teams: Copilot for GitHub, Rovo Dev for Jira/Bitbucket automation.

References:
DigitalApplied | The Verge | Atlassian Rovo

🚀 Upgrading Your Legacy Java 8 + Spring Boot 2.1 Project to Java 17 (Without Breaking Everything)

araf — Thu, 11 Dec 2025 03:21:33 +0000

Upgrading a large Java 8 + Spring Boot 2.1 codebase to Java 17 feels scary.
Modules, removed APIs, dependency conflicts, Jakarta migration — a lot can break.

This guide gives you a safe, production-tested path to upgrade without downtime.

✅ Why Upgrade to Java 17?

Benefit	Why It Matters
LTS until 2029	Long-term support & security updates
40–60% faster JVM	Better GC (G1/ZGC), faster execution
Modern language features	var, records, sealed classes, switch expressions
Better memory usage	Reduced heap footprint
More secure	Stronger TLS, crypto, JVM rules

🧭 Safe Upgrade Path (The Only Path That Won’t Break Everything)

Phase 1 → Java 8 → Java 11
Phase 2 → Spring Boot 2.1 → 2.7
Phase 3 → Java 11 → Java 17
Phase 4 → Spring Boot 2.7 → 3.x (Jakarta)

🔹 Phase 1 — Upgrade Java 8 → Java 11

Update pom.xml:

<properties>
    <java.version>11</java.version>
</properties>

Fix removed Java EE modules:

<dependency>
    <groupId>javax.xml.bind</groupId>
    <artifactId>jaxb-api</artifactId>
    <version>2.3.1</version>
</dependency>

Check incompatible libraries:

mvn dependency:tree

🔹 Phase 2 — Upgrade Spring Boot 2.1 → 2.7

Update Boot version:

<parent>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-parent</artifactId>
    <version>2.7.18</version>
</parent>

Things to fix before Spring Boot 3:

Replace Springfox with springdoc-openapi
Move to new constructor-binding style for @ConfigurationProperties
Clean deprecated security config
Start migrating from RestTemplate → WebClient (optional)

🔹 Phase 3 — Upgrade Java 11 → Java 17

Update in pom.xml:

<properties>
    <java.version>17</java.version>
</properties>

Common fixes:

Reflection warnings (--add-opens)
Replace any legacy HTTP clients
Ensure all dependencies support Java 17

🔹 Phase 4 — Upgrade Spring Boot 2.7 → 3.x (Jakarta Mandatory)

Spring Boot 3 uses Jakarta EE 9+.
All javax.* packages are now jakarta.*.

Example:

import javax.servlet.http.HttpServletRequest;

becomes:

import jakarta.servlet.http.HttpServletRequest;

Update Boot:

<parent>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-parent</artifactId>
    <version>3.3.4</version>
</parent>

Required Migrations

1. Javax → Jakarta

Run to find:

grep -R "javax" src/

2. Spring Security Rewrite

Old:

http.authorizeRequests().anyRequest().authenticated();

New:

http.authorizeHttpRequests(auth -> auth
    .requestMatchers("/api/**").authenticated()
);

3. Hibernate/JPA

Replace:

<groupId>javax.persistence</groupId>

with:

<groupId>jakarta.persistence</groupId>

4. Swagger Migration

Remove Springfox and add:

<dependency>
  <groupId>org.springdoc</groupId>
  <artifactId>springdoc-openapi-starter-webmvc-ui</artifactId>
  <version>2.6.0</version>
</dependency>

🧪 Testing Strategy

Add JDK 17 to CI

- name: Setup JDK
  uses: actions/setup-java@v3
  with:
    distribution: 'temurin'
    java-version: '17'

Run full integration tests

Controllers
WebClient/Feign
Kafka/RabbitMQ
Flyway/Liquibase
Full database workflows

🧰 Common Issues & Fixes

Error	Fix
`ClassNotFound: javax.*`	Replace with jakarta
Spring Security not working	Rewrite security config
Swagger UI not loading	Use springdoc-openapi, not Springfox
Reflection warnings	Temporary: `--add-opens`

🏁 Final Upgrade Checklist

Java Upgrade

[ ] Java 8 → 11
[ ] Fix removed Java EE modules
[ ] Java 11 → 17
[ ] Update CI pipeline

Spring Boot Upgrade

[ ] Upgrade 2.1 → 2.7
[ ] Remove deprecated Spring APIs
[ ] Upgrade 2.7 → 3.x
[ ] Migrate javax → jakarta
[ ] Update Spring Security
[ ] Replace Springfox → springdoc
[ ] Update Hibernate/JPA
[ ] Run full integration tests

🎉 Conclusion

Upgrading Java 8 + Spring Boot 2.1 directly to Java 17 + Spring Boot 3.x is risky.
But using the safe 4-phase approach prevents almost all breaking changes:

1️⃣ Java 8 → 11
2️⃣ Spring Boot 2.1 → 2.7
3️⃣ Java 11 → 17
4️⃣ Spring Boot 2.7 → 3.x (Jakarta)

Follow the checklist, fix deprecated APIs early, and test thoroughly — and your upgrade will be smooth.

Mastering Spring AOP: Real-World Use Case and Practical Code Samples

araf — Thu, 30 Oct 2025 05:37:41 +0000

Spring AOP (Aspect-Oriented Programming) is one of the most underrated yet powerful features in the Spring ecosystem. It helps you modularize cross-cutting concerns such as logging, security, transactions, and performance monitoring — without cluttering your business logic.

In this post, we’ll explore:

What AOP really is (without the academic jargon)
Real-world use cases
A practical Spring Boot example
How to apply AOP effectively in production-grade applications

💡 What is AOP (Aspect-Oriented Programming)?

In simple terms — AOP lets you inject logic around existing methods without modifying them.

Think of it as saying:

“Before any method in my service layer executes, log who called it.”

Instead of repeating the same code in every method, you define it once as an Aspect, and Spring automatically applies it wherever needed.

🧱 Key AOP Concepts

Concept	Description
Aspect	A module that encapsulates cross-cutting logic (e.g., LoggingAspect)
Join Point	A point during execution (like a method call) where an aspect can be applied
Advice	The actual code to run (e.g., before/after method execution)
Pointcut	Expression that defines where the advice should be applied
Weaving	The process of linking aspects with target objects

🔍 Real-World Use Case: Logging API Calls

Let’s build a logging aspect that:

Logs every REST controller method call
Prints method name, arguments, and execution time

🧩 Project Setup

Add this dependency to your pom.xml:

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-aop</artifactId>
</dependency>

That’s it — Spring AOP is ready to roll!

⚙️ Step 1: Create a Sample REST Controller

@RestController
@RequestMapping("/api/users")
public class UserController {

    @GetMapping("/{id}")
    public String getUser(@PathVariable Long id) throws InterruptedException {
        Thread.sleep(200); // Simulate a delay
        return "User with ID: " + id;
    }

    @PostMapping
    public String createUser(@RequestBody String user) {
        return "Created user: " + user;
    }
}

🧠 Step 2: Define a Logging Aspect

@Aspect
@Component
@Slf4j
public class LoggingAspect {

    @Pointcut("execution(* com.example.demo..*Controller.*(..))")
    public void controllerMethods() {}

    @Around("controllerMethods()")
    public Object logExecutionDetails(ProceedingJoinPoint joinPoint) throws Throwable {
        long startTime = System.currentTimeMillis();
        String method = joinPoint.getSignature().toShortString();
        Object[] args = joinPoint.getArgs();

        log.info("➡️ Entering: {} with arguments {}", method, Arrays.toString(args));

        Object result = joinPoint.proceed();

        long duration = System.currentTimeMillis() - startTime;
        log.info("⬅️ Exiting: {} executed in {} ms", method, duration);

        return result;
    }
}

⚡ Output Example

When you hit /api/users/1:

➡️ Entering: UserController.getUser(..) with arguments [1]
⬅️ Exiting: UserController.getUser(..) executed in 205 ms

Neat, right? You didn’t modify a single controller — yet logging is applied across all of them.

🔐 Other Practical AOP Use Cases

Use Case	Description
Security	Validate API tokens or check roles before method execution
Performance Metrics	Record method execution time for Prometheus or New Relic
Transaction Auditing	Track database changes automatically
Exception Handling	Catch and log exceptions from service layers
Caching	Intercept method calls to apply caching dynamically

🧭 Pro Tips for Production

✅ Keep pointcut expressions specific — avoid execution(* *.*(..)) globally.
✅ Use annotations for flexible targeting, e.g., @Loggable.
✅ Combine with Spring Boot Actuator for performance insights.
✅ Prefer @Around advice — it gives full control of before/after logic.
✅ Don’t abuse AOP — keep your core logic clear and simple.

🧩 Bonus: Annotation-Driven Logging

Let’s make it even cleaner by introducing a custom annotation:

@Target(ElementType.METHOD)
@Retention(RetentionPolicy.RUNTIME)
public @interface Loggable {}

Then mark your methods like this:

@GetMapping("/{id}")
@Loggable
public String getUser(@PathVariable Long id) {
    return "User with ID: " + id;
}

Update the aspect:

@Pointcut("@annotation(com.example.demo.aop.Loggable)")
public void loggableMethods() {}

Now only methods annotated with @Loggable will be intercepted.

🧾 Summary

Spring AOP is not just a fancy buzzword — it’s a practical engineering tool that keeps your code clean, modular, and maintainable.

In short:

Use AOP to handle cross-cutting concerns elegantly
Keep aspects focused and reusable
Embrace annotation-based customization

💬 What’s Next?

In upcoming posts, we’ll explore:

Building a performance profiler with AOP
Combining AOP + Spring Events for advanced observability

If you found this post useful, don’t forget to ❤️ like, 🧠 save, and 🔁 share it!
Follow me for more deep-dive Spring Boot articles every week.

🐢 Why Your JPA Transaction Slowed Down After Adding 'flush()' and 'clear()' (And How to Fix It)

araf — Wed, 29 Oct 2025 05:46:02 +0000

Have you ever added entityManager.flush() and entityManager.clear() inside a Spring Boot JPA transaction to make deletes and inserts “reflect immediately” — only to see your performance tank?

You're not alone.
This is one of those subtle Hibernate behaviors that bites even experienced developers.

Let’s unpack why it happens, and what to do instead.

🧩 The Real-World Scenario

You have a Spring Boot service method like this:

@Transactional
public void refreshData() {
    myRepository.deleteByType("A");
    entityManager.flush();
    entityManager.clear();

    List<MyEntity> newRecords = fetchNewData();
    myRepository.saveAll(newRecords);
}

You added flush() and clear() because deletes weren’t visible before inserts — and it “fixed” the logic.

But now, your transaction runs 3× slower, the DB CPU spikes, and Hibernate logs show hundreds of SQL statements being executed one by one.

What’s going on?

⚙️ Understanding `flush()` and `clear()`

🔹 `flush()`

Tells JPA:

“Send all pending SQL statements to the database now.”

Normally, Hibernate batches and optimizes SQL statements until transaction commit.
When you call flush(), it forces immediate execution — breaking batching and hitting the database right away.

🔹 `clear()`

Tells JPA:

“Forget everything you know about the current persistence context.”

This detaches all managed entities.
Hibernate now has to re-fetch them from the database if you reference them again, and you lose the in-memory first-level cache.

⚠️ Why It Becomes Slow

Cause	Effect
`flush()` executes pending SQL immediately	Hibernate loses batching and optimization
`clear()` wipes first-level cache	Every next entity access triggers a new `SELECT`
Same-table deletes + inserts	DB locks and index contention
Large transaction scope	Hibernate keeps snapshots for dirty checking
Cascades or orphan removal	Extra SQLs during flush

In short — you gain “visibility” but lose performance and batching efficiency.

💡 Smarter Alternatives

✅ 1. Use Bulk Deletes Instead of Entity Deletes

@Modifying
@Query("DELETE FROM MyEntity e WHERE e.type = :type")
void deleteByType(@Param("type") String type);

Bulk deletes:

Run a single SQL DELETE
Don’t load entities into memory
Don’t trigger cascade or dirty checking

Perfect for refreshing data tables.

✅ 2. Split the Transaction Logically

@Transactional
public void refreshData() {
    myRepository.deleteByType("A");
    insertNewRecordsInNewTx();
}

@Transactional(propagation = Propagation.REQUIRES_NEW)
public void insertNewRecordsInNewTx() {
    myRepository.saveAll(fetchNewData());
}

Now, the delete commits before the insert starts — no need to manually flush() or clear().

✅ 3. Use Batching for Inserts

In application.properties:

spring.jpa.properties.hibernate.jdbc.batch_size=50
spring.jpa.properties.hibernate.order_inserts=true
spring.jpa.properties.hibernate.order_updates=true

Then in code:

int i = 0;
for (MyEntity entity : newRecords) {
    entityManager.persist(entity);
    if (++i % 50 == 0) {
        entityManager.flush();
        entityManager.clear();
    }
}

You’ll get massive performance gains for large datasets.

✅ 4. Avoid `clear()` Unless You Really Need It

Instead of clearing everything:

entityManager.detach(entity);

This detaches only the specific entity you need, preserving most of the persistence context.

🚀 The TL;DR Summary

Problem	Cause	Fix
Transaction runs slowly	`flush()` executes SQL immediately	Avoid frequent flushes
Too many selects	`clear()` wipes cache	Detach selectively
Delete + insert on same table	DB contention	Split into separate transactions
High memory usage	Large persistence context	Batch + periodic flush/clear
Cascades killing performance	Entity-based delete	Use bulk delete query

🧠 Key Takeaway

Don’t reach for flush() + clear() to “fix visibility.”
They’re low-level hammers that often break performance and caching.

Instead:

Use bulk operations
Batch inserts
Split transactions when visibility matters
Or use native SQL when you’re replacing data wholesale

Your Spring Boot + JPA app will thank you with faster, cleaner transactions.

💬 What about you?

Have you run into flush() / clear() performance issues before?
How did you handle them — batching, bulk queries, or native SQL?

Drop your experience below 👇 — it helps others avoid the same trap.

Java 25: Latest Features, Examples, and Real-World Use Cases

araf — Tue, 30 Sep 2025 05:10:31 +0000

Java 25: Latest Features, Examples, and Real-World Use Cases

Everything you need to know ab
out the newest Java release

Tags: java, programming, tutorial, java25

Java 25 is here — and as the latest LTS (Long-Term Support) release, it’s packed with language features, JVM improvements, and new APIs that make Java more expressive, performant, and cloud-ready.

In this post, we’ll cover:

🚀 New and finalized features in Java 25
🧑‍💻 Practical code examples
🌍 Real-world scenarios where they shine
🔧 Migration tips and best practices

1. Compact Source Files & Instance Main Methods (JEP 512)

You can now write minimal Java programs without boilerplate:

void main() {
    IO.println("Hello, Java 25!");
}

No class, no public static void main. Just code.

Use cases:

Teaching / learning Java
Quick prototypes and utilities

2. Flexible Constructor Bodies (JEP 513)

Constructors are now more flexible: you can add validation or setup before delegating with super(...) or this(...).

public class Person {
    String name;
    int age;

    public Person(String name, int age) {
        if (age < 0) throw new IllegalArgumentException("Age must be >= 0");
        this.name = name;
        this.age = age;
    }
}

Use cases:

Input validation
Cleaner initialization logic

3. Compact Object Headers (JEP 519)

Java objects now have smaller headers, saving memory and improving cache locality.

Enable with:

-XX:+UseCompactObjectHeaders

Use cases:

Apps with lots of small objects (DTOs, domain models)
Memory-sensitive microservices

4. Generational Shenandoah GC (JEP 521)

Shenandoah garbage collector now supports generational mode:

-XX:+UseShenandoahGC -XX:ShenandoahGCMode=generational

Why it matters: Most objects die young — separating young vs old reduces pause times and improves throughput.

5. Ahead-of-Time (AOT) Method Profiling (JEP 515)

The JVM can now profile hot methods ahead of time and reuse that info across runs.

Impact:

Faster warm-up
Better performance for microservices and serverless apps

6. Java Flight Recorder (JFR) Enhancements

Cooperative sampling
More detailed method timing & tracing
Experimental CPU-time profiling

Benefit: Production-grade observability with lower overhead.

7. Pattern Matching for Primitive Types (JEP 507 — Preview)

Pattern matching now works for primitives inside switch:

static String describe(Number n) {
    return switch (n) {
        case int i when i > 0 -> "positive int " + i;
        case int i -> "non-positive int " + i;
        case double d -> "double " + d;
        default -> "other number";
    };
}

Use case: Cleaner, safer branching without boxing/unboxing.

8. Module Import Declarations (JEP 511 — Preview)

Declare module dependencies directly in source:

import module java.base;
import module java.sql;

Improves clarity when working with the module system.

9. Scoped Values (JEP 506 — Preview)

A lightweight alternative to ThreadLocal, especially useful with virtual threads.

Use case: Pass immutable context data across async boundaries without leaks.

10. Key Derivation Function API (JEP 510 — Preview)

Standardizes cryptographic key derivation (e.g., HKDF, Argon2).
Use case: Security-sensitive systems needing deterministic but secure key material.

11. Removal of 32-bit x86 Port (JEP 503)

Java 25 now runs only on 64-bit platforms. Time to retire that old 32-bit code.

Real-World Scenarios

Domain	Feature	Benefit
Microservices	AOT profiling	Faster startup, less warm-up
Memory-heavy apps	Compact headers + Shenandoah	Lower footprint, smoother GC
Event-driven systems	Pattern matching + sealed types	Safer, cleaner dispatch
Async workflows	Scoped values	Context propagation in virtual threads
Security	KDF API	Stronger, standard crypto primitives

Migration Tips

Start with finalized features (compact files, flexible constructors, compact headers).
Experiment with preview features in isolated modules.
Benchmark workloads after enabling GC/AOT options.
Update build pipelines for 64-bit only support.

Conclusion

Java 25 is more than “just another release.”
It lowers boilerplate, improves runtime performance, and makes Java more cloud-friendly.

If you’re on Java 17 or 21, now’s the time to explore Java 25 — and start adopting its new features incrementally.

👉 What’s your favorite Java 25 feature? Planning to adopt it in production? Let me know in the comments!

🐳 Docker & Docker Compose for Beginners: Full Guide + Real Project Example

araf — Wed, 25 Jun 2025 10:03:49 +0000

Whether you’re a backend developer, DevOps enthusiast, or just getting into microservices, Docker is one of the most essential tools in the modern development toolbox.

This guide will walk you through:

What Docker & Docker Compose are
Why Docker became so popular
How to install Docker
How to use Docker & Docker Compose
Real-world project: Node.js + MongoDB

Let’s dive in 👇

🔧 What is Docker?

Docker is a platform for packaging applications into containers — lightweight, portable units that bundle your app with its dependencies.

Imagine this:

"It works on my machine" – Docker makes that your reality everywhere.

Each container includes:

Code
Runtime (e.g., Node.js, Java)
Libraries
Environment/configuration

So your app runs the same on any system, cloud, or CI/CD pipeline.

🚀 Why Docker Became So Popular

Docker took over the world for several key reasons:

✅ Lightning Fast – Containers start in milliseconds vs full VMs
✅ Environment Consistency – Same behavior in dev, staging, and prod
✅ DevOps & CI/CD Friendly – Works seamlessly with GitHub Actions, Jenkins, GitLab CI
✅ Perfect for Microservices – Each service in its own container
✅ Portable – Works on Windows, Linux, Mac, cloud platforms
✅ Vibrant Ecosystem – Docker Hub provides 100,000+ ready-to-use images

⚙️ Docker vs Traditional Deployment

Feature	Traditional Deployment	Docker-Based Deployment
Setup time	Manual setup, often inconsistent	One-line setup (`docker run`)
Environment conflicts	Very common	Fully isolated per container
Portability	OS/Env dependent	Runs anywhere Docker is installed
Scaling services	Hard & manual	Easy with `docker-compose` or K8s
Dev → Staging → Prod	Error-prone	Consistent containers everywhere

🧰 How to Install Docker & Docker Compose

🔹 1. Install Docker

Go to: https://www.docker.com/products/docker-desktop
Download for your OS (Windows, macOS, Linux)
Follow installer instructions
After install, run:

docker --version

You should see something like:

Docker version 24.x.x, build abcdef

🔹 2. Docker Compose (usually pre-installed)

Check with:

docker compose version

If it shows the version, you're good to go!

📦 Real Example: Node.js + MongoDB with Docker Compose

Let’s build a simple project that runs a Node.js API connected to MongoDB — all inside Docker.

🧱 Project Structure

docker-node-mongo-app/
├── app/
│   ├── server.js
│   └── package.json
├── Dockerfile
└── docker-compose.yml

✏️ Step 1: Node.js Code (`app/server.js`)

const express = require('express');
const mongoose = require('mongoose');

const app = express();

mongoose.connect('mongodb://mongo:27017/mydb', {
  useNewUrlParser: true,
  useUnifiedTopology: true,
});

app.get('/', (req, res) => {
  res.send('Hello from Dockerized Node.js + MongoDB!');
});

const PORT = 3000;
app.listen(PORT, () => {
  console.log(`Server running on http://localhost:${PORT}`);
});

✏️ Step 2: `app/package.json`

{
  "name": "docker-node-mongo",
  "version": "1.0.0",
  "main": "server.js",
  "scripts": {
    "start": "node server.js"
  },
  "dependencies": {
    "express": "^4.18.2",
    "mongoose": "^7.2.2"
  }
}

🐳 Step 3: `Dockerfile`

FROM node:18

WORKDIR /app

COPY app/package*.json ./
RUN npm install

COPY app .

EXPOSE 3000

CMD ["npm", "start"]

🛠 Step 4: `docker-compose.yml`

version: '3.8'

services:
  app:
    build: .
    ports:
      - "3000:3000"
    depends_on:
      - mongo

  mongo:
    image: mongo
    ports:
      - "27017:27017"
    volumes:
      - mongo-data:/data/db

volumes:
  mongo-data:

▶️ How to Run the Project

Open terminal in your project root.
Run the following:

docker-compose up --build

Visit: 📍 http://localhost:3000 You’ll see: Hello from Dockerized Node.js + MongoDB!

🧹 How to Stop & Clean Up

To stop the app:

docker-compose down

To remove the volume data as well:

docker-compose down -v

🎯 Recap

By now, you've learned:

✅ What Docker and Docker Compose are
✅ Why Docker became a standard in modern development
✅ How to install and check Docker setup
✅ How to containerize an app
✅ How to run multi-container apps with Compose

💬 What's Next?

You can now dockerize:

Python Flask/Django apps
Spring Boot + PostgreSQL apps
React/Next.js with NGINX

🛡️ Mastering Java Encryption in 2025: Modern Methods, Best Practices & Real-World Examples

araf — Mon, 09 Jun 2025 05:33:43 +0000

Encryption is no longer optional—it's essential. In 2025, mastering encryption in Java means staying ahead of vulnerabilities, avoiding outdated APIs, and designing with security-first principles.

Whether you're a backend developer, architect, or security-conscious coder, this guide will help you write clean, modern, and secure encryption code in Java.

🚀 Why This Guide?

Legacy systems still use insecure methods like ECB mode or outdated algorithms like MD5. Meanwhile, cloud-native, distributed apps demand secure transmission, storage, and user data handling. This post focuses on:

Modern Java encryption libraries
Best practices for symmetric/asymmetric encryption
Practical examples with AES-GCM, RSA-OAEP, and more
Real-world scenarios (e.g., encrypting passwords, payloads, tokens)

🔐 1. Symmetric Encryption (AES-GCM FTW)

AES is the industry standard, but in 2025, ECB is dead. GCM (Galois/Counter Mode) is preferred for its authenticated encryption—it ensures integrity and confidentiality.

✅ Best Practice

Use AES-256 with GCM
Generate IVs randomly
Never reuse IVs with the same key

💡 Example: AES-GCM Encryption

Cipher cipher = Cipher.getInstance("AES/GCM/NoPadding");
byte[] iv = SecureRandom.getInstanceStrong().generateSeed(12); // 96-bit IV
GCMParameterSpec spec = new GCMParameterSpec(128, iv);
cipher.init(Cipher.ENCRYPT_MODE, secretKey, spec);
byte[] ciphertext = cipher.doFinal(plaintext);

🔑 2. Asymmetric Encryption (RSA-OAEP)

RSA is still popular for encrypting small data (like keys or tokens). But PKCS#1 v1.5 is obsolete. In 2025, go with RSA-OAEP for padding and forward security.

✅ Best Practice

Use RSA with OAEP (Optimal Asymmetric Encryption Padding)
Minimum 2048-bit keys (3072+ recommended)
Use for encrypting symmetric keys, not large data

💡 Example: RSA-OAEP

Cipher cipher = Cipher.getInstance("RSA/ECB/OAEPWithSHA-256AndMGF1Padding");
cipher.init(Cipher.ENCRYPT_MODE, publicKey);
byte[] encrypted = cipher.doFinal(secretKeyBytes);

🧂 3. Password Encryption ≠ Password Hashing

Don’t encrypt passwords. Hash them using a strong key-derivation function:

✅ Best Practice

Use PBKDF2, BCrypt, SCrypt, or Argon2
Store salt separately or alongside the hash
Never roll your own crypto

💡 Example: PBKDF2 Hashing

SecretKeyFactory skf = SecretKeyFactory.getInstance("PBKDF2WithHmacSHA512");
KeySpec spec = new PBEKeySpec(password, salt, 65536, 256);
SecretKey key = skf.generateSecret(spec);
byte[] hash = key.getEncoded();

📦 4. Java Libraries You Should Be Using

In 2025, built-in Java crypto is solid but not always ergonomic. Consider:

🔐 Bouncy Castle – Advanced crypto primitives
🔒 Tink (by Google) – Modern encryption with safe defaults
🧰 Spring Security Crypto – For secure password encoding, token handling

🧪 5. Real-World Use Cases

🧾 Encrypting JSON Payloads

AES-GCM for payload encryption
Include IV and authentication tag
Base64 encode before transmission

🔄 Token Encryption (JWT)

Avoid symmetric keys unless necessary
Use JWE (JSON Web Encryption) with RSA-OAEP + AES-GCM

📂 File Encryption

Stream-based AES encryption for large files
Split metadata and ciphertext

🧠 Pro Tips

🔄 Rotate keys periodically
📜 Use key stores (e.g., JCEKS, PKCS12)
🚫 Never log sensitive keys or plaintext
🔍 Audit your encryption flow regularly

📚 Final Thoughts

Encryption in Java has evolved—but too many apps still use insecure defaults. Mastering encryption means understanding the algorithms, using proper libraries, and staying updated with best practices.

👉 If you found this useful, drop a ❤️ or follow me for more Java security tips.
🔗 Full version with more examples on Hashnode

Microservices: Mastering the Circuit Breaker Pattern with Real Examples

araf — Fri, 30 May 2025 05:01:51 +0000

When building resilient microservices, failure is not just possible—it's inevitable. In a distributed architecture, one slow or failing service can cause a chain reaction of degraded performance and outages. This is where the Circuit Breaker Pattern becomes essential.

🔧 What is the Circuit Breaker Pattern?

The Circuit Breaker Pattern is a design pattern used to detect failures and encapsulate logic to prevent a network or service failure from constantly recurring during maintenance, temporary downtime, or unexpected system problems.

Think of it like a power circuit breaker: when the system detects too many failures, it "breaks" the circuit and stops sending requests to the failing service until it becomes healthy again.

🔪 Why Do You Need a Circuit Breaker?

Prevent cascading failures
Improve fault tolerance
Gracefully degrade functionality
Increase overall system stability

🧰 Core States of a Circuit Breaker

Closed: Everything is normal; all requests go through.
Open: The circuit is "tripped" after failures; all requests are blocked for a cool-down period.
Half-Open: A limited number of test requests are allowed to check if the service has recovered.

📊 Real-World Use Case

Scenario:

An eCommerce platform has a Product Service calling a remote Inventory Service. If the Inventory Service becomes unresponsive, the entire checkout flow gets delayed.

Problem:

No timeout or fallback mechanism = bad user experience.

Solution:

Implement a Circuit Breaker on the Product Service when calling Inventory Service.

📄 Example with Resilience4j (Spring Boot)

Maven Dependency

<dependency>
    <groupId>io.github.resilience4j</groupId>
    <artifactId>resilience4j-spring-boot3</artifactId>
</dependency>

Configuration

resilience4j:
  circuitbreaker:
    instances:
      inventoryService:
        registerHealthIndicator: true
        slidingWindowSize: 10
        failureRateThreshold: 50
        waitDurationInOpenState: 10s
        permittedNumberOfCallsInHalfOpenState: 3

Service Code

@CircuitBreaker(name = "inventoryService", fallbackMethod = "fallbackInventory")
public Inventory checkInventory(String productId) {
    return restTemplate.getForObject("http://inventory-service/api/check/" + productId, Inventory.class);
}

public Inventory fallbackInventory(String productId, Throwable t) {
    log.warn("Fallback triggered for product {}: {}", productId, t.toString());
    return new Inventory(productId, 0, "Fallback");
}

🔄 State Transitions Illustrated

Service is healthy → Closed (normal traffic)
Too many failures detected → Open (requests blocked)
After waitDurationInOpenState → Half-Open (limited test traffic)
If test succeeds → back to Closed; else → Open again

🌟 Bonus: Integrating with WebClient (Reactive)

@Bean
public Customizer<ReactiveResilience4JCircuitBreakerFactory> defaultCustomizer() {
    return factory -> factory.configureDefault(id -> new Resilience4JConfigBuilder(id)
        .circuitBreakerConfig(CircuitBreakerConfig.ofDefaults())
        .build());
}

public Mono<String> callInventoryReactive(String productId) {
    return reactiveCircuitBreakerFactory.create("inventoryService")
        .run(webClient.get()
            .uri("/api/check/" + productId)
            .retrieve()
            .bodyToMono(String.class),
            throwable -> Mono.just("Fallback Response"));
}

🚀 Production Best Practices

Configure timeouts separately (Circuit Breaker ≠ timeout)
Combine with rate limiting and bulkheads
Monitor with metrics and dashboards (e.g., Micrometer + Prometheus)
Fine-tune thresholds per service

🔍 Final Thoughts

In microservices architectures demand resilience. Implementing the Circuit Breaker Pattern isn't optional—it's foundational. Using libraries like Resilience4j or Hystrix (deprecated), we can build self-healing systems that withstand real-world chaos.

Which failure pattern has caused your microservices to crash? Share below and let's discuss how to bulletproof your system! #microservices #springboot #resilience4j #devops

Spring Boot Anti-Patterns Killing Your App Performance in 2025 (With Real Fixes & Explanations)

araf — Thu, 29 May 2025 03:41:38 +0000

Spring Boot helps developers move fast — but bad patterns kill performance, scalability, and maintainability silently.

Here’s a 2025-ready breakdown of real anti-patterns, why they’re dangerous, and how to fix them with clean, performant code.

⚠️ 1. Overusing `@Transactional` on Everything

❌ Anti-Pattern:

@Transactional
public List<User> getAllUsers() {
    return userRepository.findAll();
}

🔍 Problem:

Even read-only queries run inside unnecessary transactions, which:

Lock resources
Block threads
Add overhead to the database

✅ Fix:

@Transactional(readOnly = true)
public List<User> getAllUsers() {
    return userRepository.findAll();
}

🛠️ Explanation:

The readOnly = true hint allows the database to optimize the query plan, avoids write locks, and improves throughput for concurrent reads.

⚠️ 2. Business Logic in Controllers

❌ Anti-Pattern:

@PostMapping("/users")
public ResponseEntity<?> create(@RequestBody UserDTO dto) {
    if (dto.getAge() < 18) return ResponseEntity.badRequest().build();
    userRepository.save(new User(dto.getName(), dto.getAge()));
    return ResponseEntity.ok().build();
}

🔍 Problem:

Mixing logic with HTTP code:

Hard to test
Difficult to scale
Breaks SRP (Single Responsibility Principle)

✅ Fix:

@Service
public class UserService {
    public User createUser(UserDTO dto) {
        if (dto.getAge() < 18) throw new IllegalArgumentException("Underage");
        return userRepository.save(new User(dto.getName(), dto.getAge()));
    }
}

🛠️ Explanation:

Separating logic into a service layer:

Promotes clean architecture
Enables reuse across APIs or scheduled jobs
Makes unit testing easier

⚠️ 3. Blocking Calls in Reactive Code

❌ Anti-Pattern:

@GetMapping("/pdf")
public Mono<String> generatePdf() {
    return Mono.just(createHeavyPdf()); // Blocking!
}

🔍 Problem:

Calling blocking I/O (e.g., file, DB, network) on Netty threads breaks the reactive model.

✅ Fix:

@GetMapping("/pdf")
public Mono<String> generatePdf() {
    return Mono.fromCallable(this::createHeavyPdf)
               .subscribeOn(Schedulers.boundedElastic());
}

🛠️ Explanation:

Schedulers.boundedElastic() offloads blocking tasks to a separate thread pool — keeping the event loop free for I/O-bound processing.

⚠️ 4. Not Using Virtual Threads

❌ Anti-Pattern:

@Bean
public Executor asyncExecutor() {
    return Executors.newFixedThreadPool(10); // Limited concurrency
}

✅ Fix (Java 22+):

@Bean
public Executor asyncExecutor() {
    return Executors.newVirtualThreadPerTaskExecutor();
}

🛠️ Explanation:

Virtual threads are lightweight, memory-efficient, and allow thousands of concurrent tasks without blocking kernel threads — perfect for high-throughput apps.

⚠️ 5. Overusing `EntityManager` Manually

❌ Anti-Pattern:

@PersistenceContext
private EntityManager em;

public List<User> getUsers() {
    return em.createQuery("FROM User", User.class).getResultList();
}

🔍 Problem:

Manual queries are error-prone.
You miss Spring Data’s features (pagination, filters, query derivation).

✅ Fix:

@Repository
public interface UserRepository extends JpaRepository<User, Long> {
    List<User> findByStatus(String status);
}

🛠️ Explanation:

Spring Data JPA is optimized, tested, and handles:

Transactions
Paging
Dynamic queries Better abstraction = fewer bugs, more performance.

⚠️ 6. `@Cacheable` Without Expiry

❌ Anti-Pattern:

@Cacheable("products")
public Product getProduct(Long id) {
    return productRepo.findById(id).orElseThrow();
}

🔍 Problem:

Caches can grow unbounded, consuming memory.

✅ Fix:

@Bean
public CacheManager cacheManager() {
    CaffeineCacheManager cacheManager = new CaffeineCacheManager("products");
    cacheManager.setCaffeine(Caffeine.newBuilder()
        .expireAfterWrite(10, TimeUnit.MINUTES)
        .maximumSize(1000));
    return cacheManager;
}

🛠️ Explanation:

Adds TTL (Time to Live) and max entries — preventing memory leaks and stale data. Caffeine is ultra-fast and supports async refresh.

⚠️ 7. Default Tomcat Thread Pool

❌ Anti-Pattern:

# Default max-threads = 200

🔍 Problem:

Your API could underperform under high load — threads wait in queue, requests time out.

✅ Fix:

server.tomcat.max-threads=500
server.tomcat.accept-count=100
server.connection-timeout=10s

🛠️ Explanation:

max-threads: how many concurrent requests can be served
accept-count: queued connections
connection-timeout: prevents hanging sockets

Tuning Tomcat = faster concurrency handling

⚠️ 8. Overlapping Scheduled Jobs

❌ Anti-Pattern:

@Scheduled(fixedRate = 5000)
public void sendEmails() {
    // Takes 10s to run = jobs overlap = CPU spike
}

✅ Fix with ShedLock:

@Scheduled(fixedRate = 5000)
@SchedulerLock(name = "emailJob", lockAtLeastFor = "PT5S")
public void sendEmails() {
    // Run once, skip overlap
}

🛠️ Explanation:

ShedLock uses distributed locks (e.g., Redis, DB) to prevent concurrent job runs — crucial for long-running tasks.

⚠️ 9. No Observability

❌ Anti-Pattern:

No logs, no metrics, no traces:

// How do we know if it’s slow? 🤷

✅ Fix:

Micrometer + Prometheus + Grafana

<dependency>
  <groupId>io.micrometer</groupId>
  <artifactId>micrometer-registry-prometheus</artifactId>
</dependency>

management.endpoints.web.exposure.include=health,info,metrics,prometheus

🛠️ Explanation:

Gives real-time visibility into:

API latency
JVM memory
Cache hit/miss
DB time

Bonus: Add OpenTelemetry for distributed tracing across microservices.

🧠 Final Thoughts

Even in 2025, these old habits still slow down modern Spring Boot apps.

✅ Virtual threads
✅ Reactive practices
✅ Caching strategies
✅ Observability
✅ Clean architecture

Start reviewing your codebase for these traps — and refactor for performance, scalability, and developer sanity.

💬 What Anti-Pattern Do You See Most?

Comment below with real issues you've solved (or still suffer with). Let’s build a community playbook to clean up enterprise Spring Boot!

Understanding TransactionEventListener in Spring Boot: Use Cases, Real-Time Examples, and Challenges

araf — Wed, 28 May 2025 08:27:34 +0000

Spring Boot provides a rich programming model to handle transactional events efficiently. One such powerful feature is the TransactionEventListener, which allows you to react to transaction lifecycle events like commit or rollback, enabling clean separation of concerns and robust transaction-aware event handling.

In this post, we'll dive deep into what TransactionEventListener is, how it works, explore real-world scenarios where it shines, and also discuss its limitations and challenges.

What is `TransactionEventListener`?

TransactionEventListener is an annotation in Spring Framework (since 5.2) that lets you listen to events within the context of a transaction. It means your event handling logic can be triggered only after a transaction successfully commits, or when it rolls back, providing precise control over event-driven behavior tied to transactional outcomes.

Why use `TransactionEventListener`?

Ensure consistency: Trigger events only after the transaction commits successfully.
Avoid side effects on rollback: Prevent events from firing if the transaction fails.
Improve decoupling: Separate business logic and event handling that depends on transactional state.
Support asynchronous processing: Combine with async event handling while ensuring transaction completion.

Basic Usage

Here's a simple example to illustrate usage in Spring Boot:

@Component
public class OrderEventListener {

    @TransactionalEventListener
    public void handleOrderCreated(OrderCreatedEvent event) {
        System.out.println("Order Created Event received for order: " + event.getOrderId());
        // Perform actions that should only occur after successful commit,
        // like sending notification emails or updating caches.
    }
}

Controlling the Transaction Phase

By default, @TransactionalEventListener listens after commit (AFTER_COMMIT). You can customize it using the phase attribute:

@TransactionalEventListener(phase = TransactionPhase.AFTER_ROLLBACK)
public void handleRollback(OrderCreatedEvent event) {
    System.out.println("Transaction rolled back for order: " + event.getOrderId());
    // Compensate or log rollback-specific actions here.
}

Phases include:

BEFORE_COMMIT
AFTER_COMMIT (default)
AFTER_ROLLBACK
AFTER_COMPLETION (after commit or rollback)

Real-Time Use Cases

1. Sending Confirmation Emails After Order Creation

You want to send confirmation emails only if the order transaction commits successfully, ensuring customers aren't notified for failed transactions.

@Component
public class EmailNotificationListener {

    @TransactionalEventListener
    public void sendOrderConfirmation(OrderCreatedEvent event) {
        emailService.sendOrderConfirmation(event.getOrderId(), event.getCustomerEmail());
    }
}

2. Updating Cache Post Transaction Commit

You can refresh cache entries or invalidate cached data after successful updates in your DB.

@Component
public class CacheUpdateListener {

    @TransactionalEventListener
    public void refreshProductCache(ProductUpdatedEvent event) {
        cacheManager.evict("products", event.getProductId());
    }
}

3. Compensating Actions on Rollback

If a transaction fails, you might want to log or trigger compensating actions:

@Component
public class RollbackListener {

    @TransactionalEventListener(phase = TransactionPhase.AFTER_ROLLBACK)
    public void handleOrderFailure(OrderCreatedEvent event) {
        logger.warn("Transaction rolled back for order id: " + event.getOrderId());
        auditService.logFailedOrder(event);
    }
}

How to Publish Transactional Events?

Use ApplicationEventPublisher inside your service methods annotated with @Transactional:

@Service
public class OrderService {

    private final ApplicationEventPublisher publisher;

    public OrderService(ApplicationEventPublisher publisher) {
        this.publisher = publisher;
    }

    @Transactional
    public void createOrder(Order order) {
        orderRepository.save(order);
        publisher.publishEvent(new OrderCreatedEvent(this, order.getId(), order.getCustomerEmail()));
    }
}

Potential Challenges and Limitations

While TransactionEventListener is powerful, here are some points to consider:

1. Event Ordering and Transaction Boundaries

Events are triggered only after transaction boundaries, so if your event handler logic requires real-time processing before commit, this might not suit your needs.
If multiple events rely on each other, managing their order and dependencies can be tricky.

2. Long-running or Blocking Event Handlers

Since event handlers run within the transaction context or immediately after commit, long-running or blocking operations (like sending emails or calling external APIs) can slow down transaction processing.
To avoid this, you can combine @TransactionalEventListener with @Async to handle events asynchronously.

3. Event Handling on Rollbacks

Events fired on rollback (AFTER_ROLLBACK) should be used carefully, as the system is in an error state.
You should avoid triggering further database changes here to prevent inconsistent states.

4. Complexity in Testing

Testing transaction-aware event listeners can be complex since you need to simulate transaction commit and rollback behaviors in test scenarios.
Use @Transactional tests and Spring's testing support carefully.

5. Limited Support for Nested Transactions

If you use nested transactions or multiple transaction managers, the behavior of TransactionEventListener may vary or not work as expected.

Key Takeaways

Use @TransactionalEventListener for transaction-aware event handling.
Choose the right phase depending on your business logic.
Ensure events that trigger side effects occur only after successful commits.
Be cautious of long-running event handlers and consider asynchronous processing.
Test transaction event listeners thoroughly to cover commit and rollback scenarios.

Summary

TransactionEventListener in Spring Boot enables elegant, transaction-aware event-driven programming. It’s an essential tool when you want to execute actions only after successful database transactions, making your applications more robust and consistent.

However, understanding its limitations and potential pitfalls helps you use it effectively and avoid unexpected issues.

Have you used TransactionEventListener in your projects? Share your experience or questions below!

Spring Annotations vs Node.js Decorators: A Cross-Stack Developer’s Guide

araf — Tue, 27 May 2025 03:58:17 +0000

If worked with Java Spring Boot, likely familiar with annotations like @RestController, @Autowired, and @Transactional. These annotations help organize code, inject dependencies, and declare behavior in a clean and declarative way.

But what about the Node.js world? With TypeScript, we now have decorators, which serve a very similar purpose — but with different mechanics under the hood.

Let’s dive into a head-to-head comparison of Spring annotations vs Node.js decorators, exploring how they align and differ.

🔧 What Are They?

Feature	Spring (Java) Annotation	Node.js (TypeScript) Decorator
Syntax	`@AnnotationName`	`@DecoratorName`
Purpose	Metadata & behavior injection	Metadata & behavior injection
Under the hood	Java reflection + AOP (compile/runtime)	TypeScript decorators (experimental ES syntax)
Usage areas	Controllers, DI, Transactions, etc.	Classes, methods, params, properties

1️⃣ Controllers

Spring Boot:

@RestController
@RequestMapping("/users")
public class UserController {

    @GetMapping("/{id}")
    public User getUser(@PathVariable String id) {
        return userService.getById(id);
    }
}

Node.js (TypeScript + routing-controllers):

@JsonController('/users')
export class UserController {

    @Get('/:id')
    getUser(@Param('id') id: string) {
        return this.userService.getById(id);
    }
}

📌 Both define routes declaratively
📌 Decorators enable class-based design in TypeScript similar to Spring

2️⃣ Dependency Injection

Spring Boot:

@Service
public class UserService {
    // logic
}

@RestController
public class UserController {

    @Autowired
    private UserService userService;
}

Node.js (with typedi or inversify):

@Service()
export class UserService {
    // logic
}

@JsonController()
export class UserController {
    constructor(private userService: UserService) {}
}

🔄 Constructor injection is more common in Node.js
🧠 Java uses field/constructor injection via reflection

3️⃣ Validation

Spring Boot (Hibernate Validator):

public class UserDTO {
    @NotEmpty
    @Email
    private String email;
}

Node.js (with class-validator):

export class UserDTO {
    @IsEmail()
    @IsNotEmpty()
    email: string;
}

✅ Both use decorators to declare constraints
✅ Can validate at runtime automatically

4️⃣ Transactions

Spring Boot:

@Transactional
public void updateUser() {
    // DB logic
}

Node.js (with typeorm or custom wrapper):

@Transaction()
async updateUser() {
    // DB logic
}

🔐 Decorators help wrap method logic with transaction boundaries
🧱 Node.js needs libraries like typeorm-transactional-cls-hooked

🧠 Under the Hood Differences

Feature	Spring	Node.js
Runtime	JVM + Reflection + AnnotationProcessor	V8 + TypeScript metadata APIs
Execution context	Annotations are compiled and scanned	Decorators are applied at runtime
Maturity	Very mature (20+ years)	Still evolving (stage 3 ECMAScript)
Dependency Injection	Built-in (Spring Container)	External (Inversify, Typedi, NestJS, etc.)

✅ TL;DR: Should You Care?

Use Case	Spring (Java)	Node.js (TypeScript)
Enterprise-grade systems	✅ Battle-tested	✅ With NestJS/Inversify
Fast APIs / Prototypes	😐 Verbose setup	✅ Quick with decorators
Microservices architecture	✅ Spring Cloud	✅ Node + gRPC or REST + decorators
Learning curve	📈 Steeper	📉 Smoother with NestJS

🔚 Final Thoughts

Spring annotations and TypeScript decorators solve similar problems — declarative, DRY, organized code.
The syntax is almost identical, but the philosophy and tooling differ.
Whether you’re moving from Java to Node.js or exploring both for architecture design, understanding these patterns helps you write better, cleaner code in any backend.

Master Data Management (MDM) in Microservice Architecture: Best Approaches, Pros/Cons, and Real Examples

araf — Tue, 20 May 2025 04:01:25 +0000

Master Data Management (MDM) is often overlooked until microservices start misbehaving due to data inconsistencies. If your services rely on customer, product, or vendor data and you're not managing it centrally, you're inviting chaos. Let's fix that.

🔍 What Is Master Data in Microservices?

Master Data refers to the core, non-transactional data that defines business entities such as:

Customers
Products
Suppliers
Locations
Employees

In microservices, each service owns its own data. But when multiple services need shared, consistent master data, things get complicated.

⚠️ Common Pitfalls Without MDM

❌ Customer name mismatch across systems
❌ Product catalog inconsistencies
❌ Data duplication & syncing nightmares
❌ Hard-to-maintain integration logic

✅ Common MDM Approaches in Microservices

1. Centralized MDM Service

Create a dedicated microservice that exposes APIs for master data (e.g., CustomerService, ProductCatalogService).

🔧 Example:

GET /api/products/{id}
POST /api/customers

Pros:

Central source of truth
Easy to control validation and versioning
Ensures consistency

Cons:

Becomes a bottleneck or single point of failure
Doesn’t scale well for all domains

When to use: When master data rarely changes and strong consistency is needed.

2. Data Replication (Read-Only Caching)

Services consume master data via APIs or message queues and store local, read-only copies.

🛠️ Example:

Product service pushes updates to Kafka
Order service subscribes and caches product data locally

Pros:

Highly available and decoupled
Local read performance

Cons:

Eventual consistency
Requires sync/reconciliation mechanisms

When to use: High-read use cases (e.g., product catalogs, inventory).

3. Shared Database (Only for Master Data)

A separate shared database is used solely for master data, accessed by services via repositories or shared libraries.

Pros:

Easy implementation
Immediate consistency

Cons:

Breaks microservice independence
Tight coupling

When to use: In early-stage systems or when refactoring monoliths.

4. Domain Ownership & Reference Publishing

Each service owns its master data domain and publishes changes (via events) for other services to consume.

🔄 Example:

Customer Service publishes CustomerUpdated events
Billing and Order services subscribe to updates

Pros:

Loosely coupled
Scalable and event-driven
Easy to track changes

Cons:

Eventual consistency
Requires mature event architecture (Kafka, RabbitMQ, etc.)

When to use: In mature, distributed systems with asynchronous communication.

🧱 Best Practices

✅ Define a canonical data model (avoid ambiguity)
✅ Use versioned APIs for master data
✅ Ensure idempotency for updates
✅ Use CDC (Change Data Capture) or event sourcing for sync
✅ Audit and monitor master data changes
✅ Automate reconciliation between services

🔥 Real-World Example: Product Catalog MDM

Imagine an eCommerce system:

ProductService: owns all product master data
OrderService, CartService, InventoryService depend on it

💡 Solution:

ProductService publishes product events to Kafka
Others subscribe and cache locally
Consistency ensured via periodic sync or hash-based reconciliation

📌 Conclusion

Master Data Management in microservices isn't just a technical choice—it's a business-critical strategy.

Choose your approach based on:

Frequency of change
Consistency requirements
Scalability expectations
Team maturity

🧵 TL;DR

Approach	Best For	Trade-offs
Centralized MDM Service	Strong consistency, simplicity	Bottleneck risk
Data Replication	Fast reads, loosely coupled systems	Eventual consistency
Shared DB for MDM	Simplicity in early stages	Breaks service independence
Event-Driven Ownership	Scalability, loosely coupled systems	Complex setup, requires maturity

💬 Let’s Discuss

What MDM approach have you used in your microservice projects? Any horror stories or success patterns? Drop them below 👇

DEV Community: araf

AI Coding Agents 2025: GitHub Copilot vs Rovo Dev vs Cursor vs Claude vs Gemini vs Codeium

🧠 Quick Comparison

✅ GitHub Copilot — All-Rounder

🧑‍💻 Rovo Dev — Terminal & Enterprise

⚡ Cursor — Deep Codebase

🤖 Claude — Complex Reasoning

🆓 Gemini Code Assist — Free & Generous

💸 Codeium — Free Basic Help

🧠 Verdict

📌 Strategy

🚀 Upgrading Your Legacy Java 8 + Spring Boot 2.1 Project to Java 17 (Without Breaking Everything)

✅ Why Upgrade to Java 17?

🧭 Safe Upgrade Path (The Only Path That Won’t Break Everything)

🔹 Phase 1 — Upgrade Java 8 → Java 11

🔹 Phase 2 — Upgrade Spring Boot 2.1 → 2.7

🔹 Phase 3 — Upgrade Java 11 → Java 17

🔹 Phase 4 — Upgrade Spring Boot 2.7 → 3.x (Jakarta Mandatory)

Required Migrations

1. Javax → Jakarta

2. Spring Security Rewrite

3. Hibernate/JPA

4. Swagger Migration

🧪 Testing Strategy

Add JDK 17 to CI

Run full integration tests

🧰 Common Issues & Fixes

🏁 Final Upgrade Checklist

Java Upgrade

Spring Boot Upgrade

🎉 Conclusion

Mastering Spring AOP: Real-World Use Case and Practical Code Samples

💡 What is AOP (Aspect-Oriented Programming)?

🧱 Key AOP Concepts

🔍 Real-World Use Case: Logging API Calls

🧩 Project Setup

⚙️ Step 1: Create a Sample REST Controller

🧠 Step 2: Define a Logging Aspect

⚡ Output Example

🔐 Other Practical AOP Use Cases

🧭 Pro Tips for Production

🧩 Bonus: Annotation-Driven Logging

🧾 Summary

💬 What’s Next?

🐢 Why Your JPA Transaction Slowed Down After Adding 'flush()' and 'clear()' (And How to Fix It)

🧩 The Real-World Scenario

⚙️ Understanding flush() and clear()

🔹 flush()

🔹 clear()

⚠️ Why It Becomes Slow

💡 Smarter Alternatives

✅ 1. Use Bulk Deletes Instead of Entity Deletes

✅ 2. Split the Transaction Logically

✅ 3. Use Batching for Inserts

✅ 4. Avoid clear() Unless You Really Need It

🚀 The TL;DR Summary

🧠 Key Takeaway

💬 What about you?

Java 25: Latest Features, Examples, and Real-World Use Cases

Java 25: Latest Features, Examples, and Real-World Use Cases

1. Compact Source Files & Instance Main Methods (JEP 512)

2. Flexible Constructor Bodies (JEP 513)

3. Compact Object Headers (JEP 519)

4. Generational Shenandoah GC (JEP 521)

5. Ahead-of-Time (AOT) Method Profiling (JEP 515)

6. Java Flight Recorder (JFR) Enhancements

7. Pattern Matching for Primitive Types (JEP 507 — Preview)

8. Module Import Declarations (JEP 511 — Preview)

9. Scoped Values (JEP 506 — Preview)

10. Key Derivation Function API (JEP 510 — Preview)

11. Removal of 32-bit x86 Port (JEP 503)

Real-World Scenarios

Migration Tips

Conclusion

🐳 Docker & Docker Compose for Beginners: Full Guide + Real Project Example

🔧 What is Docker?

🚀 Why Docker Became So Popular

⚙️ Docker vs Traditional Deployment

🧰 How to Install Docker & Docker Compose

🔹 1. Install Docker

⚙️ Understanding `flush()` and `clear()`

🔹 `flush()`

🔹 `clear()`

✅ 4. Avoid `clear()` Unless You Really Need It

✏️ Step 1: Node.js Code (`app/server.js`)

✏️ Step 2: `app/package.json`

🐳 Step 3: `Dockerfile`

🛠 Step 4: `docker-compose.yml`

⚠️ 1. Overusing `@Transactional` on Everything

⚠️ 5. Overusing `EntityManager` Manually