Soto for AWS

Pitch

Include Soto for AWS in the official and recommended SSWG projects.

Motivation

Amazon Web Services (AWS) is the largest provider of cloud services. Many companies rely on the systems and automation they provide. These include storage, security, identity, messaging, databases, compute, machine learning and analytics to mention a few.

Amazon itself, provide SDKs to interact with their services using the languages Javascript, Go, Python, C#, PHP, C++, Java, Ruby but don't provide a first-party, fully comprehensive SDK in Swift. They do have aws-sdk-ios but that is written in Objective-C, which is not much use on non-Darwin platforms.

There are many Swift libraries that provide access to one or maybe two AWS services. Many teams working in the AWS ecosystem leverage multiple services, typically within the same application codebase. Having to deal with multiple libraries with different APIs, signing and serialisation code is not ideal.

The main purpose of the Soto project is to rectify these issues. The project provides access to all AWS services through a consistent API that is closely integrated with Swift NIO.

Project composition

Soto is a Swift-based interface to Amazon Web Services. It supports Linux, macOS and iOS. It is split into three sections.

  1. The core functionality repository soto-core. This is a NIO 2.0 based module. Requests to the core return an EventLoopFuture that will be populated with results at a later point. The core module encodes requests, signs requests using credentials, sends them to AWS and then decodes the response.

  2. Soto contains the service API files. Each AWS service has its own target which contains a service client object along with its operations and their input and output structures. The operations map to the REST api of the AWS service.

  3. The Code Generator which builds the service API files mentioned in section 2. This uses the JSON model files Amazon provides (which are synced from Amazon's aws-sdk-go repository) to generate Swift versions of the service APIs.

Is this something that people would be interested in including as a SSWG project?

26 Likes

Huge +1 to this - I've been using Soto in production on multiple projects for a long time now

4 Likes

I am strongly in favour of this library being adopted by the SSWG. Quite aside from the project itself, the scope of the APIs it must interoperate with mean that Soto requires the development and maintenance of tooling that produce additional value for the server-side Swift ecosystem. The vast majority of server-side developers would gain indirect benefit from the existence of Soto, even if they never used it themselves.

Firm +1.

9 Likes

The framework is really well done and works like a charm! +1

1 Like

+1 from my side as well. I'm using Soto in a number of projects and it works flawless – especially in connection with the AWS Lambda Runtime.

Disclosure: I've contributed to Soto.

+1 great work from Adam

Strong +1

+1
I've played around with Swift AWS Lambda Runtime and I'm almost always using Soto to integrate with other AWS services. It's quick to learn and I haven't had any problems so far. In the next two weeks or so I'll be releasing my first production workload with Swift AWS Lambda Runtime and of course Soto.

Thanks to @fabianfett for his great tutorials on Swift AWS Lambda Runtime and special thanks to @adam-fowler for his great tutorials and the work on Soto :+1:

4 Likes