Re: aedis review starts today

From: Marcelo Zimbres Silva (mzimbres_at_[hidden])
Date: 2023-01-17 21:11:27

On Tue, 17 Jan 2023 at 20:39, Zach Laine via Boost
<boost_at_[hidden]> wrote:
>
> 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