Dev Conversations #3: Adam Fowler & Joannis Orlandos
Dev Conversations is a monthly series where Swift Toolkit features members of Swift work groups, content creators, and people who contribute to the Swift community, focused on tooling, developer experience and Server Side Swift.
In these talks, we discuss open source projects, tips for professional growth, and many other valuable insights and perspectives from other developers.
Adam Fowler and Joannis Orlandos are both active members of the Swift Server Workgroup. Adam is known for his contributions to Soto (a community supported Swift SDK for AWS), and to the VS Code Extension for Swift, amongst other packages. Joannis was a contributor and core team member at Vapor, and is involved in many Server Side Swift projects: he created MongoKitten (a MongoDB Driver for Swift), and is a maintainer in RediStack and CoreOffice.
In the last few months, they have been working together on a new major version of a lean and modular web framework in Swift: Hummingbird 2.
In this Dev Conversations episode, Adam and Joannis join a chat where we talk about the evolution of Soto, working with Swift in VS Code and how Dev Containers are helpful, and how not, Hummingbird 2. As Joannis told his jounery in the Swift on Server world, we discussed the key differences between Hummingbird and Vapor, lessons learned along the process, and how the two frameworks help each other and the Swift community as a whole.
If you prefer reading or listening instead, you can find the written interview and the podcast links after the video, along with relevant links discussed in the chat.
Also available in your favorite podcast player 
Hummingbird
Swift Toolkit
Hello, Adam and Joannis! How are you both doing?
Adam
Doing good, good. It's been a good month. It's been nice to hear some of the feedback, from the release of Hummingbird 2.
Joannis
Yeah, doing excellent.
Swift Toolkit
And Joannis, you were just at the ServerSide.swift conference
Joannis
Yeah, I was just at the Swift Server Conference and I spoke to a lot of people. It was nice to hear so many people were already early adopters, both after release but also a of people were already engaged with Hummingbird 2 before it was formally released. So it was nice to hear, many people are happy with it.
Swift Toolkit
Before we jump to Hummingbird, I just wanted maybe to talk a little bit about Soto with Adam, who's been the person behind it. I remembered it had a different name in the beginning, right? Do want to cover a little bit how the story went?
Adam
Well, when I joined what was the AWS SDK Swift at the time, that was already on version 3. But obviously, there was a certain company that had a problem with us using that name. Because they may have been developing a similar product and it was their services they were servicing.
So, yeah, Amazon did come to us and say, can you change the name? And then I had a large amount of time trying to work out what we were going to call it.
Swift Toolkit
And there is Boto, in Python, right?
Adam
Yeah, that's kind of where we came from. There's Boto, which is the Python SDK. And then the Rust one at that point was also called... It was called Rusoto.
So it seemed to make sense to call it Soto. Yeah, Swoto sounded awful.
Swift Toolkit
And from the beginning, was it already 100 % code generated?
Adam
When I joined, it was all code generated. By that point, they were on the verge of releasing version 3. I think it had been in development already 2 or 3 years prior to then. It was started up by a guy called Yuki Takei. I think he's based in Japan.
He'd already left the project by the time I joined. Jonathan McAllister was kind of doing most of the development when I joined. And then people got jobs, they moved on, they moved away, sometimes they moved away from Swift. And so it sort of came down to me.
That's kind of when I took over. And one of the first things I wanted to do was make sure that we were actually producing what the model files were asking for, and going through every single possibility because up until then, most of the code that was output was code that people were using.
They were like, "this works for S3, let's do this for S3". But then that would break CloudFront. Getting that right was a very long project.
With version 5, Fabian Fett joined us and was quite involved in the designs for splitting the service and client into separate types. And we released 5 and he then joined Apple.
Swift Toolkit
I see that nowadays it has like almost 400 targets, right?
Adam
Every time I do a new release, I go to start seeing what was the new services that came in. There's always another five or six, and it keeps growing. I think at the time that the package index first properly came online, were like there. The package with the most targets, which at the time was about 230, I think we're somewhere nearing 350 or 380 now.
Swift Toolkit
Nice! And the other topic I wanted to touch a little bit about it is the VS Code extension.
How did you decide to go for it? How did it things unfolded?
Adam
I'm a member of the Swift server workgroup, as is Joannis, and this was a push from the workgroup. Because one of the issues at time was there was no IDEs that really properly supported Swift.
You could sort of get some bits and pieces together working on VS Code, but it was never very helpful. It was always like like, you go find a message on the forums to find out how to set it up, so we made a conscious decision to actually provide a properly supported extension for VS Code.
Most of that work was on me, until the point where Apple decided to come in and help us
Swift Toolkit
What are the main components of this project?
Adam
It has the package dependencies list, based off SwiftPM.
It then has a form of the test explorer. The main thing is trying to, if it's available in Xcode and we can do it, we'll try and replicate it in VS Code.
Swift Toolkit
But the heavy part is LSP, right? The Language Server Protocol and all the interactions for code completion
Adam
The LSP part, which we use SourceKit LSP, which is developed by Apple. And without SourceKit LSP, we would have gotten nowhere. And so yeah, that's used by pretty much all of the IDEs that got some form of Swift support.
Swift Toolkit
And Joannis, in your day to day do you use VS Code?
Joannis
I use it all the time! Well, recently it's gotten even better because there's this new IDE called Cursor, which is a fork of VS Code with a ton of niceties on top. And well, without a VS Code extension, I wouldn't be able to use cursor either, right? But also I use a lot more tools day to day when I use VS Code or VS Code based editors.
And it's just so nice to be able to write more than one language in a properly set up environment for me.
Swift Toolkit
I personally have a little bit of a hard time with yes code. I feel it lacks some native UI, and maybe keyboard shortcuts that I'm used to them. What would be your tips for people who are used to Xcode?
Adam
The keyboard shortcuts you can change all of them to whatever you want, they're not set on stone
Joannis
It's a setup that someone has to do... but you can even copy the configuration to someone else if you want to share it, right?
We do that with VS Code dev containers. We have our entire development setup in one, basically in our repository so that we all have the same stuff.
Swift Toolkit
And what other tips would you recommend for people who are still not 100% comfortable with VS Code? For tooling and server apps they want to use VS Code or give it a try?
Joannis
The most important thing that I think is, it's not like a must, you don't have to use VS Code. Most of the packages make it so that the macOS experience is very similar, if not exactly the same with Linux. Of course, you can't use the Apple frameworks, you could accidentally import those. But besides that, I think it's nice that the workflow is mostly the same.
Adam
I think one of the big things that VS Code has, which Xcode doesn't have, is the whole dev container support. If you're working now on Swift 6, there's a good chance you'll write some code that will break the Swift 5.9 build. And I can roll up a a dev container with Swift 5.9 in 5 minutes, and then be working in Swift 5.9 with real ease and that's made life a lot easier.
Joannis
It certainly helps me as well. But also when I have a customer project, then I always give them a dev container so they can have the exact same version that I was working on. Even years later, they can reproduce in exact environment.
And it goes down to even setting up the database inside the dev container. So almost every backend will need a database. Maybe even some other services like OpenTelemetry, and I include all of that in the same bundle.
And that's just super nice, that's going get set up in a couple of minutes! Because whether I'm on Windows, macOS or Linux, I can replicate the exact environment just the same.
Swift Toolkit
That's definitely one of the advantages of having Docker, and even more than that, it's an abstraction by VS Code, right? You don't interact directly with Docker!
In the last week or two, I've been working on something for the website that is related to Lambdas and DynamoDB. Do you have any tips maybe for people working on who want to test locally?
Joannis
I believe AWS SAM has a built-in tool to run lambdas locally. I've used it before, although nowadays I kind of deploy my applications in a way so that I can run them as a web server locally and as a lambda on AWS Lambda. But you can also use AWS SAM to run a local API gateway with your local lambdas.
Swift Toolkit
That somehow takes us to the next subject, which is Hummingbird, because in this project specifically, I wanted to play around with Hummingbird 2 and see how it feels.
So for people who are new to Swift on the server or they only know Vapor, what are the key differentiators between Hummingbird and Vapor? And where I assumed when the project started, Vapor was already out there. So what were the goals when you started it?
Adam
Well, I guess when I started Hummingbird with version 1, at the time my goals at time were producing something that was a little more lightweight, a little more modular.
Vapor gives you everything in one go. And it's a very large package and I wanted to able to supply something a bit more lightweight. That was my initial plan with Hummingbird 1.
It is considerably faster than Vapor, but then you have to take all these with a pinch of salt, of course, because no one returns the word Hello World repeatedly from the server a 100,000 times.
Then, just as I was sort of considering what I was going to do with Hummingbird 2, Joannis came online as well. Obviously there was discussion within the Swift Server Working Group on how modern server frameworks with Swift concurrency would work.
Originally I'd done a small server just to see how it would work out. Yeah, I called it Colibri, which is a type of hummingbird :) And then started using that as a basis for building what became Hummingbird 2. The two of us built that over, I suppose about 8 months, was it?
Joannis
So I reached out to Adam about needing a next version of a framework, I think around June June 2023. And pretty quickly after that, we started talking a bit about what that would look like. You shared your upcoming version of Hummingbird with me.
If I recall correctly, at first we were thinking about bridging, doing a gradual move towards structured concurrency, where the underlying internals were still Swift NIO in the old form, but we very quickly decided that that was not the way forward for Swift on the server.
We had our first beta in around January or February of this year (2024), which was already like a fully functioning framework.
And then we took the next eight or so months to just refine everything that we could find. I think our example projects are instrumental there. Also Hummingbird 1, thanks to Adam already had a lot of example projects that we could easily translate. And those projects perfectly demonstrated when something was awkward or didn't fit.
Swift Toolkit
I saw by the way your talk on the Swift Server Conference, which I'm going to add a link to. So there mentioned you totally got rid of Swift NIO, right? It's 100% async-await now?
Joannis
So it still uses Swift NIO for the networking, but it's abstracted away almost entirely internally. There is, I think, one place where we expose Swift NIO for the networking. But Hummingbird features are pluggable, it has a lot of extension points. The most low-level one is the HTTP server itself, which we also use to replace the input and output with AWS Lambda support.
But that same system is used for HTTP1 servers, HTTP2, HTTPS or TLS. And basically, so long as you can receive HTTP requests and send HTTP responses, we're happy. So based on those principles, we have pluggable layers all throughout Hummingbird so that other frameworks can extend Hummingbird.
And for the most part, they don't even require knowledge about Hummingbird. For example, the Hummingbird authentication library, while it does integrate with Hummingbird itself, a lot of the core concepts are very easily translatable to a library that doesn't know about Hummingbird, but can still integrate with it through protocol conformances.
Swift Toolkit
I also saw in the release note that it moved to the SwiftHTTPTypes package also.
Adam
Yes! It seemed the right time to do it because they had been out, and it would have felt wrong to continue with the NIO types. Unfortunately, the rest of the community are a bit slow in catching up. But I think the only other package, well, there is open API at the moment.
Joannis
Right! So bridging from Hummingbird to OpenAPI is very lightweight because of it. But bridging from the NIO channels into Hummingbird is at this point a little bit more expensive than we'd like. Luckily, this means that without any public API changes, we can optimize it even further down the line, which is definitely where we're headed.
Swift Toolkit
You mentioned earlier the examples repository... For this work that I did now, it was very helpful having many different examples which are like the blessed way of doing things and so they're totally helpful. So thanks for that!
Adam
It's been a really useful resource!
Swift Toolkit
I assume not only for consumers, right? Also for you.
Adam
Yeah, Joannis has already said it's been in actually designing Hummingbird and getting APIs right, having sort of 25 different examples which you have to implement those APIs and you soon find the edges and the awkward bits and you can go back and refine a bit more until everything feels right.
Joannis
Yeah, and even with Hummingbird authentication, which is not released yet, we're still refining that a little bit. And as we're refining it, we're making pull requests to the example so that we can see if things will stick or not. So before we merge a pull request into a library and publish it, we'll make sure that all the examples feel right.
Swift Toolkit
So another issue, another thing that I wanted to talk a little bit about maybe is the deployment part, at least for people who maybe are coming from a background of iOS development, maybe learning Docker or especially the deployment part is, it might be a little bit of a hurdle.
What are the recommendations you'd have for someone that's new to this whole world of deployment containers and images?
Joannis
I definitely recommend going with Docker containers or at least some form of container. The nice thing about Docker is that you can reuse a lot of your knowledge about Docker containers to set up dev containers as well. So you can kind of reuse that experience in your developments there. Docker containers are also very easily adapted to like GitHub Actions and other CI systems.
And then you can also reuse that same template for you and same knowledge and experience for deploying to many clouds. Like virtually every cloud provider supports hosting containers. So it's very instrumental that you understand that workflow.
And in addition to the many resources that are out there about containers, we're also working on deployment guides for this from within the Swift Server work group. Some of those might be going up on swift.org.
Others might be going up on our SwiftOnServer.com website and there are definitely other people talking about, talking and writing about deployments as well. Of course we need much more content than we have now but there's definitely a lot in the works as well.
Swift Toolkit
I'll tell you what I do. My trick is going to the Vapor template repository, which is the repository that whenever you run the Vapor CLI and create a new project, you go there and it has a nice Dockerfile. Would you have anything similar for Hummingbird?
Adam
Hummingbird has a template as well. There is a template repository which you can either build your own repository off or you can clone and then there's a configure script to run in that. The Dockerfile in there maybe based on the Vapor one. Maybe :)
Gwen has done a huge amount of work on that (the Vapor one) and there's no point replicating it if it's already good.
Joannis
And I think the template repository currently also already has the dev container set up. So even though you might want to add databases to your dev container, which is optional, of course, you can also do that a different way, but it should be very easy way to get started.
Swift Toolkit
We spoke about Vapor in the beginning, and the impression I had until I started playing with Hummingbird was that Vapor is the easiest path to start on because of its API and because it comes with all everything that you need.
But I'm not sure about it anymore... Would you agree with that?
Joannis
I was involved with Vapor very early on. We have a service that's running on, that has been running on Vapor since early 2016. That's still running today and I think that's a testament to how successful Server Side Swift has been.
But when I started, when I worked with Vapor throughout the years, I was part of it, I was a contributor and a maintainer. Then I was a core team member for a while.
And back in the day, there were more frameworks, but none of them really took off. And as a function of that, as a result of that, Vapor saw itself as the center of the universe, which I think was the right choice at this time.
But we used a lot of design patterns that were very much centered on Vapor itself. And you can still see remnants of that is how the package structure is, right? So you have a LeafKit and Leaf, where one integrates, one is just the package itself and the other one integrates with vapor.
Adam
I think that decision was one of the things that actually has helped Hummingbird because there are all these packages that are available which the users of Hummingbird don't have to drop because they're not using Vapor. Things like Fluent Kit. If the Vapor team hadn't done that, we would have been a lot harder for any other web server to gain ground.
Joannis
Yeah, that's true. But I think for the most part, those decisions were more backed by the fact that we could run this outside of Vapor rather than with another web framework. So back in the day, we were considering running our libraries on iOS, not with another web framework. And a lot of these ideas were inspired by that promise that we would make iOS developers' lives easier by bridging into those ecosystems.
We learned a lot about web framework development over the years. Tanner moved on to SpaceX, so that experience is out of the community. But I found that while Vapor is much easier to set up because it's only one import, there are a lot of costs you pay for it: compile times, which are frustrating, and also binary sizes.
Most people don't necessarily care about, but there are still a cost. But there are also bigger costs, like when the ecosystem needs to upgrade to Vapor 5, all those packages need to be upgraded as well. And I think Hummingbird tries to decouple that more in a way that is more scalable, more future proof. I hope Vapor 5 will go the same way, even just for their own sakes.
Swift Toolkit
I think that at the end of the day, the whole community gains, right? It's not a competition between the frameworks. Everybody gains from whoever is developing stuff. Vapor can learn from Hummingbird. Hummingbird can use packages from Vapor, and the community grows as a whole.
Adam
We're definitely collaborating a lot within the ecosystem, especially through the Swift server workgroup, but also around it. We're constantly in touch with one another and helping each other move forward. So while Hummingbird and Vapor are certainly two different pieces within the ecosystem, we're not exactly enemies :)
Swift Toolkit
Yeah, very nice! I think with this positive note, we could wrap up here.
I'm leaving links to your profiles and all the stuff we spoke here. Thanks so much for the chat!
Adam
Thank you for having us. Bye.
Joannis
Thank! Bye bye.