DEV Community: Ashish Saran Shakya

🛠️ 7 Mistakes I Made Writing My First Spring Boot APIs (And What I Do Differently Now)

Ashish Saran Shakya — Sat, 30 Aug 2025 21:35:48 +0000

Spring Boot makes building APIs feel deceptively easy.

When I started out, I focused on just “getting things working.” But when things break—or just scale badly—you realize that working code isn’t always good code.

Here are 7 mistakes I made writing my first Spring Boot APIs, and what I now do to write cleaner, more maintainable backends.

1. Not Using Validation Annotations (`@Valid`, `@NotNull`, etc.)

What I did:

Manually validated request payloads deep inside controllers or services. Missed fields caused confusing errors or null pointer exceptions.

if (userRequest.getEmail() == null) {
    throw new IllegalArgumentException("Email is required");
}

Why it's a problem:

Makes code noisy and repetitive
Delays validation too deep into the flow
Prone to human error

What I do now:

Use Spring's built-in validation support with annotations and @Valid.

public class UserRequest {
    @NotNull
    @Email
    private String email;
}

And in the controller:

@PostMapping("/users")
public ResponseEntity<?> createUser(@Valid @RequestBody UserRequest request) {
    ...
}

Pair this with @ControllerAdvice to handle validation exceptions cleanly.

2. Hardcoding config with `@Value` instead of using `@ConfigurationProperties`

What I did:

Injected config values everywhere using @Value.

@Value("${aws.s3.bucket}")
private String bucketName;

Why it's a problem:

Scattered config makes things hard to manage
No way to validate values
Harder to write unit tests

What I do now:

Use @ConfigurationProperties to bind entire config blocks into structured classes.

@ConfigurationProperties(prefix = "aws.s3")
public class S3Properties {
    private String bucket;
    // getters/setters
}

This gives you validation, IDE support, and cleaner wiring.

3. Logging the Wrong Way

What I did:

Used System.out.println() and vague messages like “Error occurred” or “Debug here”.

Why it's a problem:

Not visible in production logs
Lacks context (who, what, when)
No severity levels or structured format

What I do now:

Use SLF4J with clear, parameterized logging:

log.info("User {} uploaded file {}", userId, fileName);

And for errors:

log.error("Failed to process request for user {}", userId, e);

Be intentional with log levels: info, warn, error, and avoid logging entire stack traces unless necessary.

4. Messy Exception Handling

What I did:

Wrapped everything in try-catch blocks, often rethrowing or printing stack traces manually.

try {
    ...
} catch (Exception e) {
    e.printStackTrace();
    throw e;
}

Why it's a problem:

Duplicates logic
Makes error responses inconsistent
Hides real issues in production

What I do now:

Define custom exceptions and handle them centrally using @ControllerAdvice.

@ResponseStatus(HttpStatus.NOT_FOUND)
public class ResourceNotFoundException extends RuntimeException {
    public ResourceNotFoundException(String msg) {
        super(msg);
    }
}

And in a global exception handler:

@RestControllerAdvice
public class GlobalExceptionHandler {
    @ExceptionHandler(ResourceNotFoundException.class)
    public ResponseEntity<?> handleNotFound(ResourceNotFoundException ex) {
        return ResponseEntity.status(HttpStatus.NOT_FOUND)
                             .body(new ErrorResponse(ex.getMessage()));
    }
}

Clean, consistent, and maintainable.

5. Overusing `@Autowired` Field Injection

What I did:

Injected everything using @Autowired on fields.

@Autowired
private UserService userService;

Why it's a problem:

Makes dependencies hard to track
Breaks immutability
Difficult to write unit tests

What I do now:

Use constructor injection:

@Service
public class UserController {
    private final UserService userService;

    public UserController(UserService userService) {
        this.userService = userService;
    }
}

Bonus: With one constructor, Spring injects it automatically—no @Autowired needed.

6. Forgetting API Documentation (like Swagger/OpenAPI)

What I did:

Left API documentation in someone's Notion page or none at all.

Why it's a problem:

Frontend teams have to guess request/response formats
No way to test endpoints quickly
Becomes a bottleneck during integration

What I do now:

Use springdoc-openapi to generate live docs with minimal setup:

<!-- build.gradle / pom.xml -->
<dependency>
  <groupId>org.springdoc</groupId>
  <artifactId>springdoc-openapi-ui</artifactId>
  <version>1.6.14</version>
</dependency>

Then access Swagger UI at:

http://localhost:8080/swagger-ui/index.html

It reflects your controller annotations and helps both devs and testers.

7. Mixing DTOs with Entities

What I did:

Used JPA entities directly in request bodies and responses.

Why it's a problem:

Leaks internal persistence logic
Adds accidental complexity (lazy loading, cascade issues)
Makes refactoring risky

What I do now:

Create dedicated DTO classes:

public class UserDto {
    private String name;
    private String email;
}

Use mappers like MapStruct, ModelMapper, or just write a utility:

public UserDto toDto(User user) {
    return new UserDto(user.getName(), user.getEmail());
}

Entities stay clean. APIs stay stable.

💬 Final Thoughts

Spring Boot abstracts a lot of complexity—but with that power comes responsibility.

These 7 mistakes cost me time, performance, and headaches. But fixing them made me a better engineer.

What’s one mistake you made in your early Spring Boot journey?

Would love to hear your thoughts below 👇

Intern to Engineer: The Hard Lessons You Only Learn in Production

Ashish Saran Shakya — Tue, 22 Jul 2025 13:27:28 +0000

When I joined UBS for a 6-month internship, I thought I knew my stuff. I’d done a few projects, written some production code—but real engineering? That was still to come.

Over the next six months, I worked on the Strategic Proposal Tool, a large-scale internal platform that helps financial advisors create investment proposals for HNIs and UHNIs. This is the story of what I built, what broke, and what I’ll never forget.

🏗 The Context: Internship + Stack

Before this internship, I had:

A basic Node.js internship at a small startup, working on their ecommerce platform.
A summer internship with the same UBS team, working on a different application migrating it from Java 8 to Java 17, also implementing some new features.

This 6-month stint gave me the opportunity to move beyond beginner-level projects and contribute to core systems.

Tech stack I worked with:

Java (Spring Boot)
React
PostgreSQL
GitLab CI/CD
Azure Kubernetes

🔧 Projects I Worked On

1. Admin Banners

Dynamic notifications (like outages or feature rollouts) for FAs logging into the system. I worked on backend logic for role-based visibility and real-time display rules. Also worked on admin API to manage the banners.

2. Morningstar API Integration

Integrated Morningstar’s external API to fetch live investment instrument data, including mapping, error handling, and security.

3. Backend from Scratch

We were building a new system—not just patching legacy code. I helped define DB schemas, API flows, and adapted as requirements evolved over time.

⚠️ From 33 Seconds to 2.75: One Bug That Taught Me Backend Maturity

During load testing, a metrics API I had built performed well under development conditions, but under load it hit 33 seconds—far exceeding the acceptable limit of 5 seconds.

I traced it to redundant queries, missing indexes, and a few architectural changes introduced after my initial implementation.

Fixes I applied:

Introduced hashing to reduce repeated computation
Indexed key DB columns
Consolidated data retrieval across endpoints

Final result? We brought it down to 2.75 seconds.

That one bug forced me to revisit how I thought about system design, clean code, and performance tradeoffs. Here’s what it taught me technically…

🧠 Key Technical Takeaways

Read the System First: Understanding flows end-to-end made my development faster and more accurate.
Feign Clients: For cleaner internal HTTP service calls use feign clients as it abstracts the HTTP call implementation.
Three-Layer Architecture:
- Facade Layer: handles interactions with the UI
- Business Layer: core business logic, interacts with other business services
- Data Layer: isolated DB schema responsibilities

🤝 Communication Is Everything

I learned quickly that technical skills aren’t enough.

Clear communication avoids bugs introduced through assumptions.
Stakeholder questioning uncovers edge cases you won’t find in GitLab tickets.
Agile workflows sometimes deliver magic, other times just fragments—know when to speak up and when to flex.

😓 One Mistake I Won’t Repeat

That performance bug? I wish I’d spent more time analyzing how the system worked and profiling early.

Now, I start by:

Reading similar flows
Understanding performance implications
Testing early, not late

💬 Advice to Backend Interns

Learn your fundamentals: Auth flows, backend layering, and microservices communication.
Explore beyond your GitLab board: Use quiet sprints to pair with seniors, refactor small pieces, or research upcoming stack changes.
Don’t code blind: Read the existing APIs and logic. Learn how the system breathes before you change it.

💬 Over to You

Internships are bridges—between theory and practice, between coding and designing.

They’re also one of the fastest ways to level up as an engineer—if you’re curious and intentional.

What was your biggest lesson from your first real backend project?

I’d love to hear it 👇

DEV Community: Ashish Saran Shakya

🛠️ 7 Mistakes I Made Writing My First Spring Boot APIs (And What I Do Differently Now)

1. Not Using Validation Annotations (@Valid, @NotNull, etc.)

2. Hardcoding config with @Value instead of using @ConfigurationProperties

3. Logging the Wrong Way

4. Messy Exception Handling

5. Overusing @Autowired Field Injection

6. Forgetting API Documentation (like Swagger/OpenAPI)

7. Mixing DTOs with Entities

💬 Final Thoughts

Intern to Engineer: The Hard Lessons You Only Learn in Production

🏗 The Context: Internship + Stack

🔧 Projects I Worked On

1. Admin Banners

2. Morningstar API Integration

3. Backend from Scratch

⚠️ From 33 Seconds to 2.75: One Bug That Taught Me Backend Maturity

🧠 Key Technical Takeaways

🤝 Communication Is Everything

😓 One Mistake I Won’t Repeat

💬 Advice to Backend Interns

💬 Over to You

1. Not Using Validation Annotations (`@Valid`, `@NotNull`, etc.)

2. Hardcoding config with `@Value` instead of using `@ConfigurationProperties`

5. Overusing `@Autowired` Field Injection