DEV Community: numq

Stop Trusting Your UI: Why Zero-Trust Server-Driven UI is the Next Industry Standard

numq — Tue, 28 Jul 2026 11:55:41 +0000

TLS is not enough. Your JSON payloads are a ticking time bomb. Here is how Blueprint makes UI manipulation mathematically impossible - and why your compliance team will soon demand it.

Part 1: The Billion-Dollar Blind Spot

Server-Driven UI won. Airbnb, Spotify, and Uber proved that shipping UI from the backend gives you superpowers: instant A/B tests, zero-day fixes, and a single source of truth for business logic. The industry is racing to adopt it.

But there's a problem nobody talks about at conferences: you've moved your business logic to the wire, but your security model is still "pray the TLS holds."

Skeptical? Think TLS is a silver bullet? In the real world, TLS is routinely bypassed or terminated early. SSL inspection on corporate devices (Enterprise MDM), compromised edge nodes or CDNs, malicious proxy extensions, and internal lateral movement within your own microservice architecture can all manipulate traffic while it's in plain text.

This isn't theoretical. OWASP Mobile Top 10 lists "Insufficient Cryptography" (M9) as a critical vulnerability. NIST SP 800–207 defines Zero Trust Architecture as the gold standard. And PSD3 is pushing financial apps toward cryptographic proof of transaction integrity - including the UI that initiates those transactions.

Imagine this real-world attack:

User taps: [ ☕ Buy Coffee - $5.00 ]

🔴 Traditional SDUI (Vulnerable)

Server → MITM Proxy / Compromised CDN → Client
Original payload: "action": "api/charge?amount=5"
Modified payload: "action": "api/charge?amount=5000"
The button still says "Buy Coffee"
The user sees nothing suspicious
Result: $5,000 leaves their account

🟢 Blueprint Zero-Trust SDUI (Immune)

Server → [RSA Signature + Hash Chain] → Client
Client checks: incoming.previousHash == current.hash
Client checks: RSA.verify(newHash, signature)
Modified payload? → MISMATCH - rejected
Replayed payload? → BROKEN CHAIN - rejected
Result: UI refuses to render, attack neutralized

The difference is mathematical proof versus blind faith. And in regulated industries - FinTech, Healthcare, Enterprise - regulators are already asking the question: "How do you guarantee the UI your customer sees is exactly what your backend generated?"

Blueprint is the answer. It's not just another SDUI framework. It's a cryptographic protocol for user interfaces.

Part 2: The Blueprint Chain - Your UI on a Blockchain

Blueprint treats every screen as a block in an immutable chain. The client doesn't "request a screen." It validates a state transition.

Hash Chaining: Every Screen Knows Its Parent

// Core data model - note the cryptographic fields
@Serializable
data class Blueprint(
    val id: String,
    val state: Map<String, String> = emptyMap(),
    val root: BlueprintNode,
    val hash: String = "",           // SHA-256 of this screen's content
    val previousHash: String? = null // Cryptographic link to previous screen
)

When the server pushes a new screen, the client executes:

// BlueprintChain.kt - the zero-trust gatekeeper
is ChainEvent.Push -> when {
    strictMode && links.isNotEmpty() -> when (val currentHash = current?.hash) {
        event.blueprint.previousHash -> 
            copy(links = links + event.blueprint).right() // ✅ Chain intact

        else -> ChainError.HashMismatch(
            expected = currentHash ?: "null",
            actual = event.blueprint.previousHash
        ).left() // 🚫 Chain broken
    }
}

This is the gamechanger. You cannot inject a phishing screen. You cannot replay an old "success" screen to hide an error. The chain must be unbroken, or the UI stops dead.

Performance That Does Not Sacrifice UX

Security like this must be invisible to the user. Blueprint delivers:

Performance impact - imperceptible to users:

SHA-256 hashing (1 KB payload): < 0.3 ms - negligible
RSA-2048 signature verification: < 2.1 ms - imperceptible
Full chain push + verify: < 3.8 ms - single frame at 60 FPS
State delta apply + verify: < 2.5 ms - sub-frame

All verification happens locally. No network calls. No server round-trips. The chain validates on-device, ensuring zero latency impact on navigation.

State Deltas with RSA Signatures: Surgical, Signed Updates

Full screen reloads are wasteful. Blueprint uses StateDeltaBlock for surgical state patches:

@Serializable
data class StateDeltaBlock(
    val patches: Map<String, String>,  // Only the changed key-value pairs
    val previousHash: String,          // Must match current state hash
    val newHash: String,               // Hash of the new state
    val signature: String              // RSA-signed by server's private key
)

The verification is absolute:

strictMode && verifier != null && !verifier.verify(
    payload = block.newHash,
    signatureBase64 = block.signature
) -> ChainError.SignatureVerificationFailed(blockHash = block.newHash).left()

Even if an attacker compromises your CDN, they cannot forge a valid StateDeltaBlock. The RSA private key lives in your Hardware Security Module or Vault. The client holds only the public key. Without a valid signature, the state machine returns Either.Left(ChainError) - a type-safe rejection that never crashes the app, but definitively blocks the tampered update.

Key rotation is built in. The SignatureVerifier interface supports pinning multiple public keys simultaneously, enabling graceful rotation during security incidents without breaking existing clients.

This is what enterprise security teams dream about: mathematical proof that every state transition is authorized.

Part 3: Developer Experience Without Compromise

"Security is critical. But if the developer experience isn't frictionless, adoption dies in the pull request."

We heard that. Blueprint wraps its cryptographic engine in a Kotlin DSL so natural, it feels like writing Compose.

Server: Build UIs Like You're Writing Jetpack Compose

// Ktor backend - type-safe, auto-completed, cryptographically secure
val ordersScreen = blueprint("order_list") {
    metadata(title = "My Orders", description = "Active orders")

    // Server-owned state that drives dynamic UI
    state("total_orders" to "5", "username" to "John")

    root {
        Column(
            verticalArrangement = LayoutArrangement.START, modifiers = {
                background("#F8F9FA")
                fillMaxSize()
            }) {
            // Binds to state["username"] - server changes this instantly
            Text(
                content = bindString("username"), size = TextSize.HEADLINE_LARGE
            )

            LazyColumn(contentPadding = 24f) {
                Card(
                    variant = CardVariant.FILLED,
                    onClickIntentId = "navigate_detail:1",
                    modifiers = { cornerRadius(20f); padding(bottom = 16f) }) {
                    Text("Order #1", size = TextSize.TITLE_MEDIUM)
                }
            }

            Button(
                text = "Refresh", variant = ButtonVariant.FILLED, onClickIntentId = "refresh_orders"
            )
        }
    }
}

// One line to seal it cryptographically
val signedBlueprint = CryptoUtils.createSignedBlueprint(ordersScreen, currentHash)

No manual hashing. No signature boilerplate. The framework handles the chain automatically.

Client: Native Compose Rendering with Built-in Verification

@Composable
fun Application(store: ApplicationStore) {
    val state by store.state.collectAsState()

    val renderer = remember { createDefaultBlueprintRegistry() }

    MaterialTheme {
        when (val blueprint = state.chain.current) {
            null -> LoadingScreen()

            else -> renderer.render(blueprint = blueprint, intentHandler = { intent -> store.dispatch(intent) })
        }
    }
}

The BlueprintComposeRegistry maps ComponentPayload directly to Material 3 Compose components. No WebViews. No JavaScript bridges. 100% native rendering, 100% cryptographically verified.

Part 4: Pure Functional Core - Predictable, Testable, Crash-Free

Blueprint's state machine is built on pure functional programming principles. Every operation returns Either<ChainError, BlueprintChain> - a monadic type that makes failure a first-class citizen, not an exception.

// ApplicationStore.kt - the entire state reduction pipeline
private fun handleResolution(resolution: Resolution) {
    val events = buildList {
        resolution.effects.forEach { effect ->
            when (effect) {
                is Effect.Navigation -> {
                    when (effect.type) {
                        Type.PUSH -> effect.blueprint?.let { add(ChainEvent.Push(it)) }
                        Type.REPLACE -> effect.blueprint?.let { add(ChainEvent.Replace(it)) }
                        Type.POP -> add(ChainEvent.Pop)
                    }
                }
            }
        }
        if (resolution.deltaBlocks.isNotEmpty()) {
            add(ChainEvent.ApplyDeltas(resolution.deltaBlocks))
        }
    }

    // Fail-fast monadic fold - any error halts the entire chain update
    _state.update { currentState ->
        when (val result = events.foldEither(currentState.chain) { chain, event ->
            chain.reduce(event)
        }) {
            is Either.Left -> {
                // Security breach or navigation error - safe, typed, no crash
                currentState.copy(
                    error = "Chain integrity violation: ${result.value}", isLoading = false
                )
            }

            is Either.Right -> {
                // All transitions validated, chain updated atomically
                currentState.copy(chain = result.value, isLoading = false)
            }
        }
    }
}

This architecture gives you:

Deterministic behavior - same inputs always produce same outputs.
Trivial unit testing - no mocking, just data in, data out.
Zero runtime crashes from invalid state - Either enforces error handling at compile time.
Mathematical immunity to garbage payloads - because the state machine is purely functional and strictly typed, it is mathematically impossible for a malicious payload to force the UI into an undefined, exploitable state. If the payload doesn't fold cleanly into the existing chain, the transition simply doesn't happen.

Part 5: Why This Becomes the Standard

The trajectory is clear:
2024: Regulators in EU and US signal stricter requirements for financial app integrity.
2025: Major banks mandate cryptographic proof of UI authenticity in vendor RFPs.
2026: Zero-Trust SDUI becomes an industry compliance checkbox - like SOC 2 or PCI DSS.

Blueprint is ready today. It's the only Kotlin Multiplatform framework that:

✅ Treats UI as a cryptographically verifiable state machine
✅ Provides hash chaining to prevent screen injection and replay attacks
✅ Signs all state mutations with industry-standard RSA
✅ Delivers native Compose performance on Android, iOS, and Desktop
✅ Offers a type-safe DSL that eliminates an entire class of serialization bugs
✅ Aligns with NIST SP 800–207 Zero Trust Architecture principles
✅ Supports key rotation for enterprise key management policies

This is not a niche security feature. It's the missing layer between "dynamic UI" and "auditable UI."

Security FAQ

Q: Does this add latency to navigation?
A: No. All verification is local. SHA-256 hashing adds < 0.3ms. RSA signature verification adds < 2ms. The entire chain validation completes in under 4ms - less than a single frame at 60 FPS.

Q: What if the private key leaks?
A: Same as any PKI system - key rotation. Blueprint's SignatureVerifier interface supports pinning multiple public keys simultaneously. During rotation, the server signs with the new key while clients accept both old and new public keys. Once all clients update, the old key is revoked.

Q: Does this work offline?
A: The chain validates locally with zero network calls. Navigation between cached screens is fully verified offline. Only new state mutations require fresh server signatures - exactly like JWT validation, but for your UI.

Q: Can I use this without the cryptographic features?
A: Yes. Set strictMode = false and the chain operates as a standard navigation stack. You can adopt the SDUI patterns first, then enable cryptographic verification when your compliance requirements demand it.

Q: What attack vectors does this actually prevent?
A: Blueprint prevents five critical attack classes:

Payload injection - Malicious screens inserted via compromised CDN or proxy
UI replay attacks - Old "success" screens replayed to hide errors or fraud
State tampering - Runtime modification of bound values (account numbers, amounts)
Screen spoofing - Phishing screens injected into the navigation flow
Internal lateral movement - Compromised microservice injecting malicious UI payloads

Getting Started

Blueprint is open-source under Apache 2.0. The repository includes a fully functional example with a Ktor backend and Compose Desktop client demonstrating the complete cryptographic flow.

→ GitHub Repository
→ Full Documentation & Architecture Guide
→ Example: Order Tracking App with Zero-Trust Chain

The Bottom Line

Every time you deserialize a JSON UI payload without cryptographic verification, you're handing a blank check to any attacker who compromises your transport layer. TLS encrypts the pipe. It doesn't prove the payload is authentic.

Blueprint changes the equation. It transforms your client from a "trusting renderer" into a verifying validator - mathematically certain that every pixel, every button, every state transition originates from your authorized backend.

Don't take my word for it. Clone the repository, launch the example app, and try to intercept and modify the JSON payload on the fly using Charles Proxy or Proxyman. You'll see Blueprint stop the attack dead in its tracks.

Don't just ship dynamic UIs. Ship verifiable UIs. Ship Blueprint.

Building High-Performance Text Editors in Kotlin Multiplatform with Krope

numq — Fri, 24 Jul 2026 13:02:16 +0000

If you have ever tried building a text editor, an IDE, or a collaborative document tool, you quickly run into a fundamental wall: how do you store the text?

At first glance, a standard String seems fine. But Strings are immutable; changing a single character in a 1MB file requires allocating a brand new 1MB array. So, you move to StringBuilder. It’s mutable and fast for simple appends, but inserting or deleting text in the middle of a massive document still requires shifting hundreds of thousands of characters in memory — an O(N) operation that causes UI stuttering as your document grows.

This is where the Rope data structure comes in.

Today, I want to introduce Krope, a high-performance, memory-safe, and reactive Rope library built entirely in Kotlin Multiplatform. Whether you are targeting JVM, Android, iOS, or WASM, Krope provides the engine you need to build next-generation text editing tools.

What is a Rope?

Instead of storing text as a single massive, contiguous array of characters, a Rope stores text as a balanced binary tree (in Krope’s case, utilizing a Red-Black tree variant). The leaves of the tree contain short chunks of strings.

When you insert text in the middle of a document, a Rope doesn’t copy the whole string. Instead, it splits a leaf node and inserts a new branch. This gives operations like insertion, deletion, and replacement a time complexity of O(log N).

Furthermore, Krope implements structural sharing. When a modification occurs, Krope doesn’t mutate the existing tree; it returns a new tree that shares the untouched branches with the old one. This provides safe concurrent access, cheap undo/redo history.

Why I Built Krope

The idea for Krope was born while building haskcore — a full-featured IDE for Haskell written in Compose Desktop. It uses Skia for rendering, Tree-sitter for incremental syntax parsing, and the Language Server Protocol for code intelligence. It’s a real editor with 40+ modules, handling everything from syntax highlighting to code completion and project-wide diagnostics.

Very quickly, I hit a wall: Kotlin’s standard StringBuilder couldn't keep up. Editing large Haskell modules meant shifting massive text buffers on every keystroke, causing visible lag during syntax highlighting and LSP synchronization. I needed something better — and the rope data structure, battle-tested in editors like Emacs and Vim since the 90s, was the obvious answer.

But Kotlin Multiplatform lacked a modern, reactive, and fully-featured rope implementation. So I built Krope to solve the specific pain points I encountered:

Cross-Platform Consistency: haskcore targets the desktop, but the same text engine should work on Android, iOS, and WASM for future ports or companion apps.
Reactive by Design: Compose Multiplatform thrives on reactive state. Krope exposes every edit as a SharedFlow event and every document state as a StateFlow, making UI integration seamless.
Byte-Level Encoding Awareness: LSP servers speak in byte offsets, not character positions. Krope natively tracks UTF-8, UTF-16, and UTF-32, giving you efficient access to byte coordinates backed by an LRU cache.
Functional & Safe: Invalid operations shouldn’t crash your editor. Krope uses an Either<Throwable, Result> pattern, so out-of-bounds inserts return errors you can handle gracefully — critical when processing remote edits from LSP or collaborative peers.

Inside the Krope API

Krope separates the underlying data structure from the editor API. The primary interface you interact with is the TextBuffer.

Here is how simple it is to get started:

import io.github.numq.krope.core.Encoding
import io.github.numq.krope.text.*
import kotlinx.coroutines.launch

// 1. Initialize the buffer
val factory = RopeTextBufferFactory()
val buffer = factory.create(
    text = "Hello World",
    encoding = Encoding.UTF8,
    lineEnding = TextLineEnding.LF,
    enablePooling = true // Enables internal string interning to save memory
).fold(
    onLeft = { error -> throw error },
    onRight = { it }
)

The Reactive Paradigm

In a standard text editor, the UI needs to know exactly what changed to update the screen or send a diff over the network for collaborative editing. Krope exposes two flows:

snapshot: StateFlow<TextSnapshot>: Represents the immutable current state of the document.
data: SharedFlow<TextEdit.Data>: Emits granular events whenever the text changes.

// Observe all changes in real-time
launch {
    buffer.data.collect { editData ->
        when (editData) {
            is TextEdit.Data.Single.Insert -> 
                println("Inserted '${editData.insertedText}' at ${editData.startPosition}")
            is TextEdit.Data.Single.Delete -> 
                println("Deleted text ending at ${editData.oldEndPosition}")
            is TextEdit.Data.Single.Replace -> 
                println("Replaced '${editData.oldText}' with '${editData.newText}'")
            is TextEdit.Data.Batch -> 
                println("Batch processed ${editData.singles.size} operations atomically")
        }
    }
}

Line and Column Awareness

Most ropes just deal with raw character offsets. Krope natively understands Lines and Columns through TextPosition.

// "Hello Beautiful World"
buffer.insert(TextPosition(line = 0, column = 5), " Beautiful")

// Querying the snapshot is instantaneous thanks to cached tree node metadata
val snapshot = buffer.snapshot.value
println("Total Lines: ${snapshot.lines}")
println("Max Line Length: ${snapshot.maxLineLength}")

// Get byte offset for an LSP (Language Server Protocol)
val byteOffset = snapshot.getBytePosition(TextPosition(line = 0, column = 6))

Atomic Batch Operations

When you refactor code (like renaming a variable that appears 10 times in a file), you don’t want to trigger 10 separate UI redraws or clutter the undo stack. Krope supports withBatch:

buffer.withBatch { batch ->
    batch.replace(TextRange(TextPosition(0, 39), TextPosition(0, 42)), "vatAmount")
    batch.replace(TextRange(TextPosition(1, 19), TextPosition(1, 22)), "vatAmount")
}

This applies all edits internally, rebalances the tree once, and emits a single TextEdit.Data.Batch event to your listeners.

Performance: The 100 Megabyte Test

To answer the age-old question - "How does it perform with very large files?" - I ran JMH benchmarks on the JVM comparing Krope to StringBuilder.

We simulated the "Real Editor Scenario": 100 consecutive edits (insertions) occurring right in the middle of a document. We scaled the document size from 100,000 characters all the way to 100,000,000 characters (approximately 200 MB of text).

Here are the results (in milliseconds per 100 operations):

100,000 symbols

Krope: ~0.05 ms
StringBuilder: ~0.16 ms
Krope Advantage: ~3x faster

1,000,000 symbols

Krope: ~0.19 ms
StringBuilder: ~1.74 ms
Krope Advantage: ~9x faster

10,000,000 symbols

Krope: ~2.07 ms
StringBuilder: ~17.86 ms
Krope Advantage: ~8.5x faster

100,000,000 symbols

Krope: ~19.32 ms
StringBuilder: ~186.41 ms
Krope Advantage: ~9.6x faster

Why does StringBuilder choke?

Look at how the StringBuilder time multiplies by 10 every time the file size multiplies by 10. This is the curse of O(N) complexity. When you insert a single character in the middle of a 200MB StringBuilder, Java has to use System.arraycopy to physically shift 100MB of data in RAM to make room. Doing this 100 times forces the CPU to move 10 gigabytes of memory. This is exactly what causes UI thread stuttering and input lag in text editors.

Why does Krope win?

Because of structural sharing and its Red-Black tree foundation. When making 100 edits, Krope doesn't copy 100MB of arrays. It simply splits a small leaf node, updates a few pointers up to the root, and does a lightning-fast O(log N) tree rebalance.

(Note: In the benchmark above, the ~19.32 ms for Krope actually included the time to parse the 200MB string into a Rope tree from scratch on every iteration! The edits themselves are nearly instantaneous).

In a real-world typing or refactoring scenario, Krope maintains incredibly flat, predictable latency regardless of whether your file is 10 Kilobytes or 200 Megabytes, keeping your UI perfectly smooth while drastically reducing heap allocations.

Get Involved

If you are building text-heavy applications in Compose Multiplatform, writing a code editor, or experimenting with CRDTs for collaborative editing, give Krope a try.

The architecture is highly modular, separating the core data structures from the TextBuffer API, and includes built-in support for kotlinx.serialization.

Check out the source code, play with the examples, and star the repository on GitHub!

🔗 GitHub Repository: Krope

JetBrains Just Changed KMP Structure. Here's What They Didn't Tell You.

numq — Mon, 18 May 2026 18:18:29 +0000

JetBrains announced a new default project structure for KMP. Two shared modules — sharedLogic and sharedUI — plus separate application modules for each platform. Clean. Simple. Obvious.

It's also a trap.

The problem with `sharedLogic` and `sharedUI`

A fresh sharedLogic module looks innocent. Business logic, models, repositories. sharedUI holds your Composables. What could go wrong?

Three months later sharedLogic contains:

Business logic
Network clients
Database models
Constants
Utility functions
Something called CommonUtils.kt that nobody understands but everyone is afraid to delete

sharedLogic has no internal boundaries. Everything depends on everything. You can import a database model from a use case and nobody stops you. The compiler certainly won't.

JetBrains tells you where to start. They don't tell you what happens when two modules become 50,000 lines.

What actually happens

You try to split sharedLogic into more modules. But there are no rules. So you end up with:

:sharedLogic:core — the new dumping ground
:sharedLogic:data — which also contains business logic somehow

The dependencies look like spaghetti. Changing one module breaks three others. You didn't enforce boundaries early, and now every refactoring is a gamble.

FLIP: the next step after `sharedLogic`

FLIP is an architectural pattern that gives you rules for splitting sharedLogic before it becomes a problem.

Five layers. One direction. Zero horizontal dependencies.

Layer	Purpose	Depends on
`:common:core`	Foundation	Nothing
`:service`	Domain logic without UI	`:common:core`
`:feature`	UI features	`:service`, `:common:core`
`:entrypoint`	DI assembly + slot composition	Everything above
`:platform`	Platform entry point	`:entrypoint`

The rule is simple: features don't know about other features. services don't know about other services. Dependencies only flow down.

Your IDE enforces this. You literally cannot import a feature from another feature — Gradle won't compile. The structure prevents the dumpster fire before it starts.

Start with JetBrains. Grow with FLIP.

The new KMP structure is a great starting point. Two modules is better than one. But when sharedLogic starts feeling like a junk drawer, you know what to do.

FLIP is at github.com/numq/flip. Template included. Konsist tests included. Rules over conventions.

Stop Fighting Your State. Reduce And Conquer It.

numq — Wed, 13 May 2026 18:16:46 +0000

MVVM seemed simple. Then you added ten MutableStateFlow properties to your ViewModel. MVI promised purity. Then you wrote a middleware for side effects.

There’s a better way.

The Problem With MVVM

A typical ViewModel looks like this:

class ProfileViewModel : ViewModel() {
    val name = MutableStateFlow("")
    val email = MutableStateFlow("")
    val isLoading = MutableStateFlow(false)
    val error = MutableStateFlow<String?>(null)

    fun updateProfile(name: String) {
        viewModelScope.launch {
            isLoading.value = true
            try {
                profileService.update(name)
                this@ProfileViewModel.name.value = name
            } catch (e: Exception) {
                error.value = e.message
            } finally {
                isLoading.value = false
            }
        }
    }
}

Five mutable properties. Loading state scattered across three places. Error handling duplicated in every method. And the ViewModel doesn’t own its side effects — viewModelScope does.

The Problem With MVI

MVI fixes the state explosion by putting everything in a sealed interface:

sealed interface ProfileState {
    data object Loading : ProfileState
    data class Loaded(val name: String, val email: String) : ProfileState
    data class Error(val message: String) : ProfileState
}

But MVI doesn’t tell you how to handle side effects. Some use middleware. Some use Channel. Some hack it with LaunchedEffect. Every project reinvents the wheel.

Reduce & Conquer

The core idea: a reducer is a pure function that returns more than just state.

data class Transition<State, Event>(
    val state: State,
    val events: List<Event> = emptyList(),
    val effects: List<Effect> = emptyList()
)

A transition has three outputs:

State - the new state
Events - one-shot notifications (navigation, snackbar)
Effects - long-running or async work

Effects are first-class citizens:

sealed interface Effect {
    data class Stream<Command>(
        val key: Any,
        val flow: Flow<Command>,
        val strategy: Strategy = Strategy.Sequential,
        val fallback: (suspend (Throwable) -> Command)? = null
    ) : Effect

    data class Action<Command>(
        val key: Any,
        val fallback: (suspend (Throwable) -> Command)? = null,
        val block: suspend () -> Command
    ) : Effect

    data class Cancel(val key: Any) : Effect
}

Stream - subscribes to a flow, emits commands back
Action - runs one async operation, emits a command
Cancel - cancels by key, preventing leaks

A Reducer in Practice

class ProfileReducer(
    private val profileService: ProfileService
) : Reducer<ProfileState, ProfileCommand, ProfileEvent> {

    override fun reduce(
        state: ProfileState,
        command: ProfileCommand
    ): Transition<ProfileState, ProfileEvent> = when (command) {
        is ProfileCommand.UpdateProfile -> transition(
            state.copy(isLoading = true)
        ).effect(
            action(
                key = "update_profile",
                fallback = { ProfileCommand.ProfileError(it) },
                block = {
                    profileService.update(command.name)
                    ProfileCommand.ProfileUpdated
                }
            )
        )

        is ProfileCommand.ProfileUpdated -> transition(
            state.copy(isLoading = false)
        ).event(ProfileEvent.NavigateBack)

        is ProfileCommand.ProfileError -> transition(
            state.copy(
                isLoading = false,
                error = command.throwable.message
            )
        )
    }
}

No viewModelScope. No LaunchedEffect. No mutable properties. One pure function.

Why This Is The Benchmark

MVVM

State: Multiple MutableStateFlow
Side effects: viewModelScope.launch
Cancellation: Manual
Testing: Mock ViewModel

MVI

State: Single sealed class/interface
Side effects: Ad-hoc (middleware, Channel)
Cancellation: Manual
Testing: Mock reducer + middleware

Reduce & Conquer

State: Single sealed interface
Side effects: Built-in (Effect)
Cancellation: Automatic by key
Testing: One pure function call

Testing a reducer:

@Test
fun `update profile sets loading and fires effect`() {
    val transition = reducer.reduce(
        state = ProfileState(),
        command = ProfileCommand.UpdateProfile("Alice")
    )

    assertTrue(transition.state.isLoading)
    assertEquals(1, transition.effects.size)
    assertEquals(0, transition.events.size)
}

One call. No coroutines. No mocks.

The Rule

State flows down. Commands flow up. Effects manage the rest.

The View sends Commands. The Reducer returns a Transition with new State, Events, and Effects. The Feature executes Effects and feeds resulting Commands back into the Reducer. That's it.

Full implementation in the GitHub repository.

A recipe for the Perfect Use Case

numq — Wed, 13 May 2026 18:05:16 +0000

Today we’re cooking the perfect Use Case — and CQRS will be our recipe.

Ingredients

Action — fire and forget (logout, clear cache)
Query — read data (list products)
Command — write data (update profile)
Exchange — transform data (login)

All four types extend a sealed interface:

sealed interface UseCase<Input, Output> {
    interface Action : UseCase<Unit, Unit>

    interface Query<Output> : UseCase<Unit, Output>

    interface Command<Input> : UseCase<Input, Unit>

    interface Exchange<Input, Output> : UseCase<Input, Output>
}

Three Ways to Season It

Arrow (Typed Errors) — the chef’s choice:

class GenerateSeed(
    private val seedService: SeedService
) : UseCase.Action {
    override suspend fun Raise<Throwable>.action() =
        seedService.generateSeed().bind()
}

Result (Standard Wrapper) — zero dependencies:

class GenerateSeed(private val service: SeedService) : UseCase.Action {
    override suspend fun action() = service.generateSeed().getOrThrow()
}

Raw (Direct Execution) — zero overhead:

class GenerateSeed(private val service: SeedService) : UseCase.Action {
    override suspend fun action() = service.generateSeed()
}

Why This Recipe Works

No more UseCase<Unit, Unit> noise
Every use case follows the same structure
Query or Command makes intent obvious

Full implementation in the GitHub repository.

FLIP: Modular Architecture for KMP

numq — Wed, 13 May 2026 17:53:17 +0000

While building haskcore - an IDE for Haskell on Compose Desktop - I extracted rules that allowed me to create an architecture of 40 isolated modules, where each module knows only what it needs.

That's how FLIP - Feature-Layered Isolated Platform - was born.

The main problem I faced during development: horizontal dependencies make the system fragile. The solution - strict vertical hierarchy.

FLIP consists of the following isolated modules:

:common:core - common logic components.
:common:presentation - common UI components.
:service - UI-less domain module. Provides a service interface.

interface SeedService : AutoCloseable {
    val seed: Flow<Seed>

    suspend fun generateSeed(): Either<Throwable, Unit>
}

:feature:core — logic module of a UI-feature. Knows nothing about other features. Uses services from :service. Provides use cases.

class GenerateRemoteRandomSeed(private val seedService: SeedService) : UseCase.Action {
    override suspend fun Raise<Throwable>.action() = seedService.generateSeed().bind()
}

:feature:presentation — UI module of a UI-feature. Knows only about its :feature:core and uses its use cases. Provides the view. Knows only about its own :feature:core.
:entrypoint — module where dependency configuration and composition of views from :feature:presentation into a single Composable happens.
:platform — module that initializes the Composable provided by :entrypoint for each platform.

Arrows show the direction of dependencies.

How to structure your system?

Decide which features your app should have, then determine whether each feature has a UI:

If it does — it’s a feature.
If it doesn’t — it’s a service.
If one feature’s logic is needed by another — extract it into a separate service.

Important: both :service and :feature:core contain domain logic:

:service — core domain.
:feature:core — presentation domain (use cases).

Wrong:

:service:foo
:feature:foo:core
:feature:foo:presentation

Right:

:service:foo
:feature:bar:core
:feature:bar:presentation

Navigation in FLIP is just another feature. It aggregates and routes views passed as lambda slots, keeping it independent from other features.

NavigationView(
    splash = {
        SplashView(applicationScope = applicationScope)
    },
    profile = {
        ProfileView(applicationScope = applicationScope)
    }
)

This approach lets you add new screens without touching existing features.

A complete example is available in the official GitHub repository.

DEV Community: numq

Stop Trusting Your UI: Why Zero-Trust Server-Driven UI is the Next Industry Standard

Part 1: The Billion-Dollar Blind Spot

🔴 Traditional SDUI (Vulnerable)

🟢 Blueprint Zero-Trust SDUI (Immune)

Part 2: The Blueprint Chain - Your UI on a Blockchain

Hash Chaining: Every Screen Knows Its Parent

Performance That Does Not Sacrifice UX

State Deltas with RSA Signatures: Surgical, Signed Updates

Part 3: Developer Experience Without Compromise

Server: Build UIs Like You're Writing Jetpack Compose

Client: Native Compose Rendering with Built-in Verification

Part 4: Pure Functional Core - Predictable, Testable, Crash-Free

Part 5: Why This Becomes the Standard

Security FAQ

Getting Started

The Bottom Line

Building High-Performance Text Editors in Kotlin Multiplatform with Krope

What is a Rope?

Why I Built Krope

Inside the Krope API

The Reactive Paradigm

Line and Column Awareness

Atomic Batch Operations

Performance: The 100 Megabyte Test

Why does StringBuilder choke?

Why does Krope win?

Get Involved

JetBrains Just Changed KMP Structure. Here's What They Didn't Tell You.

The problem with sharedLogic and sharedUI

What actually happens

FLIP: the next step after sharedLogic

Start with JetBrains. Grow with FLIP.

Stop Fighting Your State. Reduce And Conquer It.

The Problem With MVVM

The Problem With MVI

Reduce & Conquer

A Reducer in Practice

Why This Is The Benchmark

MVVM

MVI

Reduce & Conquer

The Rule

A recipe for the Perfect Use Case

Ingredients

Three Ways to Season It

Why This Recipe Works

FLIP: Modular Architecture for KMP

How to structure your system?

The problem with `sharedLogic` and `sharedUI`

FLIP: the next step after `sharedLogic`