February 6th, 2020

Server Workgroup Updates
1

attendance:
@johannesweiss
@tanner0101
@Logan_Wright
@tomerd

Meeting schedule

decision : move meeting to wed, @tomerd to reschedule + Webex + update website

Crash handling and backtraces

backtraces

The language will add support over time, in the meanwhile we will rely on swift-backtraces Ian put together

decision: move swift-backtraces to a github organization where we can collaborate more easily.

Guides for deployment and production best practices

decision: start working on a “swift in production” guide

Server package index scope and goals

Team discussed the scope of the server packages index. Consensus that the goal is to include anything that solves an impactful enough problem in the server space. The fact it may also be applicable to mobile development should not add or subtract, the focus is if there is enough of an impact on a big enough portion of the server community. We want to encourage the community to make pitches so that others in the community can help decided if this is an impactful enough problem to try and solve. It is not the role of the SSWG to make this judgement, but rather the role of the community, via feedback in the forums, to demonstrate interest that will encourage the pitch author to make a full proposal and eventually land the library/tool on the index.

In the context of GitHub - peek-travel/swift-currency: Type-safety and algorithms for working with money in Swift., which triggered this discussion:

  • @tanner0101 to review the library with the author. Ideally make the pitch to discuss with community and see if there is a strong server community that needs this, and if so make a pitch
  • @tanner0101 to review the incubation process language to make sure the intent as described above is clear enough

Dependencies of non-SSWG libraries in SSWG libraries

Team discussed the role of the index in this aspect. consensus that the package index is designed to give a list of recommended solutions for common server use cases, and it is not an all inclusive list of strictly approved packages. If a package listed on the SSWG wants to add a dependency, it is on the library authors to make sure the dependency is secured, solid, has the right license, etc. iow, there is not a strict requirement for the deps to be SSWG approved as well

SSWG periodic package review

  • Logging : Vote to take to graduated: all in favor
  • Metrics : used in production, but waiting for Vapor 4.0 for to go GA before qualifying as incubating/graduated given the 3 production usage bar.
  • Postgres : used in production, but waiting for Vapor 4.0 for to go GA before qualifying as incubating/graduated given the 3 production usage bar.
  • Redis : some use in production, keep at sandbox given the 3 production usage bar.
  • Async HTTP Client : used in production, but waiting for Vapor 4.0 for to go GA before qualifying as incubating/graduated given the 3 production usage bar.
  • APNS : used in production, but on the surface too few committers. process of approving & merging PRs seems to be based on a single person (to be confirmed). keep in sandbox. @tanner0101 to follow up with author to confirm these points.
  • Statsd - keep in sandbox, pending metrics and additional production usage data
  • Prometheus - keep in sandbox, pending metrics and additional production usage data

swift-crypto

Apple just release a new cross platform crypto library :partying_face:. vapor is already in the process of integrating it into vapor 4.

Apple will pitch to the SSWG in the coming days/weeks

10 Likes
2

Thanks for taking time to publish the summary of your meetings. I think you are spot on the core pain points with Swift server side programming.

I’m really happy to see this point is now a focus of the group. I have recently build a server side swift service but had really hard time to understand how to host it. I don’t even know if I did it properly. Having guidance around this is crucial(something even better could be a docker/kubernetes generator).

Context

For context I’m an iOS dev that used to do backend dev 10 years ago.
FWIW most of the features of my web service are developed in a SPM package.

I have tried:

  • vapor 3 but it’s dependencies conflicted with mine(mainly AsyncHttpClient)
  • vapor 4(since it’s in beta) was not documented on this, I did have a lot of small issues and the peoples on Discord help me with them
  • I tried Kitura find tutorial and successfully build docker image and kubernetes(handler to re-spawn new instances in case of crashes) but don’t really understand how to properly host the result of this work

At the end of the day after going around most issue I discovered that some of my dependencies didn’t worked on Linux(I do have PR waiting to be merged for them).

Do you think that providing the ability to search based on os compatibility, should be done for the index ?

3

At least in regards to the SSWG, they have this graduation requirement for packages:

- CI setup for two latest Swift.org recommended versions of Swift
- CI setup for two latest versions of Swift.org recommended Linux distributions
- Unit tests for both macOS and Linux

In terms of a wider Swift package index, this is a highly requested feature and should be considered mandatory

1 Like