1. Library
  2. Podcasts
  3. Jamstack Radio
  4. Ep. #149, Server-Side Swift with Joannis Orlandos of Unbeatable Software
Jamstack Radio
28 MIN

Ep. #149, Server-Side Swift with Joannis Orlandos of Unbeatable Software

light mode
about the episode

In episode 149 of Jamstack Radio, Brian sits down with Joannis Orlandos to dive into the world of Server-side Swift. They unpack Swift’s growing adoption, Apple's investment in the language, its strengths on the server, and its future. Tune in to hear Joannis's insights and advice for anyone eager to get started with Swift.

Joannis Orlandos is the co-founder of Unbeatable Software. He maintains several Swift projects, including Server-Side Swift. He is a member of the Swift Server WorkGroup and is also the creator of MongoKitten.

transcript

Brian Douglas: Welcome to this installment of Jamstack Radio. On the line we've got Joannis. How you doing?

Joannis Orlandos: Hey, I'm doing all right.

Brian: Excellent, well, I reached out because I had a question. Server-side Swift, it's a thing. I watched the WWC keynote, and we got to all see what Apple's been doing with cool things.

I've been watching Swift for years at this point. Like 2015, I think it's when it came out. Learned Swift development for iOS apps, for me personally. Haven't done it in a quite a, I think the last thing I did was 2020, so it's been a while since I did anything Swift, but I bring this up because it's this whole other world on the server side.

Joannis: Yeah.

Brian: And I brought you on because you have been in that world since the beginning. So first, can you introduce yourself, what do you do? How did you get here? But then tie it to like server-side Swift.

Joannis: Yeah, so I actually started software development at a very early age. My half brother was doing an IT study when I was really young, like he's like 16 years older than me, so I always had this background interest in computers, thanks to him.

And he always tried to motivate me by giving me the exercises that he was getting at his school, right? And his school, he was studying software development a bit, mostly focused on backend development, so from a very early age, he gave me small tasks in PHP and Java.

And when I was going to middle school, I was actually automating most of my homework with those programming languages.

Brian: Yeah, classic.

Joannis: Right, so that was my way of making the workload lighter, but I didn't think it was really cheating, right? Because you still have to learn what the concepts were, how the concepts work at school before you can teach them to do a computer, so I thought it was fair game.

So I knew basically already that I wanted to be a programmer at a very early age. And I wanted to do a study, and during the summer vacation there was this hackathon that I was joining, and I did so well compared to the other people there, and most of them were at the end of their study already when they did enter the hackathon, so they offered me a job on the spot when I completed the hackathon.

And I basically started doing PHP backend developments from there. So that sounds like a bit odd, right? I'm not a PHP backend developer now, but I kind of already understood at that point that PHP was not the language that I wanted to stick with.

So as soon as I had that job, I wanted to kind of investigate what other languages there would be, and this was like 2013, 2014, and I stumbled upon Dart. So Dart is a great language, right? Like at least I think it's a great language. It has like all these async paradigms, and it's kind of NodeJS.

Brian: How does one stumble on Dart, though? I'm curious about that.

Joannis: So at that time, Google was kind of trying to integrate Dart into the web browser by having it replace JavaScript, and I thought it was brilliant up until Google, like all projects, kind of killed it off. And they had this promise like, we're going to do something called Flutter, and nobody heard from that in like years after the fact, right?

Like they were completely silent about it, and Dart was stagnating. So I didn't think that language was going to be existing for any significant amount of time. I thought it was dead, but back in the day, there was like a really cool MongoDB driver for that that I appreciated, and I thought it was great because that MongoDB driver was like really tightly integrated with the ecosystem there.

So then this friend of mine, Robert Bronsmar, who actually worked with me at the same company at the time, he said, "You know what? I really like this new language called Swift. I wish they would bring it like to other platforms."

And then they did bring it to other platforms, they brought it to Linux, or at least they announced in like 2015, they were going to bring it to Linux, and I didn't believe him, right? I was like, Apple is so close for us, right? This is never going to happen. But I promised him like in a bit of a jesting manner, if they do it, I'll give it a try.

So they did release it and I did give a try, and I kind of fell in love with the language almost instantly, like overnight. It was the first day, I think 15th December if I'm correct, I remember because I had to go to work the next day, but I kind of called in sick. I just kept working on learning Swift.

First day evening, Friday, and then the weekend, and then it was kind of Christmas, so I kind of had like a full week of Swift behind the belt basically as soon as it released, and I basically took it from there.

So what's interesting there is that I wanted to do backend development with it, but there was nothing for it. There was this one framework called Perfect, and they had announced that they wanted to collaborate with IBM on Kitura, neither of which exists now anyways, but none of them were mature enough to really be meaningfully useful, right?

Like there was just released on Linux. There was no previous tool chain available. So even the people working at Perfect, they were basically building a Mac OS backend framework that they were hoping to port to Linux as soon as they could.

So there were some small people being interested, right? Whenever a new platform releases, any people just jump the boat, right? And people wanted to use this in production all over the place, mostly iOS developers.

And there was this group called Zero that started working on a HTTP server almost instantly, right? Like they were pre-organized I think. I'm not sure if they were, but it kind of seemed like it. They were organizing themselves through Reddit, and then the STACK channel eventually.

So we thought, hmm, if they're building a web server, we don't have a database driver, and there's this small C wrapper around libmongoc, and we don't like the way it works, so why don't we practice Swift a bit by building a database driver? In Swift of course, because using existing source code is easy.

So basically in December we decided, okay, we already have this existing MongoDB driver in Dart, so let's look at how they're doing. If they can do it, surely we can, right? It's not that difficult building a database driver.

It was very difficult, so we learned a lot along the way, but we basically released I think the first version of this database driver called MongoKitten halfway through January, and then posted it on Reddit, and then that way we got in touch with the rest of the community that was also interested in server-side Swift. Basically, I stuck around from there.

Brian: Yeah, I mean, that's pretty quick, and that's pretty early in the Swift journey as well, because like I've only heard the term server-side Swift like much later. Like as I mentioned, I did some iOS development, and that was my focus like, and I think that's what a lot of folks think of Swift as.

Joannis: Yeah.

Brian: iOS, macOS, maybe a little like small projects. But so since the inception of this database driver and now you have server-side Swift, what's the goal for server-side Swift? Like what problem is it solving today?

Joannis: I think for most people, the reason they use server-side Swift is because they, and this was the original promise, right? It's code sharing between iOS and backend, and this is even more emphasized now that we have Codable.

Based on the idea here is you write business logic or JSON types or whatever, you write a lot of code ones like serialization, deserialization logic, and then you share it between macOS, iOS, and the backend Linux. Now personally, that was the great promise at first, but it's not the biggest strength, in my opinion.

There are two big strengths when it comes to server-side Swift. The first one is you can share resources, and this is mostly from a business perspective, mainly startups, but also bigger businesses. You can basically, the iOS developers can do backend, and the backend developers can do iOS.

So I'm sure if you're an iOS developer, right? You know that it's frustrating when you're done with a feature but the backend isn't ready yet, right? And you're just sitting around. You can optimize a few animations, but the real deal is done, or the opposite happens as well, right? You can't start before the backend is in a more workable state.

And as frustrating as it is for us developers to be blocked by someone else, it's even more frustrating for business owners to kind of have to have you wait and basically fiddle with your thumbs, doing less productive stuff than they would like you to.

And so for both a business and developers, it's nice to be able to pool resources and be more involved with different sides of the code base. It also helps the teams a lot, because you understand what the other people are doing so you can kind of spar a bit more, right?

Like instead of being dependent on this backend guy that's just in a different room, and hoping that he gives you the right APIs that you need without having to go back and forth 10 times, you can basically just jump in and tell them, "I would do this a little bit differently." Give feedback on the PRs, vice versa as well. So that's, I think the main benefit.

The second benefit, which is more recent is that Swift back in the day was a really young language, right? Like when I started with Swift, this was a very immature language compared to now. But nowadays we have so many features that make it very safe to write code, like with Sendible support, we basically have Rust level trust safety if you opt in in Swift 6, and like all of the big features that you want in a backend, they're present in Swift, so server-side Swift gets to benefit from them greatly.

Brian: Excellent, and then I'd be curious to know like your day job and like how this aligns with your sort of working around server-side Swift, but I'm also curious like what projects are you maintaining today as well?

Joannis: Do you mean open-source projects that I'm maintaining?

Brian: Open-source, yeah.

Joannis: So open-source wise, I'm involved with half of the ecosystem, I would say. I have previously been involved as the core maintainer, and then a normal maintainer for the Vapor project. Nowadays, I'm more involved with the Hummingbird framework, both of which are web frameworks for Swift.

I maintain the MongoDB driver still, MongoKitten, and I help maintain RediStack, which is the Redis driver for Swift. Other than that, I have a JSON library that is like more memory-efficient than the one bundled with the Foundation, which is like standard library for Swift, basically just a layer above.

And I maintain a bunch of other smaller libraries, Citadel, which is an SSH client and server, completely programmable, so you could make your own honeypot with that or even command line applications that you kind of SSH into. Yeah, just a lot of a really varied amount of libraries that I'm involved with or primarily maintaining.

As for my day job, I'm the owner of my company. I kind of started this company because I wanted to do more with server-side Swift. It's still very difficult to find server-side Swift jobs at the moment.

There are a lot of people that are eager to work in this space. Like most iOS developers that I speak to have heard of server-side Swift, and a lot of them have done like audio hobby projects with them as well. But professionally, it's very hard to find a job that is like specifically recruiting for server-side Swift.

Usually what I see is that existing iOS teams kind of need to do backend as well, and instead of hiring more people, they kind of start adopting server-side Swift. That's what most of my clients do as well.

Brian: Cool, so half the ecosystem is a big footprint as far as like what server-side Swift is, what you touch. So I'm curious based on like what you see is like, what is the future for server-side Swift, because like the thing I was taken aback on like was watching the keynote where you do AI questions on the phone, on the computer on the phone, and then when it needs to go off phone to like a private cloud server.

Joannis: Yeah.

Brian: Like that was really interesting, because everyone like sat around like, "Hey, why is Apple hiring a bunch of Kubernetes people? Are they going to compete with Azure?" And then now it clearly makes sense, okay, they have a very secure cloud that they can go do compute and AI and stuff too, and that's all powered by server-side Swift.

So like what's your take on like the future of where Apple's going with this technology outside of iOS?

Joannis: So server-side Swift is powering a lot more than just that service, a service of iCloud, right? Like it's Power, I dunno what specific ones, but there are like many things like Apple Notes. I think it's Apple Notes that they hinted at that they were using server-side Swift as well for the synchronization of information.

Jonas Wise did a presentation on how they manage small objects and different objects in iCloud and kind of shared, bring them in sync between different participants in the same app. So that's kind of what he was discussing, the way they persist state across your iCloud account, and that was clearly built in server-side Swift, the way he was talking about it.

So, yes, Apple Intelligence is built with server-side Swift, but it's much more than that, and they're definitely really invested in it, and have been for years. They have a team of like 10 developers focused just on improving networking infrastructure, programmatic network infrastructure like SwiftNIO team basically, that are involved with database drivers, HTTP clients, stuff like that.

It's only going to expand from here really. They're reeducating existing Java developers to be comfortable with Swift on the Server as well, all over the place, they're making sure that their accessing developers can work with Swift and new developers are capable with the server as well.

Brian: Yeah, so would you recommend folks look into Swift today?

Joannis: Yeah, oh totally. I wouldn't say Swift is a beginner language per se, right?

One of the charms that Swift already has, especially on iOS, is that it's a very low entry barrier, right? Compared to some other languages that are compiled, because it has this ergonomic kind of strip-like syntax. But once you get into iOS, like there are a lot of ergonomics in available frameworks, but also like language features that are taking care of you. On Swift on the Server, we amplify our focus on quality a lot more.

So Swift 6 mode, which is like threat safety, kind of like Rust and being race condition free, that is like a feature that you have on iOS, but on the server, it's almost mandatory to you to know how to use those.

So building server-side Swift applications is really interesting if you want to build high quality applications with relative ease, but I wouldn't say it's an easy way to build a backend. I would say it's an easy way to build a high quality backend.

Brian: Yeah, and that makes sense. I think the sort of transfer of knowledge, but also the observability of like I can do my server and I can do iOS and I can do macOS this move into small language models, and like being able to use phone compute, and I know now hardware devices that are doing AI as well.

I wouldn't say it's like a, it's a huge ocean, but I think the ocean's getting, it's expanding. I think that's what we're looking at right now. Because like mobile 15 years ago, like that was all the rage, like everyone was trying to build on the iPhone and build mobile apps, and I think we've saturated the market with how many iOS apps that out there in the market.

So I think like my intro to programming was the web. Even though I wanted do iOS, I ended up making my way into the web and doing all the like Rails development. But I think it's exciting, like AI is like kind of driving a lot of this, and basically I'm asking the question be cause I was recently watching a couple interviews with Chris Lattner, the creator of Swift.

Joannis: Yeah.

Brian: And he's building a new language I think called Mojo. So I'm curious like is he hyper-focused in something completely different that server-side Swift doesn't overlap? Or is Mojo a competing language to Swift?

Joannis: I haven't looked much into Mojo. I believe he was developing that initially for Tesla, right? But from my initial investigations, it seems to be more focused on competing with Python on mathematical use, AI, that kind of area, whereas I wouldn't say that Swift is necessarily focused on computationally heavy work in that area like AI or quick prototyping, anything like that.

One of the examples that I think makes Swift great but also very frustrating for some developers is that the compiler checks everything really thoroughly, and all this checking takes a lot of compile time, which takes you out of your flows for some people, right?

When you're working with Node.js, you're used to whole preloading maybe even your server where you don't even need to rebuild or wait for your web application, it just has a new route. Unfortunately, we can't have this in Swift the way it's designed right now, or I don't think we would ever have that in Swift.

But on the flip side, we get a lot of benefits like Typescript type checking, being race condition free in a multi-threaded language. A lot of mistakes that you can make as a programmer are caught very early on. So I basically, most of the time when I write a route in Swift in my backend, I know that it works before I hit run.

Brian: Yeah, makes sense, cool. So if folks are interested in getting involved in getting started with with Swift, you'd mentioned in passing there's a Foundation as well, and I don't think we actually talked a bit about how the Foundation's set up, but yeah, how would folks get started, and if you also want to mention the governance of how server-side Swift is run as well.

Joannis: The governance of server-side Swift is actually pretty interesting. So we have this core team and we have the core team of Swift alongside the steering group.

Basically, Apple has a couple teams that are focused on the compiler from various perspectives, right? So one group is called the platform steering group, and they're focused on bringing Swift to new platforms or non-standard platforms, right? That Apple doesn't necessarily inherently own.

So that team focuses on bringing Swift to Windows, improving the stability there, improving support in all areas, including IDE. Then they also focus on Linux, and they focus on things like Android even potentially or WebAssembly.

On the flip side of that, there is a compiler team that's mainly focused on language features, not the infrastructure side of things. So they're more concerned with what new language features do we need and how do they look, very global, overarching issues, right?

And then underneath those teams, we have something that we call work groups, and work groups are focused on more specific topics. So one example of a work group is a documentation work group which focuses on making the experience for people who are writing documentation better.

So they're working on the DocC, which is a documentation compiler, which also has a rendering system and symbol resolution, and we use some really cool stuff with that on our blog as well. We use DocC for all of our tutorials on swiftonserver.com, which is where I post articles on how to get started with server-side Swift as well, to answer your question.

And what we do there is we leverage all of the tools that the documentation would provide or help develop, and we basically write our documentation in Markdown and Swift Snippets. Swift Snippets are basically executable bits of code that are compiled. That way, I know that my tutorial doesn't have broken examples.

Then I reference my code material from within my Markdown, and that builds up the website. So this tooling is what Apple provides from their members of the teams, but all of the teams within those previously mentioned groups, including the Swift Server work group, also have people outside of Apple.

So Saleem is a part of the Swift core team, so he gets a major vote in this language design decisions, but also in the Swift ecosystem steering group, so kind of he also supports Windows and other platforms, and he works for the browser company which makes the Arc web browser.

And then the Swift server work group is like two members from Apple and one core team member, and the core team members' function is to basically bring us in touch with the language people if we need more language features or we need to find a, fix a bug in the compiler, which I've done on many occasions.

But most of that group, like out of 10 people, eight of them are non-Apple people within the work group, so a majority of server-side Swift is being done by non-Apple people being involved from various aspects, and we get a lot of say in where the ecosystem grows, where we want language improvements to basically get discussed by the compiler team, et cetera.

Brian: Very cool, yeah, so appreciate you coming on, Joannis, to talk about server-side Swift. I found this like very educational, because like now I've got a good better understanding of like where this came from, who's running this operation, but also a good idea of like where this potentially is heading to as well.

There's a lot of opportunity outside of just macOS, iOS, but I think as this world sort of expands, and folks are now-- If I could be a web developer and now I can also leverage some AI to help me fastly get into like production-ready code into like a Swift, I will probably start building my iOS apps native, and also understanding that I can also build some of my server-side Swift native to make things work like faster, and not have to worry about things like compute.

With that, thanks for the conversation. I'm going to move us to Picks. So these are called Jam Picks, things that we're jamming on, could be music, could be food related, could be tech related as well. And if you don't mind, I'll go first, and I've got to pick.

I've been spending a bit more time on Instagram. I don't actually like TikTok anymore because it feels like it's just like a, they just want to sell you something. Like every other video, it's going to be like some TikTok shop or some live stream about the shop.

And ironically, I've been using Instagram, which I don't feel like I'm sold to because I feel like it's more catered to my interest, which is a lot of food related. But I recently cut out sugar back in December of last year, and dropped, at this point, 30 pounds since December.

Joannis: Impressive.

Brian: Yeah, and the goal was just like, if I consume 25 grams of sugar per day, less than that, and most days I don't have any sugar, and that's pretty much the secret.

But I was on the Instagram, and I was advertised low sugar gummy worms, and I'm like, okay, well if I only do so much sugar, let me try testing out low sugar gummy worms. And there are gummy worms called Rotten, and they have sour gummy worms which are six grams of sugar, I think for the serving size, there are four serving size in the package. Anyway, if I ate the whole bag, it'd be under my sort of daily allotment.

Joannis: Yeah.

Brian: Which I have not done, so I do have some self-control, but they're really good. And for someone who's like cut out candy and sugar December, like these are nice, a nice little treat. And the benefit is that they're low sugar, so the kids, I have two kids, they're gone before, like I only ordered like a couple packs, and yeah, they're already gone.

So the benefit is that these taste good for kids. I don't mind that they have a couple handfuls of it, and then I get a little taste of sugar with these gummy worms. So definitely check them out. They're called Rotten, and I think they're actually going to be sold in stores pretty soon, like Target and a few other stores here in the US. So yeah, worth checking out.

Joannis: Great, yeah, we have, you know peanuts with the case around them still?

Brian: Yeah, yeah.

Joannis: And then we kind of peel them, and that kind of, because you have to peel them still, it still makes you feel fulfilled a bit more than you otherwise would when you were just eating handfuls of them at the time, right?

Brian: Yeah, yeah, a little bit of work and effort.

Joannis: Yeah, a little bit of work and effort, and then you kind of are more satiated after eating a bit of them. That's how I kind of get around that.

Brian: Excellent, yeah, burn a little calories cracking the shells off, but yeah.

Joannis: Sure. That will drop 30 pounds as well, I hope. I don't think it will.

Brian: Cool, so do you have picks?

Joannis: My primary pick is God Is an Astronaut. It's an Irish road band or like somewhere UK, I believe. They've been touring around Europe a bit lately, but I fell in love with their music I think about eight years ago. There is this song by them, which is called "All Is Violent, All Is Bright," and it really just, it almost, or sometimes, it really brings me to tears how powerful that music is.

It's not non-vocal, it's completely just instrumental music, post-rock. But it's such powerful music that they create, and they've been making music for quite a while now, but that specific one, "All Is Violent, All Is Bright," brilliant album, brilliant song, and they really take the time for you to kind of recoup yourself, gather the energy from the song. It's worth listening to.

Brian: Cool, yeah, I'll definitely add it to the playlist and check it out later today.

Joannis: Cool, are we allowed a second pick?

Brian: Oh yeah, please, as many as you'd like.

Joannis: Cool, I've been working on an app, it's originally not my app, but I am looking to get more involved with the app as a contributor as well. It's called Odio, and it's spelled O-D-I-O. We published it in the App Store already, and we're bringing out frequent updates on, it's a completely spacial soundscape environment.

We've got various artists that are publishing their spatial creations to it, and we're working on a composer mode so that people can make their own soundscapes. And the reason I got involved with them is because, well they're a local, they were originally a local company that I knew, and they were working with this South Korean composer called Joon Kwak, and he brought out this album, which is like a nature soundscape, and I gave it a try.

Before I started working with them, I gave it a try, and I never fell asleep this quickly. Most of the soundscapes are not my jam, but yeah, here, it's specifically made in the nature soundscape that completely gets me in the zone. Because what we do is we position, we make a 3D space around you virtually with your AirPods on our headphones, but with AirPods, we can do head tracking, so it stays positionally aware.

So if I put a sound next to my monitor or around me, the sounds stay where they are, right? So if I have a couple birds in a tree over there on the other side of the room, then it knows that my head tracking keeps it there, and that just feels like such a nice wind-down.

Now I'm really looking forward to how I can leverage this way of working more with AVFoundation and Swift, because using AVFoundation, you can kind of build these 3D spatial sounds. And ever since that I got in touch with spatial music also in Apple Music, it's just never been like, like some music seems a bit flat to me now.

So I hope I can touch on people with this app, and then maybe we can make some more apps down the line with this as well.

Brian: Awesome, yeah, I will definitely check that out as well. I appreciate your picks, appreciate the conversation around server-side Swift, and listeners, keep spreading the Jam.