Forem: Rachid

[Boost]

Rachid — Wed, 29 Oct 2025 09:52:12 +0000

Spring Boot: Stop Using @Value Everywhere! Discover @ConfigurationProperties

Rachid ・ Oct 29

Spring Boot: Stop Using @Value Everywhere! Discover @ConfigurationProperties

Rachid — Wed, 29 Oct 2025 09:45:45 +0000

Hey dev community!

When working on Spring Boot projects, we all need to read values from our application.properties or application.yml files.

Most of us start by using the @Value annotation to inject each property one by one.

The Problem (The "Old Way")
As your application grows, your service or configuration class starts to look like this:

@Service
public class MyOldService {

    @Value("${app.api.url}")
    private String apiUrl;

    @Value("${app.api.key}")
    private String apiKey;

    @Value("${app.feature.toggle.new-feature}")
    private boolean featureToggle;

    @Value("${app.thread-pool-size}")
    private int poolSize;

    // ... and it goes on and on
}

This is verbose, hard to maintain, and not type-safe (just Strings and primitives). If you mistype a prefix, everything breaks at runtime.

The Solution: @ConfigurationProperties
Spring Boot offers a much cleaner, safer, and more organized way to manage your configuration: the @ConfigurationProperties annotation.

The idea is simple: map an entire block of your configuration file to a single Java object (a POJO or a Record).

Let's see how.

Step 1: Your application.yml file
Structure your properties logically. It's much more readable!

app:
  name: "My Awesome Service"
  feature-toggle:
    new-feature: true
    beta-access: false
  api:
    url: "https://api.example.com"
    key: "your-secret-api-key"

Step 2: Create the Configuration Class
We'll create a class (or even better, a Java 17+ record) that represents this structure.

Note: For this to work with records (constructor binding), you need a recent version of Spring Boot (3+). Otherwise, use a classic class with getters and setters.

import org.springframework.boot.context.properties.ConfigurationProperties;

// The "app" prefix matches the root of our config
@ConfigurationProperties(prefix = "app")
public record AppProperties(
    String name, 
    ApiConfig api,
    FeatureToggle featureToggle
) {

    // We can even have nested objects!
    public record ApiConfig(String url, String key) {}

    public record FeatureToggle(boolean newFeature, boolean betaAccess) {}
}

Step 3: Enable the Configuration
We need to tell Spring to scan and activate this class. The easiest way is on your main application class:

import org.springframework.boot.context.properties.EnableConfigurationProperties;
import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;

@SpringBootApplication
@EnableConfigurationProperties(AppProperties.class) // <-- The key step!
public class MyApplication {

    public static void main(String[] args) {
        SpringApplication.run(MyApplication.class, args);
    }
}

Step 4: Use Your Configuration (The Clean Way!)
Now, instead of injecting 10 @Value fields, you just inject one single bean, perfectly typed:

@Service
public class MyNewService {

    private final AppProperties appProperties;

    // Constructor injection (always a good practice!)
    public MyNewService(AppProperties appProperties) {
        this.appProperties = appProperties;
    }

    public void doSomething() {
        String url = appProperties.api().url(); // Clean!
        String key = appProperties.api().key(); // Type-safe!

        if (appProperties.featureToggle().newFeature()) {
            // ... new feature logic
        }

        System.out.println("App name: " + appProperties.name());
    }
}

Why This is 100x Better
Type-Safe: No more 'String' vs. 'int' errors. You're handling a real Java object.

Centralized: All 'app'-related configuration is in one single class.

Validation: You can add validation annotations (@Validated, @min, @NotEmpty) directly to the fields of your AppProperties class!

Auto-completion (The Pro-Tip):
If you add this dependency to your pom.xml (or Gradle), your IDE will give you auto-completion right in your .yml or .properties file!

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-configuration-processor</artifactId>
    <optional>true</optional>
</dependency>

Conclusion
Stop fighting with @Value. For any configuration that's more than two or three keys, switch to @ConfigurationProperties. It's cleaner, more robust, and much more maintainable.

What's your favorite Spring Boot tip? Let me know in the comments! 👇

Happy coding!

Spring Boot Pro Tip: Boost Performance with @Cacheable + Java 17

Rachid — Mon, 17 Mar 2025 13:45:58 +0000

If your Spring Boot app is hitting the database too often and slowing down, you need caching! Using @Cacheable, you can reduce unnecessary queries, speed up responses, and improve scalability.

Let’s explore how to cache efficiently and avoid common pitfalls.

The Problem: Too Many Database Calls
Imagine we have a user service fetching data from the database:

@Service
public class UserService {
    @Autowired private UserRepository userRepository;

    public User getUserById(Long id) {
        return userRepository.findById(id).orElseThrow();
    }
}

Every time getUserById() is called, it hits the database. But do we really need to fetch the same user multiple times?

The Solution: @Cacheable
Spring Boot makes caching easy. Just add @EnableCaching in your main class:

@SpringBootApplication
@EnableCaching
public class MyApplication {
    public static void main(String[] args) {
        SpringApplication.run(MyApplication.class, args);
    }
}

Then, modify your service to cache users:

@Service
public class UserService {
    @Autowired private UserRepository userRepository;

    @Cacheable("users")
    public User getUserById(Long id) {
        return userRepository.findById(id).orElseThrow();
    }
}

Now, when getUserById(id) is called multiple times, it returns the cached result instead of querying the database again!

Fine-Tuning the Cache
By default, @Cacheable caches results forever. To control expiration, use Caffeine or Redis.
Use Caffeine for In-Memory Caching (Fast & Lightweight)
Add the dependency:

<dependency>
    <groupId>com.github.ben-manes.caffeine</groupId>
    <artifactId>caffeine</artifactId>
    <version>3.0.6</version>
</dependency>

Then, configure the cache with TTL (Time-To-Live) settings:

@Configuration
public class CacheConfig {
    @Bean
    public CacheManager cacheManager() {
        return new CaffeineCacheManager("users");
    }
}

This ensures cached users expire after a certain period, preventing stale data.

Use Redis for Distributed Caching (Great for Microservices)
For scalability, store cached data in Redis:

Add Redis dependency:

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-data-redis</artifactId>
</dependency>

Configure Redis in application.yml:

spring:
  redis:
    host: localhost
    port: 6379

Use Redis as Cache Manager:

@Configuration
public class RedisConfig {
    @Bean
    public RedisCacheManager cacheManager(RedisConnectionFactory connectionFactory) {
        return RedisCacheManager.builder(connectionFactory).build();
    }
}

Result: The cache is shared across multiple instances, perfect for cloud deployments!

Common Cache Mistakes to Avoid
Forgetting to update the cache when data changes
Use @CachePut to update cache when saving new data

@CachePut(value = "users", key = "#user.id")
public User saveUser(User user) {
    return userRepository.save(user);
}

Caching large objects
Cache only frequent, small, and non-sensitive data

Not setting an expiration time
Always define TTL to prevent outdated data issues

[Boost]

Rachid — Mon, 10 Mar 2025 15:36:08 +0000

🚀 Spring Boot Pro Tip: The Hidden Power of @TransactionalEventListener!

Rachid ・ Mar 10

#springboot #java #programming #webdev

💻 6+ years of coding… and still learning!

Rachid — Mon, 10 Mar 2025 12:27:29 +0000

I just took a look at my GitHub activity since 2018, and it made me realize how far I’ve come. From my first commits back then to my peak in 2021 (where I was super active with 287 contributions), I’ve been on a non-stop journey of learning, building, and improving.

Lately, I’ve been more focused on freelance projects and real-world applications with Spring Boot & Angular, which means fewer open-source contributions. But I’m planning to change that!

🚀 My goals for 2024-2025:
✅ Get back into open-source & share more code
✅ Keep refining my skills in Spring Boot & Angular
✅ Build & contribute to projects that actually help developers

🚀 Spring Boot Pro Tip: The Hidden Power of @TransactionalEventListener!

Rachid — Mon, 10 Mar 2025 11:36:05 +0000

Did you know that Spring Boot allows you to execute code after a transaction is committed using @TransactionalEventListener? Most developers use @EventListener, but this hidden gem ensures your logic only runs if the transaction succeeds.
Problem: When Events Fire Too Early
Imagine you're saving a user and sending a welcome email before the transaction commits:

public class UserCreatedEvent {
    private final User user;

    public UserCreatedEvent(User user) {
        this.user = user;
    }

    public User getUser() {
        return user;
    }
}

@Component
public class UserEventListener {
    @EventListener
    public void handleUserCreated(UserCreatedEvent event) {
        emailService.sendWelcomeEmail(event.getUser()); //  Runs even if transaction fails!
    }
}

If the database transaction fails, the email is still sent, leading to inconsistencies.

Solution: @TransactionalEventListener

@Component
public class UserEventListener {
    @TransactionalEventListener
    public void handleUserCreated(UserCreatedEvent event) {
        emailService.sendWelcomeEmail(event.getUser()); //  Runs ONLY if the transaction is committed!
    }
}

Now, the event fires only if the transaction succeeds!
How to Use It in a Spring Boot App

Publish an Event Inside a Transaction

@Service
public class UserService {
    @Autowired private ApplicationEventPublisher publisher;
    @Autowired private UserRepository userRepository;

    @Transactional
    public void createUser(String name, String email) {
        User user = userRepository.save(new User(name, email));
        publisher.publishEvent(new UserCreatedEvent(user)); //  Event is published
    }
}

Listen to the Event After Transaction Commits

@Component
public class UserEventListener {
    @TransactionalEventListener
    public void handleUserCreated(UserCreatedEvent event) {
        System.out.println("User created: " + event.getUser().getEmail());
    }
}

Guaranteed execution only if the transaction is successful.
Why is This Useful?
Prevents sending emails, messages, or notifications for failed transactions.
Ensures event-driven logic only executes when the database is consistent.
Perfect for logging, auditing, and triggering external services.

Say Goodbye to Boilerplate with Java 17 Records

Rachid — Mon, 10 Mar 2025 11:28:51 +0000

Spring Boot applications deal a lot with DTOs, responses, and immutable objects. Java 17’s record feature makes our lives easier:

public class User {
    private String name;
    private String email;
    public User(String name, String email) {
        this.name = name;
        this.email = email;
    }
    public String getName() { return name; }
    public String getEmail() { return email; }
}

After (Using Java 17 record 🎉)

public record User(String name, String email) {}

✅ No more boilerplate.
✅ Automatic toString(), equals(), and hashCode().
✅ Immutable by default.

When to use records? Perfect for DTOs and API responses, but avoid them for JPA entities!