I'd like to suggest a new category "Persistence", or "Databases", in the Packages page on Swift.org. This page could help developers digging in the landscape of available solutions, and give visibility to useful community packages.
Out of my head, I can list quite a few packages (without claiming exhaustivity!):
Server databases: Fluent, MongoKitten, CassandraClient...
Local storage + remote sync: SwiftData, Realm.swift
Local storage/SQLite: SQLite.swift, GRDB, Lighter, Blackbird, Boutique...
There is some overlap with the Server category, but I'm not sure this is a problem, as long as visitors can find the packages they are looking for.
I did some work on this today and the best keyword that I could find packages actively using is database. Using this keyword does bring in two duplicate packages from the Swift on server package category, but itâs the best I could find.
It also brings in one package that you could argue is not relevant as it does not directly interact with data persistence, but I donât think itâs very out of place for this list.
The full list of packages that generate this list can be found here.
One thing that came up when this was discussed at the SWWG was that these categories are not meant to be comprehensive but a small selection of what's available before diving into the Swift Package Index. We all agreed that it's completely valid for there to be a category for persistence/database packages, though, and it's always fine to ask for more categories, but I don't think it's written anywhere publicly how the SWWG considers this page.
I have opened a draft PR but we welcome more discussion here, too.
Thank you Dave :-) I personally agree with the "Database Access" name, because it has a sharper information scent than "Persistence".
People who look for server databases don't have "Persistence" in mind. They have "database", "vector database", "distributed database", "nosql", or the name of a specific product, etc. To them, "Persistence" may bring in unrelated technologies such as Codable, JSON files, UserDefaults, etc.
People who look for an alternative to Core Data and SwiftData are a different category of developers. But they are not the app developers who think that a database is overkill, though, so "Database Access" still smells good to them.
Those are all pretty subjective considerations, so I'll support whichever decision is taken by the SWWG
I prefer persistence, too, but the list was less relevant (and excluded GRDB). Here's what it would return:
Boutique and Bodega make it in, which is good and Papyrus and ManagedModels both look relevant, too, but SwiftQueue and ModernAVPlayer are less well tagged than anything in "database"
Oh, I understand, now. You want a tag that brings in as many relevant packages as possible, without glaring omissions. Those tags are not an editorial choice of SPI: they are set by repository owners.
A possible solution would be to contact repository owners, and suggest to add some tags.
Another possible solution is to enhance SPI with the search for multiple tags: https://swiftpackageindex.com/keywords/persistence+database.
Maybe a mix is necessary For example, GitHub - marcoarment/Blackbird has no tag and would be missing from all those lists. Also missing: vapor/postgres-nio and vapor/sqlite-nio (but unless I'm mistaken they're under the Fluent umbrella anyway).
Thatâs absolutely it! The only manually curated part of that page is the Community Showcase, where packages are nominated by the community and voted on by the members of the SWWG.
All other lists are taken from a keyword list, which as you said is not SPI editorial but package authors self-selecting their tags and our (transparent) algorithm giving every package a score.
I'm afraid within the context of adding this list to Swift.org, that's the entire scope of what's possible. Mixing techniques and introducing new ones is interesting, but not something I have time to do right now.
We also think it's the start of a slippery slope for SPI to get into editorialising package recommendations. This is the main reason I excuse myself from voting on the Community Showcase, even though I am a member of the SWWG. Reaching out to package authors to suggest that they change their tags to get in a list is beyond what Iâm comfortable doing. I regularly raise PRs to fix various bits of package data when I see things that are not quite right, but not where that would lead to a package being featured on Swift.org.
Happy to take discussion of which keyword fits best, which you can preview with our search. Keywords are listed on the right hand side:
Thank you for your explanations. I'm sorry I have suggested actions that go beyond what's acceptable for you. Actually, I don't see any problem to let each package maintainer deal with their own visibility, even if community push ups are well appreciated :)
It's no problem at all, and it's quite a reasonable suggestion. I just want to make sure that there is no question of me being accused of abusing my position on the SWWG.
The community push ups I take care of with the podcast, where we talk about other people's packages every episode and my nominations on the nomination thread
i might as well plug swift-mongodb, which is our internal MongoDB driver. although it only has four GitHub stars and it only recently started supporting macOS, so i wouldnât say it has a huge audience yet.
For example, 