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?
Thanks,
Johannes Weiss
Review Manager
You may notice that this is the first SSWG proposal which follows a process much closer to Swift Evolution. The new process is documented here.
What is your evaluation of the proposal and its APIs/implementation?
+
Is the problem being addressed relevant for the wider Swift on Server ecosystem?
Yes, it's one of the pillars to make swift on the server awesome and ubiquitous.
Does this proposal fit well with the feel and direction of the Swift Server ecosystem?
Fits very well into the overall direction of world domination (i.e. Swift "everywhere")
If you have used other libraries in Swift or other languages, how do you feel that this proposal compares to those?
I don't have experience on the previous takes of lambda libs for swift.
I do have looked into the library though from a perspective of integrating with the ongoing Tracing GSoC and we'll be able to marry the two very well in the future
How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
I have poked around with the library a little bit and reviewed bits and pieces of it over time.
I have sadly not had a chance to try it out "for real"
What is your evaluation of the proposal and its APIs/implementation?
I'm really happy with the way this has come out. In general it provides an easy interface to developing AWS Lambdas. It provides different levels of control for different types of Lambda. There has been what seems a fair amount of thought gone into optimising the code. My only concern, and it isn't a small one, is the deploying of Lambdas is still fairly adhoc. There isn't a huge amount of support for someone coming to this new and wanting to get something running on an actual AWS Lambda. If a template project was setup which included both shell scripts running aws cli and cloud formation setup files that'd be great. It'd need to include a ton of documentation about what everything does and how it can be customized for the individuals needs.
Is the problem being addressed relevant for the wider Swift on Server ecosystem?
Yes. Serverless computing is a common model and AWS Lambda is one the most popular implementations.
Does this proposal fit well with the feel and direction of the Swift Server ecosystem?
Yes. This is one of the things I most liked about the implementation. Swift NIO was integral to the system and everything I implemented could easily have been translated into a Vapor server route. Systems designed to work with Swift NIO fitted in well.
If you have used other libraries in Swift or other languages, how do you feel that this proposal compares to those?
I have tested out other systems, but none of them felt complete or integrated into NIO in the way Swift AWS Lambda runtime does. Also none of them had local testing so implementing anything more complex than squaring numbers was time consuming.
How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
I implemented two different Lambdas using the system, I implemented my own deploy scripts based off what was already in the examples. While I have a fairly good idea how the interfaces work, I haven't investigated the internals too heavily.
It looks good to me, and seems important to have a standardised "base" for future serverless runtime implementations. The Protocol definitions seem idiomatic and well-thought-out to me. I have written Lambda handlers in JS, Python, and Swift (with earlier "unofficial" runtimes) and this one looks very solid, although I have not used the one under review yet directly.
Hi @calebkleveter, we have different APIs for different user groups:
People with now background in server side Swift. For them we wanted to provide an API that is not intimidating at all. For those we have the Lambda.run callback API. We hope by building on known language features (callbacks instead of EventLoopFutures) to increase the potential reach of the runtime.
People with a background in server side Swift are encouraged to use the ByteBufferLambdaHandler or EventLoopLambdaHandler protocol. These build directly on top of SwiftNIO and they shall provide an interface that fits well into the server side ecosystem.
The Lambda.run interface is just quite some syntactic sugar around the low level protocols.
What is your evaluation of the proposal and its APIs/implementation?
+1 overall, though agree with @adam-fowler's comments about deploying and this should be addressed with, or shortly after, launch.
Is the problem being addressed relevant for the wider Swift on Server ecosystem?
Yes. AWS Lambdas (and serverless in general) are a great, and growing, area in the serverside community, and having Swift in this area is a great step.
Does this proposal fit well with the feel and direction of the Swift Server ecosystem?
Yes. Adds to the "Run Swift anywhere" direction.
If you have used other libraries in Swift or other languages, how do you feel that this proposal compares to those?
I have worked with the Python and .NET Lambda APIs, and IMO these APIs compare nicely. Keeping the simplicity through plain Lambda.run, but adding amazing flexibility using EventLoopLambdaHandler, along, of course, with Swift's great typesystem and typesafety. And, purely in my opinion, a step up from the .NET API with added verbosity of what is executed when, how and why.
How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
Did a full read of the proposal and a quick scan of the source. Have not been able to try the Swift Lambdas "for real" yet, but have worked with Python and .NET lambdas in the past to compare against.
Full disclosure: We are working with @fabianfett on this project and therefore have excellent help. :)
We are currently implementing our ReviewSender (www.reviewsender.com) review aggregation engine with the Swift Lambda Runtime. So far it works really well and is stable.
We are using the Vapor MySQL NIO package alongside with some other libraries (all pure Swift). We also make extensive use of the AWS ecosystem (SQS, SNS, Cloudwatch, etc.).
The integration with other swift packages has been painless and as long as Swift NIO is the common underlying architecture we have not had any real problems. Our software is an internal worker, there is no public-facing communication so I cannot speak to how well responses are being formed or received.
One challenge, that is not solely a matter of this runtime but related is testability and deployment. It is neither easy nor self-explanatory to test locally or to deploy well. Documentation and guides would be highly appreciated. Possibly some "starter-kit" that would have examples set up would make it easier for people that have no deep knowledge of Lambda (or Swift?) to get started.
Alternatively, this runtime could be classified (if that's even a thing) as an expert runtime that requires deep previous knowledge of Swift and Lambda beforehand, but I do not get that this is the intent.
How well does this fit into the Swift ecosystem? It's frankly a little bit odd to have a focus on AWS Lambda as this is a proprietary solution. But then Swift does the same to proprietary solutions from Apple. I would wish for a similar runtime for other cloud function providers (Google, Oracle etc.) to keep people from locking themselves into a specific dependency. All that said, as a long-time and very happy AWS customer I am loving this runtime!
We are using our product in early-stage production (beta-testers) btw.
