EGOR Y.’s Post

𝗢𝗽𝘁𝗶𝗺𝗶𝘇𝗶𝗻𝗴 𝗗𝗮𝘁𝗮 𝗔𝗰𝗰𝗲𝘀𝘀 𝘄𝗶𝘁𝗵 𝗝𝗣𝗔 𝗥𝗲𝗽𝗼𝘀𝗶𝘁𝗼𝗿𝗶𝗲𝘀 & 𝗛𝗶𝗯𝗲𝗿𝗻𝗮𝘁𝗲 𝗖𝗮𝗰𝗵𝗶𝗻𝗴 When working with Spring Data JPA, repositories provide a clean abstraction for database interactions - no need for boilerplate SQL. Hibernate handles the translation to SQL and manages entity state behind the scenes. ⚠️ But abstraction alone doesn’t guarantee performance. Repeated database calls can become a bottleneck. 𝗛𝗶𝗯𝗲𝗿𝗻𝗮𝘁𝗲 𝗖𝗮𝗰𝗵𝗶𝗻𝗴 𝗵𝗲𝗹𝗽𝘀 𝗵𝗲𝗿𝗲: 𝗙𝗶𝗿𝘀𝘁-𝗟𝗲𝘃𝗲𝗹 𝗖𝗮𝗰𝗵𝗲 (𝗟𝟭) • Enabled by default • Per session/transaction • Avoids duplicate queries 𝗦𝗲𝗰𝗼𝗻𝗱-𝗟𝗲𝘃𝗲𝗹 𝗖𝗮𝗰𝗵𝗲 (𝗟𝟮) • Optional • Shared across sessions • Reduces database load 🔄 Flow: Request → L1 → L2 → Database 💡 Key takeaway: • JPA Repositories improve development speed, • Hibernate caching improves performance. • but balance is key to avoid stale data. #Java #SpringBoot #Hibernate #JPA #BackendDevelopment

Most developers use Spring Data JPA… But very few actually understand what happens behind this: userRepository.findByName("Sharief"); No SQL. No JDBC. No boilerplate. But internally 👇 → Spring reads the method name → Creates a proxy implementation → Delegates to Hibernate → Hibernate generates SQL → Database executes it → Result comes back as Java objects 💡 The important truth Spring doesn’t remove SQL. 👉 It writes SQL for you ⚠️ And this matters more than you think If you don’t understand this: →You may write inefficient queries →You may face performance issues →You’ll struggle in debugging 🚀 Final thought Spring Data JPA is powerful… But it’s not magic. Once you understand what’s happening behind the scenes, you start using it with intent, not assumptions. #SpringBoot #Java #BackendDevelopment #JPA #Hibernate

Understanding the N+1 Query Problem in Hibernate While working with ORM frameworks like Hibernate, a common performance issue is the N+1 Query Problem. 📌 What happens? 1 query → Fetch parent data N queries → Fetch related child data Result: ❌ Too many database calls ❌ Slow performance ❌ Increased load on DB 🔹 Example: Fetching a list of Users → and then fetching each User’s Orders separately 🔹 How to solve it? ✔ Use JOIN FETCH ✔ Use Entity Graphs ✔ Use Batch Fetching ✔ Prefer LAZY vs EAGER wisely 📌 Key Insight: Performance issues are not always about code — sometimes they come from how data is fetched. Optimizing database interactions is crucial for scalable backend systems. #Java #Hibernate #JPA #BackendDeveloper #Database #Performance #SoftwareEngineering #TechLearning #Developers #Coding

Ever spent hours chasing down a performance issue in your Spring application, only to realize it’s the classic N+1 problem? For anyone who hasn’t encountered it yet, it typically appears when you fetch a list of entities, and then Hibernate executes an additional query for each related entity. Instead of a single efficient query, you end up with N+1 queries hitting your database.Everything may look fine in development, but under real traffic, the impact becomes obvious. I recently ran into this with a simple parent-child relationship. The code looked clean and straightforward, but once I enabled SQL logging, it became clear that multiple unnecessary queries were being executed behind the scenes. What helped me address it:1- Enabling SQL logs to see what was really happening.2- Using JOIN FETCH in JPQL where appropriate3- Applying @EntityGraph for better control over fetching.4- Being more intentional about lazy versus eager loading. The main takeaway for me was that ORMs simplify development, but they don’t remove the need to understand how queries are executed. #Spring #Springboot #JPA #ORM #Database

Worked on JPA / Hibernate Advanced Mappings today, focusing on real-time entity relationships and database handling. Key things I implemented: • One-to-One mapping (uni-directional & bi-directional) • One-to-Many relationships with proper entity design • Many-to-Many mapping between entities • Configured DAO layer and executed CRUD operations • Understood Fetch Types (Eager vs Lazy loading) • Worked with JOIN FETCH for optimized data retrieval • Implemented cascade operations and delete handling • Performed operations like find, update, and delete across relationships This helped me understand how complex entity relationships are managed efficiently using JPA/Hibernate in real-world applications. 💻🚀

Clean Architecture fixes this permanently. Here's the rule: dependencies point INWARD only. 📦 Domain layer (innermost)   → Pure Java. Zero Spring. Zero DB.   → This is where your business rules live.   → If this layer compiles, your business logic is correct — regardless of framework. ⚙️ Application layer   → @Service classes. Use cases. Orchestration.   → Calls domain objects. Talks to repository interfaces.   → Never talks directly to controllers or DB. 🔌 Infrastructure layer   → @Repository implementations. JPA. External APIs.   → The only layer that knows about Spring Data, Hibernate, or AWS. 🌐 Presentation layer   → @RestController only. Maps HTTP to use cases.   → Converts DTOs. Nothing more. The result? → You can swap your database without touching business logic → You can test domain rules without starting Spring → New teammates understand the codebase in hours, not days This is what I build. Every project. Every time. #CleanArchitecture #Java #SpringBoot #SoftwareDesign #BackendDeveloper #FullStackDeveloper

I recently built nerv-audit, a library on top of Hibernate Envers focused on vertical auditing. Most audit discussions focus on system-wide (horizontal) logs. But in practice, debugging usually comes down to a simpler question: 👉 What exactly changed in this entity? That’s where vertical auditing shines: • Clear, per-entity history • Precise diffs you can actually reason about • Less noise compared to aggregated audit streams • Better alignment with domain-driven design Instead of reconstructing state from a global timeline, you can directly inspect the evolution of a single entity with confidence. GitHub: https://lnkd.in/gSBi_ksN Curious how others approach auditing in their systems — vertical, horizontal, or a mix? #java #springboot #hibernate #ddd #softwareengineering

Your database is not the problem. Your queries are. A slow application doesn't always mean you need a bigger server or a fancier cache. Most of the time, the bottleneck is sitting right there in a query nobody questioned. Spring Boot, or ORMs in general makes data access so easy that it's tempting to just let JPA handle everything. And it will, until it won't. The classic traps: N+1 queries. You fetch a list of 100 orders. Then for each order, JPA quietly fires another query to get the customer. That's 101 queries instead of 1. Feels fine in dev with 10 rows. Falls apart in prod with 100,000. Fetching everything when you need one field. findById() returns the full entity when the screen only needs a name and a date. Multiply that by thousands of requests and you're moving data for no reason. No pagination. findAll() sounds harmless. Until your table hits 2 million rows and you just loaded all of them into memory. Ignoring indexes. A query that runs in 3ms on 1,000 rows runs in 4 seconds on 1,000,000 if the column isn't indexed. The code didn't change. The data did. Use @Query when the query matters. Use projections or DTOs to fetch only what you need. Add @EntityGraph to control fetching explicitly. Paginate by default. And always look at the actual SQL being generated. What Hibernate writes is not always what you'd write. Performance issues are rarely mysterious. They're usually a query doing too much, too often, or too blindly. Read your queries like they cost money. Because in production, they do ! #SpringBoot #Java #DatabasePerformance #BackendDevelopment #SoftwareEngineering #CleanCode #JPA #Hibernate #TechTips #WebDevelopment

Day-5 of 15 #SpringBoot One interface. Zero boilerplate. Full database access. That is Spring Data JPA. JDBC made you write everything manually. Hibernate introduced objects over SQL. JPA standardized the approach. But even then, save, fetch, delete, paginate, you were rewriting the same code in every single project. But wait, what if I say spring Data JPA eliminates that completely. You define an interface, Spring generates the full implementation at runtime. public interface UserRepository extends JpaRepository<User, Long>{ UserfindByEmail(String email); } That single interface gives you save, fetch, search, paginate and delete out of the box. No SQL. No manual wiring. No boilerplate. Spring reads your method names and figures out the query on its own. This is the final form of database interaction in Spring Boot. Stop managing databases. Start building products.

Your API is slow… and it’s likely not your business logic. 🚨 It’s the N+1 query problem. I’ve seen this kill performance in countless Spring Boot applications using JPA. The Anatomy of the Failure: 1️⃣ You fetch a list of 100 Users (1 query). 2️⃣ Your code iterates through them to get their Orders. 3️⃣ JPA triggers a separate fetch for each user. 📉 Result: 101 queries for just 100 records. At scale, this isn't just a "bottleneck"—it's a production outage waiting to happen. Why it happens: JPA defaults to LAZY loading for collections. While this sounds like an optimization, it becomes a "silent killer" when you blindly iterate over those collections in your service or mapping layer. How to fix it (The Pro Way): ✅ JOIN FETCH: Use JPQL to grab everything in a single SQL join. ✅ @EntityGraph: Use a declarative approach to specify which associations to load. ✅ Batch Size: Use hibernate.default_batch_fetch_size to turn $N$ queries into $\frac{N}{batch\_size}$. Performance isn’t about writing "faster" code; it’s about reducing unnecessary work. Have you ever debugged a massive N+1 issue in production? Share your "war stories" below! 👇 #Java #SpringBoot #JPA #Hibernate #Performance #BackendDevelopment #SoftwareEngineering #DatabaseOptimization