bentocache icon indicating copy to clipboard operation
bentocache copied to clipboard

json feature

Open yovanoc opened this issue 1 year ago • 7 comments

I think it would be a good idea to add an option to toggle a json mode, to use the json type in redis instead of string

yovanoc avatar Jul 07 '24 14:07 yovanoc

Can you explain why?

Julien-R44 avatar Sep 30 '24 17:09 Julien-R44

because im using ft.search and json.get tu search and get part of json object stored with bentocache, and I think this shouldn't be to difficult to add the option here directly if it help other people

yovanoc avatar Oct 01 '24 06:10 yovanoc

I'll add my 2 cents - de/serialization is known to be expensive, plus it unexpectedly transforms values.

A common use-case is to cache database models. Let's say your article model has createdAt attribute, hydrated by your ORM to Date object. You wrap the fetch to bentocache, and your GraphQL engine starts complaining, because the Date scalar expects Date instance, not string (which is the result of de/serialization).

This is especially confusing when using just L1 inmemory cache, which doesn't need serialization at all. Having an option to provide a no-op serializer, or better, to use best matching native methods at the storage driver level, would (massively, I believe) increase throughput/rps for L1-only scenarios, and reduce integration hiccups, such as the Date-string conversion.

wodCZ avatar Oct 01 '24 09:10 wodCZ

I'll add my 2 cents - de/serialization is known to be expensive, plus it unexpectedly transforms values.

A common use-case is to cache database models. Let's say your article model has createdAt attribute, hydrated by your ORM to Date object. You wrap the fetch to bentocache, and your GraphQL engine starts complaining, because the Date scalar expects Date instance, not string (which is the result of de/serialization).

This is especially confusing when using just L1 inmemory cache, which doesn't need serialization at all. Having an option to provide a no-op serializer, or better, to use best matching native methods at the storage driver level, would (massively, I believe) increase throughput/rps for L1-only scenarios, and reduce integration hiccups, such as the Date-string conversion.

Sorry I think I did'nt really understood what you meant. Because all these problems will still exist if you use RedisJSON

To come back to the main issue: I think the ideal would just be to have a RedisJSON driver rather than modifying the original redis driver. Maybe a community package, or even a PR that add that driver could do the job. Would you be willing to contribute that @yovanoc ? Should be pretty easy to do if your take a look at other drivers : https://github.com/Julien-R44/bentocache/blob/main/packages/bentocache/src/drivers/redis.ts

Julien-R44 avatar Oct 02 '24 21:10 Julien-R44

IORedis doesn't support JSON out of the box, but I created myself a wrapper around it, if I can add that too (only for this new redis json driver), I can try to open a PR !

yovanoc avatar Oct 03 '24 06:10 yovanoc

Because all these problems will still exist if you use RedisJSON

@Julien-R44 right, I'm sorry for the confusion and for "hijacking" the issue with a different topic.

wodCZ avatar Oct 03 '24 10:10 wodCZ

Oh okay, no worries. Feel free to open another issue about this issue if needed

Julien-R44 avatar Oct 03 '24 19:10 Julien-R44

Closing the issue since I don't have the bandwith to work on it right now. If the feature is still needed feel free to reopen it

Julien-R44 avatar Feb 01 '25 13:02 Julien-R44