Would it be possible to make `org.http4k:http4k-se...

# http4k

[Jonathan Hult]

Would it be possible to make org.http4k:http4k-security-oauth "pluggable" with other JSON formatters instead of relying directly directly on http4k-format-moshi?

[dave]

the reason we use moshi is because there is no reflection and it should all be self contained.

[Jonathan Hult]

Makes sense.

But would there be a way to create something so it could be "pluggable"?

The reason I ask is perhaps I want to use org.http4k:http4k-format-klaxon and org.http4k:http4k-security-oauth. Currently, this would also pull in a dependency on moshi that I'd prefer to avoid (since I want to use Klaxon).

[Jonathan Hult]

Also, FWIW, it seems some other modules rely on `http4k-format-jackson`:
• https://github.com/http4k/http4k/blob/8ac72bf3df2fa6950238d00ae6614b24c5984ad1/core/api/graphql/build.gradle.kts#L13
• https://github.com/http4k/http4k/blob/8ac72bf3df2fa6950238d00ae6614b24c5984ad1/connect/storage/http/build.gradle.kts#L13

[dave]

I don';t think there is a way right now. Moshi is very small though - it's not jackson and it should exclude the reflection jar. you shouldn't be exposed to it at all, so consider it an internal dep

[Andrew O'Hara]

It could be pluggable if we hand-crafted the marshalling and have the user plug in a Json. But it's more effort to maintain.

[Jonathan Hult]

That's sort of what I was envisioning but wasn't sure if it was worth the effort. Sounds like it isn't worth it (at least at this moment in time).

[Andrew O'Hara]

IMO, it's only worth it in super-resource-constrained scenarios where even Moshi with codegen is too heavy.

[dave]

Also / when you need to avoid reflection because you are compiling to GraalVM 🙃

[Andrew O'Hara]

Kotshi uses no reflection though

[dave]

yes - that's my point 🙂