[butabah]

I don't see how it's useful then. Maybe someone can give me a good use case?

redis is already very bare-bones and dead simple to set up and maintain, what more does one want? Wouldn't adding more logic into a redis-like environment be a little cumbersome from an architecture perspective?

[eknkc]

Could be used for proxying redis connections, be it for clustering or I don't know, add sophisticated access control or something.

You could expose a memcached cluster as a redis server using this. (Not sure why would you want to do that.. Maybe if you have an existing memcached cluster and have redis client code?)

Or you could go crazy and implement the entire set of redis commands on top of sqlite and call it a "strongly persistent redis" or something like that.

It's just a nice building block, I'm sure people would find ways to abuse it :)

[tidwall]

This is not for recreating Redis, but for custom server implementations such as the Tile38 project, proxying services, and microservices that might need to use the RESP protocol.

[otterley]

Then please don't call it a "Redis server implementation." That is misleading, at the very least. A "framework" would be an accurate description.

[tidwall]

Thanks a bunch for your feedback. I totally agree and changed the title to "Fast Redis compatible server framework for Go".

[dasil003]

Doesn't seem to have taken...

[omni]

He meant he changed the project description on GitHub. You can't change HN titles once they're posted afaik.

[otterley]

I'm not sure, either. By the time you've implemented all the actual Redis functions, there's no telling whether the server will be more or less performant than Redis itself. (Most likely less, since Redis is written in optimized C.)

Of course the existing benchmark shows that the example Go implementation is faster. For one, the Go implementation provided avoids a lot of functionality that the Redis server implements, such as TTL checking.

[bradrydzewski]

The use case would be implementing the redis protocol for client server communication in your own software. There is a specification for using the redis protocol [1]. The fact that redis is widely used and there are a number of client libraries in many languages may make it an attractive option compared to creating your own protocol from scratch.

I believe disque, the distributed message broker [2] uses the redis protocol for client server communication.

[1] http://redis.io/topics/protocol [2] https://github.com/antirez/disque

[JulianMorrison]

You have a more complicated data storage, or an established one that you don't wanna change, or a mandate from on high that all data must be put in X due to auditing or whatever - and a program that wants to talk to Redis.

[_RPM]

Because it's written in Go of course.