Replies: 1 comment
-
I'm personally conflicted. Node Redis strives to be a simple passthrough to Redis and so a minimum of transformation is appropriate. On the other hand, typing brackets with strings to access properties on JavaScript is kind of a pain in the butt. That all said, the cases where I need to do this tend to be rare. So, I think I land on option 1 but would be content with option 2. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
The JavaScript community expects things to be named
camelCase
, redis usually implementssnake_case
(i.e.INFO
for example), and occasionallykebab-case
(i.e.XINFO STREAM
for example). Moreso, it can also be random (i.e.MEMORY STATS
).
There are 3 options to handle this:
Option 1
Maintain the current state (i.e whatever Redis sends, users receive)
This is the most performant option, and makes it easier to copy-paste examples from redis.io, other languages, and other communities. But, using the data is gonna be kinda ugly and not "JavaScript-y".
Option 2
Convert the keys to
camelCase
.
Converting the keys to
camelCase
is the most JavaScript-y option, but there is a performance cost - CPU cycles are used to convert the keys. This also makes it harder for first-time users (as most of the documentation and examples out there are usingredis-cli
).
Option 3
Maintain both options: a "JavaScript-y", and a
camelCase
name.
This is the most user-friendly option, but it'll cost in CPU cycles and result in higher memory (bigger "struct" when using an object, duplicate entries when using
Map
orArray
).I think we should pursue with option 1, as it is more performant and cheaper to implement. What do you think?
6 votes ·
Beta Was this translation helpful? Give feedback.
All reactions