hey guys, I'm gonna continue my last thread some how about how structure a backend (REST api) applic...

# ktor

[Ramin]

hey guys, I'm gonna continue my last thread some how about how structure a backend (REST api) application with ktor or let's say with kotlin. I tried to read kotlin conf backend and I see a normal php application is much more organized and structured than what I can see in KotlinConf app. the question is how do you feel about it. is there anybody in here who is going to develop a complete application with ktor or kotlin? to me it seems ktor needs a boilerplate or something to be more structured with a comprehensive web application

[bdawg.io]

What do you mean by “structured”? Are you referring to conventions similar to rails (ie, a Controllers directory with a MemberController, a Models directory with a Member model, etc) or pods (ie, a Members directory with its controller, models, etc)?

[Ramin]

yes similar to what you mentioned about rails. as far as I see in KotlinConf app nothing is tidy all configuration initialization and routing is in a big messy file

[Ramin]

I couldn't find any good example how things should organize in a ktor app

[Ramin]

apart from it I'm more curios if people are using kotlin for writing a comprehensive api or it's more suitable and focus on android.

[bdawg.io]

We use it but we leave it to our teams to define and document what the project's convention is. "Pod" style is the most popular (structured around your data types instead of your class types, ie, a members directory with the types that deliver member APIs whether it be controllers, models, etc)

[Shawn]

what is a “normal” php application anyhow

[Shawn]

is Laravel normal?

[Shawn]

Symfony?

[Shawn]

CodeIgniter?

[bdawg.io]

Messy is subjective to the convention you expect to be used. IMO the KotlinConf backend is fine because all of the API handlers are in a single file that's only a few hundred lines of code. That API is extremely simple and primarily serves data and isn't a long-term application that needs to have tens or hundreds of developers continually build it

[Shawn]

there’s also really nothing stopping you from writing a Spring Boot or Dropwizard or Vaadin or whatever application in Kotlin if you really want that mandated structure

[Ramin]

@Shawn all of them have a well structured layout that anybody can understand at first sight if the know MVC but I couldn't find any stright forward decoupled layout which is a big weakness to me

[dave08]

It's not too hard to seperate api into multiple files using fun Routing.mainController(injecatableRepo: MainRepo) and calling them from the main application inside a route { } to show where its under. A bit like Symfony Silex mounting... You can also make your own controller classes (I think @Deactivated User has a repo of examples of using DIs and other such things.

[dave08]

https://github.com/ktorio/ktor-samples

[dave08]

A bit like the YouKube example there (although I prefer not using locations, or putting them in the corresponding file, also I like "mounting" them in the application file to a base route.

[poohbar]

I feel like Ktor does not enforce any structure. You can choose any structure you want and use it. So far it seems quite similar to Spark although it is probably very different under the hood.

[dave08]

You're right @poohbar, but the question was how to structure the code using Ktor in an organized way. When the Api gets bigger, not having some organization principles can result in a big mess...

[poohbar]

I see.. well I think the answer is "however you want". I am used to Spring Boot mostly so my Ktor app would probably resemble Spring Boot in structure. For example I use Koin and have a single file where I wire all my dependencies which very much resembles a @Configuration class in Spring Boot.

[dave08]

Other frameworks provide the ability to make Controllers or similar patterns to organize things, in Ktor, a beginner just sees a big DSL that doesn't seem to be easy to "split up"... until you get used to receiver functions, and know how to hook up a DI...