Allan Roberto’s Post

When building APIs in Spring Boot, you’ll see multiple mapping annotations. But what’s the difference? @RequestMapping → Generic mapping (can handle all HTTP methods) @GetMapping → Used for GET requests (fetch data) @PostMapping → Used for POST requests (create data) Example: @RestController @RequestMapping("/users") public class UserController { @GetMapping public List<String> getUsers() { return List.of("A", "B"); } @PostMapping public String createUser() { return "User created"; } } Modern Spring Boot prefers specific annotations like @GetMapping for clarity. Rule of thumb: GET → Read POST → Create PUT → Update DELETE → Remove Next post: What is @PathVariable and @RequestParam #Java #SpringBoot #APIDevelopment #BackendDevelopment

Spring Boot handles your REST APIs. Spring Security locks them down. Spring Data talks to any database. Thymeleaf + HTMX covers your UI. Testcontainers tests the real thing. GraalVM compiles it all to a native binary. One language. One ecosystem. Zero context switching. While everyone's juggling 5 frameworks across 3 languages, Java developers ship end-to-end features without leaving their IDE. Stop sleeping on the stack that runs half the world's enterprise software. #Java #SpringBoot #FullStackDevelopment #SoftwareEngineering #BackendDevelopment

Something I still find fascinating about Spring Boot. You write a simple controller like this: @RestController public class UserController { @GetMapping("/users") public List<User> getUsers() { return service.getUsers(); } } Looks simple. But when a request hits this endpoint, a lot happens behind the scenes: • Tomcat accepts the HTTP request • Spring DispatcherServlet receives it • HandlerMapping finds the correct controller • Argument resolvers prepare method parameters • The method executes • Jackson converts the response into JSON All of that… just to return a list of users. Frameworks like Spring Boot hide an incredible amount of complexity so developers can focus on business logic. Sometimes it's worth pausing and appreciating how much engineering is happening behind one simple endpoint. #Java #SpringBoot #BackendDevelopment #SoftwareEngineering

Hi everyone 👋 📌 Spring Boot Annotation Series Part 22– @RequestParam @RequestParam is used to read query parameters from the request URL and bind them to method parameters. It is part of the Spring Framework and commonly used in REST APIs built with Spring Boot. 🔹 Why do we use @RequestParam? Sometimes we need to pass additional information through the URL. Example: GET /users?age=25 Here, age is a query parameter. @RequestParam helps us capture that value in the controller method. 🔹 Simple Example @RestController @RequestMapping("/users") public class UserController { @GetMapping("/search") public String getUserByAge(@RequestParam int age) { return "User age is: " + age; } } 👉 Request URL: GET http://localhost:8080/users/search?age=25 Output: User age is: 25 🔹 In Simple Words @RequestParam takes values from query parameters in the URL and passes them to the controller method. 👉 🧠 Quick Understanding Used in filtering, search APIs Can be optional using required=false Can provide default values Used to read query parameters from URL Mostly used in GET APIs #SpringBoot #Java #RESTAPI #RequestParam #BackendDevelopment #LearningInPublic

Spent 30 minutes wondering why my Spring Boot @Transactional annotation was not rolling back on exceptions. The code looked fine: @Transactional public void processOrder(Order order) {   orderRepository.save(order);   paymentService.charge(order); // throws exception } An exception was thrown. But the order was still saved in the database. The problem: @Transactional only rolls back on unchecked exceptions (RuntimeException) by default. The payment service was throwing a checked exception. The fix: @Transactional(rollbackFor = Exception.class) public void processOrder(Order order) {   orderRepository.save(order);   paymentService.charge(order); } One attribute. That was it. Spring does not warn you when checked exceptions bypass rollback. It just commits the transaction anyway. What @Transactional behavior has surprised you? #Java #SpringBoot #Debugging #BackendDevelopment

🔥 Your Spring Boot app is only as fast as the engine underneath it. Most developers talk about controllers. Few talk about the embedded server. 🧵 Tomcat vs Netty in Spring Boot, so what really changes? Let’s break it down 👇 1. 🐱 Tomcat (Default in Spring Boot) Tomcat is: ✔️ Servlet-based ✔️ Thread-per-request model ✔️ Mature and battle-tested ✔️ Great for traditional MVC apps How it works: Each incoming request ➡️ Gets a dedicated thread ➡️ Processes ➡️ Returns response Simple. Predictable. Stable. But under massive concurrency? • Threads consume memory. • Context switching increases. • Blocking I/O limits scalability. 2.⚡ Netty (Used in Spring WebFlux) Netty is: ✔️ Event-driven ✔️ Non-blocking ✔️ Built on async I/O ✔️ High concurrency optimized How it works: Few event-loop threads ➡️ Handle thousands of connections ➡️ Process events asynchronously ➡️ No thread-per-request model 🧠 The Real Difference 🐱Tomcat = Blocking model ⚡ Netty = Non-blocking event loop model Tomcat scales with threads. Netty scales with events. One scales vertically. The other scales with concurrency efficiency. 📊 When to Choose What? 🟢 Choose Tomcat if: • You build traditional REST APIs • You rely on blocking libraries (JPA, JDBC) • You prefer simplicity ⚡ Choose Netty if: • You build high-throughput APIs • You need WebSockets or streaming • You operate at very high concurrency • You use reactive stack end-to-end 🚀 Final Thought: Tomcat is stable horsepower while Netty is concurrency efficiency. The right choice depends on your workload, not hype. Are you running Tomcat or Netty in production? 👇 #SpringBoot #Java #BackendEngineering #SystemDesign #WebFlux #Microservices

🚀 Day 25 & 26 — Backend Debugging, Optimization & Documentation Focused on improving the quality of my Spring Boot Job Portal backend beyond just “working code”. 🔐 Auth & Security Fixes: • Fixed JWT handling — invalid/expired tokens now return proper 401 instead of 500 • Removed redundant DB query during login using authenticate.getPrincipal() • Standardized constructor-based dependency injection ⚡ Performance Improvements: • Eliminated double DB lookups using optimized repository methods (JOIN-based queries) • Fixed N+1 query issue using JOIN FETCH • Added @Transactional(readOnly = true) for better Hibernate performance 🛡️ Logic & Stability Fixes: • Prevented unintended reset of employer verification • Handled null cases using Optional (avoided runtime crashes) ⚠️ Error Handling Overhaul: Implemented GlobalExceptionHandler with proper mappings: • 404 → Resource not found • 401 → Unauthorized • 403 → Access denied • 409 → Conflict • 500 → Only for unexpected errors 📄 Day 26 — Documentation Upgrade: • Improved README with API endpoints • Added setup & deployment instructions • Documented architecture & authentication flow 💡 Key Learning: A good backend is not just about building features — it’s about handling edge cases, optimizing performance, and writing clean, maintainable code. #SpringBoot #Java #BackendDevelopment #100DaysOfCode #LearningInPublic

🚀 Spring Boot Series #003 Spring vs. Spring Boot: Why pick one when you can have both? 🍃👢 The most common interview question for Java devs: "What is the actual difference?" Think of it like this: 🛠️ Spring Framework is the massive toolbox. It gives you every tool imaginable (Dependency Injection, Data Access and many more), but you have to set up the workbench, the lighting, and the instructions. 🚀 Spring Boot is the pre-assembled, turbo-charged factory. It uses the Spring toolbox but handles the setup for you with opinionated defaults. In short: Spring: Total control, but manual configuration (XML/Java Config) and external servers (Tomcat). Spring Boot: Auto-configuration, "Starter" dependencies, and embedded servers. The Verdict: Spring is the engine. Spring Boot is the car that’s already running and ready for a road trip. "We all love Spring Boot's speed, but what’s the biggest 'Auto-Configuration' nightmare you’ve ever had to debug? 🛠️👇" #Spring #SpringBoot #Java #BackendDevelopment #SpringbootwithVC

Most Spring Boot apps I review have the same problems. Not complex architecture issues. Basic mistakes that compound over time and make the codebase painful to work with. Here are 7 that come up again and again: 1. Field injection instead of constructor injection 2. Business logic stuffed inside controllers 3. Try-catch scattered everywhere instead of a global exception handler 4. No database indexes on filtered columns 5. Hardcoded config values baked into the code 6. One config file for all environments 7. Unit tests only, no integration tests The fix for each one takes less than 30 minutes. The cost of ignoring them shows up months later when onboarding slows down, bugs slip through, and deployments break. Which of these have you seen in production code? Follow Amigoscode for more Spring Boot and Java content. #Java #SpringBoot #SoftwareDevelopment

which is the one you hate the most? Mine is try-catch everywhere and unit test only on database access heavy apps. I have to add another one though: Returning Response objects in controller instead of POJOs... which is a direct consequence of not using a global exception handler. Less code => less code to worry about!