Reviews are an important part of the Swift Server Work Group incubation process. All review feedback should be either on this forum thread or, if you would like to keep your feedback private, directly to the review manager (via email or direct message in the Swift forums).
What goes into a review of a proposal?
The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, become listed on the Swift Server Ecosystem index page.
When reviewing a proposal, here are some questions to consider:
What is your evaluation of the proposal and its APIs/implementation?
Is the problem being addressed relevant for the wider Swift on Server ecosystem?
Does this proposal fit well with the feel and direction of the Swift Server ecosystem?
If you have used other libraries in Swift or other languages, how do you feel that this proposal compares to those?
How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
What is your evaluation of the proposal and its APIs/implementation?
Big +1, provides a decent Swift API for accessing all the AWS services. Additionally the code generation and parsing of spec files will provide excellent examples for other projects that need this.
Is the problem being addressed relevant for the wider Swift on Server ecosystem?
Yes, having an incubated AWS SDK is definitely required and will be a popular package for the ecosystem
Does this proposal fit well with the feel and direction of the Swift Server ecosystem?
Uses Async HTTP Client, Swift Log, SwiftNIO, Swift Metrics, integrating well with the rest of the SSWG packages
If you have used other libraries in Swift or other languages, how do you feel that this proposal compares to those?
I've used the AWS CLI extensively and this provides everything that that does
How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
I've read the proposal a couple of times but have been using Soto v5 in production for a few months now, touch several AWS services
Positive. SDKs for managing prominent and important cloud services like AWS are a good fit for the Swift on Server ecosystem. Soto is in-line with the standard solutions for AWS SDKs, meaning that developers familiar with other ecosystems will recognise the patterns used by Soto. The implementation seems to be on solid ground as well.
Yes. Orchestration is a vital part of many server-side workloads, and API clients like Soto are a critical part of orchestration.
I believe so. Soto is in a tricky spot because the AWS APIs are so vast that they distort the world around themselves, but it does the best that can be expected to make those APIs feel native in Swift. Soto itself does a good job of fitting into the Swift on Server ecosystem.
I've used Python's boto a lot. Every time I looked at the documentation of boto I felt dizzy, like I was standing at the top of a cliff. Soto makes me feel the same way. I think this is a good thing.
In depth study plus some hobbyist use of Soto for Lambda workloads.
What is your evaluation of the proposal and its APIs/implementation?
Big +1 from me as well. AWS is a major player and having an officially supported package would provide more stability to Swift as a server language I believe.
Is the problem being addressed relevant for the wider Swift on Server ecosystem?
Since Swift on the server is so new there are only so many packages. AWS is very important (as is Google, Azure, to be clear) and this would fill a perceived gap of needed support.
Does this proposal fit well with the feel and direction of the Swift Server ecosystem?
Yes, similar to the AWS Swift Lamba Runtime, this will open the door for other clouds too. It also fits nicely with the Lambda Runtime as you rarely will use Lambda without also using the rest of AWS.
Soto also nicely utilizes swift native libraries (like NIO).
How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
We, that is Skelpo, are using AWS in every project at this point. We have about 10+ projects using Soto in production already. Working very well and not too overwhelming to use.
@amlug That's great to hear you are using Soto in so many projects. One of the requirements for a package to go from Sandbox to Incubating is
Document that it is being used successfully in production by at least three independent end users which, in the SSWG judgement, are of adequate quality and scope.
It is very hard to get an idea how a package is being used without some input from users, so I've added an Issue to the Soto repository asking for details of how Soto is being used. If people could add to this it would be much appreciated.
I'm sorry for being so late. I was on vacation and had some other problems to solve. I hope this still gets counted in.
What is your evaluation of the proposal and its APIs/implementation?
Big +1 here too! Whenever I'm writing a lambda function in Swift I also use Soto. Until Swift AWS Lambda Runtime I used Python for all my lambda functions and of course boto to talk to other AWS Services. Now I use the Swift runtime and Soto. The API feels good and after reading/working through a few tutorials I was able to start my own projects. Although I'm using the v5.0.0 beta it feels very stable and I haven't had any problems so far.
Is the problem being addressed relevant for the wider Swift on Server ecosystem?
Yes, if someone wants to work with Swift in the AWS eco system Soto helps to connect to all the AWS Services. Since AWS is a big player in the cloud computing world this is a clear win for the Swift on Server eco system.
Does this proposal fit well with the feel and direction of the Swift Server ecosystem?
Yes, this is a perfect match for the Swift AWS Lambda runtime. As far as I can tell it also makes use of other projects in the Swift Server ecosystem like AsyncHttpClient and NIO.
If you have used other libraries in Swift or other languages, how do you feel that this proposal compares to those?
I've used Python and boto to write my lambda functions until now and I can tell Swift and Soto can definitely compete wit them.
How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
I have three small production projects running using Swift Lambda Runtime and Soto. I also worked through @adam-fowler's and @fabianfett's tutorials and did some playing around. All in all I've written about 12-15 lambda functions with Soto.
