Kobweb's design

[stevenflautner]

Hey there! I have been testing Kobweb in order to migrate my full stack project running in production. It was built with a custom framework, and uses Ktor. I really appreciate the tooling that Kobweb brings which is lacking in the Kotlin for web community. That being said I have a hard time trying to migrate my existing Ktor server despite having the option to create a custom ServerPlugin and there's a few reasons for that.

While a ServerPlugin (which needs it's own tedious setup) gives you access to the configuration of Ktor and I was able to create custom endpoints I still can't reconfigure e.g. ContentNegotiation and the likes. "Hot restart" also doesn't seem to pull ServerPlugin changes which was a selling point for me.

For the best developer experience when you setup kobweb core, You immediately have your compose html with a ktor webserver working with Ktor exposed. But no additional configuration between the client and the server should be part of core, and any core configuration to the webserver should potentially be supplemented.

Silk, Api, Streaming should be built on top of this leaving no trace in Kobweb's core. I understand these might need their own configuration, but this should be done as an additional dependency and as a plugin to Ktor. Exposing Ktor might produce conflicting configurations, doing so via plugins we would be able to make suitable changes and opt into features as we see fit.

While I understand this was the initial focus of the project I believe this would enable many more projects to consider using Kobweb for it's many advantages.

Thank you for your hard work and building Kobweb

[bitspittle]

I really appreciate comments like this. It's clear you're taking your time to explore and engage with the framework.

Just to make sure you're aware, I absolutely want the "user has a custom ktor server" approach to work someday. You can see me mentioning this both in our roadmap (backend section) and this very old bug (which shows I've been biting my nails about this one for a while).

"Hot restart" was a lot of effort to get working, and it works only because it introduces a level of abstraction. Even all my ktor code is baked in at compile time -- all the hot reloading stuff is one level down. (This is why I don't use web sockets directly in Kobweb but introduce my own API streams -- they look like web sockets but they're all new code which are delegated to by web sockets)

As for having the server drive the behavior of your site, that unfortunately wouldn't work for a vast majority of Kobweb's users who use a static hosting site provider to serve their files directly. (See this discussion if you're not already familiar with it).

For now, my best recommendation for custom ktor folks is to have them export their sites using kobweb export --layout static and then add code in their own ktor servers to serving those files directly. (It should be really easy using the APIs discussed here). Of course you'll lose live reloading at this point, but at least it will give you access to kobweb routing and Silk support if that's important to you.

I think the ultimate plan will be to refactor parts of the Kobweb ktor server out into separate libraries which then you could import in your own ktor server. But given everything else on my list, it's not something high on my current priorities, and it may even prove troublesome for reasons I can't quite foresee.

I hope this helps explain a bit why Kobweb is designed the way it is, although please keep the conversation going if you feel like I'm missing something.