I can take a look at this next 👍

I have the server running as a native image, but there are some gotchas with GraalVM metadata and serialization.

Ktor's content negotiation still uses reflection as described here and the workaround kinda defeats its purpose entirely. So invoking either call.receive() or call.respond() will lead to runtime exceptions, unless you include every reflectable class in reflect-config.json.

Another thing I ran into is kjwt using kotlinx-serialization internally:

kotlinx.serialization.SerializationException: Serializer for class 'JsonObject' is not found.
Please ensure that class is marked as '@Serializable' and that the serialization compiler plugin is applied.

@nomisRev (re: above) how should I scope this change? I feel like the Ktor workaround (applied in the draft PR) is a bit ugly and the fact that receive() / respond() must be avoided in favour of some homebrew helpers is non-trivial. Maybe 🤔

Another option is to use the @Reflectable annotation where needed, but that's not much better since you still need to remember to do that to avoid runtime surprises.

Do you have any better options in mind? 😅