basic one but what's the best pattern for accessing config in top level functions (or is this just n...

# ktor

[Henry]

basic one but what's the best pattern for accessing config in top level functions (or is this just not the way to do things)? e.g.

fun fetchInternalClientInstance() { ...I need access to application.config in here...}

on a wider point could anyone link me to some resources discussing higher level application architecture with ktor as I'm starting to get beyond what is covered by the Youkube example?

[Henry]

Similarly it'd also be useful to get access to the application coroutine context which is also accessible through the application instance

[David Eriksson]

I suggest you try to follow the setup pattern for ktor itself

[Henry]

makes sense, it's just a big shift coming from a service-oriented design!

[David Eriksson]

I'm trying to find a suitable example...

[David Eriksson]

https://ktor.io/samples/feature/custom-feature.html

[David Eriksson]

Maybe

[David Eriksson]

Depends a bit what you need the config for 🙂

[David Eriksson]

Maybe it's not a Feature (similar to a middleware in ExpressJs or .NET MVC) you want the config for

[David Eriksson]

But by writing extension functions to Application you have all its context

[mp]

personally I don't like the way the ktor project guides you towards doing config. I suggest just using embeddedServer in a main method, and then you can do config any way you please. Load from env vars, or property files, or whatever, at startup and distribute the resulting config object(s) as you see fit

[mp]

I think it's a mistake to bolt that sort of lifecycle stuff (reading config out of files) into an HTTP server lib.

[Henry]

thanks for responses

[Henry]

I think it's a mistake to bolt that sort of lifecycle stuff (reading config out of files) into an HTTP server lib.

this is possibly true but I'm seeing what I can do with a pure ktor implementation for now

[Henry]

(there are benefits to a tightly integrated config system as well imo)

[David Eriksson]

Framework vs library @mp? 🙂

[Henry]

@David Eriksson I suppose making all my top level functions extensions on application is an option. They then remain callable from routes etc.

[David Eriksson]

I think that's the ktor way

[Henry]

makes sense

[Henry]

I'll give it a go, thanks for the tip!

[David Eriksson]

It feels pretty strange compared to the "class-based" like Spring Boot or DropWizard :)

[Henry]

yeah it's an interesting shift in mindset

[mp]

The extension function way breaks down as the app grows because you'd need all the various support objects (Db connections, etc) in scope.

[Henry]

I can well imagine that happening

[mp]

I maintain a demo project showing patterns I've used in other (production) ktor services: https://bitbucket.org/marshallpierce/ktor-demo/src/master/

[Henry]

I'm already wondering about the best way to use kodein with this pattern as it's straightforward with service constructor injection

[mp]

key principle: every component is replacable, as much as possible. Obviously ripping out ktor is going to be more of a pain since all the url routing would change, but you could do it. Same for everything else.

[mp]

Don't like the way that project does config? Or json mapping? or whatever? select the corresponding code, press delete, do what you like.

[mp]

that said, the components I've chosen all play nicely together, and if you don't want to worry about every detail, you won't hate it if you just go with what I've picked.

[mp]

re injection with kodein or anything else - just set up routes in your constructor, as here: https://bitbucket.org/marshallpierce/ktor-demo/src/9180858c267194e6a75d39dc9e8280e3ba53777a/src/main/kotlin/org/mpierce/ktordemo/WidgetEndpoints.kt#lines-27

[mp]

That's using Guice but the same idea would work for anything

[Henry]

oh so you're using DI to inject the application object

[Henry]

that did seem like a viable alternative

[Henry]

removes the need to make all your service functions extension functions as well

[Henry]

well thanks again everyone

[Henry]

will go off and build some things

[Henry]

and see what happens

[mp]

best way to learn!

[Henry]

quite!

[David Eriksson]

Your demo is very interesting @mp, thanks for sharing... there is certainly more than one way to do things 🙂