On Tue, 17 Jan 2023 at 20:39, Zach Laine via Boost
No. In particular, the API requires the user to write lots of Redis strings by hand. A typo will not be detected until runtime. The set of Redis keywords is fixed; there's no reason not to make an enumeration of them all, like this:
I had enums in the past but I had to remove them for a couple of reasons 1. There are a multitude of possible commands in the Redis stack, for example * Redis search: https://redis.io/commands/?group=search * Redis graph: https://redis.io/commands/?group=graph * Redis time series: https://redis.io/commands/?group=timeseries * Redis json: https://redis.io/commands/?group=json * Perhaps more I might be missing righ now. Then, we would probably agree that the command syntax is equally important. To check it properly I would have to write a generator that parses the description of each command and generates a checker, see https://github.com/redis/redis/tree/unstable/src/commands. I have made no thoughts so far about how that would work and if I get that correctly I would still have to watch for versioning (what changes from release to release), what new commands were implemented and which were deprecated. That might be enough for Redis, but them I would be keeping other Redis-like databases off, for example * https://github.com/Snapchat/KeyDB * https://github.com/scylladb/scylladb/blob/master/docs/dev/redis.md * https://github.com/dragonflydb/dragonfly * Perhaps more. I don't know how compatible they are with the Redis API. I can't afford working on this right now and in the foreseeable future, I see it almost as a second library of a module of my library e.g. aedis::redis::search::request or something. <snip>
// Even better, we can write this directly: void user_code_v2() { // No need to allocate a request object for smallish requests; you only // need to allocate the underlying buffer that the bytes are serialized // into. If you insist, you can always overload with an initial allocator // param. co_await conn->async_exec_request(HELLO(3), HGETALL("hset-key"), QUIT); }
Aedis will coalesce requests before writing to the socket and reuse the buffer. The small buffer optimization is however something that might make sense for the request, however it is simpler to clear() the request and add new commands, namely, reuse the already allocated buffer. <snip>
These are the kinds of easy-to-use-correctly and hard-to-use-incorrectly interfaces that I would expect of such a library. I think the marshalling/unmarshalling and handling of ASIO parts of the existing design make my life easier, but with raw string literals in the interface, I consider the library interface work only half-done.
Aedis solves the problem of efficient async-io for the RESP3 protocol and offers a way to serialize user data-structures into an array of blob-strings. In this sense it is more about RESP3 than about Redis, perhaps I am advertising it wrongly. <snip>
For Redis aficionados, there should also be a step-by-step guide to how to do real work with the lib. The examples seem pretty good.
Thanks. I will think more about your other points and eventually commit more tomorrow. Many thanks for taking some time to Review Aedis. Marcelo