💡 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
Common file upload mistakes in production: storing full URLs, skipping compression, and public storage buckets
More Relevant Posts
-
🚨 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
To view or add a comment, sign in
-
#Post6 In the previous posts, we built basic REST APIs step by step. But what happens when something goes wrong? 🤔 Example: User not found Invalid input Server error 👉 By default, Spring Boot returns a generic error response. But in real applications, we need proper and meaningful error handling. That’s where Exception Handling comes in 🔥 Instead of handling exceptions in every method, Spring provides a better approach using @ControllerAdvice 👉 It allows us to handle exceptions globally Example: @ControllerAdvice public class GlobalExceptionHandler { @ExceptionHandler(Exception.class) public String handleException(Exception ex) { return ex.getMessage(); } } 💡 Why use this? • Centralized error handling • Cleaner controller code • Better API response Key takeaway: Use global exception handling to manage errors in a clean and scalable way 🚀 In the next post, we will create custom exceptions for better control 🔥 #Java #SpringBoot #BackendDevelopment #RESTAPI #LearnInPublic
To view or add a comment, sign in
-
#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
To view or add a comment, sign in
-
Most developers think Spring handles 500 requests “all at once.” It doesn’t. Here’s what actually happens: Spring Boot (via embedded Tomcat in Spring Boot) uses a thread pool to handle incoming requests. Each request follows this path: → Request arrives at Tomcat → A free thread is assigned → DispatcherServlet routes it to your @RestController → Controller → Service → Database → Response is returned → Thread goes back to the pool That’s it. No magic. ━━━━━━━━━━━━━━━━━━━━ What happens when all threads are busy? → New requests are placed in a queue → If the queue is full, requests may be rejected (e.g., 503 errors depending on configuration) ━━━━━━━━━━━━━━━━━━━━ The real bottleneck isn’t traffic, it’s blocked threads. Consider this: A slow database call takes 3 seconds × 200 threads = Your system can stall under moderate load This is why backend engineers focus on: Thread pool tuning Reducing blocking operations Asynchronous processing (@Async) Efficient database access (connection pooling) Non-blocking architectures (Spring WebFlux) Key takeaway: Performance is not about handling more requests. It’s about how efficiently your threads are utilized. #Java #SpringBoot #Concurrency #BackendDevelopment #SoftwareEngineering #JavaDeveloper
To view or add a comment, sign in
-
🚀 Spring Boot Tip for Faster Applications One simple improvement that can make a big difference in Spring Boot applications is database connection pooling. Instead of opening a new database connection for every request, Spring Boot uses HikariCP by default to manage connections efficiently. Why it matters: ⚡ Faster response times 📉 Reduced database overhead 🔁 Better handling of high traffic A few useful configurations: • maximumPoolSize – controls the number of connections • connectionTimeout – how long a request waits for a connection • idleTimeout – closes unused connections Optimizing database connections is a small change that can significantly improve application performance. Sometimes performance improvements don’t come from complex architecture, but from tuning the fundamentals. #SpringBoot #Java #BackendDevelopment #JavaDeveloper #Microservices #SoftwareEngineering #TechTips
To view or add a comment, sign in
-
-
If your tests are slow, your learning curve is slow too—H2 can change that today. 🚀 In Spring Boot, H2 is a lightweight in-memory database that starts instantly, making it perfect for repository and integration tests. You get realistic SQL behavior without managing an external DB during development. <dependency> <groupId>com.h2database</groupId> <artifactId>h2</artifactId> <scope>runtime</scope> </dependency> spring: datasource: url: jdbc:h2:mem:testdb username: sa password: h2: console: enabled: true Use @DataJpaTest to validate repository logic in isolation and catch mapping/query issues early. A great workflow is: H2 for fast local feedback, then PostgreSQL integration tests for production parity. Common pitfall: assuming H2 behaves exactly like PostgreSQL/MySQL in every SQL edge case—it does not. Treat H2 as a speed layer, not your only verification layer. #Java #SpringBoot #BackendDevelopment
To view or add a comment, sign in
-
-
⚡ A simple thing that improved my API performance While working on a backend API, I noticed the response time was higher than expected. The issue wasn’t complex logic — it was this: 👉 Fetching unnecessary data from the database Here’s what I changed: ✔ Avoided using SELECT * ✔ Fetched only required fields ✔ Reduced multiple DB calls ✔ Added proper indexing Result? 🚀 Faster response time 🚀 Better performance 💡 Lesson: Small optimizations in database queries can make a big difference in real-world applications. What’s one small change that improved your system performance? 👇 #Java #SpringBoot #BackendDevelopment #SQL #Performance #Microservices
To view or add a comment, sign in
-
What I learned today while exploring Spring Boot. Instead of just going through theory, I focused on understanding how Controllers actually work in a real backend application. Here’s what I covered: 🔹 @RestController — used to expose REST APIs and return data directly (JSON/XML) 🔹 @Controller — mainly used for returning views (like in MVC-based applications) 🔹 Mapping requests properly using: → @RequestMapping (base mapping) → @GetMapping (fetch data) → @PostMapping (create data) → @PutMapping (update data) → @DeleteMapping (delete data) → @PatchMapping (partial update) 🔹 Handling client input: → @PathVariable for dynamic values in URL → @RequestParam for query parameters → @RequestBody for sending JSON data What I’m realizing is — Controllers are not just annotations, they define how the client and backend communicate. Focusing more on clarity and real usage rather than just memorizing. Learning step by step ⚡ #SpringBoot #Java #RestAPI #LearningJourney #Consistency #LearningJourney #Consistency
To view or add a comment, sign in
-
🚀 Learning Update: Why Single-Threaded Server is Not Enough? After building a Single-Threaded Client-Server application, I explored its real limitations — and this changed how I think about backend systems. --- ⚠️ Drawbacks of Single-Threaded Server: ❌ Handles only one client at a time → If one client is connected, others must wait ❌ Blocking nature → "accept()" and I/O operations block the entire server ❌ Poor scalability → Cannot handle real-world traffic (multiple users) ❌ Slow response under load → Requests get queued → delay increases --- 💡 Solution: Multi-Threaded Server Instead of one thread handling everything, we use multiple threads. 🔁 How it works: - Each client request is handled by a separate thread - Server can process multiple clients simultaneously --- 🔥 Benefits of Multi-Threading: ✅ Handles multiple clients at the same time ✅ Better performance and responsiveness ✅ Efficient CPU utilization ✅ Foundation of real-world backend systems --- 🧠 Real Understanding: Single-threaded server = 🚶♂️ One person handling all work Multi-threaded server = 👥 Team handling multiple tasks together --- 🚀 Next Step in My Journey: I’ll implement a Multi-Threaded Server using Thread & ThreadPool to handle concurrent client requests efficiently. --- #Java #Multithreading #BackendDevelopment #SystemDesign #LearningInPublic #JavaDeveloper #100DaysOfCode
To view or add a comment, sign in
-
🚀 Spring Boot — Why I stopped using Entity in request body Earlier, I used to accept Entity directly in my APIs: @PostMapping("/users") public User createUser(@RequestBody User user) { return userService.save(user); } It worked… but later I realized the problem. ⸻ Issues I faced: ✔ Unnecessary fields coming from request ✔ Hard to control what client sends ✔ Tight coupling with DB structure What I do now: Use DTO instead: @PostMapping("/users") public User createUser(@RequestBody UserDto dto) { return userService.create(dto); } ✔ Only required fields ✔ Better validation ✔ Cleaner API contract ⸻ ⭐ Simple rule: 👉 Entity → database 👉 DTO → request/response Small change, but made APIs much safer. Do you accept Entity or DTO in your request body? #SpringBoot #JavaDeveloper #BackendDevelopment #LearningInPublic #Java
To view or add a comment, sign in
-
Explore content categories
- Career
- Productivity
- Finance
- Soft Skills & Emotional Intelligence
- Project Management
- Education
- Technology
- Leadership
- Ecommerce
- User Experience
- Recruitment & HR
- Customer Experience
- Real Estate
- Marketing
- Sales
- Retail & Merchandising
- Science
- Supply Chain Management
- Future Of Work
- Consulting
- Writing
- Economics
- Artificial Intelligence
- Employee Experience
- Workplace Trends
- Fundraising
- Networking
- Corporate Social Responsibility
- Negotiation
- Communication
- Engineering
- Hospitality & Tourism
- Business Strategy
- Change Management
- Organizational Culture
- Design
- Innovation
- Event Planning
- Training & Development