RedisJSON support should work out of the box without requiring Jackson

[raphaeldelio]

Feature Request

Is your feature request related to a problem? Please describe

Currently (6.8.1-RELEASE), if you use Lettuce’s RedisJSON commands (jsonSet, jsonGet, etc.) without adding the jackson dependency, you immediately get:

Could not load JsonParser, please consult the guideat https://redis.github.io/lettuce/user-guide/redis-json/

This means RedisJSON integration is effectively coupled to Jackson, unless you provide your own JsonParser implementation manually

That makes it difficult for projects that use other JSON libraries (like kotlinx.serialization or Gson), or that simply want to treat JSON values as opaque strings.

Describe the solution you'd like

Lettuce’s RedisJSON API should not force Jackson (or any parser) just to round-trip JSON.

With Jedis, the GET (or JSON.GET) API simply returns a String containing the JSON text. That string can then be passed to any JSON library (kotlinx.serialization, Gson, Moshi, Jackson, etc.) for deserialization. This is flexible and works out of the box, without coupling Jedis to a specific JSON library.

Lettuce could mirror this behavior:
• For jsonGet – if no JsonParser module is present, Lettuce should fall back to returning a raw String containing the JSON text from Redis. This gives developers the same convenience Jedis offers: get back the JSON string directly and decode it with whichever library they prefer.

[tishun]

Hey @raphaeldelio ,

That makes it difficult for projects that use other JSON libraries (like kotlinx.serialization or Gson)

Do you mean that the current API is hard to implement?
Because the JsonParser abstraction is provided precisely for that reason.
How could we improve it to make it more usable?

, or that simply want to treat JSON values as opaque strings.

There is a downside to returning pure String values, that I (and before me - @mp911de) was hoping to avoid.

Lettuce is an async client that uses the Netty event loop to encode and decode the bytes coming from the wire. In this case a large document is returned that might cause the event loop to slow down, effectively slowing down other multiplexed commands and drastically impacting the speed of the driver.

To alleviate this I implemented delayed parsing, that is done on the client thread instead. With a String contract we do not have this luxury.

Do you think that we need to have such and API anyway? I am afraid that even if we put warnings in the JavaDoc and guides users would still prefer to use it and not know the impact of such a choice.

[tishun]

By the way,

we can also offer examples of how other popular libraries could be used instead of Jackson.

Would this help?

[raphaeldelio]

@tishun Thanks for the explanation about the reason behind the design choice! Is this documented? I think documenting the reasons behind why the parser is necessary would be enough.

I don't think that's a problem for enterprise applications implementing lettuce, though. My concern was more about libraries that may integrate with tens of different data sources.

Koog, the new library implemented by JetBrains for building AI agents that is growing fast (2500 stars already), implemented a sort of prompt caching with Redis. They did so using Lettuce, but they store the JSONs as strings. I'd like to propose changing this to store them as JSONs in Redis, but I was afraid that the clutter that implementing an extra parser could cause would make the proposal be more easily rejected.

However, with an explanation of why such a parser is necessary when using Lettuce, I believe that the concern of the proposal being rejected would be mitigated.

"https://github.com/JetBrains/koog/blob/develop/prompt/prompt-cache/prompt-cache-redis/src/jvmMain/kotlin/ai/koog/prompt/cache/redis/RedisPromptCache.kt"

What do you think?

[mp911de]

Every approach has its two sides and a driver cannot know, what users would like to use. Using a String-based API motivates users who would like to use objects file tickets asking for object mapping support. A structured API reflecting JSON concepts and using a library under the hood always requires some implementation as no one is keen of writing their own JSON parser.

Looking at the broader ecosystem of databases that support JSON, there is a variety of support. The JDBC API accepts JSON objects but only for the reason of having a rather generic API that accepts any object.

• https://docs.oracle.com/en/database/oracle/oracle-database/23/jajdb/oracle/sql/json/package-summary.html
• https://stackoverflow.com/a/32661959
• https://learn.microsoft.com/en-us/sql/connect/jdbc/use-json-data-type?view=sql-server-ver17
• MongoDB: Everything is a Document, there is only one parser, but there cannot be top-level arrays.

Java Redis API's provide the convenience of modeling the Redis API using Java concepts. This has the premise that we need to decide what types we want to accept and return. In some cases, APIs could provide both variants, low-level and high-level objects to avoid forcing users into a particular dependency arrangement that isn't ideal for them.

Passing plain JSON strings increases the ask on responsibility and encoding on the calling code side, but it can ship with benefits when using low-level buffers that could be e.g. reused by netty.

[raphaeldelio]

Thanks, @mp911de — that makes sense. Given the trade-offs, would you be open to a dual-track approach?

I also wonder whether the JsonValue class is truly useful for enterprise applications. From my perspective, I usually need to convert it to a POJO at some point anyway.

Jedis provides both low- and high-level APIs, and I find that approach flexible. It lets you either work with raw JSON strings or pass in the target class directly:

// Low level: raw JSON string
String json = jedis.jsonGet("user:1");

// High level: mapped to a POJO via Jackson
User user = jedis.jsonGet("user:1", User.class);

Would you and @tishun see value in offering something similar in Lettuce, so developers can choose between raw JSON and structured mapping?

[tishun]

Thanks for all your input, folks.

Let me discuss this with the team and we will get back to you.