The second Swift Server meetup will be hosted online on June 26 at 10am Cupertino, 6pm London, and 7pm Brussels.
The agenda is now finalized
@mikaelacaron will show us How to Make Vapor Fly, Deploying Vapor toFly.io Fly.io is another platform to deploy your Vapor app, for free! In this talk, attendees will learn how to deploy their Vapor app to Fly using the Dockerfile. Having a familiarity with Docker and Linux will be helpful, but isn’t required.
After this talk, attendees will understand Fly as a platform, and can have their Vapor app deployed onto Fly.io.
@Joannis_Orlandos and @adam-fowler will tour the new Hummingbird 2.0 web framework.
Hummingbird is modern web application framework for Swift. Let's discover the recently released v2 with its creators and core maintainers.
Finally, we want to discuss with you. Several members of the Swift Server Working Group (SSWG) will be present to answer any question (swift on the server-related) and collect your feedback.
I'm very curious about using Swift on AWS Lambda. How is the developer experience? How easy is it to locally test, deploy and run?
In particular in a serverless context (i.e. DynamoDB, S3, API Gateway, ...). As there is interest in Swift on server in our organisation. And we have a serverless strategy.
The developer experience is pretty good, from my experience the main issue is how you end up deploying. Testing different lambda events locally can be a bit of a challenge, at least last time I tried.
In terms of interacting with other services, Soto handles all that for you and it's very simple. Deploying is pretty easy whether you're using the CDK, the SwiftPM plugin or doing it all manually.
Developer experience is getting better and better thanks to the archive plugin provided with the runtime (See the deployment section of the README) and other recent improvements.
Getting started with an initial project scaffolding is also made very easy with the new VSCode Swift Lambda extension. It creates a project from template, together with the correct SAM template (extension, source)
Also, the Lambda Event library is getting more and more data types. We recently added support for Lambda Authorizer and Bedrock agents.
When it comes to call other AWS services, you have the choice to use Soto or the AWS SDK for Swift (in preview). The AWS SDK has the advantage to be consistent with other AWS SDK (should you use any). Soto offers some higher level constructs on top of the API that greatly improve the developer experience. The DynamoDB Codable support is an example of that.
We (Apple, the SSWG, some members from the community) are working on a series of upcoming improvements : providing Swift 6 builds for Amazon Linux 2023, revisit the Lambda runtime to better support Swift concurrency and the Swift, Service LifeCycle, investigating the impact of the new Swift Static SDK, support for detached tasks in Lambda, just to name a few.
Please give it a try and provide us feedback. What is missing ? What can be improved ?
I work at Microsoft in Azure. Would be interest if there is any demand for azure functions support similar to lambda. Is there an issue and or place I can monitor for interest in this (other than these forums)?
Apart from a few hobbyists (incl myself), I saw demand and interest growing after the Lambda runtime was released.
These forums are a great place to get feedback from the Swift server community. I guess the usual forum where Azure customers are discussing is another good starting point.
I looked at the Azure Function runtime documentation this morning and found out that the approach is different from AWS. On Azure, the custom runtime provides a web endpoint that is called by the Azure function service. On AWS, the custom runtime must poll the Lambda service to receive events to process.
I think it means that, at high-level, no custom runtime is necessary to deploy Swift code on Azure functions. Developers can just develop a web app with existing Swift frameworks, such as Hummingbird and Vapor and deploy their app to an Azure function.
The other aspect you will have to pay attention is the packaging and deployment : make sure it is easy for developer to cross compile for Linux and generate a package ready to be uploaded.
In my current company our main cloud provider is Azure. We are not using Swift server in any production product, however we have many initiatives on exploring other languages, Swift included. So, having a Swift support for Azure functions would be cool I guess, but there are no hard-requirement on this because well, this is still experimental.
Basically, I see some interest in my company but it's not a dealbreaker. And seeing @sebsto reply it seems like there is no need for a custom runtime, however I still think having some kind of package or tooling to ease-out the usage of Azure function would still facilitate the adoption ... what do you think?
100% agree ! My comment was about a runtime library itself. From my understanding, an Azure function with a custom runtime is just a web app.
But having tooling to cross compile, link, test, package and deploy will make the developer life easier. What would be the most convenient way to propose such tooling ? a Visual Studio extension ? A VSCode extension ? A command line tool ? A Swift plugin for Hummingbird / Vapor ? A combination of these ?
As a Quarkus user, to me the best way would be to do something similar to Quarkus Funqy : Funqy - Quarkus. Here you can do something as simple as 'quarkus deploy' and it'll deploy on the configured FaaS, simple as that.
An extension/plugin that abstract the function provider and give you a unique set of methods/functions to handle the deployment to any FaaS. For Swift, I guess that would be a Swift plugin.
Looking forward to the next one.
)