Gabriel Glodean’s Post

Excited to share Querier, our new open-source Java project for type-safe SQL building. If you work with Java and SQL, you know how quickly queries can become hard to read, hard to maintain, and even harder to refactor safely. Querier is designed to make that experience cleaner by helping you build SQL in a way that is more expressive, safer, and easier to evolve. Query execution agnostic, Querier can be used with most Java DB frameworks such as: Spring JDBC, Hibernate native query, jOOQ, R2DBC, Vert.x SQL... We built this project to make SQL feel more natural in Java while keeping type safety front and center. Check it out on GitHub: https://lnkd.in/duBA-X3x Project page: https://lnkd.in/dkNFKnsm #Java #OpenSource #SQL #SoftwareEngineering #BackendDevelopment #GitHub

Spring Boot's OSIV default turns your JSON serializer into a hidden query engine I'm building a personal finance platform with Spring Boot 3.5 + Java 21. The first thing I disabled was Open Session in View. Spring Boot ships with spring.jpa.open-in-view=true. That means Hibernate keeps a database connection open through the entire HTTP request - including JSON serialization. When Jackson walks your entity graph to build a response, every uninitialized lazy relationship triggers a database query. Your serializer is now executing SQL. In a load test with HikariCP's default pool of 10 connections and around 150 concurrent requests, this is where things break. Each request holds a connection for the full request lifecycle instead of just the service layer. The pool exhausts, threads queue up, and response times spike. The tricky part is that it works fine in dev when you're the only user. Disabling OSIV forces you to think about what data you actually need. You fetch it explicitly in the service layer with JOIN FETCH or projections, map it to a DTO, and the connection goes back to the pool before serialization even starts. It's more code upfront but the data flow becomes visible instead of hidden behind proxy magic. The second thing I changed was ddl-auto. Hibernate's update mode can generate schema changes automatically, but it can't rename columns, drop unused indexes, or migrate data. It produces a schema that looks right but drifts from what you intended. I use validate with Flyway migrations instead - every schema change is an explicit, versioned SQL file. If the code and the database disagree, the app refuses to start rather than silently diverging. These two defaults share the same problem. They hide complexity that surfaces as production issues. OSIV hides query execution. ddl-auto update hides schema drift. In both cases, making the behavior explicit costs more effort early but removes an entire class of debugging later. #SpringBoot #Java #BuildInPublic #BackendDevelopment

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

🚀 Day 7/45 – Backend Engineering (JPA & Hibernate) Most performance issues in backend apps don’t come from logic — they come from how data is fetched from the database. Today I focused on one of the most common JPA pitfalls: ❗ The N+1 Query Problem 💡 What happens: You fetch a list of entities (1 query) For each entity, JPA triggers another query for related data Result → 1 + N queries 👉 This can silently kill performance in production. 🔍 Example: Fetching a list of users and their orders: 1 query for users N queries for orders ❌ 🔧 Fix: Use JOIN FETCH Use Entity Graphs Choose fetch type wisely (LAZY vs EAGER) 🛠 Practical: Tested API behavior with lazy loading and saw how queries multiplied without optimization. 📌 Real-world impact: Ignoring this leads to: Slow APIs High DB load Poor scalability 🔥 Takeaway: ORMs don’t guarantee performance. You must understand what queries are actually being executed. Currently building a production-ready backend system — sharing real backend lessons daily. https://lnkd.in/gJqEuQQs #Java #SpringBoot #Hibernate #BackendDevelopment #Performance #LearningInPublic

Was working on a Spring Boot REST API the other day. Everything looked fine entity class, repository, controller all set up. But two fields, createdAt and updatedAt, were coming back null in every response. Spent time checking the constructor, the DTO mapping, the database config. Turns out I just needed two annotations: @CreationTimestamp → auto-sets the time when record is created @UpdateTimestamp → auto-updates the time on every save Two lines. That's it. Hibernate handles everything behind the scenes you don't set these manually. One more thing I'd missed without @JsonFormat, Java's Timestamp serializes weirdly in JSON. Add this and it formats cleanly: @JsonFormat(pattern = "yyyy-MM-dd HH:mm:ss") Small things. But they'll silently break your API if you miss them. #Java #SpringBoot #Backend #LearningInPublic #HibernateJPA

Day 20: 🧑💻 Read Replicas - Scale Reads Horizontally, Free the Primary (Java + Spring Boot) What Are Read Replicas? Read Replicas are copies of your primary database that continuously receive updates via replication (WAL streaming / binary log). All writes go to the primary; reads are distributed across replicas — offloading the primary and enabling horizontal read scale. Without Replicas:  All traffic → Single Primary  90% reads + 10% writes fighting for same connections  Primary saturates → everything slows down With Read Replicas:  Writes → Primary only  Reads → Replica 1, Replica 2, Replica 3 (load balanced)  Primary free for writes → faster writes  Add replicas = scale reads linearly Key Takeaways — Plain English :   1. Read Replicas = copies of primary — receive updates via replication 2. All writes → Primary — replicas are read-only 3. All reads → Replicas — offloads primary, enables horizontal scale 4. readOnly=true = Spring routes automatically to replica via AbstractRoutingDataSource 5. Replica lag= milliseconds behind primary — eventual consistency 6. Read-after-write = don't write then immediately read from replica 7. Failover = if primary fails, promote replica (RDS/Aurora does this automatically) 8. Monitor lag = SELECT EXTRACT(EPOCH FROM now()-pg_last_xact_replay_timestamp()); 9. Rule: every SELECT-only method should have @Transactional(readOnly=true) — no exceptions #SystemDesign #ReadReplicas #Database #PostgreSQL #SpringBoot #Java #Microservices 

Your Spring Boot API is slow. Not because of bad code. Because of invisible garbage. A simple request like GET /api/users/123 looks harmless. But Spring Boot creates a storm of temporary objects you never see: → Tomcat builds request/response objects → Spring Security creates SecurityContext → Filters wrap everything in decorators → Hibernate creates lazy-load proxies → Dirty checking snapshots entity state → Jackson builds serialization objects → @Transactional wraps services in proxies You wrote 15 lines. The framework created thousands of objects. At 100 RPS? Fine. At 1,000 RPS? Disaster. Young Gen fills every second GC runs constantly p99 latency spikes CPU burns on cleanup, not business logic No crash. No exception. Just mysteriously slow performance. ━━━━━━━━━━━━━━━━ How I reduce object creation: Return DTOs, not entities Use @Transactional(readOnly = true) for reads Use log placeholders: log.info("User {}", id) Prefer primitives (int vs Integer) in hot paths Avoid streams/maps in performance-critical loops Tune JVM Young Gen size Profile with Java Flight Recorder ━━━━━━━━━━━━━━━━ The real performance truth: The fastest code isn't code that executes the fastest. It's code that creates the least garbage. Master this, and your APIs will scale. What's your go-to optimization for high-traffic Spring Boot apps? #SpringBoot #Java #Microservices #BackendDevelopment #SoftwareArchitecture

Day 3 – Tech Stack Tech Stack used in my project: Java Spring Boot Spring Data JPA MySQL REST APIs Focused on building a scalable backend system. #TechStack #Backend

I wrote "Clean Code" that silently killed our database performance. 📉🐢 It worked perfectly on my local machine. The tests passed. The UI was fast. But as soon as we hit 50 concurrent users in staging, the database CPU spiked to 90%. The Mistake: I was fetching a list of Orders, and for each order, I was calling order.getUser().getName(). In my head, it was one simple query. In reality, Spring was executing: 👉 1 query to get all Orders. 👉 100 extra queries to get each User. This is the classic N+1 Problem, and in a microservices environment, it’s a death sentence for your latency. The 2026 Solution (My Fix): Instead of a basic.findAll(), I moved to a custom @Query with a JOIN FETCH. java @Query("SELECT o FROM Order o JOIN FETCH o.user") List<Order> findAllWithUsers(); Use the code with caution. The Result? One single, efficient query. Database CPU dropped back to 10%. API response time cut by 70%. Lesson Learned: Don't just trust the "magic" of JPA. Always check your logs to see what Hibernate is actually doing behind the scenes. Have you ever been surprised by a "hidden" query? What’s your go-to tool for monitoring SQL in Spring Boot? 👇 #SpringBoot #JavaDeveloper #BackendEngineering #PerformanceOptimization #LearningInPublic #AhmedabadTech #CleanCode #Database

We've been building something quietly for a while, and I'm ready to share it. OpenTaint is an open-source taint analysis engine with the most thorough Spring Boot support. https://lnkd.in/darQ5ZRN Not "Java support." Actual modeling of how Spring works. Spring Boot's annotation-driven architecture creates data flows that are invisible to conventional static analysis. A bean injection crosses class boundaries with no call site in the source. JPA persistence links two HTTP endpoints through the database with no shared code path. A Freemarker configuration object determines whether user input reaching template.process() is exploitable — or harmless. These are not edge cases. This is the default architecture of most Java web applications. OpenTaint traces tainted data through every layer: - Following data across file and class boundaries — through DTO field access and method chains. - Resolving configuration-aware sinks — tracing through DI to determine whether a resolver or handler is actually exploitable. - Connecting endpoints through persistence — where the database or service state is the only link. - Distinguishing dangerous fields from safe ones — at per-column granularity within those flows. The engine operates on bytecode, resolves virtual dispatch, and maps every finding back to its HTTP endpoint. If you're using Semgrep or CodeQL on your Java/Kotlin/Spring codebase — try OpenTaint on the same project and compare what it finds. We've published reproducible comparisons on the blog, but seeing it on your own code is more convincing. Apache 2.0 + MIT. Engine, rules, CLI, GitHub Action, GitLab CI — everything is open source. #java #kotlin #spring #springboot #security #appsec #opensource #sast #taintanalysis