DEV Community: Shashwath S H

🌍 I Stopped Using RestTemplate… Spring Boot RestClient Is Cleaner

Shashwath S H — Sat, 24 Jan 2026 07:16:34 +0000

When I started building backend services in Spring Boot, I thought REST APIs were only about creating endpoints.

But in real-world projects, you often need the opposite too:

✅ Your service must call other services
✅ Your backend must consume external APIs
✅ Your application must handle HTTP responses + errors properly

That’s where I discovered RestClient — and honestly, it feels way cleaner.

🧠 What is RestClient in Spring Boot?

RestClient is a synchronous HTTP client with a modern, fluent API.

It provides a clean abstraction over HTTP libraries and helps you:

✅ Convert Java objects into HTTP requests
✅ Convert HTTP responses back into Java objects
✅ Write readable and maintainable API-call code

In simple terms:

RestClient makes calling APIs from Spring Boot easier and cleaner.

🏗️ Building a RestClient

You typically create a RestClient using a builder.

Example:

RestClient restClient = RestClient.builder()
    .baseUrl(BASE_URL)
    .defaultHeader(HttpHeaders.AUTHORIZATION,
        encodeBasic(properties.getUsername(), properties.getPassword())
    )
    .build();

What I like here:

baseUrl keeps calls consistent
defaultHeader avoids repeating auth in every request
The builder feels very readable

✅ Using RestClient (GET Example)

Once built, using it feels super fluent:

CustomerResponse customer = restClient.get()
    .uri("/{id}", 3)
    .accept(MediaType.APPLICATION_JSON)
    .retrieve()
    .body(CustomerResponse.class);

What’s happening here:

.get() sends a GET request
.uri("/{id}", 3) builds dynamic URLs
.retrieve() executes the request
.body(CustomerResponse.class) maps response into your Java class

This is exactly how a clean backend should consume APIs.

🔁 RestClient Supports More Than Just GET

Apart from get(), RestClient supports:

✅ post()
✅ put()
✅ patch()
✅ delete()

So it fits perfectly for full CRUD interactions with external services.

🚨 Handling Errors in RestClient

Calling external APIs isn’t always smooth.

Sometimes the response is:

4xx (client errors)
5xx (server errors)

RestClient allows handling these cleanly using onStatus().

Example (DELETE + error handling):

ResponseEntity response = restClient.delete()
    // ...
    .onStatus(HttpStatusCode::is4xxClientError,
        (req, res) ->
            logger.error("Couldn't delete " + res.getStatusText())
    )
    .toBodilessEntity();

This makes error handling:
✅ explicit
✅ readable
✅ maintainable

And most importantly:

It prevents silent failures.

🧠 Why This Matters in Real Projects

Most real backend projects are not standalone.

They talk to:

payment services
authentication servers
notification APIs
microservices
third-party providers

A clean HTTP client is essential, and RestClient fits perfectly into modern Spring Boot development.

🚀 Final Thoughts

RestClient is one of those tools that feels small…

…but improves your backend workflow massively.

If you’re building Spring Boot applications that consume APIs:
✅ try RestClient
✅ set a baseUrl
✅ handle errors properly
✅ keep responses typed

This post is part of my learning-in-public journey while exploring Spring Boot and real-world backend development.

Do you use RestTemplate, WebClient, or RestClient in your Spring Boot projects?

⏱️ I Was Manually Setting createdAt & updatedAt… Until I Learned Spring Boot Auditing

Shashwath S H — Wed, 21 Jan 2026 11:01:04 +0000

🔥 Backup options:

“Stop Writing createdAt/updatedAt Manually in Spring Boot”
“Spring Boot Auditing: The Feature That Makes Your Backend Look Professional”
“How I Automated Entity Timestamps in Spring Data JPA”

When I started building CRUD APIs with Spring Boot, everything worked fine.

But one thing kept bothering me.

Every entity needed fields like:

createdAt
updatedAt
createdBy
updatedBy

And I was setting them manually.

Again and again.
In every service method.
For every entity.

That’s when I discovered Auditing in Spring Boot — and it instantly made my backend feel more real-world and production-ready.

🧠 What is Auditing in Spring Boot?

Auditing in Spring Boot allows you to automatically populate fields such as:

✅ Creation timestamp
✅ Last modification timestamp
✅ Created by user
✅ Last modified by user

So instead of manually updating these fields, Spring does it for you automatically.

✅ Why Auditing is Actually Useful

Auditing helps in:

tracking data history
debugging changes
maintaining clean records
building professional enterprise systems

Most real applications require this, especially when multiple users are modifying records.

🛠️ Steps to Add Auditing in Spring Boot

1️⃣ Create an Auditable Base Entity

Create a superclass and add:

✅ @EntityListeners(AuditingEntityListener.class)

This gives access to:

@CreatedBy
@CreatedDate
@LastModifiedBy
@LastModifiedDate

2️⃣ Extend All Entities from the Superclass

Instead of repeating auditing fields in every entity, simply extend the base class.

This keeps the code:
✅ clean
✅ reusable
✅ consistent

3️⃣ Implement AuditorAware

Create a class that implements AuditorAware.

Its job is to provide:
✅ the current authenticated user (usually from Spring Security)

This is how Spring knows who created/modified the entity.

4️⃣ Enable JPA Auditing

Enable auditing using:

✅ @EnableJpaAuditing

This is usually added in a configuration class.

5️⃣ Pass the AuditorAware Bean Reference

Connect your auditor provider to auditing configuration so Spring can use it globally.

🔍 Internal Working of Auditing (Simple Explanation)

Auditing works using an entity listener called AuditingEntityListener.

Whenever an entity is saved or updated, Spring triggers:

✅ PrePersist (before insert)
✅ PreUpdate (before update)

So when an entity is:

created → created fields are filled automatically
updated → last modified fields are updated automatically

The user information comes from AuditorAware.

🚀 Final Thoughts

Spring Boot Auditing is one of those features that quietly improves your backend quality.

If you’re still:

manually setting timestamps
repeating createdAt/updatedAt logic everywhere
struggling to track modifications

Start using Auditing.

It makes your project look professional and enterprise-ready.

This post is part of my learning-in-public journey while exploring Spring Boot and real-world backend development.

Do you handle createdAt/updatedAt manually or are you using Spring Boot Auditing?

⚡ I Was Restarting Spring Boot Again and Again… Until I Found DevTools

Shashwath S H — Tue, 20 Jan 2026 05:26:15 +0000

When I started learning Spring Boot, I thought restarting the server was normal.

Change code ✅
Stop server ❌
Start again ✅
Wait… 😴
Repeat 🔁

At first it was fine.
But once the project grew, restarting again and again became painful.

That’s when I discovered Spring Boot DevTools — and it instantly made development faster.

🧠 What is Spring Boot DevTools?

Spring Boot DevTools is a development-time dependency that improves productivity by enabling features like:

✅ Automatic restart
✅ Faster feedback loop
✅ Better developer experience

It’s meant only for development, not production.

✅ Step 1: Add the DevTools Dependency

In Maven (pom.xml), add:

<dependency>
  <groupId>org.springframework.boot</groupId>
  <artifactId>spring-boot-devtools</artifactId>
  <optional>true</optional>
</dependency>

After adding this, Spring Boot can detect classpath changes and restart automatically.

🔄 The Best Feature: Automatic Restart

DevTools automatically restarts your application when files on the classpath change.

Why this is useful:

It’s faster than a full restart
Only changed parts get reloaded
Development becomes smoother

🧩 How DevTools Restart Works Internally (Simple Explanation)

DevTools uses two class loaders:

✅ One for base classes that don’t change (libraries, dependencies)
✅ One for application classes that change (your code)

So when you change your code:

Only your application class loader reloads
Restart happens faster

This is why it feels quick and lightweight.

⚙️ IntelliJ Setting (Important)

After adding DevTools, you may need to update IntelliJ settings to allow restart properly during development.

This step matters because sometimes IntelliJ doesn’t trigger automatic reload unless configured.

🛠️ Useful DevTools Configurations

You can control DevTools behavior using application.properties.

✅ Disable restart (if needed)

spring.devtools.restart.enabled=false

✅ Exclude folders from restart

spring.devtools.restart.exclude=static/**,public/**

Useful when you don’t want restart triggers for static content.

✅ Poll interval

spring.devtools.restart.pollInterval=20

Defines how often DevTools checks for changes.

✅ Quiet period

spring.devtools.restart.quietPeriod=10

Wait time before restarting after changes are detected.

🚀 Final Thoughts

Spring Boot DevTools is one of those small features that makes a huge difference.

If you're tired of:

restarting again and again
losing time during development
slow feedback while learning

DevTools is a must-have for Spring Boot development.

This post is part of my learning-in-public journey while exploring Spring Boot and real-world backend development.

Do you still restart Spring Boot manually or are you using DevTools?

🚀 My Spring Boot Project Finally Felt Real After Adding Web MVC + JPA

Shashwath S H — Mon, 19 Jan 2026 09:59:13 +0000

When I started learning Spring Boot, I built small demos.

A controller here.
A GET API there.
Everything looked fine…

But it didn’t feel like a real backend project.

A real project needs:
✅ REST APIs
✅ Database integration
✅ Clean layered structure
✅ Proper dependencies and configuration

So today I’m documenting how I set up a Spring Boot project with Web MVC + Spring Data JPA the right way.

✅ What We Are Setting Up

This project will include:

Spring Boot Web MVC → for building REST APIs
Spring Data JPA → for database operations
A clean layered structure:
- controller
- service
- repository
- dto
- entity

This is the most common structure used in real-world Spring Boot apps.

🧱 Step 1: Create a Spring Boot Project

You can create the project using Spring Initializr.

Choose:

Project: Maven
Language: Java
Packaging: Jar
Java Version: (your installed version)

✅ Add Dependencies

Add these:

✅ Spring Web
✅ Spring Data JPA
✅ H2 Database / MySQL Driver (optional but recommended)

📦 Step 2: Understand Your Dependencies

Once dependencies are added, Spring Boot handles most setup automatically.

Spring Web gives you:

Controllers
REST APIs
JSON support (via Jackson)
Embedded server (Tomcat)

Spring Data JPA gives you:

Repositories
CRUD operations
Query methods
ORM support (Hibernate under the hood)

This combination = production-ready backend base.

🗂️ Step 3: Follow a Clean Project Structure

Here’s the structure I use:

com.yourapp.project
 ├── controller
 ├── service
 ├── repository
 ├── dto
 ├── entity
 └── Application.java

Why this matters

Without structure:

Controllers become huge
Logic becomes messy
Debugging becomes painful

With structure:
✅ separation of concerns
✅ maintainability
✅ scalability

🌐 Step 4: Web MVC Setup (Controller Layer)

To expose APIs, we use @RestController.

This layer should:

Handle request mappings
Accept input
Return response
Call service layer

Rule:
👉 Controller should NOT talk to database directly.

🗄️ Step 5: JPA Setup (Entity + Repository)

To connect your backend to the database, you need:

✅ Entity

Represents table in DB

✅ Repository

Handles database operations

Spring Data JPA makes database work simple because you can use:

JpaRepository
Dynamic query methods like:
- findByName()
- findByEmail()

No need to write boilerplate DAO code.

⚙️ Step 6: Configure Database in `application.properties`

Your project needs DB configuration.

In general, you set:

datasource URL
username/password (if needed)
JPA behavior like ddl-auto

This is where you control:

table creation/update
SQL logging
dialect settings

🧠 Step 7: Add Service Layer (Business Logic)

This is the layer that makes your backend “real”.

The Service Layer:

encapsulates business logic
connects controller and repository
keeps architecture clean

Rule:
👉 Controller → Service → Repository → DB

✅ Final Thoughts

Setting up Spring Boot with Web MVC + Spring Data JPA is the moment where projects start feeling like actual backend systems — not demos.

Once this setup is done, you’re ready to build:
✅ CRUD APIs
✅ validations
✅ exception handling
✅ pagination
✅ relationships

This post is part of my learning-in-public journey while exploring Spring Boot and real-world backend development.

What was the most confusing part when you set up your first Spring Boot + JPA project?

🐌 My Spring Boot API Was Fast… Until Relationships Caused N+1 Queries

Shashwath S H — Sat, 17 Jan 2026 18:51:18 +0000

When I first built relational APIs using Spring Data JPA, everything worked fine.

Entities saved properly ✅
Relationships mapped correctly ✅
Responses returned clean JSON ✅

But then I noticed something scary:

The API got slower as the data increased.

No code changes.
No heavy computation.
Just… slower.

That’s when I discovered the hidden performance killers:

✅ FetchType
✅ orphanRemoval
✅ N+1 Query problem

🧠 FetchType: The Silent Decision Maker

Whenever you map a relationship like:

@OneToMany
@ManyToOne
@OneToOne
@ManyToMany

Hibernate has to decide:

“Should I load related data now… or later?”

That decision is controlled using FetchType.

🔥 Two Fetch Strategies in JPA

✅ FetchType.EAGER

Hibernate loads related data immediately.

That means:

Parent loads ✅
Child loads ✅
Even if you don’t need child data ❌

This can lead to:

Heavy queries
Bigger payloads
Slower APIs

✅ FetchType.LAZY

Hibernate loads related data only when needed.

That means:

Parent loads ✅
Child loads only when accessed ✅

This is usually better for performance…

But it introduces real-world issues if you're not careful.

⚠️ The Real Problem: N+1 Queries

This is where performance gets destroyed quietly.

What happens in N+1?

You fetch:

1 query for parent list ✅ Then for each parent:
1 query for its children ❌ ❌ ❌

So if you have 10 parents:

👉 1 (parent query) + 10 (child queries) = 11 total queries

If you have 100 parents:
👉 101 queries

That’s why it’s called N+1.

💥 Why N+1 Happens So Often

Because with LAZY loading, Hibernate doesn’t fetch children in the first query.

So when you loop through results and access relations, Hibernate keeps firing extra SELECT queries.

And the scary part?

✅ Your code looks clean
❌ Your database gets abused

🛠️ How to Fix / Optimize N+1 Queries

N+1 is not “a small issue”.
It’s a performance bug.

Common ways to fix it include:

Fetching required relations efficiently (instead of triggering lazy loads repeatedly)
Using optimized fetch strategies in queries
Designing API responses properly (DTOs / projections)

The key is:

Fetch what you need — not everything, and not one-by-one.

🧹 Orphan Removal: Helpful… and Dangerous

When I saw orphanRemoval = true, I thought it was just cleanup.

But orphan removal means:

When a child is removed from the parent’s collection, it gets deleted from the DB automatically.

Example idea:

Patient has appointments
Remove an appointment from list
Hibernate deletes that appointment record ✅

This is useful when:
✅ Child cannot exist without parent

But it can also cause unexpected deletions if used blindly.

✅ orphanRemoval vs Cascade REMOVE (Quick Clarity)

CascadeType.REMOVE

Child gets deleted when parent is deleted

orphanRemoval = true

Child gets deleted when it is no longer referenced by parent
(even when parent still exists)

⚠️ The Mistakes I Made

I used to:

Use EAGER without thinking
Use LAZY and accidentally trigger N+1 queries
Enable orphanRemoval and forget about it
Wonder why performance dropped randomly

Once I understood FetchType + N+1:

APIs became faster
Queries became predictable
Debugging got easier

🚀 Final Thoughts

Relationships in Spring Data JPA are easy to write…

…but hard to scale if you ignore performance.

If your Spring Boot API is slow and you don’t know why:

Check:
✅ FetchType
✅ N+1 queries
✅ orphanRemoval behavior

This post is part of my learning-in-public journey as I explore Spring Boot and real-world backend optimization.

Have you ever noticed your API getting slower after adding relationships?

💀 I Deleted a Parent Entity… and Hibernate Deleted Everything (Cascades Explained)

Shashwath S H — Sat, 17 Jan 2026 12:48:10 +0000

When I started working with Spring Data JPA relationships, I thought saving and deleting was simple:

repository.save(parent);

Or:

repository.delete(parent);

Then I tried it with relationships like:

Patient → Appointments
User → Orders
Department → Employees

And suddenly…

✅ Saving one object saved many
💀 Deleting one object deleted many
❌ Updates didn’t behave how I expected

That’s when I learned the two concepts that control everything:

✅ Cascade Types
✅ @Transactional

🧠 What is Cascading in JPA?

In JPA, cascading tells Hibernate:

“When I perform an operation on the parent, automatically apply it to the child entities too.”

So instead of manually doing:

save parent
save child
save child
save child

Hibernate can do it for you.

🔁 Common Cascade Types (and what they really mean)

✅ CascadeType.PERSIST

When you save the parent, child entities are saved automatically.

Use case: parent creation should create children too.

✅ CascadeType.MERGE

When you update the parent, related child updates propagate.

Use case: parent update should sync children.

💀 CascadeType.REMOVE

When you delete the parent, child entities are deleted too.

Use case: child has no meaning without parent (like appointments without patient).

⚠️ This is the one that can wipe data if used blindly.

✅ CascadeType.REFRESH

Reloads child entities when parent is refreshed.

✅ CascadeType.DETACH

Detaches child entities when parent is detached from persistence context.

✅ CascadeType.ALL

Applies all cascade operations:
PERSIST, MERGE, REMOVE, REFRESH, DETACH

This feels convenient — but it can be dangerous if you don’t understand it.

🧹 The Hidden Killer: orphanRemoval = true

This is not a cascade type, but it changes deletion behavior massively.

orphanRemoval = true means:

If a child is removed from the parent collection, Hibernate deletes it from the database automatically.

Example:

Parent remains in DB ✅
Child removed from list ❌ → deleted from DB 💀

✅ Cascade REMOVE vs orphanRemoval (Important Difference)

CascadeType.REMOVE

Child is deleted only when parent is deleted.

orphanRemoval = true

Child is deleted when it is no longer referenced by parent, even if parent is still alive.

This is perfect for true parent-child lifecycle relationships.

🔥 Why @Transactional Becomes Important in Relational Queries

At first I thought transactions are only for big systems.

But relational operations break easily without a transaction because:

multiple DB operations happen in one flow
entity states change during execution
lazy loading may fail outside a session

That’s why Spring provides @Transactional.

🧠 What does @Transactional do?

@Transactional ensures that all operations inside a method run in one transaction.

That means:

Either everything succeeds ✅
Or everything rolls back ❌

This makes database operations safe and consistent.

⚠️ What Happens Without @Transactional?

This is where people get errors like:

partial save (half data inserted, half failed)
inconsistent state
lazy-loading issues (accessing relations after session closes)

Even if your code looks correct, database behavior becomes unpredictable.

✅ Real-World Scenario: Saving Parent + Children

If you have:

Patient has many Appointments

and you set:

cascade = PERSIST or ALL

Then:
✅ Saving Patient automatically saves Appointments
✅ No need to explicitly save Appointment records

This keeps code clean and avoids repeated repository calls.

✅ Final Thoughts

Cascading and transactions are not “extra JPA features”.

They decide whether your application is:

clean ✅
scalable ✅
safe ✅ or
unpredictable ❌
dangerous ❌
bug-prone ❌

If you’re using Spring Data JPA relationships, you can’t ignore:
✅ Cascade Types
✅ orphanRemoval
✅ @Transactional

This post is part of my learning-in-public journey while exploring Spring Boot and real-world backend behavior.

Have you ever deleted a parent entity and lost child data by mistake? 😅

🔗 JPA Relationships Finally Made Sense When I Stopped Memorizing Them

Shashwath S H — Fri, 16 Jan 2026 05:59:54 +0000

When I started Spring Data JPA, I thought relationships would be easy.

Just add:

@OneToOne
@OneToMany
@ManyToOne
@ManyToMany

Done ✅

But then I hit real problems:

Foreign keys didn’t update
Extra tables appeared
Deletes didn’t behave correctly
Infinite JSON recursion happened

That’s when I realized:
JPA relationships are not about annotations… they’re about ownership and data modeling.

🧠 The Real Meaning of JPA Relationships

JPA mappings are basically answering one question:

How do two tables relate to each other in the database?

Spring Data JPA only makes it easier — the relationship rules still come from SQL fundamentals.

1️⃣ @OneToOne — One record links to one record

Example:

One User has one Profile
One Employee has one IDCard

✅ Best used when the child record has meaning only with the parent.

💡 Tip:

Usually implemented using a foreign key with a unique constraint

2️⃣ @ManyToOne — Many children belong to one parent

This is one of the most common relationships in real applications.

Example:

Many Employees belong to one Department
Many Orders belong to one Customer

Important point:
👉 The Many side holds the foreign key

That’s why @ManyToOne is usually the owning side.

3️⃣ @OneToMany — One parent has many children

Example:

One Department has many Employees
One Customer has many Orders

This relationship is basically the reverse of ManyToOne.

But here’s what confused me initially:

⚠️ The OneToMany side is often NOT the owning side

Meaning:

Changing the parent collection alone may not update the foreign key
Ownership decides what actually updates in the database

4️⃣ @ManyToMany — The most confusing one (at first)

Example:

Many Students can enroll in many Courses
Many Users can have many Roles

This mapping creates a join table in the database automatically.

That join table stores:

student_id
course_id

This works great… but in real-world apps:

⚠️ ManyToMany can become messy quickly
Because:

You often need extra fields (like createdAt, status, etc.)
Join tables become actual entities later

⚠️ The Biggest Mistake I Made

I thought relationships were just:

“Pick an annotation and done.”

But the real key is:

✅ Owning Side vs Inverse Side

Because:

The owning side controls foreign key updates
The inverse side only reflects the relationship

If you don’t understand ownership:
your mapping will “work sometimes” — and break later.

✅ Final Thoughts

JPA relationships became easy when I stopped memorizing definitions and started thinking like this:

Where is the foreign key stored?
Who is the parent?
Who controls the relationship updates?
Do I need a join table?

If you’re learning Spring Boot and struggling with mappings…

You’re not alone 😅
This topic is confusing at first — but once it clicks, backend development becomes 10x easier.

This post is part of my learning-in-public journey while exploring Spring Boot and real-world backend design.

🧠 Hibernate Felt Like Magic… Until I Understood Entity Lifecycle & Cascading

Shashwath S H — Thu, 15 Jan 2026 06:27:23 +0000

At first, Spring Data JPA felt amazing.

I wrote:

repository.save(entity);

Data magically appeared in the database.

But then strange things started happening.

Updates didn’t persist
Deletes didn’t behave as expected
Child records disappeared (or didn’t)
Entities acted… alive

That’s when I realized:

👉 I didn’t understand what Hibernate was actually doing.

🏗️ The Big Stack (Clear Mental Model)

Before diving deep, here’s the actual hierarchy:

👉 Spring Data JPA → abstraction (repositories)
👉 JPA → specification (rules)
👉 Hibernate → implementation (ORM engine)
👉 JDBC → executes SQL
👉 Database

Spring Data JPA reduces boilerplate.
Hibernate does the heavy lifting.
JDBC talks to the database.

🧬 Hibernate Entity Lifecycle (The Missing Piece)

Every JPA entity lives in one of these states.

Understanding this changed everything for me.

🟡 Transient

Patient p = new Patient();

Just a Java object
Not tracked by Hibernate
Not stored in DB

If garbage collected → gone forever.

🟢 Persistent

Triggered by:

persist()
save()
find()
get() / load()

Now:

Entity is managed
Tracked inside Persistence Context
Changes are auto-synced to DB

👉 This is where Hibernate magic happens.

🔵 Detached

Triggered by:

detach()
clear()
close()

Entity:

Exists in DB
Exists in memory
But Hibernate stops tracking it

Changes won’t be saved unless you merge().

🔴 Removed

Triggered by:

remove()
delete()

Entity:

Marked for deletion
Deleted during transaction commit

🧠 EntityManager & Persistence Context (VERY IMPORTANT)

Hibernate doesn’t hit the DB immediately.

It first checks the Persistence Context.

Flow:

find() → checks Persistence Context
If found → return object
If not → DB SELECT
Store entity in Persistence Context

👉 This is why multiple finds don’t always hit the DB.

🔗 Relationships: Owning Side vs Inverse Side

This is where many bugs are born.

🔑 Owning Side

Controls the foreign key
Updates actually affect DB

🔄 Inverse Side

Only reflects relationship
Cannot update foreign key

👉 Updating inverse side alone does nothing in DB.

🏥 One-to-Many Example (Patient & Appointments)

Patient = Parent
Appointment = Child

If Patient is deleted → Appointments should also go.

That’s why:
👉 Patient is the owning lifecycle controller

🔁 Cascading: Let Hibernate Do the Work

Cascading tells Hibernate:

“When I do something to the parent, do the same to children.”

Common Cascade Types:

PERSIST → save child automatically
MERGE → update child
REMOVE → delete child
REFRESH
DETACH
ALL

Example:

Save Patient → Appointments saved automatically
Delete Patient → Appointments deleted automatically

No manual repository calls needed.

🧹 orphanRemoval = true (POWERFUL & DANGEROUS)

This one surprised me.

What it does:

Deletes child entity when it’s removed from parent collection
Parent still exists

Example:

patient.getAppointments().remove(appointment);

👉 Appointment gets deleted from DB automatically.

orphanRemoval vs CascadeType.REMOVE

Feature	CascadeType.REMOVE	orphanRemoval
Parent deleted	✅ Child deleted	✅ Child deleted
Child removed from collection	❌	✅
Parent still exists	❌	✅

🎯 When to Use orphanRemoval

Perfect when:

Child has no meaning without parent
Appointment without Patient
Insurance without User

⚠️ Use carefully — deletions are automatic.

⚠️ The Mistakes I Was Making

I used to:

Call save() everywhere
Ignore entity states
Manually delete children
Get confused by unexpected deletes

Once I understood:

Entity lifecycle
Persistence Context
Cascades & orphanRemoval

👉 Hibernate stopped feeling random.

🚀 Final Thoughts

Hibernate is not magic.

It’s state + rules + lifecycle.

If JPA ever feels:

Unpredictable
Dangerous
Confusing

You’re missing this layer of understanding.

This post is part of my learning-in-public journey while exploring Spring Boot, JPA, and real-world backend behavior.

Did Hibernate ever delete or update something you didn’t expect?

🎯 I Was Fetching Entire Entities… Until I Learned About Projections

Shashwath S H — Wed, 14 Jan 2026 04:43:21 +0000

When I started using Spring Data JPA, my approach was simple:

Need data?
Fetch the entity.

Every time.

It worked.
But something felt wrong.

APIs returned too much data.
Performance started degrading.
Clients received fields they never asked for.

That’s when I discovered Spring Data JPA Projections — and everything changed.

🧠 What Are Projections in Spring Data JPA?

Projections allow you to fetch only the data you actually need from the database.

Instead of loading the entire entity:

You select specific fields
You reduce query overhead
You return lighter responses

In short:

Projections help you avoid over-fetching data.

⚠️ The Problem with Fetching Full Entities

Fetching full entities:

Loads unnecessary columns
Increases memory usage
Makes APIs slower
Exposes more data than required

This may be fine for small apps — but it doesn’t scale.

🧩 Types of Projections in Spring Data JPA

Spring Data JPA supports three main types of projections.

Each one solves a slightly different problem.

1️⃣ Interface-Based Projections (Most Common)

This is the most popular and cleanest way to use projections.

You define an interface with getter methods for required fields.

Spring Data JPA automatically maps query results to it.

Why this is powerful:

No implementation needed
Clean and readable
Works seamlessly with repositories

Perfect when:

You want partial data
You don’t want extra objects

2️⃣ Class-Based (DTO) Projections

Here, you define a DTO class and use a constructor to map values.

This is useful when:

You want custom logic
You want computed fields
You need strong control over response structure

Slightly more verbose — but very flexible.

3️⃣ Open Projections (Advanced but Dangerous)

Open projections allow:

Derived values
Expression-based fields

They look powerful — but there’s a catch.

⚠️ They may trigger additional queries, impacting performance.

Use them carefully and only when needed.

🔍 How Spring Data JPA Makes This Work

Under the hood:

Spring analyzes your repository method return type
Detects projection usage
Generates optimized queries
Maps results automatically

You don’t write SQL.
You don’t write mapping code.

This is convention over configuration done right.

🛠️ Projections with Repository Methods

Projections work naturally with:

Query methods
Derived queries
Sorting
Pagination

Which means:
👉 You can combine Projections + Pageable + Sort for production-ready APIs.

⚠️ The Mistake I Was Making

I used to:

Always return entities
Let Jackson decide response shape
Ignore payload size

It worked… until APIs slowed down.

After switching to projections:

Responses became lighter
Performance improved
APIs felt cleaner and safer

🚀 Final Thoughts

Spring Data JPA Projections are not a micro-optimization.

They are a design decision.

If your Spring Boot APIs:

Return too much data
Feel slow
Expose unnecessary fields

Start with Projections.

This post is part of my learning-in-public journey while exploring Spring Boot and real-world backend optimization.

🐌 “My Spring Boot API Became Slow… Until I Learned Pagination & Sorting”

Shashwath S H — Tue, 13 Jan 2026 05:18:06 +0000

At first, my Spring Boot APIs worked perfectly.

Data was returned.
UI was happy.
Everything looked fine.

Then the database grew.

Hundreds of records became thousands.
Responses slowed down.
Memory usage increased.

That’s when I realized I was missing something critical:
Sorting and Pagination.

🧠 Why Sorting & Pagination Matter

In real applications:

Databases grow fast
Fetching everything at once is expensive
Clients rarely need all data

Sorting and pagination help you:

Improve performance
Reduce memory usage
Deliver faster APIs
Build scalable systems

This is not optional in production backends.

🔀 Sorting Using Method Query Names

Spring Data JPA allows sorting directly in method names.

Example:

List<Employee> findAllByOrderByNameAsc();
List<Employee> findAllByOrderByNameDesc();

This works well when:

Sorting logic is fixed
Requirements are simple

But real applications need dynamic sorting.

🧭 Dynamic Sorting with the Sort Class

Spring Data JPA provides the Sort class for flexible sorting.

Sorting with repository methods

List<Employee> findByDepartment(String department, Sort sort);

This allows clients to decide:

Which field to sort
Ascending or descending order

⚙️ Creating Sort Objects

Examples:

Sort sort = Sort.by(Sort.Direction.ASC, sortField);

Multiple sorting fields:

Sort sort = Sort.by(
    Sort.Order.asc("name"),
    Sort.Order.desc("salary")
);

This gives full control without complex queries.

📚 Why Sorting Alone Is Not Enough

Even with sorting:

Returning thousands of rows is inefficient
APIs become slower
Clients struggle to handle large responses

That’s where Pagination comes in.

📄 Understanding Pagination (Simple Terms)

Pagination breaks large datasets into smaller chunks.

Key Pagination Concepts

🔹 Page

Represents a single chunk of data.
It also contains:

Total elements
Total pages
Current page data

🔹 Pageable

Defines:

Page number
Page size
Sorting rules

🔹 PageRequest

A concrete implementation of Pageable used to create pagination objects.

🧩 Using Pageable in Repositories

Spring Data JPA makes pagination extremely simple.

Page<User> findAll(Pageable pageable);
Page<User> findByLastName(String lastName, Pageable pageable);

No SQL.
No complex logic.
Just clean method signatures.

🛠️ Creating a Pageable Instance

Pageable pageable = PageRequest.of(
    pageNumber,
    size,
    Sort.by("lastName").ascending()
);

With this:

You control page size
You control page number
You control sorting

All in one object.

⚠️ The Mistake I Was Making

I used to:

Fetch all records
Sort in memory
Ignore scalability

It worked… until data increased.

After using pagination and sorting:

APIs became faster
Memory usage dropped
Backend felt production-ready

🚀 Final Thoughts

Sorting and Pagination are not “extra features”.

They are core backend fundamentals.

If your Spring Boot APIs feel:

Slow
Heavy
Hard to scale

Start here.

This post is part of my learning-in-public journey while exploring Spring Boot and real-world backend development.

✨I Didn’t Write a Single SQL Query… Yet Spring Data JPA Queried My Database

Shashwath S H — Sun, 11 Jan 2026 19:41:34 +0000

When I started using Spring Data JPA, something felt unreal.

I wrote a method like this:

findByEmail()

No SQL.
No JPQL.
No query annotations.

Yet… it worked.

At first, it felt like magic.
Later, it felt confusing.
Finally, it clicked.

🧠 Where Spring Data JPA Fits in the Big Picture

Before diving in, here’s the clear hierarchy:

👉 Spring Data JPA sits on top of JPA
👉 JPA is implemented by Hibernate
👉 Hibernate executes SQL using JDBC

Spring Data JPA’s job is simple but powerful:

Make data access easier by removing boilerplate code.

📦 What is Spring Data JPA?

Spring Data JPA is part of the larger Spring Data family.

It provides:

Repository abstractions
Ready-made CRUD operations
Dynamic query generation
Pagination and sorting support

Instead of writing DAO classes manually, you just define Repository interfaces.

🗄️ Repositories: Where the Magic Starts

Spring Data JPA provides repository interfaces like:

CrudRepository
JpaRepository

By extending them, you instantly get:

save()
findById()
findAll()
delete()

No implementation needed.

This alone saves a huge amount of code.

🔮 Dynamic Query Methods (The Cool Part)

Dynamic query methods allow Spring Data JPA to generate queries from method names.

Yes — your method name defines the query.

This is called Query Derivation.

🧩 Anatomy of a Query Method Name

A query method has four parts:

ReturnType + QueryPrefix + Subject + Predicate + Parameters

Once I understood this structure, everything became predictable.

🏷️ Rules for Creating Query Methods

🔹 1️⃣ Method Name Prefix

Query methods must start with one of these:

find…By
read…By
query…By
get…By

Examples:

findByName
readByEmail
queryByStatus
getByUsername

🔹 2️⃣ Limiting Results with First or Top

To limit results, add First or Top before By.

Examples:

findFirstByName
findTop10ByStatus
readFirst2ByCategory

This avoids unnecessary data fetching.

🔹 3️⃣ Fetching Unique Results with Distinct

To return unique results, use Distinct.

Examples:

findDistinctByName
findNameDistinctBy

This helps when duplicates exist in data.

🔹 4️⃣ Combining Conditions with AND / OR

You can combine conditions directly in method names.

Examples:

findByNameAndDepartment
findByStatusOrRole

Spring automatically builds the correct query.

📄 Pagination & Sorting (Real-World Requirement)

Spring Data JPA provides built-in support for:

Pagination
Sorting

This is essential for:

Large datasets
Performance optimization
API scalability

And the best part — no complex query writing.

⚠️ The Mistake I Was Making

Initially, I:

Thought method names were arbitrary
Memorized examples without understanding rules
Got confused when queries failed

Once I learned the naming rules, dynamic queries stopped feeling magical — they became logical.

🚀 Final Thoughts

Spring Data JPA dynamic query methods are not magic.

They are well-designed conventions.

If you understand:

Method name structure
Query keywords
Naming rules

You can build powerful data access layers without writing SQL.

This post is part of my learning-in-public journey while exploring Spring Boot and backend development.

🔍 JPA, Hibernate, JDBC… I Was Confused Until This Finally Clicked

Shashwath S H — Sun, 11 Jan 2026 05:37:45 +0000

When I started backend development with Spring Boot, these terms kept showing up everywhere:

JPA
Hibernate
JDBC

Everyone explained them — yet I was still confused.

Who does what?
Why do we need all three?
Are they competitors or teammates?

It finally made sense when I stopped memorizing definitions and understood how they work together.

🧠 The Big Picture (Before Details)

Here’s the simplest mental model:

👉 Your code talks to JPA
👉 JPA uses Hibernate
👉 Hibernate uses JDBC
👉 JDBC talks to the database

Once I understood this chain, everything clicked.

📜 What is JPA (Java Persistence API)?

JPA is NOT a framework.

It is a specification — a set of rules and guidelines that define:

How Java objects map to database tables
How relationships should work
How queries and transactions are handled

Important point:

JPA itself does not execute anything.

It only defines how things should behave.

⚙️ What is Hibernate?

Hibernate is a powerful ORM framework and a JPA implementation.

That means:

Hibernate follows JPA rules
Hibernate provides the actual logic
Hibernate converts Java objects into SQL queries

In short:

Hibernate is the engine that makes JPA work.

It also provides extra features beyond JPA, which is why it’s so popular.

🔌 Where Does JDBC Fit In?

JDBC is the lowest-level database API in Java.

Hibernate does not talk to the database directly.
Instead:

👉 Hibernate generates SQL
👉 JDBC executes that SQL
👉 Database returns results

So even if you never write JDBC code:
JDBC is still working behind the scenes.

🧱 Spring Data JPA: The Final Layer

Spring Data JPA sits on top of JPA and Hibernate.

Its job:

Reduce boilerplate
Help you build DAO methods easily
Provide repositories like JpaRepository

That’s why you can write:

findByEmail()

…and it magically works.

🏗️ Common Hibernate Configurations (That Actually Matter)

These are the ones I see in almost every real project:

spring.jpa.hibernate.ddl-auto
- update / create / validate / create-drop / none
spring.jpa.show-sql
- Shows generated SQL in logs
hibernate.format_sql
- Makes SQL readable
hibernate.dialect
- Helps Hibernate generate database-specific SQL

Understanding these made debugging MUCH easier.

🧩 Entity Mapping: Where Magic Begins

Hibernate maps Java classes to database tables using annotations like:

@entity
@Table
@id
@GeneratedValue
@column
@CreationTimestamp
@UpdateTimestamp

This mapping is what makes ORM possible.

Once entities are correct, everything else becomes smoother.

🔑 Key Features of JPA

JPA provides powerful abstractions for:

✅ Entity Management

Defines how objects are persisted.

✅ JPQL

A query language that works on entities, not tables.

✅ Transactions

Handles commit and rollback cleanly.

✅ Entity Relationships

Supports:

One-to-One
One-to-Many
Many-to-One
Many-to-Many

This is where real-world data modeling happens.

⚠️ The Mistake I Was Making

I used to:

Treat JPA and Hibernate as the same thing
Ignore JDBC completely
Memorize annotations without understanding flow

Once I understood the layered responsibility, my learning speed doubled.

🚀 Final Thoughts

If you’re learning Spring Boot and feel confused by:

JPA
Hibernate
JDBC

You’re not alone.

The clarity comes when you understand who does what — not when you memorize definitions.

This post is part of my learning-in-public journey while exploring Spring Boot and backend development.

DEV Community: Shashwath S H

🌍 I Stopped Using RestTemplate… Spring Boot RestClient Is Cleaner

🧠 What is RestClient in Spring Boot?

🏗️ Building a RestClient

✅ Using RestClient (GET Example)

🔁 RestClient Supports More Than Just GET

🚨 Handling Errors in RestClient

🧠 Why This Matters in Real Projects

🚀 Final Thoughts

⏱️ I Was Manually Setting createdAt & updatedAt… Until I Learned Spring Boot Auditing

🧠 What is Auditing in Spring Boot?

✅ Why Auditing is Actually Useful

🛠️ Steps to Add Auditing in Spring Boot

1️⃣ Create an Auditable Base Entity

2️⃣ Extend All Entities from the Superclass

3️⃣ Implement AuditorAware

4️⃣ Enable JPA Auditing

5️⃣ Pass the AuditorAware Bean Reference

🔍 Internal Working of Auditing (Simple Explanation)

🚀 Final Thoughts

⚡ I Was Restarting Spring Boot Again and Again… Until I Found DevTools

🧠 What is Spring Boot DevTools?

✅ Step 1: Add the DevTools Dependency

🔄 The Best Feature: Automatic Restart

🧩 How DevTools Restart Works Internally (Simple Explanation)

⚙️ IntelliJ Setting (Important)

🛠️ Useful DevTools Configurations

✅ Disable restart (if needed)

✅ Exclude folders from restart

✅ Poll interval

✅ Quiet period

🚀 Final Thoughts

🚀 My Spring Boot Project Finally Felt Real After Adding Web MVC + JPA

✅ What We Are Setting Up

🧱 Step 1: Create a Spring Boot Project

✅ Add Dependencies

📦 Step 2: Understand Your Dependencies

Spring Web gives you:

Spring Data JPA gives you:

🗂️ Step 3: Follow a Clean Project Structure

Why this matters

🌐 Step 4: Web MVC Setup (Controller Layer)

🗄️ Step 5: JPA Setup (Entity + Repository)

⚙️ Step 6: Configure Database in application.properties

🧠 Step 7: Add Service Layer (Business Logic)

✅ Final Thoughts

🐌 My Spring Boot API Was Fast… Until Relationships Caused N+1 Queries

🧠 FetchType: The Silent Decision Maker

🔥 Two Fetch Strategies in JPA

✅ FetchType.EAGER

✅ FetchType.LAZY

⚠️ The Real Problem: N+1 Queries

What happens in N+1?

💥 Why N+1 Happens So Often

🛠️ How to Fix / Optimize N+1 Queries

🧹 Orphan Removal: Helpful… and Dangerous

✅ orphanRemoval vs Cascade REMOVE (Quick Clarity)

CascadeType.REMOVE

orphanRemoval = true

⚠️ The Mistakes I Made

🚀 Final Thoughts

💀 I Deleted a Parent Entity… and Hibernate Deleted Everything (Cascades Explained)

🧠 What is Cascading in JPA?

🔁 Common Cascade Types (and what they really mean)

✅ CascadeType.PERSIST

✅ CascadeType.MERGE

💀 CascadeType.REMOVE

✅ CascadeType.REFRESH

✅ CascadeType.DETACH

✅ CascadeType.ALL

🧹 The Hidden Killer: orphanRemoval = true

✅ Cascade REMOVE vs orphanRemoval (Important Difference)

CascadeType.REMOVE

orphanRemoval = true

🔥 Why @Transactional Becomes Important in Relational Queries

🧠 What does @Transactional do?

⚠️ What Happens Without @Transactional?

✅ Real-World Scenario: Saving Parent + Children

✅ Final Thoughts

🔗 JPA Relationships Finally Made Sense When I Stopped Memorizing Them

⚙️ Step 6: Configure Database in `application.properties`