Motivation:
The default port for Redis is well published to be 6379, and it is common to want to pass this value around or use it as a static default value in methods and initializers.
Modifications:
Add `RedisConnection.defaultPort` static property for all users to use, and update references of the `6379` literals to use new the new property.
Result:
Users should have a reliable default defined to use everywhere to avoid bugs.
Motivation:
`Foundation.Data` was unexpectedly receiving `RESPValueConvertible` conformance through the `Collection` extension which lead to incorrect encoding.
Modifications:
Add explicit conformance to `RESPValueConvertible` for `Data`.
Result:
Users should see their `Data` encoding to RESP format as expected.
Motivation:
Reading output from `RESPValue` existentials is entirely verbose and does not provide a human-readable description of what is being represented.
Modifications:
- Add conformance to `CustomStringConvertible` for `RESPValue`
- Remove redundant logging of arguments in `RedisConnection.send`
Result:
String representations of `RESPValue` should now be more readable for human to understand.
Motivation:
The emojis in the README were not rendered consistently in the docs and on different screen form factors making a poor UX.
Modifications:
The CI config now properly sends the custom theme to Jazzy, and the README no longer has the `🔔` emoji in the disclaimer header.
Result:
A consistent UX with the README and proper API docs referring to GitLab
Motivation:
After moving to GitLab, and while still having a GitHub mirror, it is important to drive people to the proper location for getting help and reporting bugs or feature requests.
Also, some information should be updated to include new tags, formatting, and a link to the new API docs.
Modifications:
README is updated to point users to the GitLab repository and to have up-to-date information about the project.
Result:
Users should know where to reach project maintainers and where to find documentation.
Motivation:
Users need a quick reference available online that is up to date.
Modifications:
Add CI job to generate and publish API docs with Jazzy
Result:
Users can view API docs that are updated when new releases are tagged at https://mordil.gitlab.io/swift-redis-nio-client
Motivation:
Now that the project has migrated from GitHub, it can now fully use GitLab CI.
Modifications:
Removed `circle.yml` and added `.gitlab-ci.yml` files
Result:
GitLab CI should be fully supported
Motivation:
The SSWG has identified a fast approaching reality of namespace clashes in SPM within the ecosystem and has proposed a rule on names that `NIORedis` no longer complies with.
Modifications:
All references to `NIORedis` have been switched to `RedisNIO` as this module name is unique (at least within GitHub's public repositories).
The goals for this name are as follows:
1. To indicate that this is a Redis client library that is built with SwiftNIO
2. That it is a lower level library, as it directly exposes SwiftNIO as an implementation detail
2a. The idea being that a higher level library (`Redis`) will be used, and to "go one level deeper" in the stack, you append the "deeper" `NIO` postfix
3. It follows a naming pattern adopted by Vapor who has expressed their desire to adopt this library as their Redis implementation
Result:
A repository, package name, and module name that are unique across GitHub's public repositories that achives the goals outlined above.
Motivation:
End users will want to capture some baseline performance metrics that can only be accurately gathered at this level of the stack.
Modifications:
Added new `RedisMetrics` struct that retains all SwiftMetrics objects used throughout the system lifecycle, and appropriate code to track desired metrics.
Result:
Users now have a way to peek into the system's performance to understand what NIORedis is being asked to do from their usage.
Motivation:
The project has adopted the `swift-log` and `swift-metrics` API packages, and the project's license needs to include attributions to their authors.
Modifications:
`NOTICE.txt` now lists `swift-log` and `swift-metrics` from Apple.
Result:
Apple has been properly attributed for the code from `swift-log` and `swift-metrics`
Motivation:
To be a comprehensive library, all commands should be implemented, even if they are highly discouraged. List's collection of commands were missing `brpop`, `blpop`, and `brpoplpush`.
Modifications:
`brpop`, `blpop` and `brpoplpush` are supported with defaults and overloads for an easier API.
Result:
Users now have access to `brpop`, `blpop` and `brpoplpush` commands.
Motivation:
To be a comprehensive library, all commands should be implemented, even if they are highly discouraged. Sorted Set's collection of commands were missing `bzpopmin` and `bzpopmax`.
Modifications:
`bzpopmin` and `bzpopmax` are supported with defaults and overloads for an easier API.
`RedisClient.channel` is now `internal` to have access during testing for bypassing normal guards for closing connections.
Result:
Users now have access to `bzpopmin` and `bzpopmax` commands.
Motivation:
Debugging and properly handling errors was difficult as the `ChannelHandler` names were the default generic names, in addition the `RedisCommandHandler` did not pipe errors further up the pipeline.
Modifications:
`RedisCommandHandler` now calls `context.fireErrorCaught(error)` when receiving errors, and the default Redis `ChannelPipeline` handlers are added with debugging names.
Result:
It should be easier for debugging purposes to work with any Redis `ChannelPipeline`.
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.
Nathan Harris
Nathan Harris
Nathan Harris