The Vapor Core team would like to pitch its MySQL NIO library to the SSWG incubation process. This provides a client for connecting to, authorising, and querying a MySQL sever.
Motivation
Most Swift implementations of a MYSQL client are based on the libmysqlclient C library which handles most things internally internally. Building a library directly on top of MySQL's wire protocol using SwiftNIO should yield a more reliable, maintainable, and performant interface for MySQL databases.
Additionally MySQL is a widely used database solution and providing a server client would fill an important gap in the server-side Swift ecosystem.
Propsed solution
Vapor's MySQLNIO library is already released and in use, with about 1300 unique cloners a week. The library provides a Swift native solution for MySQL and has been fairly well tested and put through it paces in the 8 months since its 1.0.0 release.
A detailed implementation (and usage guide in the README) would be provided if the community though the package was useful and decided to proceed with a proposal. We are slightly constrained in that as we are already released, breaking changes would need to address significant issues to be warranted.
As a long-term user of Vapor, I really appreciate Vapor’s contribution to Swift server ecosystem. Since SSWG projects are the core of the whole ecosystem, and are intended to be “formal” and “standardized”, I believe we should align the experience of packages with similar functions. That is, we can conclude a common design guideline for databases from PostgresNIO, enabling users to switch between different backends easily and creating a uniformed experience across SSWG packages.
I agree with @johannesweiss, a MySQL client is definitely an important part of the ecosystem and this is a valuable library.
I do have some more meta questions. If I understand correctly, this is a lower-level library, and e.g. if someone wants connection pooling they must utilize the higher-level MySQLKit. Does this library have users/potential future use cases outside of MySQLKit?
On the flip side other drivers e.g. MongoSwift (and I think RediStack, @Mordil correct me if I'm wrong) do not separate out the functionality in the same way.
As a result, we currently have a bit of a mix in terms of how high-level the DB drivers in the incubation process are: some are meant to be used directly by application developers, others probably need another layer atop them.
I don't view that as an issue, as regardless they are all valuable to the ecosystem - but it makes me wonder if e.g. it would make sense in the future to also incubate higher-level libraries like MySQLKit?
I believe you're correct in that MySQLNIO (and PostgresNIO) is effectively a low-level wire protocol implementation. PostgresKit is the actual useful thing that manages connection pooling and that most people will want to use. We could pitch those as well and I'm happy to do so.
Paging @graskind for the real explanation of the -NIO and -Kit packages
.