Swift on Server guides

[hassila]

Just want some input before spending time documenting some stuff - I’d like to expand the guides to be much more comprehensive also from a new users starting point.

See eg. https://forums.swift.org/t/the-current-state-of-swift-for-server-and-linux/47732/18 (quite awful)

I think that a lot of this friction could be removed with a better starting point in the documentation and a better starting point from swift.org for Linux. It’s not much that’s needed to make a big difference I think, but want to confirm it’s inline with the ambitions of the repo.

I made a PR for a first trivial restructuring to prepare for adding some more content.

[tomerd]

@hassila your work on this topic is very valuable! once we have the content well organized we can figure out how to best make it discoverable via swift.org, the swift forums and/or other potential places

[hassila]

Thanks @tomerd , my question was more along the lines whether there would be friction if adding more fundamental starting docs if its not purely in the SSWG related domain (e.g. like in #27).

I think its good to just scope what should be here and personally I think it would make sense to have all the needed starting points for a new potential server-side developer to get started.

I mean, like that forum post, it shouldn't be like that - a reasonable experienced developer should be able to take the documentation and run with it to get an initial environment up and running and "hello world" up as well as more advanced topics.

So basically I just wanted to verify that the maintainers agreed with that scope.

[tomerd]

hi @hassila, in my opinion (not representing the rest of the SSWG), I think adding such getting started guide is great and within the goals for these guide, they should serve both new users that just want to get started as well as more advanced topics like performance troubleshooting, etc.

when it comes to #27, I feel that one is less "in scope" given that the SSWG is also an incubator for tools and libraries and already publishes a list of libraries that are going through incubation process in https://swift.org/server#projects. in other words having two lists with different sets of libraries, and no clear criteria for inclusion in the "frameworks" list could become confusing for users and challenging from a governance point of view.

what I can suggest is working with the folks behind swiftpackageindex.com to see if they have some "tag" or other search criteria for server packages and add links in these guides to teach folks where to find libraries/tools/packages for swift on server. this democratizes the process, since any framework author can publish their package into that index and tag it accordingly to show up in the search results. cc @daveverwer @finestructure

@swift-server/sswg wdyt?

[hassila]

Sounds reasonable, will see what comes out from SPI, I think swift package index could play a role there as you suggest, the friction to get started with swift on the server needs to be smoothed out to reach a broader audience I think.

[daveverwer]

what I can suggest is working with the folks behind swiftpackageindex.com to see if they have some "tag" or other search criteria for server packages and add links in these guides to teach folks where to find libraries/tools/packages for swift on server. this democratizes the process, since any framework author can publish their package into that index and tag it accordingly to show up in the search results. cc @daveverwer @finestructure

We're just wrapping up a couple of final features before announcing what we'll be working on next, but it's very likely that adding categories/tags to package metadata will feature prominently in our next set of features we add.

[hassila]

what I can suggest is working with the folks behind swiftpackageindex.com to see if they have some "tag" or other search criteria for server packages and add links in these guides to teach folks where to find libraries/tools/packages for swift on server. this democratizes the process, since any framework author can publish their package into that index and tag it accordingly to show up in the search results. cc @daveverwer @finestructure

We're just wrapping up a couple of final features before announcing what we'll be working on next, but it's very likely that adding categories/tags to package metadata will feature prominently in our next set of features we add.

Thanks @daveverwer - don't hesitate to reach out if you want a sounding board.