Rishikesh Jadhav’s Post

N+1 Query Problem (Hibernate / JPA) Your Spring Boot app is fast… until it hits the database. Then suddenly: 👉 1 query becomes 101 👉 and your API dies under load I saw this in a production audit last week. // ❌ Looks harmless List<User> users = userRepository.findAll(); for (User user : users) { System.out.println(user.getOrders().size()); } 🚨 What actually happens: • 1 query to fetch users • +1 query PER user to fetch orders 👉 This is called the N+1 problem 💥 Real production impact: • DB overload • Massive latency increase • Works in dev… crashes in prod ⚠️ Important nuance (don’t get roasted in comments 😄) This happens when: 👉 @OneToMany(fetch = LAZY) (default) If it's EAGER, behavior changes (but creates other problems) ✅ Fix: // ✔️ Use fetch join @Query("SELECT u FROM User u JOIN FETCH u.orders") List<User> findAllWithOrders(); OR // ✔️ Use EntityGraph @EntityGraph(attributePaths = "orders") List<User> findAll(); 🧠 Takeaway: If you don’t control your queries… your database will control you. Are you sure your app isn’t doing 100 hidden queries right now? #JavaDev #SpringBoot #Hibernate #JavaPerformance #Backend #SoftwareEngineering

Most slow Spring Boot apps have the same problem. It's not the database. It's how you ask it. After years debugging production performance, I see the same pattern over and over: The N+1 query problem. You fetch a list of orders. Looks fine. Then you loop through them and access order.getCustomer(). Hibernate happily fires one extra query per order. 100 orders → 101 queries. Your endpoint goes from 50ms to 4 seconds. Your database CPU climbs. Nobody understands why. The trap is that the code looks clean. Lazy loading is doing exactly what it said it would. The framework isn't broken. The mental model is. What actually fixes it: - JOIN FETCH for predictable, single-use queries - @EntityGraph for reusable fetch plans - Batch fetching (hibernate.default_batch_fetch_size) when you need lazy but not crazy - DTO projections when you don't need the full entity at all ⚠️ The mistake most teams make is enabling spring.jpa.show-sql=true, seeing 5 queries per request, and shrugging. Five becomes fifty under load. Fifty becomes the incident. The fix is not "tune the database." The fix is reading what your ORM is actually doing. Hibernate is not slow. Most Hibernate code is. What's the worst N+1 you've seen in production? #Java #SpringBoot #Backend #Hibernate #Performance #SoftwareEngineering

Real world projects in production... At Architectural level - Java (Spring boot) 1) AOP implementation 2) Cache management 3) Interceptor 4) Global exception handling 5) Thread management 6) database integration 7) Microservices communication At Architectural level - Angular 1) Microfrontend communication. (using Module federation) 2) shared library to share components , directives between different microfrontends. 3) proxy file (CORS) to connect with backend (Java) 4) Generic components 5) cache management 6) Prevention from different attacks like... XSRF, XSS etc. At service level (Java): 1) Always use Composition over inheritance 2) Validations like @notnull, @notEmpty etc.. 3) use of var keyword 4) memeory leak prevention through weakHashMap 5) MVC: creating a controller , model, repository and service file. 6) use of virtual threads for multi-Threaded Environment. 7) Use of signals instead of traditional approach of for loop iterations. At Component Level (Angular) 1) creating directives and pipes. 2) use of scss for styling different components 3) use of structural directives @If, @for track: trackId 4) use of @defer for lazy loading of components 5) routing file for different routes let say /home, /dashboard, /user/:id etc... 6) standalone components 7) Use of Signals for forms and reactive programming 8) Interpolation 9) two way binding through ngModel Integration of frontend and backend and database is done with 1) At frontend (Angular) , field--> target: 'http://localhost:8080' in proxy.json file. (let's say your backend Java is running on localhost:8080) 2) At backend (Java) , application.properties file has i) base URL /api (org/system name), ii) server.port=8080 iii) database url: spring.datasource.url=jdbc:mysql://localhost:3306/your_db_name (let's say mySQL is running on localhost:3306.) Hope this helps! 😊 #architecture #angular #integration #realworldprojects #productionscale #java #springboot #javafullstack #springboot #mysql #latestfeatures

Day 60 – Image Upload & Storage in Backend (Spring Boot + React) Today I learned how images are uploaded from the client (React) to the server (Spring Boot) and stored in the database. On the frontend, I used FormData with Axios to send both product details and an image file in a single request using "multipart/form-data". The product data is converted into JSON and wrapped inside a Blob, while the image is sent as binary data. On the backend, I used "@RequestPart" to receive both the JSON object and the image file. Spring Boot automatically splits the multipart request and converts: - JSON → Java object (Product) - File → MultipartFile In the service layer, I extracted image details such as name, type, and binary data using: - "getOriginalFilename()" - "getContentType()" - "getBytes()" The image is then stored in the database as a byte array ("byte[]") using the "@Lob" annotation, which maps to a BLOB (Binary Large Object). This helped me understand the complete flow of file handling: Client → FormData → Axios → Spring Boot → Multipart parsing → byte[] conversion → Database storage. I also learned the importance of: - Matching request part names between frontend and backend - Using "consumes = multipart/form-data" - Using "@RequestPart" instead of "@RequestBody" for file uploads This is a key concept for building real-world applications like e-commerce platforms where images are an essential part of data.

Most Spring Boot apps don’t have performance problems… They have invisible problems 🔴 Built with Spring Boot + Hibernate, everything looks clean: ✔️ Controllers ✔️ Services ✔️ Repositories But behind the scenes: → 1 API call → 30+ queries → Duplicate executions → N+1 issues And you don’t notice… until production slows down. 📉 So I built something to expose it. 🛡️ Query Guard A Spring Boot starter that shows exactly what your database is doing per request. What it gives you: → Detects N+1 queries → Finds duplicate queries → Shows query execution flow (like tracing) → Works out-of-the-box with Prometheus + Grafana + Loki ⚡ Quick facts: ✅ Published on Maven Central ⚙️ Works with Spring Boot 3 & 4 🔌 Plug & play (no code changes) 📎 Inbuilt Dashboard & Query Explorer 🧪 I have built a demo app With intentional: → N+1 issues → Duplicate queries 👉 So you can see the problem, not just read about it Demo: https://lnkd.in/gvtAnPHw Starter: https://lnkd.in/gC5hKjg3 Most tools tell you: ❌ “Your API is slow” This tells you: ✅ Why ✅ Where ✅ How often Would love your feedbacks... #SpringBoot #Java #Backend #Performance #Hibernate #OpenSource #PoojithaIrosha

Understanding #SpringBoot Flow Architecture If you are diving into backend development with Java, understanding how data flows through a Spring Boot application is a game-changer. I found this great visual that simplifies the entire process. Here is a quick breakdown of how a request actually travels through the system: 1. The #Client (The Start) Everything begins with the Client (like a web browser or a mobile app) sending an HTTPS Request. This could be anything from logging in to fetching a list of products. 2. The #Controller (The Gatekeeper) The request first hits the Controller. Think of this as the front desk. It handles the incoming request, decides where it needs to go, and sends back the final response to the user. 3. The #Service Layer (The Brain) The Controller passes the job to the Service Layer. This is where the "magic" happens—all the business logic, calculations, and rules are kept here. Pro Tip: This layer uses Dependency Injection to pull in the Repository it needs to talk to the database. 4. The #Repository & Model (The Data Handlers) Repository: This class extends CRUD services, allowing the app to Create, Read, Update, or Delete data without writing complex SQL every time. Model: This represents the structure of your data (like a "User" or "Product" object). 5. #Database (The Memory) Finally, using JPA / Spring Data, the application communicates with the Database to store or retrieve the information requested by the client. #SpringBoot #Java #Spring #SpringSecurity #SystemDesign #Backend

Day 20. I stopped using `FetchType.EAGER`. Not because it’s wrong. Because it was silently killing my API. I used to write this: @OneToMany(fetch = FetchType.EAGER) private List<Order> orders; It worked. Until it didn’t. Every time I fetched a User, Hibernate also fetched ALL their orders. Didn’t matter if I needed them or not. One user → dozens of records 100 users → hundreds of queries Production → slow API That’s when it clicked. EAGER loading is convenient. But it’s expensive. And you don’t see the cost until it’s too late. So I changed it. (see implementation below 👇) @OneToMany(fetch = FetchType.LAZY) private List<Order> orders; Now data loads only when I ask for it. What I learned: → EAGER loads everything — even when you don’t need it → LAZY gives you control → Defaults are not always the right choice The hard truth: → Most developers use EAGER without thinking → It works fine in small data → It breaks under real load Using EAGER is easy. Controlling what your database loads is what makes you a backend developer. Are you still using `FetchType.EAGER`? 👇 Drop it below #SpringBoot #Java #Hibernate #BackendDevelopment #JavaDeveloper

🚀 Excited to share my latest project! I built and deployed a Full Stack Task Manager Web Application using Spring Boot, Thymeleaf, and POSTGRESQL Database. 🔧 Key Features: • Add, Edit, Delete, and Complete Tasks • Priority and Due Date Management • Interactive Dashboard with Charts 📊 • Clean and Responsive UI • Real-time database integration using JPA & Hibernate • Deployed live on cloud ☁️ 🌐 Live App: https://lnkd.in/d_FS7qw6 💻 GitHub: https://lnkd.in/dSUWwxxg This project helped me understand backend development, database handling, debugging real-world issues, and deployment. I’m continuously learning and working towards becoming an AI-enabled Full Stack Java Developer 🚀 Would love your feedback and suggestions! hashtag #Java hashtag #SpringBoot hashtag #FullStack hashtag #WebDevelopment hashtag #LearningByDoing hashtag #StudentDeveloper

🚀 Improving SQL Performance in Spring Boot Applications While working on a backend system, I noticed some APIs were taking longer than expected to respond. After analysis, the issue was inefficient SQL queries. Here’s what I did to optimize performance: 🔍 Identified Slow Queries Used logs and query analysis to find bottlenecks ⚡ Applied Indexing Added indexes on frequently queried columns, which significantly reduced query execution time 🔄 Optimized Hibernate Usage Reduced unnecessary joins Used lazy loading where required Avoided N+1 query problem 📉 Result Improved API response time and reduced database load 💡 Key Learning: Even a well-written application can perform poorly if database queries are not optimized. ⚙️ Tech Used: Java, Spring Boot, Hibernate, SQL If you're facing performance issues, start by analyzing your queries—you might find quick wins there. #Java #SpringBoot #SQL #PerformanceTuning #Backend #Hibernate