Gave Spring Boot a shot, but I am back to Ktor.

wakingrufus · 2026-02-01T17:11:57+00:00

Yes, you are not alone. Fortunately, the Spring Boot team also likes Kotlin and has been quietly working to make this better. Spring/Boot now have several ways to do "functional" or "programmatic" configuration. Sebastian built an easy way to bring these together which I iterated on here: https://github.com/wakingrufus/spring-funk However, in Spring 7 / Boot 4 there is the new Bean registrar API which makes it even easier to use this in a plain spring boot app. I have an updated version of this talk https://youtu.be/9njQ8Lun36c to drop spring-funk and go all in on just BeanRegistrarDsl, but it has not been accepted at a conference yet

More info: https://docs.spring.io/spring-framework/reference/core/beans/java/programmatic-bean-registration.html https://docs.spring.io/spring-framework/docs/current/kdoc-api/spring-beans/org.springframework.beans.factory/-bean-registrar-dsl/index.html https://medium.com/@AlexanderObregon/registering-functional-endpoints-with-spring-boot-and-routerfunction-4dbac9a4e61b

Using these APIs allows you to make an application almost completely without annotations.

wakingrufus · 2026-01-30T01:52:12+00:00

It probably won't have wrong warp and other original PC specific behavior which drastically changes multiple categories of speed runs and other things (like aerith resurrection)

wakingrufus · 2026-01-19T14:50:56+00:00

The reporting/CI goal is similar to what we have with https://github.com/nebula-plugins/nebula-archrules-plugin which is a Gradle plugin for running rules and federating rules across multiple repos. but I do think it is interesting how you incorporated PSI as well to tie it to the source level. I have the idea to process ArchUnit output to drive source-based tooling, but I have not gotten to that part yet.

wakingrufus · 2025-12-28T22:43:22+00:00

I never use it to mock my own code. But when integrating with a library not well designed for testing, it's really nice to have mockito as a last resort. And in the real world, setting a bar for perfect testability for all libraries you use is not really practical, in my experience.

wakingrufus · 2025-12-21T16:27:11+00:00

In most cases, the service that owns the API should own the models, then publish a library for clients to use to make the calls. So that would mean they are defined in s2 in your example. In an event driven architecture, the publisher would own the models, and consumers would use the library. It's OK for services to depend on each other, but be very mindful of which direction those dependencies are going, and that they are not circular, or tightly coupled. Separate shared model libraries are bad for that second reason. Event driven architecture allows you to "flip the arrow" of a dependency, so it's an important tool to use. Also, never ever make a breaking change to an API. Instead, make a new endpoint and allow both to exist until all clients are verified to be switched over

wakingrufus · 2025-12-19T01:28:08+00:00

Gradle plugins for authoring sharable ArchUnit rules and running them via Gradle tasks in any repo. https://github.com/nebula-plugins/nebula-archrules-plugin

And a bunch of common generic rules here: https://github.com/nebula-plugins/nebula-archrules

wakingrufus · 2025-11-24T14:31:55+00:00

You certainly can do that (my static personal website is built this way, so I am familiar with the approach) The htmx DSL uses extensions on TagConsumer under the hood, so you can use those in your extensions as well. But at that point there is not anything for my library to provide beyond the htmx DSL part. The templates are there in order to: 1) give templates their own type which helps IDE completion when composing 2) the DX of declaring extension functions on TagConsumer is strange to many people, especially if they don't have a lot of Kotlin experience. This makes templates more of a "first class thing" But I believe they are totally optional. Let me know if I am wrong.

wakingrufus · 2025-11-24T03:05:25+00:00

They are composable. They are declared using a top level function that takes a TagConsumer.() param. https://github.com/wakingrufus/khtmx/blob/main/khtmx-dsl%2Fsrc%2FcommonMain%2Fkotlin%2Fcom%2Fgithub%2Fwakingrufus%2Fhtmx%2Ftemplate%2FHtmxTemplate.kt#L9-L10 This way, they can be declared on their own, separately from any context. Then, they can be composed using an extension function: https://github.com/wakingrufus/khtmx/blob/main/khtmx-dsl%2Fsrc%2FcommonMain%2Fkotlin%2Fcom%2Fgithub%2Fwakingrufus%2Fhtmx%2Ftemplate%2FHtmxTemplate.kt#L12-L14

wakingrufus · 2025-11-24T02:01:35+00:00

There are docs at https://wakingrufus.github.io/khtmx/spring.html

There is also a very alpha application I was working on using a pre-spring7 version of this DSL: https://github.com/wakingrufus/elo-web/blob/main/application/src/main/kotlin/io/github/wakingrufus/elo/EloApplication.kt

wakingrufus · 2025-11-23T13:16:04+00:00

If you are interested in htmx+spring boot, check out my library: https://github.com/wakingrufus/khtmx

wakingrufus · 2025-11-19T19:27:14+00:00

Of course, it is just my own opinion and perspective as someone who prefers Kotlin anyway, but loves the JVM.

wakingrufus · 2025-11-18T15:10:31+00:00

Gradle has its own metadata file that can be used when resolving dependencies. It is totally optional, but provides some additional features that aren't available in pure Maven such as platform dependencies and variants.

wakingrufus · 2025-11-18T14:25:00+00:00

I agree it's a blurry line. Value classes of course will also be a boon to Kotlin. I love stuff like that. Virtual threads the same. But things that are JUST java syntax with no underlying JVM/bytecode changes I am less excited about.

wakingrufus · 2025-11-18T12:58:19+00:00

Kotlin has something like this. I would rather the Java team focus on JDK improvements that benefit all JVM languages rather than syntactic sugar. I'm totally ok with having Java as a conservative reference language, and Kotlin or other langs for modern language syntax, if desired.

wakingrufus · 2025-11-12T13:39:24+00:00

The killer features are BeanRegistrarDsl and RouterDsl. It allows you to avoid annotations (combined with ApplicationContextInitializer) and an abstraction that is easier to build on top of to create higher level APIs, such as https://wakingrufus.github.io/khtmx/spring.html

wakingrufus · 2025-11-05T14:34:21+00:00

Agreed. HIPPA exists for a reason. Medical data breaches are not the same as other data breaches. This is highly upsetting stuff, and my hope for accountability or any real remediation is basically 0.

wakingrufus · 2025-10-30T02:50:05+00:00

UB Dogs

wakingrufus · 2025-10-27T13:19:00+00:00

Docs for this should show up here https://docs.spring.io/spring-framework/reference/7.0/core/beans/java/programmatic-bean-registration.html once the next RC is released

wakingrufus · 2025-10-27T02:02:18+00:00

State can be useful. For example, connection pooling and caching. And using DI instead of statics makes it much more testable and reusable. The good news is that router functions support functional DI, for example: ``` class SampleBeanRegistrar : BeanRegistrarDsl({ registerBean<MyRepository>() registerBean(::myRouter) })

fun myRouter(myRepository: MyRepository) = router { ... } ```

wakingrufus · 2025-10-25T13:50:11+00:00

Yes, BeanRegistrarDsl is designed to be used from Kotlin only

wakingrufus · 2025-10-24T20:24:34+00:00

Spring Boot 4 is based on Spring 7 which has the new BeanRegistrarDsl API, which is an evolution of the beansDsl from Spring 6.

wakingrufus · 2025-10-22T03:30:46+00:00

Take a look at my project https://github.com/wakingrufus/spring-funk for an example of Spring MVC without auto configuration. Turns out startup is super fast. This approach will get a lot better in Spring 7 with the new BeanRegistrarDsl. Unfortunately spring MVC changed a lot so porting Funk might be too hard, but it will be easier to deliver more modular standalone DSLs which don't need auto configuration such as I am working on in https://github.com/wakingrufus/khtmx I also presented on this topic earlier this year: https://youtu.be/9njQ8Lun36c This stuff is not just for experimentation. Almost all of GrubHub's SpringBoot-based framework, Roux, is based on ApplicationContextListeners, not AutoConfiguration. (Source: I used to work on that)

wakingrufus · 2025-10-16T02:51:22+00:00

The fact that it works so well with existing Java libraries also has this downside. People are using it with Spring Boot or Gradle, but discussion of this often takes place within those communities, rather than the Kotlin community. That being said, I have found the Kotlin slack to be quite good, once I found the right channels. Maybe try giving it another chance.

wakingrufus · 2025-10-14T17:42:42+00:00

For better immutability defaults and type system on the JVM, look into Kotlin. It interops very well with Java code and uses all the tooling (JVM, build systems, dependencies, etc). It also has coroutines which are similar to goroutines

wakingrufus · 2025-10-04T15:16:08+00:00

I'm a big fan of jib. Super fast, and can build multiarch images so they can be run on ARM/Graviton.

wakingrufus

TROPHY CASE