Spring Boot Logging from Zero to Production

💡 The file upload mistake that would've haunted me in production storing a full URL in your database is a trap. https://lnkd.in/getwKNqc — looks fine. works fine. until you switch storage providers and realize you now have 50,000 rows to update in production. Took me an embarrassing amount of time to figure out the right way: store only the key → users/abc123.jpg keep the base URL in your config combine them at runtime when building responses One env variable change. entire system migrated. database never stores a domain name again. That was just one of three things I got wrong building file uploads this week. The second one: skipping compression. a user uploads a 4MB phone photo, you store a 4MB phone photo. your storage bill is quiet now. it won't be later. compress before upload, not after. a 3MB image should leave your server under 150KB. The third: public storage buckets. if your file URL works forever with no auth, that's not a feature. generate signed URLs with expiry instead. 10 extra lines of code, one less thing to regret. File uploads feel like a solved problem until you actually build one properly. #Java #SpringBoot #BackendDev

🚀 Day 19/100: Spring Boot From Zero to Production Topic: Disabling Auto Configuration Quick Recap previously we covered Auto Configuration in Spring Boot. (Link to that post in the comments 👇) The Problem: Auto Configuration is magical. But magic shouldn't cage you. Sometimes you need to go beyond the defaults. Sometimes a specific auto config just gets in your way. So the question is.... does Spring Boot let you opt out? Absolutely. And it's dead simple. ✅ How to Disable Auto Configuration: Just add an exclude to your @SpringBootApplication annotation: @SpringBootApplication(exclude = DataSourceAutoConfiguration.class) public class MunasibApplication{ public static void main(String[] args) { SpringApplication.run(MyApp.class, args); } } That's it. One line. No database auto-wiring. Done. Not Just DataSource You're not limited to one config. Exclude multiple auto configurations at once Works with any AutoConfiguration class Spring Boot ships @SpringBootApplication(exclude = { DataSourceAutoConfiguration.class, SecurityAutoConfiguration.class }) Alternative: Use application.properties Don't want to touch your code? spring.autoconfigure.exclude=\org.springframework.boot.autoconfigure.jdbc.DataSourceAutoConfiguration Same result. Zero code change. 🎯 Why This Matters Spring Boot gives you sensible defaults. But it never forces them on you. That's what makes it a great framework, not just smart, but flexible. #Java #SpringBoot #SoftwareDevelopment #100DaysOfCode #AutoConfiguration

Spring Boot in Real Projects — Day 19 We already know how APIs return data. But what happens when your application grows and starts handling hundreds or even thousands of tasks daily whether from a single user or many users? For example: User1 → 50 tasks   User2 → 120 tasks   User3 → 300 tasks   It's simple to fetch data for user-1 and next user-2 with 120 tasks gets heavy to fetch and for the next user-3 its hard to fetch and the API response may gets slow, to solve this Pagination & Sorting come in What is Pagination? Pagination is the process of dividing data into smaller chunks (pages) and fetching only the required portion instead of loading everything at once. What is Sorting? Sorting allows us to order data based on a specific field like createdAt, title, etc. Flow Client → Controller → Pageable → Repository → Database (applies LIMIT, OFFSET, ORDER BY) → Returns Page → Response to Client #SpringBoot #Java #BackendDevelopment #Pagination #APIDesign #SoftwareEngineering

#Post8 In the previous post, we learned how to create custom exceptions. Now the next question is 👇 How do we validate incoming request data? That’s where validation comes in 🔥 In Spring Boot, we use @Valid along with validation annotations. Example 👇 public class User { @NotNull private String name; @Min(18) private int age; } Controller: @PostMapping("/user") public User addUser(@Valid @RequestBody User user) { return user; } 👉 If invalid data is sent, Spring automatically triggers validation errors 💡 Common validation annotations: • @NotNull • @NotEmpty • @Size • @Min / @Max 💡 Why use validation? • Prevent invalid data • Improve API reliability • Reduce manual checks Key takeaway: Always validate incoming data to build robust APIs 🚀 In the next post, we will handle these validation errors globally 🔥 #Java #SpringBoot #BackendDevelopment #RESTAPI #LearnInPublic

Spent 25 minutes wondering why my Spring Boot API was returning empty response The controller looked fine @GetMapping("/users") public List<User> getUsers() {   return userService.findAll(); } Service was returning data when I debugged But the API response was always empty The problem was the User class had no getters Jackson needs getters to serialize objects to JSON No getters means no fields in the response The fix was adding @Data from Lombok One annotation and everything worked Spring Boot returned the data but Jackson could not read the fields without getters Ever had a bug that made you question everything #Java #SpringBoot #Jackson #Debugging #BackendDevelopment

𝗔𝗳𝘁𝗲𝗿 𝗿𝗲𝘃𝗶𝗲𝘄𝗶𝗻𝗴 𝗵𝘂𝗻𝗱𝗿𝗲𝗱𝘀 𝗼𝗳 𝗣𝗥𝘀, 𝗜 𝗸𝗲𝗲𝗽 𝘀𝗲𝗲𝗶𝗻𝗴 𝘁𝗵𝗲 𝘀𝗮𝗺𝗲 𝗽𝗲𝗿𝗳𝗼𝗿𝗺𝗮𝗻𝗰𝗲 𝗶𝘀𝘀𝘂𝗲. The developer did everything right: clean code, proper repository, correct relationships. And yet, the application was making 𝟱𝟬 𝗱𝗮𝘁𝗮𝗯𝗮𝘀𝗲 𝗾𝘂𝗲𝗿𝗶𝗲𝘀 to display a single page. Nobody noticed. Until production. This is the N+1 problem. In simple terms: instead of 1 query, your app makes 1 + N, one for each item. You don't see it in your code. You see it in your logs: 1 query for orders, then 1 query per customer. 500 orders = 501 queries. The reflex fix? Switch to EAGER loading. That's often the wrong answer. The real fix is understanding 𝘄𝗵𝗮𝘁 𝘆𝗼𝘂'𝗿𝗲 𝗹𝗼𝗮𝗱𝗶𝗻𝗴 𝗮𝗻𝗱 𝘄𝗵𝗲𝗻. Need the data always? use JOIN FETCH Need it sometimes? use @EntityGraph Need full control? use DTO query N+1 is not a JPA bug. It's a judgment problem: the difference between code that works locally and systems that perform in production. I've attached a visual breakdown of these 3 approaches with real examples. Have you ever shipped something that worked perfectly in dev… but broke in production? #Java #SpringBoot #JPA #Hibernate #Backend #Performance #SoftwareEngineering

Not every API should return Entity objects. Spring Boot experts use DTOs and Projections for read performance. Most developers do this: @GetMapping("/users") public List<User> getUsers() { return userRepository.findAll(); } It works… but it’s not optimal. ⸻ ❌ Problem Returning Entity: • Loads unnecessary fields • Fetches relationships lazily • Slower response • Tight coupling with DB ⸻ 🧠 Better Option 1 — DTO public class UserDto { private String name; private String email; } Mapping: return users.stream() .map(user -> new UserDto( user.getName(), user.getEmail())) .toList(); ⸻ ⚡ Best Option — Projection (Expert Way) Spring Boot supports interface-based projections: public interface UserProjection { String getName(); String getEmail(); } Repository: List<UserProjection> findAllProjectedBy(); Only required fields are fetched. ⸻ 💡 When to Use Use Entity → write operations Use DTO → API responses Use Projection → read-only optimized queries ⸻ 🧠 Expert Rule Write APIs for write flexibility Read APIs for performance ⸻ Day 18 of becoming production-ready with Spring Boot. Question: Do you use DTO or Projection for read APIs? ⸻ #Java #SpringBoot #BackendEngineering #Performance #SoftwareArchitecture

🚨 Without connection pooling, your DB will struggle under load Spring Boot uses HikariCP by default. But default config isn’t always optimal. 💥 Issue I faced: Under load → DB connections exhausted Root cause: Pool size too small for concurrent traffic ✅ Fix: - Tuned max pool size - Monitored active connections 💡 Takeaway: Database is often the bottleneck. Connection pooling decides how well you scale. #Java #SpringBoot #BackendDevelopment #SoftwareEngineering  #Microservices #JPA #RESTAPI  #DeveloperLife #CareerGrowth

Most transaction bugs in Spring Boot are not SQL bugs—they’re transaction boundary bugs. Today’s focus is a deep dive into @Transactional: propagation, isolation, and rollback rules. If you only use the default settings everywhere, you may accidentally create hidden data inconsistencies or unexpected commits. Example: @Service public class PaymentService { @Transactional(propagation = Propagation.REQUIRED, isolation = Isolation.READ_COMMITTED, rollbackFor = Exception.class) public void processPayment(Order order) { paymentRepository.save(new Payment(order.getId(), order.getTotal())); inventoryService.reserve(order.getItems()); } } Key idea: REQUIRED joins an existing transaction or starts a new one, REQUIRES_NEW creates a separate one, and isolation controls visibility of concurrent changes. By default, rollback happens for unchecked exceptions, so checked exceptions often need explicit rollbackFor. Treat @Transactional as an architectural decision, not just an annotation. #Java #SpringBoot #BackendDevelopment

Most transaction bugs in Spring Boot are not SQL bugs—they’re transaction boundary bugs. Today’s focus is a deep dive into @Transactional: propagation, isolation, and rollback rules. If you only use the default settings everywhere, you may accidentally create hidden data inconsistencies or unexpected commits. Example: @Service public class PaymentService { @Transactional(propagation = Propagation.REQUIRED, isolation = Isolation.READ_COMMITTED, rollbackFor = Exception.class) public void processPayment(Order order) { paymentRepository.save(new Payment(order.getId(), order.getTotal())); inventoryService.reserve(order.getItems()); } } Key idea: REQUIRED joins an existing transaction or starts a new one, REQUIRES_NEW creates a separate one, and isolation controls visibility of concurrent changes. By default, rollback happens for unchecked exceptions, so checked exceptions often need explicit rollbackFor. Treat @Transactional as an architectural decision, not just an annotation. #Java #SpringBoot #BackendDevelopment