QUESTION TIME Folks, I have a question regarding ...
# ktor
h
QUESTION TIME Folks, I have a question regarding Ktor “Features”. In many technologies Features are called other things such as Middleware, Interceptors, Filters, etc. When you first came to Ktor, did you immediately understand what “Feature’ means? Do you at all find it complicated to talk about Features, not to be confused with features? 🙂
r
I did not immediately get what Features were when reading about them. I always found the term Middleware very confusing. Interceptor and Filter and very generic terms, like Feature, but I can’t think of a word closer to what Features actually are than Feature. It’s not very descriptive though. I’m sometimes thinking of Features as Components in a Composite Pattern. Another generic word
c
I think plugin is would be a fitting name
👍 1
a
It was a bit confusing
c
a feature of ktor is that it supports multiple engines, or that it has a routing dsl. plugins add features
b
I personally didn't get them at all until someone told me to think of them as "middleware". It immediately clicked after that :D
r
I still don't understand Ktor Features 😉
😂 1
Documentation (https://ktor.io/docs/features.html) is confusing. E.g. I still don't know if everything between request and response is just a Feature? Or if "routing is a feature" and "By default, Ktor does not activate any Feature" how is routing available without installing it with
install(Routing)
?
b
routing is implicitly installed when using
routing {}
dsl 😄
r
I'm just saying it's a bit confusing 😉
j
The importance of naming… maybe Feature is holding a very wide set of options… But definitely better than Middleware
s
I recall repeating term definitions to myself when learning Ktor. "Features" is a bit too broad, and not used as such amongst other frameworks, at least amongst the ones that I know.
h
What do folks think of the concept of “Interceptor”? In that it is essentially intercepting the request/response?
a
Yes, I would interpret interceptor as a request/response thing in the context of KTor. To me it would make sense to have separate concepts for plugins and interceptors (filters). Even though looking from the inside of KTor it is conceptually the same because you want it to be really flexible. 🙂
c
if its only intercepting requests and responses then interceptor or filter is good. if it can add all kinds of behavior, then plugin is better. for example routing is a feature now, does it only intercept requests?
☝️ 1
o
Looking at the list of "Features" available, I'd lean towards "Strategy" as a generic term, with derivatives being "LoggingStrategy", "CompressionStrategy", "RoutingStrategy", and others...
h
Not everything however is a strategy.
Please feel free to comment on this issue at it affects all Ktor users immensely https://youtrack.jetbrains.com/issue/KTOR-2326
o
Hmm, it probably depends on how broadly one interprets the term, but still: I wonder which Ktor "Feature" doesn't qualify as a strategy?