Serverless Swift with Compute@Edge by Andrew Barba | Fastly

Recently Andrew Barba, the engineer behind Swift Cloud, released a highly performant and fully featured Swift SDK for our Compute platform. And he built the initial release in just four days, to boot! Understandably impressed, we sat down with Andrew to learn about his goals and build process for the project. 

If you’re a developer in or around Apple’s ecosystem, you’ve probably heard of Swift — the programming language built by Apple and the open-source community for iOS, iPadOS, macOS, tvOS, and watchOS.

Though the Apple ecosystem is massive on devices like tablets and phones, the Swift community has long sought a pathway to run their favorite language on servers. Maintainers of the language have been laying the groundwork for this, including adding support for compiling code to WebAssembly, but there hasn’t been much traction in the community yet… Until now. 

Read on for excerpts from our conversation with Andrew Barba: 

What makes Swift a good choice?  What do you like about it?

I got started in the industry as an iOS developer and adopted Swift early on — Swift is huge in the iOS ecosystem, and I fell in love with its safety and performance. My career ended up taking a different path, towards the backend, so I wasn’t using Swift as much anymore – I was writing a lot of JavaScript on Node.js.

I found the development experience severely lacking compared to building native applications in Swift. It was exciting when Apple made a push for Swift on the server a few years ago, including releasing CI tools and public packages to run Swift on AWS Lambda, etc.

What made you want to write a Swift runtime for Compute?

The overhead to getting Swift packages into AWS was too high — you need to know too much about cloud architecture, Docker files, etc. I wanted to decrease the barrier to entry for the iOS developer community to run Swift on the server. 

There's a Swift Wasm team, which has been doing amazing work allowing Swift to compile to WebAssembly. As I immersed myself in their work, I had my lightbulb moment: “Let's implement the entire runtime spec so there’s nothing in the way between the compiler and the platform!”

Why did you choose Compute?  

I tried to build the Swift integration on Cloudflare Workers but found there were too many dependencies required to build a package within Workers’ size requirements. Additionally, it wasn’t clear how to take advantage of platform features like outbound HTTP requests and the cache layer. I was able to directly integrate Swift and Compute because Fastly exposes Compute’s core system hostcalls, making for fewer layers of abstraction and much smaller packages.

Essentially, Fastly is polyglot and supports multiple languages.

Edge computing is evolving in lots of interesting directions at the moment. How do you think developers want to interact with edge platforms, and will we converge on a standard?

There is a standardized spec for HTTP, so potentially a universal set of abstractions could be defined today for edge computing. I think, universally, developers want fine-grained control of caching. Platforms can continue to diverge on things like state. Everyone's trying to reinvent the same thing but in slightly different ways.
With the complexities of these platforms and the amount of stuff they're now doing for you, it's harder and harder to test a production-equivalent setup locally, so we also see more tools that help you use the remote service as part of development or testing workflows – tunnels, playgrounds etc. Fastly's Fiddle and Viceroy tools are great.  There's a lot to be said for 'single file apps' – the ability to grok everything in one place and the ability to test and iterate quickly. 

What new use cases do you think will emerge at the edge? 

It’s hard to say whether there's anything you will only be able to do on edge compute. Image optimization is one of my favorite features, and I think machine learning is another huge opportunity for edge compute. 

One of the greatest features of an edge network is resiliency. Stateless edge compute apps are easy. The problems come with state and consistency. Spanner from Google is really interesting for that reason.

What advice do you have for developers just starting out? How is that different from the advice you'd give yourself when you started out?

We're now writing in more of a functional, declarative way – getting away from imperative logic and lowering the mental barrier to understanding what your application is doing. It's important to pick the thing that makes it easier to think about your code. The tools are so much more powerful today, and there's no need to dive below the surface; once you have found a good platform that matches your needs, you can be incredibly productive.

Want to kick Swift’s tires on Compute (or even help Andrew fine-tune the SDK)? Check out the repo for Andrew’s runtime here. Or if Andrew’s work has inspired you to bring your own build process to Compute, get started here.

At Fastly, we often talk about our by developers, for developers ethos. When we say “by developers,” we don’t just mean the Fastly teams building our products — we also mean the broader community of developers that contribute to our ecosystem so our entire user base can build how they want, in the languages they know and love.
If you’d like to see your work featured on our blog, or want to share your experience as you experiment with Andrew’s Swift SDK, tweet us!