-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Create ktor
adapter for SDK
#27
Conversation
I think someone with better spring boot knowledge can shape a better interface to create the inngest client + CommHandler but this is already better than manually creating a singleton and having everything in a random controller. Note: It might be better to not have a second adapter package and instead have these spring boot helpers as a feature variant. But I'll see how it goes with this PR first: #27 I'm also adding a way to build the Inngest client configuration possibly through a Builder pattern targeted to the specific environment that the user wants to use.
I think someone with better spring boot knowledge can shape a better interface to create the inngest client + CommHandler but this is already better than manually creating a singleton and having everything in a random controller. Note: It might be better to not have a second adapter package and instead have these spring boot helpers as a feature variant. But I'll see how it goes with this PR first: #27 I'm also adding a way to build the Inngest client configuration possibly through a Builder pattern targeted to the specific environment that the user wants to use.
I think someone with better spring boot knowledge can shape a better interface to create the inngest client + CommHandler but this is already better than manually creating a singleton and having everything in a random controller. Note: It might be better to not have a second adapter package and instead have these spring boot helpers as a feature variant. But I'll see how it goes with this PR first: #27 I'm also adding a way to build the Inngest client configuration possibly through a Builder pattern targeted to the specific environment that the user wants to use.
I think someone with better spring boot knowledge can shape a better interface to create the inngest client + CommHandler but this is already better than manually creating a singleton and having everything in a random controller. Note: It might be better to not have a second adapter package and instead have these spring boot helpers as a feature variant. But I'll see how it goes with this PR first: #27 I'm also adding a way to build the Inngest client configuration possibly through a Builder pattern targeted to the specific environment that the user wants to use.
ee4de8a
to
c41ece9
Compare
* Add spring-boot-adapter project & InngestController * Remove the singleton in favor of bean injecting the inngest config I think someone with better spring boot knowledge can shape a better interface to create the inngest client + CommHandler but this is already better than manually creating a singleton and having everything in a random controller. Note: It might be better to not have a second adapter package and instead have these spring boot helpers as a feature variant. But I'll see how it goes with this PR first: #27 I'm also adding a way to build the Inngest client configuration possibly through a Builder pattern targeted to the specific environment that the user wants to use.
c41ece9
to
6c2e1d3
Compare
core
packagektor
adapter for SDK
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good 👍
@@ -15,6 +15,8 @@ dependencies { | |||
implementation("com.fasterxml.jackson.core:jackson-databind:2.16.1") | |||
implementation("com.squareup.okhttp3:okhttp:4.12.0") | |||
|
|||
implementation("io.ktor:ktor-server-core:2.3.5") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hm, I know you were looking at optional dependencies but I think it's a bit clearer if the framework specific adapters are wrappers outside of a generic inngest-core
. Not sure what's more common in Kotlin/Java ecosystem though
Provide pre-defined routes for
ktor
, and also move the comm handler and client in there to hide implementation details from the user.ktor
has been added as a dependency for the SDK, but it should probably be an optional dependency based on enabled feature.Reference: https://docs.gradle.org/current/userguide/feature_variants.html?_gl=1*1shpi06*_ga*MTUzOTI5MTY2NS4xNzA4ODQ3NjEw*_ga_7W7NC6YNPT*MTcwODg0NzYxMC4xLjAuMTcwODg0NzYxMC42MC4wLjA