Motivation:
The goal of the `Redis.makeConnection` factory method is to provide end users with a quick way to jump in and get started with Redis in Swift.
Right now, users have to provide an `EventLoopGroup` instance, when a reasonable default is available for us to define.
Modifications:
- Add: `MultiThreadedEventLoopGroup` for 1 thread as a default argument to the `using:` label in `Redis.makeConnection`
- Remove: The `with:` label for the password in `Redis.makeConnection`
- Change: The project README to reflect the current state of the project
Results:
Users should be able to create `RedisConnections` by just defining an IP Address & Port to connect to - and possibly a password.
In addition, the README should now properly direct users on how to use the latest version of the library.
Motivation:
During the discussion thread of the NIORedis SSWG proposal, there were concerns expressed over the implementation
of `RedisPipeline` that covered the following areas:
1. Clashes with SwiftNIO concepts such as "Pipeline"
2. Misleading users on library behavior with using a Pipeline vs. a single `RedisConnection`
3. The implementation was "too clever" in that it allowed users to easily find themselves in "Undefined Behavior"
due to lack of enough type safety in the API
However, the value in being able to control how frequently "flush" happens on a socket was discussed and considered
high - so something still needs to be in place to force flushes by users.
It was decided to leave the implementation of batching commands and their responses to library users, perhaps in
higher level frameworks while the library will provide said mechanism for controlling writing and flushing of commands.
Modifications:
- Add: `sendCommandsImmediately` bool property to `RedisConnection` to handle choice of flushing after each command
- Remove: `RedisPipeline`
Results:
Users should now have a more clear understanding on what type of control they have over the timing of when commands
are actually sent over the wire, with the greater emphasis placed on `RedisConnection`.
Motivation:
As it stands, the parsing / encoding implementations for RESP was directly tied to the NIO Channel Handlers.
Unit tests were sloppily spread across multiple files and it made it difficult to explicitly separate out
the Channel Handler behavior from the RESP specification implementation.
Modifications:
- Add: `RESPTranslator` enum helper object with static methods that only handles RESP parsing / encoding
- Rename: `RESPEncoder` to `RedisMessageEncoder`
- Rename: `RESPDecoder` to `RedisByteDecoder`
Results:
It should be easier to understand what type is intended to be used as part of a NIO channel pipeline while
still having a direct way of parsing / encoding between Swift types and the RESP specification.
Unit tests should be more maintainable as well.
Motivation:
The two provided factory methods for creating `RedisConnection` and `ClientBootstrap` were not readily discoverable or appropriately expressible.
Modifications:
- Add: `Redis` top-level namespace enum
- Move & Rename: `RedisConnection.connect` factory method to `Redis.makeConnection`
- Move & Rename: `ClientBootstrap.makeRedisDefault` factory method to `Redis.makeDefaultClientBootstrap`
- Rename: `EventLoopFuture` extension file to just `SwiftNIO` to have all framework extensions in a single file
Results:
Using NIORedis should be more discoverable and straight forward on how to create a connection with `Redis.makeConnection(...)` over `RedisConnection.connect(...)`
Motivation:
`RedisError` was being used in many places in an ad-hoc fashion that made it unclear as to what source of errors it exactly represents.
In addition, it doesn't follow community conventions of handling known "classes" of errors with enums rather than static struct instances.
Results:
All errors that are generated and thrown within the library are specified as either `RESPDecoder.Error` or `NIORedisError`.
`RedisError` is simplified to represent an error message sent by a Redis instance that conforms to `LocalizedError`.
Motivation:
When later adding support for pub/sub, and potentially batching commands, a state is going to need to be defined and multiple booleans will create a large matrix that will be error prone.
Results:
Rather than using `Atomic<Bool>`, a `Lock` and `ConnectionState` enum are used to determine if a connection is open.
Motivation:
Throughout the process of creating and using RESPValue, many unnecessary allocations happened translating ByteBuffers into [Int8] raw byte arrays.
Results:
RESPValue has a more conherent underlying data structure and computed properties, while decoding RESP is more straight forward and performant
Resolves#31
Motivation:
`Foundation.Data` is known to be more expensive than is necessary for this low level of a library, and has some quirks with its usage.
Results:
This library now works with byte arrays (`[UInt8]`) directly, and all references to `Foundation` now explicitly import the exact types they need.
Motivation:
As this command is embedded in the creation of a `RedisConnection` and you authorize an entire connection to a Redis instance - this command serves no purpose and could make it easier for users to shoot themselves in the foot.
Results:
`authorize(with:)` convenience method is removed, and the `RedisConnection.connect` method now sends a raw command
Motivation:
`RedisDriver` has one of the weakest use cases for existence, as its entire purpose can be solved with a static function on `RedisConnection`.
Result:
`RedisDriver` no longer is a thing, and a simpler process of creating a `RedisConnection` is available through the static method `connect(to:with:on:logger:)`.
Also, the `ClientBootstrap.makeForRedis(using:)` method has been cleaned up and renamed to `ClientBootstrap.makeRedisDefault(using:)`.
Motivation:
`RedisPipeline` has a weak use case as a protocol, as it is more than likely 98% of use cases will end up using the `NIORedisPipeline` implementation.
Result:
`RedisPipeline` is more direct in its intended usage, with comment blocks being more clear.
Motivation:
`RedisCommandExecutor` was a complex and "wordy" name that was not 100% clear as to how it relates to other types.
`RedisConnection` also has not had a strong use case shown for it to exists as a separate protocol - using up a great name for the "out of the box" implementation.
Result:
`RedisClient` instead of `RedisCommandExecutor` is more clear as to what it is, in Redis terminology, a communication client.
`RedisConnection` as a concrete class provides an identifiable basic block for making connections to Redis.
`RedisConnection` also saw some fixes to `close()` while having some names and comment blocks tweaked for updated naming.
Motivation:
The goal of this commit is to make it easier for library users to implement their own types for creating connections and pipelines without losing all of the convenience command extensions.
This also splits executing commands from the concept of a "connection" to make it more swifty in `RedisPipeline`.
- Move: `String.convertedToData()` to `NIORedisTests` as a test utility
- Change: URLs in code comments to be Markdown links
- Change: Code comments to be more correct
This is to remove the need of allocations with Foundation.Data before writing to the buffer.
We should see an estimated ~10% performance boost to encoding values.
- Rename: `RESPConvertible` to `RESPValueConvertible`
- Change: `RESPValueConvertible.convertFromRESP(_:)` to be a non-throwing failable initializer
- Rename: `RESPValueConvertible.convertToRESP()` to non-throwing `convertedToRESPValue()`
Nathan Harris
Nathan Harris
tanner0101