Spring Boot @PathVariable vs @RequestParam Usage

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

#Post3 In the previous post, we understood the role of @RestController in building APIs. Now the next step is 👇 How do we map HTTP requests to methods? That’s where mapping annotations come in 🔥 In Spring Boot, we use: • @GetMapping → for GET requests • @PostMapping → for POST requests • @PutMapping → for UPDATE • @DeleteMapping → for DELETE • @PatchMapping → for partial updates Example: @GetMapping("/users") → fetch all users @PostMapping("/users") → create a new user 💡 What about @RequestMapping? @RequestMapping is a generic annotation that can handle all HTTP methods. Example: @RequestMapping(value="/users", method=RequestMethod.GET) 👉 But in modern Spring Boot, we prefer specific annotations like @GetMapping for cleaner and readable code Key takeaway: Use specific mapping annotations for better clarity and maintainability 👍 In the next post, we will understand how @RequestBody works in handling request data 🔥 #Java #SpringBoot #BackendDevelopment #RESTAPI #LearnInPublic

#Post5 In the previous post, we saw how @RequestBody helps us handle request data. Now the next question is 👇 How do we get data from the URL? There are two common ways: • @PathVariable • @RequestParam Let’s understand 👇 👉 @PathVariable Used when the value is part of the URL path Example: GET /users/10 @GetMapping("/users/{id}") public String getUser(@PathVariable int id) { return "User id: " + id; } 👉 @RequestParam Used when the value comes as a query parameter Example: GET /users?id=10 @GetMapping("/users") public String getUser(@RequestParam int id) { return "User id: " + id; } 💡 Key difference: @PathVariable → part of URL @RequestParam → query parameter Key takeaway: Use the right approach based on how data is passed in the request 👍 In the next post, we will explore exception handling in Spring Boot 🔥 #Java #SpringBoot #BackendDevelopment #RESTAPI #LearnInPublic

🧬 Spring Boot – @PathVariable vs @RequestParam Today I learned how to handle data coming through URLs in Spring Boot APIs. 🧠 Key Concepts: ✔️ "@PathVariable" – Used to capture values from the URL path (e.g., "/user/10") ✔️ "@RequestParam" – Used to capture query parameters (e.g., "/search?name=Rony") 💡 Understanding the difference: • PathVariable → for specific resources (like user by ID) • RequestParam → for filtering or searching data 🔁 Real Flow: Frontend → URL → Controller → Extract value → Process → Response 💻 DSA Practice: • Counting vowels in a string • Reversing words in a sentence ✨ Learning how to handle request data effectively is essential for building flexible and scalable REST APIs. #SpringBoot #Java #BackendDevelopment #RESTAPI #WebDevelopment #DSA #LearningInPublic #SoftwareEngineering

Day 28. I fixed the N+1 problem. Or at least… I thought I did. I had this: @Entity public class User {   @OneToMany(mappedBy = "user", fetch = FetchType.LAZY)   private List<Order> orders; } And I was careful. I wasn't using EAGER. I avoided obvious mistakes. Still… something felt off. The API was slow. Query count was high. That's when I checked the logs. And saw this: → 1 query to fetch users → N queries to fetch orders Again. Even after "fixing" it. Here's what was actually happening. I was mapping entities to DTOs like this: users.stream()   .map(user -> new UserDTO(     user.getId(),     user.getName(),     user.getOrders().size()  // 👈 triggers lazy load per user   ))   .toList(); Looks harmless. But user.getOrders() → triggers lazy loading → inside a loop → causing N+1 again That's when it clicked. N+1 isn't just about fetch type. It's about when and where you access relationships. So I changed it. (see implementation below 👇) What I learned: → LAZY doesn't mean safe → DTO mapping can silently trigger queries → N+1 often hides in transformation layers The hard truth: → You think you fixed it → But it comes back in a different place Writing queries is easy. Controlling when data is accessed is what makes your backend scalable. Have you ever fixed N+1… and then seen it come back somewhere else? 👇 Drop your experience #SpringBoot #Java #Hibernate #BackendDevelopment #Performance #JavaDeveloper

Most used Spring Boot annotations (that you’ll see almost everywhere) If you’ve worked with Spring, you already know… half the magic is in annotations 😅 Here are some of the ones I keep using almost daily: * @SpringBootApplication → starting point of the app * @RestController → tells Spring this class handles APIs * @RequestMapping / @GetMapping / @PostMapping → for routing requests * @Autowired → dependency injection (used a lot, sometimes too much 👀) * @Service → business logic layer * @Repository → database layer * @Component → generic bean * @Entity → maps class to DB table * @Id → primary key * @Configuration → for config classes * @Bean → manually define beans when needed When I started, I used to just memorize these. Over time, I realised understanding when NOT to use them is equally important. Like: * overusing @Autowired everywhere * mixing @Component, @Service randomly * not understanding bean lifecycle Spring feels simple at start, but there’s a lot going under the hood. If you’re learning Spring right now → focus less on remembering, more on understanding what each annotation actually does. Which Spring annotation do you use the most? 👇 #ThoughtForTheDay #SpringBoot #Java #Backend #SoftwareEngineering

🚀 Excited to share my latest project — 4mulaQuery! I built a fully functional database engine from scratch — no existing DB libraries used. 🔧 What's under the hood: • Custom C++ storage engine with binary file I/O • Java Spring Boot REST API as the bridge layer • Docker containerized & deployed on Render • Live analytics dashboard with real-time charts • Persistent backend authentication system • ML query logging pipeline (Python + Pandas) 💡 Why I built this: Most developers use databases without understanding how they actually work. I wanted to go deeper — implement binary storage, page management, CRUD from scratch, and expose it all through a clean REST API. 🌐 Live Demo: fourmulaquery.onrender.com 💻 GitHub: https://lnkd.in/gKrjbYGh #OpenSource #Java #CPlusPlus #Docker #SpringBoot #DatabaseEngineering #BuildInPublic

🔍 Since I have plenty of time, I was building a tool that indexes every hardcoded constant in your Java bytecode and config files — and diffs them across versions. Ever had to answer "where is this SQL string used?" or "what changed between our last two releases?" across a large multi-module codebase? That's the problem I set out to solve. Constant Tracker parses JVM class files, classifies constants by semantic type (SQL, URL, logging, file path, error message, annotation), and indexes everything into Solr for full-text search. The version diff feature is my favourite part: upload two finalized JARs and see exactly which constants were added, removed, or changed — per class, with full usage context. Tech: Java 25 · Spring Boot 3 WebFlux · Solr 10 · Redis · Postgres · React 19 · Docker Compose 3-command quickstart with pre-seeded demo data included. 🔗 GitHub: https://lnkd.in/dzqxKGHP #java #springboot #solr #postgres #redis #react #githubcopilot

🚨 𝗬𝗼𝘂𝗿 𝗦𝗽𝗿𝗶𝗻𝗴 𝗕𝗼𝗼𝘁 𝗔𝗽𝗽 𝗜𝘀 𝗤𝘂𝗶𝗲𝘁𝗹𝘆 𝗕𝘂𝗿𝗻𝗶𝗻𝗴 𝗤𝘂𝗲𝗿𝗶𝗲𝘀 🤯 Most developers use @𝗙𝗼𝗿𝗺𝘂𝗹𝗮 and @𝗘𝗻𝘁𝗶𝘁𝘆𝗚𝗿𝗮𝗽𝗵 interchangeably. That one mistake can turn a 1-query operation into 1,001. 𝗪𝗵𝗮𝘁'𝘀 𝗮𝗰𝘁𝘂𝗮𝗹𝗹𝘆 𝗵𝗮𝗽𝗽𝗲𝗻𝗶𝗻𝗴 𝘂𝗻𝗱𝗲𝗿 𝘁𝗵𝗲 𝗵𝗼𝗼𝗱? @Formula looks innocent: @𝙁𝙤𝙧𝙢𝙪𝙡𝙖("(𝙎𝙀𝙇𝙀𝘾𝙏 𝘾𝙊𝙐𝙉𝙏(*) 𝙁𝙍𝙊𝙈 𝙤𝙧𝙙𝙚𝙧𝙨 𝙤 𝙒𝙃𝙀𝙍𝙀 𝙤.𝙘𝙪𝙨𝙩𝙤𝙢𝙚𝙧_𝙞𝙙 = 𝙞𝙙)") 𝙥𝙧𝙞𝙫𝙖𝙩𝙚 𝙇𝙤𝙣𝙜 𝙤𝙧𝙙𝙚𝙧𝘾𝙤𝙪𝙣𝙩; But Hibernate fires a separate subquery for every row fetched. 500 customers → 500 extra DB hits. That's the 𝗡+𝟭 problem wearing a clean disguise. @𝗘𝗻𝘁𝗶𝘁𝘆𝗚𝗿𝗮𝗽𝗵 𝗱𝗼𝗲𝘀 𝗶𝘁 𝗿𝗶𝗴𝗵𝘁: @𝙀𝙣𝙩𝙞𝙩𝙮𝙂𝙧𝙖𝙥𝙝(𝙖𝙩𝙩𝙧𝙞𝙗𝙪𝙩𝙚𝙋𝙖𝙩𝙝𝙨 = {"𝙤𝙧𝙙𝙚𝙧𝙨", "𝙖𝙙𝙙𝙧𝙚𝙨𝙨"}) 𝙇𝙞𝙨𝙩<𝘾𝙪𝙨𝙩𝙤𝙢𝙚𝙧> 𝙛𝙞𝙣𝙙𝘼𝙡𝙡𝙒𝙞𝙩𝙝𝙊𝙧𝙙𝙚𝙧𝙨(); One JOIN. All related data. Done. The real-world gap Same 500 products, with category + supplier associations: ❌ Wrong fetch strategy → 1,001 queries ✅ @EntityGraph → 1 query Same data. P99 latency going from 80ms to 4 seconds. In production. 𝗪𝗵𝗲𝗻 𝘁𝗼 𝘂𝘀𝗲 𝘄𝗵𝗶𝗰𝗵  • ScenarioUseComputed value (count, sum) ->@Formula  • Fetching related entities -> @EntityGraph  • Sort/filter by derived column -> @Formula  • Avoiding lazy loading on APIs -> @EntityGraph One question cuts through the confusion every time: "Am I computing something, or loading something?" They're not competing tools — they solve different problems. The mistake is reaching for @𝗙𝗼𝗿𝗺𝘂𝗹𝗮 where a JOIN belongs. Most Spring Boot performance issues I've seen weren't bad logic. They were the wrong fetch strategy in the right place. Have you hit this in production? Drop it in the comments 👇 #Java #SpringBoot #Programming #SoftwareEngineering #SoftwareDevelopment #JPA #Hibernate #BackendDevelopment #BackendEngineering #APIDesign #SystemDesign #PerformanceOptimization #CleanCode #CodeQuality #TechDebt #TechCommunity #100DaysOfCode #LearnToCode #Developer #CodingLife

🚀 Day 3/30 – Spring Boot Journey Today I explored @Component, @Service, and @Repository in Spring Boot. 🔹 @Component → Creates Spring Bean automatically 🔹 @Service → Used for business logic layer 🔹 @Repository → Handles database operations + exception handling 💡 Key Learning: All these annotations are special types of @Component, but using them properly improves code structure, readability, and follows clean architecture. Also understood how these layers work together: 👉 Controller → Service → Repository This made Dependency Injection much clearer! #SpringBoot #Java #BackendDeveloper #Learning #Microservices #100DaysOfCode