Bringing the Joy of Ktor to Cloudflare Workers: Sharing Types and Logic at the Edge

[mole828]

The Vision
Imagine the perfect full-stack Kotlin workflow: Sharing your Data classes between a Kotlin/JS frontend and a Cloudflare Worker backend, using Ktor's elegant DSL for routing. No more manual JSON mapping, just pure, type-safe Kotlin across the entire stack.

My Current Experiment
I've been working on a proof-of-concept here: mole828/ktor-cloudflare-worker.

The goal is to use Ktor Server's routing inside a Worker. My current strategy is to bridge the Cloudflare Fetch API into Ktor's processing pipeline.

The Technical "Hiccup"
While trying to handle requests, I encountered a roadblock. When using parts of Ktor's infrastructure (like TestApplication or certain engine components) to process the request/response, the compiler pulls in Node.js-specific modules (e.g., os, fs).

Since Cloudflare Workers run in a V8 Isolate (not Node.js), it throws: Uncaught ReferenceError: os is not defined

Discussion Points
I believe Ktor is already very close to being "Edge-ready," but we might need a small push:

Lightweight Request Handling: Is there an existing way in Ktor to run the routing logic in a "pure" JS environment without triggering Node.js dependencies?

Custom Engine: Would a ktor-server-cloudflare (or a generic Fetch-based engine) be the right path? I'm curious if the maintainers have thought about a "Standard Web API" target for Ktor Server.

Environment Agnostic Core: How can we ensure ktor-server-core stays decoupled from the underlying JS runtime (Node vs. V8)?

Why this matters
Ktor's coroutine-based model is a perfect fit for the event-driven nature of Workers. Solving this would open the door for Kotlin developers to build ultra-fast, type-safe global APIs with zero friction.

Post.content = myIdeas.map { AI.translate(it) }

[Bruce Hamilton (bjhham)]

Interesting idea... We do currently assume that any JS code is running in either the browser or Node. A custom engine would be the right idea, though the abstraction doesn't quite align with the worker's runtime, because it would require managing the lifecycle and state of a Ktor server. I'll think about the solution and get back to you. It may be useful for us to provide a separate application container, without a lifecycle or coroutine contexts, that can be called like a function for serverless function environments.

[ghostflyby (ghostflyby)]

I have made a example server engine using purely kotlin-wrappers web types, but not being able to run for testing due to Kotlin/kotlinx-io#496 referenced by

ktor/ktor-server/ktor-server-core/common/src/io/ktor/server/engine/ServerEngineUtils.kt

Line 9 in 1115fae

internal val WORKING_DIRECTORY_PATH: String = SystemFileSystem.resolve(Path(".")).toString()

Workers do have nodejs_compat, but kotlinx-io is for some reason using eval which is not available.

[Bruce Hamilton (bjhham)]

Looks like a good approach for this here, though I can't think of a workaround for the watch paths issue atm. Ideally we could provide some shell of the embedded server that doesn't reference watch paths, ports, or lifecycle events, for direct calls like this.

[ghostflyby (ghostflyby)]

I solved the kotlinx-io problems temporarily by monkey-patching (Nice, JavaScript), and the example now works well.

[Bruce Hamilton (bjhham)]

Beauty! 🏆