Skip to content
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

Merged
merged 11 commits into from
Feb 25, 2024
Merged

Create ktor adapter for SDK #27

merged 11 commits into from
Feb 25, 2024

Conversation

darwin67
Copy link
Contributor

@darwin67 darwin67 commented Feb 25, 2024

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

KiKoS0 added a commit that referenced this pull request Feb 25, 2024
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.
KiKoS0 added a commit that referenced this pull request Feb 25, 2024
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.
KiKoS0 added a commit that referenced this pull request Feb 25, 2024
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.
KiKoS0 added a commit that referenced this pull request Feb 25, 2024
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.
KiKoS0 added a commit that referenced this pull request Feb 25, 2024
* 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.
@darwin67 darwin67 marked this pull request as ready for review February 25, 2024 10:07
@darwin67 darwin67 changed the title Move ktor routes into core package Create ktor adapter for SDK Feb 25, 2024
Copy link
Collaborator

@KiKoS0 KiKoS0 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good 👍

@KiKoS0 KiKoS0 merged commit a9b635b into main Feb 25, 2024
7 checks passed
@KiKoS0 KiKoS0 deleted the darwin/ktor-routes branch February 25, 2024 11:17
@@ -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")
Copy link
Collaborator

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants