Tobias

Posted on Sep 4 Originally published at tobiasboner.substack.com AI-assisted

From TypeScript to Spring Boot: a small developer convenience I missed

#opensource #java #springboot

Coming from TypeScript, Node.js, and Express, I was used to having useful local URLs printed in the terminal when an application started.

Start the server. Click the link. Open the API documentation.

When working with Spring Boot, I missed that small convenience. So I built a tiny open-source starter that prints the configured Swagger UI URL after application startup—just add the dependency and enable it in configuration.

I know what you might be thinking: Spring Boot doesn’t need a library to print a URL!

The one-line solution is perfectly valid

In a Spring Boot application, this is enough:

public static void main(String[] args) {
    SpringApplication.run(MyApplication.class, args);
    System.out.println(
        "Swagger UI: http://localhost:8080/swagger-ui.html"
    );
}

If your application always uses that port and path, this is a reasonable solution. You probably don’t need another dependency.

The same distinction applies to Express. Express itself doesn’t automatically print a Swagger UI link. Its official example explicitly adds a console message inside the app.listen() callback.

My inspiration was the workflow I associated with my Node projects—not a built-in feature that Java was missing.

That leaves a fair question: why build a library?

The URL is the part that changes

A hardcoded message is simple because it assumes the address is already known.

That assumption gets less convenient when applications have different configurations:

One uses a different server port.
Another runs beneath an application context path.
Swagger UI has a custom path.
A local instance uses a randomly assigned port.
Documentation is exposed on a separate management port.
Local access uses HTTPS.

You can handle these cases in application code. But then you’re maintaining URL-building logic rather than a single print statement.

The starter packages that behavior so it can be reused across services.

Its purpose is deliberately narrow:

A tiny, opt-in Spring Boot starter that prints your configured Swagger UI URL—without maintaining URL-building startup code across services.

Here’s the output from an application where I tried it:

The starter prints the configured Swagger UI URL immediately after application startup, including the custom port and context path.

Using it

If your application already serves Swagger UI, add this dependency:

<dependency>
    <groupId>io.github.dydent</groupId>
    <artifactId>swagger-ui-link-spring-boot-starter</artifactId>
    <version>0.1.0</version>
</dependency>

Then enable it in your local configuration:

# application-local.yml
swagger-ui-link:
  enabled: true

Run your application with the local Spring profile active.

For an application using the default port and springdoc UI path, the output looks like:

Swagger UI: http://localhost:8080/swagger-ui.html

Most terminals and IDE consoles make that URL clickable.

The dependency does not install Swagger UI. It reports the address of the UI your application already serves.

Local convenience, explicitly enabled

I only want this message during local development.

The starter is disabled by default, so I enable it in application-local.yml. Production stays quiet as long as that profile isn’t active and the setting isn’t enabled elsewhere.

This uses Spring Boot’s existing profile mechanism. It isn’t a separate environment-detection system.

You can achieve the same result yourself. In Express, you could guard a startup message:

app.listen(3000, () => {
  if (process.env.NODE_ENV === 'development') {
    console.log('Swagger UI: http://localhost:3000/api-docs');
  }
});

In Spring Boot, you can check the profile after startup. Assuming an existing SLF4J logger named log:

var context = SpringApplication.run(MyApplication.class, args);

if (context.getEnvironment().matchesProfiles("local")) {
    log.info("Swagger UI: http://localhost:8080/swagger-ui.html");
}

Both are valid solutions. The starter simply packages the opt-in behavior alongside URL resolution, so application code doesn’t need to handle either concern.

Importantly, disabling the message does not disable or secure Swagger UI. That remains the application’s responsibility.

A small library with a small job

This isn’t rocket science, and it’s not trying to be. In my opinion, it’s just a nice little developer-experience improvement: start the application, click the link, and get on with your work.

For one application with a fixed URL, a simple log statement may be enough. For multiple services with different configurations, the starter saves you from maintaining that startup logic yourself.

Version 0.1.0 is available on Maven Central under the Apache-2.0 license. You can find the source and setup instructions on GitHub.

Now I’m curious: how do you handle this in your Spring Boot projects today—a startup log, an IDE shortcut, a bookmark, or something else? Would a tiny starter like this be useful to you, or would you stick with a few lines of application code? I’d love to hear your approach and what you think in the comments.

DEV Community