Thanks for pitching this @rparada.
Swift is a beautiful and elegant language but it's totally lacking database connectivity on the server.
I agree. The Swift server work group is currently prioritizing work on database driver packages. We've made a lot of progress on this so far, but there are many more to cover. Creating good driver packages is the key to creating good, higher level packages.
Here's what has been proposed so far:
- GitHub - vapor/postgres-nio: 🐘 Non-blocking, event-driven Swift client for PostgreSQL.
- GitHub - swift-server/RediStack: Non-blocking, event-driven Swift client for Redis.
- SwiftNIO based MySQL client
- SwiftNIO integration for SQLite APIs
- [Discussion] MongoDB Swift driver
As always, if anyone is interested in helping create a new database driver package we'd be more than happy to help you get a pitch going.
That is great start but I think a unified API would be highly beneficial to developers and open the door to the creation of very cool and powerful higher level frameworks.
I agree this could be useful eventually, but I think we are still too early days to make a big decision like this. There are a lot of great features yet to come in Swift that could have a large impact on how such an API is designed. There's also a ton of ways such a library could look. As @esummers's mentioned, there are a few existing database APIs in Swift already. Two I've created at least are:
- GitHub - vapor/fluent-kit: Swift ORM (queries, models, and relations) for NoSQL and SQL databases
- GitHub - vapor/sql-kit: *️⃣ Build SQL queries in Swift. Extensible, protocol-based design that supports DQL, DML, and DDL.
But there are a lot more than just those. There's also a plethora of client-side database libraries in Swift that have been used for iOS and macOS development. We should first strive to understand and discuss the possible solutions before we agree on a unified API. We should also prioritize building on Swift's strengths. Learning from the success of something like JDBC is obviously great but we shouldn't assume something that works well in Java would also work well in Swift without strong evidence.
That said, exploring JDBC's design in a Swift package could be very useful. It might end up working out extremely well and be a model for how things should work in Swift. We won't know until we test it.