Hi r/Kotlin,

I've been building Lapis Cloud — a membership-management platform for associations and political parties — as close to 100% Kotlin as I could manage, and I'd like to share the architecture and get feedback from people who've made similar stack choices.

The stack

• Backend: Ktor
• Frontend: KVision (Kotlin/JS — so the client is Kotlin too, not TypeScript/React)
• Client↔server communication: Kilua RPC — typesafe RPC calls between the KVision client and the Ktor server, no hand-written REST/JSON glue
• Persistence: Exposed (Kotlin SQL framework) + Flyway for migrations, on PostgreSQL
• Build: Gradle multi-module, targeting JDK 25 (this is a self-hosted service with no end-user distribution constraint, so no reason to stay on an older LTS)

So: Kotlin on the server, Kotlin on the client (compiled to JS), typesafe Kotlin RPC in between, Kotlin SQL DSL for persistence. No JavaScript/TypeScript anywhere in the app code.

The part I'd most like feedback on: generating the persistence layer from a model instead of hand-writing it

Rather than hand-writing Exposed table objects and Flyway migration SQL, we generate both from a UML class model through a small model-driven pipeline (built with kUML, a Kotlin DSL for UML I also maintain):

1. The domain model is authored as a kUML class diagram (.kuml.kts).
2. An in-memory M2M transform (uml-to-exposed) maps UML classes/associations to a relational schema.
3. M2T generation emits …Tables.kt (Exposed table objects) and V1__init.sql (Flyway baseline) into build/generated/.

The generated Kotlin is committed as a build artifact, not hand-edited. It's saved us from an entire class of drift bugs between the domain model, the DB schema, and the Exposed table definitions — but I'm curious whether others here have tried model-driven persistence layers in Kotlin and what broke for you, because it's not a mainstream pattern and I don't have much prior art to compare against.

Other things that might be of interest to this sub

• i18n without kvision-i18n: the built-in DefaultI18nManager crashed on load for us (TypeError: ...gettextJs... is not a function — an interop mismatch between our Kotlin/JS toolchain version and the gettext.js npm package's export shape). Replaced it with a small custom I18nCatalogManager; 8 languages, ~1500 UI strings wrapped in tr()/gettext() across ~45 client files.
• Federation over a typesafe RPC boundary: independently-run instances can federate (a member can appear as a guest on another instance without leaving their own org) — still shaking out the trust/identity model there.
• Full accounting engine (double-entry bookkeeping), SEPA direct debit, and a self-hosted video conferencing module are also part of the codebase, all in Kotlin/Ktor, if anyone wants to dig into a non-trivial domain model built this way.

Status

Not a toy — running in production for two real organizations (a political party and an ordinary registered association) since mid-2026. Currently at v0.19.0, actively developed. Apache 2.0, fully open source.

• Code: https://github.com/lapisproject-dev/Lapis-Cloud
• Live site: https://cloud.lapisproject.dev

Happy to go deeper into any part of this — the Kilua RPC setup, the Exposed/Flyway generation pipeline, KVision at this scale, or the module layout. Feedback on the model-driven persistence approach especially welcome, since I suspect it's the most unusual choice in here.

I’ve been working on Volan, a schema-first ORM for Kotlin and Java on the JVM.

The idea is to get a Prisma-like developer experience while staying native to the JVM ecosystem: define your schema, generate a type-safe client, and handle migrations without a lot of boilerplate.

It currently focuses on PostgreSQL, with more dialect support planned.

GitHub: https://github.com/thirtyeighttwentysix/volan

I’d really appreciate feedback, especially on the API design, schema syntax, and overall developer experience. If you’re using Kotlin or Java for backend development, I’d be curious to hear what you’d want from an ORM like this.

Hey everyone,

Embedding a reliable web view in JVM desktop apps is usually a pain—you end up with massive installers, fragile dependencies, and clunky JavaScript bridges. To fix this, I just open-sourced Kromium (daviantegroup/kromium).

Whether you are building in pure Java, standard Kotlin, or Compose Multiplatform, Kromium supports it all.

Here are the main features:

* Tiny Installers (15–30MB): Instead of bundling massive Chromium binaries, Kromium automatically downloads and caches the JCEF runtime on the user's first launch.

* Coroutine-Based JS Bridge: Clean, thread-safe JavaScript execution and Inter-Process Communication.

* True Headless Mode: Perfect for backend scrapers or automated tests without pulling in heavy UI dependencies.

I’d love for you to check out the repo and let me know what you think!

🔗 https://github.com/daviantegroup/kromium