Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

why not use Redis as the storage? #81

Closed
akeyboardlife opened this issue Apr 27, 2019 · 3 comments
Closed

why not use Redis as the storage? #81

akeyboardlife opened this issue Apr 27, 2019 · 3 comments
Labels
discussion This topic needs discussion

Comments

@akeyboardlife
Copy link

akeyboardlife commented Apr 27, 2019

I personally use Redis as the backend storage.

How to let the client listen to certain event based on the resource id without a cached resource?

@akeyboardlife akeyboardlife changed the title why not user Redis as the storage? why not use Redis as the storage? Apr 28, 2019
@jirenius jirenius added the discussion This topic needs discussion label Apr 28, 2019
@jirenius
Copy link
Collaborator

jirenius commented Apr 28, 2019

Hi @akeyboardlife!

Why not use Redis?

It is actually a good idea, which I would really encourage, to use a key/value store such as Redis as storage for the microservice. Resgate's resource IDs (rid) translates well to the key in the key/value store. Redis' hashes should translate well to Resgate's models, and Redis' lists should translate fairly well to Resgate's collections.

Now, I must admit, I haven't used Redis in any project myself, so I have little experience with it. We've more used simpler key/value stores such as LevelDB or BadgerDB, or if we've needed proper indexing and such, we've used MongoDB.

But the sharding of a Redis cluster would probably work well with the sort of sharding (briefly described on Resgate.io).

In the backlog, I have a story to make a generic storage service with NATS/Resgate. It is not yet decided what sort of storage it will use, but Redis is one of the possible options.

How to listen to events without a cached resource?

The RES protocol revolves around resources, and events are always sent on a resource. You subscribe to a resource, and then you will receive the events for that resource. But if you only want events, and you don't need any resource data, you can use a static empty dummy model. The resource could then be considered more like a streaming channel.

For a node.js service, it would look like this:

nats.subscribe("get.test.channel.myevents", (msg, reply) => {
   nats.publish(reply, '{"result":{"model":{}}}');
});

// To publish a foo event
nats.publish("event.test.channel.myevents.foo", '{"bar":42}');

The web client would fetch dummy-model as usual:

let client = new ResClient('ws://localhost:8080');
client.get('test.channel.myevents').then(channel => {
   channel.on('foo', (e) => {
      console.log("Foo event: ", e);
   });
});

@ghost
Copy link

ghost commented Jun 14, 2019

There are golang Redis implementation that support Clustering.

https://github.com/tidwall/redcon

Also for storgae and indexing using badger i am using
https://github.com/mosuka/blast
It supports clustering and federation also which has just been finished:
https://github.com/mosuka/blast/tree/federation
This federation logic can be used for Cete below.
Its really nice.

For a Key Value store that also supports Federation and Clustering use https://github.com/mosuka/cete
Its builton the same base foundation as Blast, in that it uses Badger with Raft.

@jirenius
Copy link
Collaborator

jirenius commented Aug 5, 2019

I’m closing this issue because it has been inactive for a few months

For those looking further into support for Redis, you might want to check out the BadgerDB middleware in the go-res package for Go. A similar middleware for Redis should be rather basic to create.

@jirenius jirenius closed this as completed Aug 5, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
discussion This topic needs discussion
Projects
None yet
Development

No branches or pull requests

2 participants