Much Simpler Alternative to Spring Profile

Real Case Scenario - Vault Vendor A Single configuration only One of our customers uses an external service for their Vault service, which requires some proprietary dependencies and initialization of a few spring components when the server starts up. That's normal but worked well only on environments that require the use of their Vault service. Adding a special environment configuration However, on Dev environments, accessing the real vendor service had resources limits implications, primarily costs. So there was no need to actually perform operations on the real Vault service while running on local dev or unit testing. Spring Profile Also loading the real Vault dependencies and initializing its components were necessary only in production and staging. But, not on Dev or CICD pipelines, so they used a Spring "profile": Working with Spring Profile You choose appropriate names for each of the "setups" you want your server to starts with. For example: "dev", "production" - These setups are called the "Profiles", so we can have "dev" profile, "production" profile, "staging", etc... You associate (or "map") a Spring Component with the Profile you wish it to initialize with E.g: public interface VaultService { String getSecret(String key); } @Component @Profile("dev") public class DummyVaultService implements VaultService { @Override public String getSecret(String key) { return "dummy-secret"; } } @Component @Profile("prod") public class RealVaultService implements VaultService { @Override public String getSecret(String key) { // Real Vault logic return "real-secret"; } } Then, you "tell" your server what "Profile" to run with by providing a system property. E.g: -Dspring.profiles.active=dev And "Voila"! only components annotated with @Profile("dev") will be loaded and initialized by spring. So for the dev env, the server works with a dummy vendor implementation. Dynamically Switching Vendors at Runtime But, Spring Profiles are good for static configurations. Our customer defined a new requirement where it must be able to switch between multiple real vendors without restarting their server. And spring "profile" can not support that. Lazy Loading Factory Pattern They've decided to drop the @Profile way and implement their own dynamic way by maintaining a Map of implementations. E.g: private Map vaultVendorsMap = new HashMap(); They would map a vendor name to its implementation. But, how would they trigger the change in runtime? Trigger Changes in Runtime One option was to define an API on their server like: /api/auth/vendor?name=VendorNameToWorkWith Then they realized they will need to expose their server to more API paths in order to change other "settings" like changing URLs to other external services, or simply change thresholds like "max-queue-size" which they still wanted to be able to change while the server is running, without the need to restart. So they started to think about one "General" API like /api/settings/ but when they realized only one web client would know the latest settings because if multiple developers are viewing a "Settings Page" (which they would need to create and maintain), then if one modifies the settings, all others need to "Refresh" their web-page and since they have multiple micro-services work together, then they need to "Dispatch" the new settings to all relevant micro-services. Enjoying Kiponos.io At that point they decided to use Kiponos which uses WebSockets to dispatch delta updates into all relevant SDKs and team members. Kiponos organizes your entire account into environments, releases, and configuration variants (like profiles) but all in realtime. Kiponos provides Role Based Access Control Per Team on active Environment. This way you can define a developer as a team admin to modify the R&D team configuration and at the same time, define the same developer as read-only user for accessing QA team settings. I hope you find Kiponos flexible and powerful as others found. Learn More or Sign Up to a Free Team Starter account. Enjoy! and let me know if you want me to elaborate on code examples or other configuration patterns. Respectfully yours, David. Kiponos.io

Apr 3, 2025 - 13:24

Real Case Scenario - Vault Vendor

A Single configuration only

One of our customers uses an external service for their Vault service, which requires some proprietary dependencies and initialization of a few spring components when the server starts up.

That's normal but worked well only on environments that require the use of their Vault service.

Adding a special environment configuration

However, on Dev environments, accessing the real vendor service had resources limits implications, primarily costs. So there was no need to actually perform operations on the real Vault service while running on local dev or unit testing.

Spring Profile

Also loading the real Vault dependencies and initializing its components were necessary only in production and staging.
But, not on Dev or CICD pipelines, so they used a Spring "profile":

Working with Spring Profile

You choose appropriate names for each of the "setups" you want your server to starts with.
For example: "dev", "production" - These setups are called the "Profiles", so we can have "dev" profile, "production" profile, "staging", etc...
You associate (or "map") a Spring Component with the Profile you wish it to initialize with E.g:

public interface VaultService {
    String getSecret(String key);
}

@Component
@Profile("dev")
public class DummyVaultService implements VaultService {
    @Override
    public String getSecret(String key) {
        return "dummy-secret";
    }
}

@Component
@Profile("prod")
public class RealVaultService implements VaultService {
    @Override
    public String getSecret(String key) {
        // Real Vault logic
        return "real-secret";
    }
}

Then, you "tell" your server what "Profile" to run with by providing a system property.
E.g:

-Dspring.profiles.active=dev

And "Voila"! only components annotated with @Profile("dev") will be loaded and initialized by spring. So for the dev env, the server works with a dummy vendor implementation.

Dynamically Switching Vendors at Runtime

But, Spring Profiles are good for static configurations.
Our customer defined a new requirement where it must be able to switch between multiple real vendors without restarting their server. And spring "profile" can not support that.

Lazy Loading Factory Pattern

They've decided to drop the @Profile way and implement their own dynamic way by maintaining a Map of implementations. E.g:
private Map vaultVendorsMap = new HashMap<>();

They would map a vendor name to its implementation.

But, how would they trigger the change in runtime?

Trigger Changes in Runtime

One option was to define an API on their server like: /api/auth/vendor?name=VendorNameToWorkWith

Then they realized they will need to expose their server to more API paths in order to change other "settings" like changing URLs to other external services, or simply change thresholds like "max-queue-size" which they still wanted to be able to change while the server is running, without the need to restart. So they started to think about one "General" API like /api/settings/ but when they realized only one web client would know the latest settings because if multiple developers are viewing a "Settings Page" (which they would need to create and maintain), then if one modifies the settings, all others need to "Refresh" their web-page and since they have multiple micro-services work together, then they need to "Dispatch" the new settings to all relevant micro-services.

Enjoying Kiponos.io

At that point they decided to use Kiponos which uses WebSockets to dispatch delta updates into all relevant SDKs and team members.

Kiponos organizes your entire account into environments, releases, and configuration variants (like profiles) but all in realtime.

Kiponos provides Role Based Access Control Per Team on active Environment. This way you can define a developer as a team admin to modify the R&D team configuration and at the same time, define the same developer as read-only user for accessing QA team settings.

I hope you find Kiponos flexible and powerful as others found.

Learn More or Sign Up to a Free Team Starter account.

Enjoy! and let me know if you want me to elaborate on code examples or other configuration patterns.

Respectfully yours,
David.

Kiponos.io