Show HN: Rebridge – A transparent bridge between JavaScript and Redis

It's not worth it :)

Good: 1) I love higher abstraction for things that just work. I hate writing boilerplate code to do simple stuff. JS and Redis caching is one that I often have to write boilerplate code for. 2) Cheap and simple way to improve performance.

Bad: 1) Lacking fall-back mechanism and transparency about what would happen if error occurs, connection dies, etc. 2) One common reason (at least for me) people use redis caching instead of local caching is to have caching across difference servers or even services. How do you deal with conflict resolution and asynchronous operations?

  await db.hello.world(['foo', 'bar'])
  console.log((await db.hello.world()))
  await db.hello.world.push('baz')
  console.log((await db.hello.world()))

A quick review...

1. Could have made your life easier using promises or equivalent to handle the asynchronous flows.

2. Could have made your life easier using lodash instead of implementing recursive functions that can throw stack overflows.

3. JSON.parse can throw with invalid JSON and JSON.stringify can throw with circular references. There might be other cases in which those throw.

4. Line 25: "if key is inspect, return thing". That wasn't in test code, but in the actual library code. That would execute in the application using this library.

...And that part was the one that pushed me over the edge and the extent of my review. I punched my keyboard.

Then, you claim it handles a redis connection transparently. But nobody would use a redis server without redundancy, you need a redis sentinel somehow, and this does not support it. When you have a sentinel you need to handle failover events. The library does none of this, and is therefore not suitable for production use.

    db.hello = {world: ["foo", "bar"]};

    db.set("hello", JSON.stringify(
      {world: ["foo", "bar"]}))