Swift on the Server, Hummingbird
41:08 Share

What's up, everybody? Welcome to the Compile Swift Podcast. We have another special episode here for you. We're going to focus on some server-side rules today. But first of all, Jeff, how are you doing? Yeah, I got a new release of my app out actually earlier than I expected it to. I accidentally clicked the checkbox or left the checkbox on that was go ahead and roll out the app as soon as it's available and...

It went out and I didn't expect it to go out. So everybody's going to get the like social media push a couple of days late, but, uh,

you know, Hey, it's not like anybody reads release notes anyway. Right. Right. Right. And did you have one of those moments where you're like, Oh wait, dang, did I, did I publish everything on the backend is, you know, did I take it? Thankfully there was no backend needed required, but yeah, I was actually at lunch with a friend of mine and he's like, Oh, Hey, I saw the new update was out. And I was like, Oh, you, you, I think you're on my test flight. You must be in the test flight building. He's like, no, no,

that's, that's not what I mean. And Oh yeah, sure enough. We looked in the app store and yeah, no, it was in the app store. So whoops. Uh, but Hey, you know what? It's not the end of the world. Um,

You know, I didn't get to do my last minute testing that I wanted to do. Didn't get to have my release notes up and ready to go. Didn't have, you know, social media stuff pushed. But, you know, people will get that on the day that it's supposed to be released, which is tomorrow as I record. And just, you know, I can always follow up any bugs that I didn't catch later. So I was just going to say not the ideal way to go, but it could have been worse.

Well, it's funny because, you know, you can't complain about these things because if you used to complain, right, quite rightly, Apple folks would be like, look, you folks, you complain when the app review is too long, so we speed things up for you. And now you're complaining that we do it efficiently. Which one do you want, right? No, the...

App Review, like that was exactly why I submitted it early is like I want the App Review out. I want it to be ready to go. And then I take my time after App Review to get everything ready to go. And the entire problem was just that Apple has this checkbox there to say once it's ready,

let me click it or once it's ready go ahead and put it out on your own and i just apparently had it set to go ahead and roll it out automatically and that was not what i wanted but uh hey that's i just need to be able to double check that better next time totally get it because i never as far as i can recall which is quite a while now i have never done an automatic release

I'm just too afraid of it being at an awkward moment. I think what happened was the last release before that may have been a big bug fix release, and I wanted that one out as soon as possible, and then I just did not set the...

checkbox back is what happened I believe yeah because the release prior to this 24.5 was the fix for Apple Watch Sync and for Apple Wallet Export not working with a particular set of barcodes and so I was like oh crap you know

Apple Wallet was like this big thing and then I'm going to ship it and then everybody's going to be like, well, it doesn't work with this barcode. So I wanted to get a fix out as fast as I possibly could. And so I submitted it to Apple, did the expedited review and had the checkbox on that. Go ahead and ship it immediately as soon as it's done, because, you know, if I submitted this and then I go to bed and it's the middle of the night, I don't want people to have to wait an extra eight hours or whatever. So, yeah, that one rolled out whenever it was available. Yeah.

And unfortunately, it remembers what your preferences was. And that was not what I wanted this time. See, it's funny because as you're saying that, I was just asking myself, you know, am I happy that it remembers or not? And honestly, I don't know. I guess it's one of those times where it's like, no, I think I'd rather it defaulted to the safest option.

But then I bet there's plenty of people out there that are like, just ship the darn thing. All right. Okay, let's get into this. So we are covering a topic. We've covered this before on the podcast many times. And I want to give... Sorry? You've covered it on the podcast.

I'm trying to be inclusive. I'm thinking about your feelings, you know. Perfect. First time ever, right? It's like, really? Now's the moment you choose to do that? Really? Yeah.

Yeah, so we've had, you know, Yanis on the show before. We'll put a link in the show notes to this from the Hummingbird project. And yes, we are talking about Swift on the server. We are going to primarily focus on Hummingbird in this episode. However, I'm sure many of you out there will be screaming, what about this? What about Vapor? What about that? Yes, and a lot of those have been covered before. And of course, there are many options, but...

We have our reasons for focusing on this one. Primarily, Jeff has been using this. So let's dive into this here. But like I say, we'll put a link in the show notes to everything like we usually do. But there is this episode with Yannis talking about the Swift server group as well. A lot of push behind that project.

But let's dive in here. You know, I started at the beginning, Jeff. So you are actually using this in production, right? And I think that's really important to folks because we all do this as developers. We play with things, right? But you're going up that whole other level when you're like, okay, it's in production now. So you want to talk about that?

Yeah, so I'm actually running a couple different services in production right now. I have a mix of both Vapor Services and Hummingbird. We'll get into the difference between those two projects in a bit. But yeah, my by far most used one is in Hummingbird. That is the most recent one that I've done. And it is used by my most recent app, Bark.com.

And so it is seeing a lot more use than any of the vapor services are themselves. But yeah, I've been running both of these in production for a while now. And I think I have some opinions on how they've worked and how they've been done and kind of the benefits and drawbacks to each of them. Yeah.

Well, I think, you know, the first natural question, and this always comes up, and to be fair, this is one that I ask myself quite often too, which is why use Swift on the server at all? Now, this is a difficult one to answer, I think, because it falls in that bucket, like why use anything at all on a server, right? Replace it with language X, and I don't mean that social media website, right?

You know, there's, yeah, you've got a million options available to you on the web. Personally, I have not shipped anything with Swift, not because there's anything against it, but, you know, I'm just so used to all those other web languages, having a web background to begin with. So let's dive in and talk about, you know, that primary question, why use Swift at all on the server?

I mean, I think I'm going to give the easiest possible answer up front, and that is it's personal preference. I am the only person who has to work on this, and therefore what I say goes. And therefore, I'm choosing this particular option over any of the other options that I have. So I'm going to jump in there because, you know, this is something a lot of folks, you know, we all know this, internet people, right? Oh, you should use X. Why are you using Y?

You've hit on, I think, the key argument for just about everything right there. If you're the one maintaining it and you're the one that's building it and you're the one with the knowledge of Swift in this case,

There is no wrong answer for whatever you choose. And I just want to jump in there and point that out because I'm sure it'll come up, right? There are those people on the internet. But I think that that is the perfect answer for so many things as to why use this at all for whatever. So thank you for putting that out there, folks. You go with what you're comfortable with. Simple as that. Don't listen to other people.

What's up everybody? I want to tell you about CleanMyMac by MacPort. Now I have been using this for years. So many years that I don't even remember at this point. But if you're a Mac user and you don't have this tool, trust me, you need it. So let me tell you what you can do with this.

Now, when I open up the application, not only is the UI absolutely gorgeous, but I run SmartCare, and all I got to do is open the app, click on SmartCare, and hit the scan button. Now, when I do that...

what's going to happen it's going to analyze my system and it's going to go through and it's going to look for junk it's going to check to make sure that i don't have any malware or anything like that on my mac it's going to run some performance checks it's going to go through and check for application updates and then it's also going to give me the option to look at what i would call the clutter on my machine kind of my files right the stuff that that i put there

And I'm not kidding you. Every time I run this, and I run this at least once a week, it will find at least a couple of gigs worth of junk files to clean out.

And all I got to do is to tell it, go ahead and run and it'll clean out the junk files. The other day when I ran it, it found six gig of files. And believe me when I tell you I am meticulous about keeping junk off of my machine. And it will just find this stuff splattered all over different folders.

And then it'll run the performance checks, like I say. And it'll just look and see if there's anything that it thinks needs to be done. It'll let me know about any app updates. And I can just have it update them for me. Now, on top of that, there are other tabs. There's the Cleanup tab. And it'll go in there. And you can tell it to do various cleanup operations for you. Again, it's going to run an analysis.

As developers, we all know about Xcode and how much space it takes up, but you will be amazed about the amount of files that can build up and caches over time that you just don't think about. And, you know, they just don't clean themselves up very well. And again, it's,

It'll go through there and save me gigabytes of space. It's absolutely unbelievable. The performance tab is fantastic. It'll run things like flushing the DNS for me, and it'll run the maintenance scripts. It'll check disk permissions for issues there, and all of those things to give you every ounce of performance out of your machine. And if all of this sounds good to you, and it should if you're a Mac user, like I say, I consider this like one of my first installs.

you can go to peterwhedham.com/cmm and that's going to jump you to the right spot where you can go in and you can try out CleanMyMac. You'll get a seven-day free trial. Personally, like I say, every time they bring out a new version, it's an instant upgrade for me. So again, go to peterwhedham.com/cmm and get started with CleanMyMac today.

Yeah. And so what I'll give is the reasons behind some of this personal preference. But again, I am not out here selling that Swift is the one best way to do web backend services because the answer is there is not one best way. It all comes down to benefits and trade-offs and all of that.

And you ultimately have to use what you or your team or your company are comfortable with and what you're doing for that versus the tradeoffs that you would see versus using a different language.

And so I'm going to tell you what I like about Swift on the server. But again, these are, there's a lot of different projects out there. There's a lot of different things that you could do out there. And it's ultimately going to come down to your own calculus as to what you actually use.

One of the things that I really like about Swift on the server versus some of the more popular languages out there for server-side backend stuff is the existence of a compiler. We have a lot of the web tools out there are interpreted tools, whether that's JavaScript or Python,

And there are some languages out there that are upfront compiled. So you've got Rust is obviously the big hot new thing these days. And Golang is a little bit more, it's not quite as up and coming as Rust is, but it's definitely around there as well. Another project that is very similar to that. And having a compiler allows for better performance performance.

because everything's compiled ahead of time. It's not being interpreted. And it allows you to have a bunch of stuff that is caught earlier in the code base. So you don't have to actually run all of your code. You don't have to write a bunch of tests just to make sure that simple stuff like, oh, this variable doesn't actually exist. You get a lot of that kind of stuff, quote unquote, for free. And security too. Yeah. And so I like the...

benefits of compiled languages there. And again, like I said, there's a lot of compiled languages that you can also use. So that's just one thing that I like about Swift. And obviously with that, you get all of the benefits of the Swift compiler with all of the type safety and all of the new

concurrency safety stuff that you have in Swift 6, that kind of thing, that all of the things that the Swift compiler helps you with for your client side code, it can also help you with for your server side code. So compiler, that's the main thing that I love there.

The other thing I know a lot of people are going to think about, and I have not found this quite as useful as you might think ahead of time, but it's still worth mentioning is the limited potential to share code across code bases. And I have found a little bit of that possible in my tools. You can make Swift packages that are just regular raw Swift packages and share them between the two services. And I would say that with that,

you get kind of the sliding scale of how well you can actually share your code. And so models, if you just have like a struct that's got codable conformance, it's pretty easy to share. You just have a whole library that is just your models that all conform to codable. It works exactly the same on server versus on your client. Use that code directly in both places. Your business logic. So this would be your controller in an MVC world or your view model in an MVVM world.

Those are dependent on kind of how tightly you couple with the system, but there is some of that there. I have a SVG, well, I have an image rendering portion to my server that is run on both the server and the client, and I have it going basically to an intermediate server.

of saying like, this is what is represented in this image. And from there, I then split that apart between server and client. But it does get me

A decent chunk of the way there. And that is something that I can share across these two libraries. And then obviously the end result of an image rendering. That's your view. That's what's being displayed. That's not happening. There's not a whole lot of sharing of code. View wise between Swift UI and Swift on the server. So yeah, like I said, models, super easy business logic. And then views, it's just not going to happen. That's true of a lot of these kinds of,

shared code thing. So if you're sharing code between a Rust project, for example, I feel like a lot of the same sort of stuff is going to happen. The one contrast would be JavaScript. You have server-side rendering versus client-side rendering. You can actually share a lot of those codes depending on the framework that you're using. If you're using something like React, for example, I know that you totally can share Vue code across the two. But a lot of the projects are going to be more similar to what Swift does where

Yeah, it's backend type stuff that is easily shareable between the two. Yeah, I mean, you're in the Swift environment, right? And so therefore, naturally, you're going to be using a lot of the techniques and skills and different architecture ways that we are used to using in Swift is going to apply here, right? And so like you say, I think it's fair to say there are some things that...

don't translate across to the server side quite as well as they would with other languages. But that's kind of by design, I think. For me, when I think about Swift on the server, my brain automatically goes to APIs first, for example.

And yeah, and so I think you hit on something there, which is, does using Swift on the server make sense at all if you're not already in the Swift ecosystem? And I would say there's benefits, and they're the same benefits that you get from the Swift compiler as a whole. But ultimately, I don't know that I would...

choose Swift on the server as my default given I don't use Swift anywhere else it's more just hey I'm familiar with this language I know the ins and outs of this language I know some of the quirks and oddities and so I'm much more comfortable with that than say Rust which I know very little to nothing about I'm not going to pick up that whole language just to use it on my server and

I don't think that I would, if I were not somebody who is already familiar with Swift, I don't know that I would do the same thing with Swift on the server. I would not pick up Swift just for server type stuff. I do agree with that. And I'd throw in there as well. If, you know, cause we get asked this question a lot. If you're someone who's like, Hey, I don't know anything about Swift and I want to get into Swift. I wouldn't start Swift.

with the server-side Swift as a way to kind of your gateway into learning Swift. I would recommend that you go and start building apps client-side first, learn those techniques. And the reason I say that is, yes, whichever one you do,

You are learning Swift. No question there. But I think that you learn some disciplines and certain ways of doing things from client side. But I don't know, you may disagree.

You do have one nice benefit with Swift on the server that you don't have with apps per se is that you can start learning Swift on the server without having a Mac. And that is something that is really a limitation to being able to build, say, an iOS or a Mac app.

That being said, I would still suggest that even if that's part of what you're trying to learn there, I would still start with command line tools, something simple. You know, I'm generating a bunch of text or I'm making an API request. I'm doing something else with that. I would start there rather than hopping straight into Swift on the server.

Even if you are wanting to start building Swift and learning Swift without having a Mac, you can get into...

doing Swift on Linux for a bunch of other cool stuff and then build on the server on top of that once you're more familiar with the language as a whole. And then, yeah, if you ultimately obviously want to get into iOS apps or Mac apps, you're going to need a Mac in order to do that development on. But I think that, yeah, there are ways to get started with Swift on Linux that are not hopping straight to running web servers. Yeah.

Right. Okay, fair point. Yeah. Okay. Yeah, folks, I'm not saying run out and buy a Mac. Just start learning Swift that way. And actually, we'll touch on this more when we get to, you know, setting this thing up. But since you've raised it there, a key thing to note in what Jeff said there is...

Yeah, right? You can run this on Linux, right? In fact, arguably one of the best ways, server-side, to do this. You know, again, there are folks out there who are always surprised to learn that Swift is not just...

an apple um os based language yes you can run it on windows and absolutely you can run this on linux as well and i do agree with you for example um swift scripting hey great way to get into it from the terminal right you definitely don't have to be on a mac for that yeah

So, yeah, Peter, do you want to talk a little bit about what the options are out there as far as Swift on the server projects? I know there are kind of two big projects out there. You mentioned them already. Do you want to kind of go into the differences between them? Yeah, sure. So the two big ones that I think, you know, certainly the most well-known are Vapor and Hummingbird.

I'm trying to recall, I don't think I've done an episode on Vapor, but we have certainly covered Hummingbird with some of the Swift Server Group before. Vapor is the one that has been around, I'm going to say the longest of these two, and I'll explain why in a second.

So therefore, both of these have good communities. Arguably, Vapor has a bigger community, which is always important with these things, just because it's been around longer, and certainly it's the most well-known, although I think that's changing now. It is definitely a very opinionated, very structured way of doing things. I would say with Vapor,

The approach is you are going to do it the way they want you to. That's it.

And I'm not saying that's a bad thing, but you are definitely going to have to follow the rules. It definitely gives you more structure to build on. I think that is the nice way of putting that, which is it is very strongly opinionated, as you say, but strong opinions mean constraints and constraints make it easy to build in some sense. So, yeah, both the benefit and the downside to being much more opinionated.

Yeah, absolutely. Vapor is, I would say, an easier one. Like I say, it's got, obviously, because it's been around longer, it's a massive amount of documentation out there. There are examples, I would say, of just about any

style of app that you think you might want to build, I'm willing to bet there's a code example out there. To the best of my knowledge as well, Vapor is one, depending on how you want to do this, you can just run it natively. We'll get into the installing process. But you can install it on your machine or your server,

And other options, of course, you can, you know, there are pre-built Docker images, if I remember rightly, that you can just spin up and, hey, away you go, right? So you've got those as options as well, plus different, you know, custom ways. But you're going to find a lot out there on that. Now, talking about Hummingbird, Hummingbird is on version 2 now. It is Hummingbird...

from what I can remember talking with Giannis is, you know, Hummingbird is very much inspired by Vapor. And in fact, I know from what he was saying, the two groups work closely together, right? It's not like they're in competition here. They borrow and learn from each other. So, you know, whichever one you go with, you are definitely getting into an ecosystem. And just like so many things, I will mention this quickly, on the Swift side,

There's no competition here. There's just a willingness on both sides to see both projects succeed because they benefit from each other, right? But Hummingbird has, in my opinion, really nice documentation, great explanations and walkthroughs for getting started. Now, I will say that you should definitely have...

at least a basic understanding of Swift. And what I mean by that is you don't have to have anything fancy, right? But you're going to see a lot of code on both of these thrown at you very quickly. Take your time. But Hummingbird has a great series of tutorials. There are examples. They do, you know, the classic to-do example, which, hey, at least you're doing an app that we're all familiar with, right? It's like the one up from the hello world. Hummingbird,

Hummingbird version 2 supports and actually draws from quite heavily Swift concurrency. So Swift 6, for example, where concurrency is the word of the day. And yes, I know it's been around for a while now, but they definitely draw heavily from there.

So you're getting all of the nice features from the more recent versions of Swift as well. But that's kind of the primarily the breakdown of both of them. Now, either one is exceptionally good, in my opinion.

Like I said, we're going to talk, we've discussed Hummingbird in this one because that's what we're focusing on. But you are going to have a great experience with either of these. But Jeff, is there anything you want to throw in there? No, like you said, they're both great at their job of being a Swift web server. It really is kind of...

It really does come down to whether you like the more structure heavy paradigm of something like Vapor or whether you prefer the more bring your own architecture style of design that Hummingbird has. And really both have their fan bases. And so they both work great. Another thing that is great about these two tools kind of being built on a similar framework

is there's a lot of libraries out there and a lot of them really do work with both. They can both talk to these databases through the same ORM, Fluent, and they just have a very similar way of communicating with those. They both have their own HTML templating library. Vapor has its own kind of more Swifty type one. Hummingbird has one that's based on a more open standard called Mustache. They both have their own authentication libraries.

There's a wide set of libraries available that you can use with either one of these frameworks that are just built for Swift in general. I know there's some like a MongoDB library that you could just straight up use with either one and it doesn't have a preference to either or the other. So yeah, both of these communities work very well together. And I think that that's a great for both of them. I'm happy to see that there are two vibrant ecosystems out there building a

tools for shift on the server all right here it is the one thing that i cannot do without every day and that is my coffee anyone that knows me or anyone that's listened to it in my podcast or anything else knows that i absolutely cannot operate without my coffee and i love good coffee

So here's the deal. I'm going to give you one free bag of coffee by going to peterwhitam.com forward slash coffee. There is a wonderful company out there that follows the fair trade practices, helps out a lot of independent roasters of all sizes, and the operation is simple. What you do is you're going to go to peterwhitam.com forward slash coffee. You sign up there. You get a free bag of coffee sent to you, yes, in return, and

They say thank you to me by giving me some coffee. But that's not the reason I'm doing this. The reason I'm doing this is because I have found so many good coffees that I just would never have come across, heard about, or experienced without this service. Trade Coffee is just fantastic. You know, there are plenty of places out there. We all know them that supply coffee, good coffee.

You can go to the store, get the coffee, but there is nothing better than discovering new independent roasters and supporting them, discovering new flavors of coffee, new grinds for you can set it up. It's very smart. You tell it the kind of coffee you like. And over time, it gets better and better as it trains in on your selections and your choices and gives you exactly the coffee you're looking for and recommending new ones that will be very similar to

Every time I get a new packet of coffee, I go through and afterwards I try the coffee. I go through the service and I say, look, I loved this coffee. I thought this coffee was okay. Or I say, look, this was really not for me. And every time I do that, it makes the service a little more accurate on the next selection for me.

So again, just go to peterwhitam.com forward slash coffee. Get your free bag of coffee today. If you're a coffee lover, you're going to really appreciate this service. I have been using it for years at this point and thoroughly recommend it.

So, for example, Hummingbird, if you go to the website, and of course we'll put links in the show notes, but hummingbird.codes, there's an ecosystem tab, and they list on there a lot of official extensions that they have in there. Just to give you a couple of examples, right? Some of these should be familiar, but should also make you feel comfortable. So, WebSockets, Redis, those are in there. Like you mentioned, there's a Fluent ORM extension.

It covers many databases. I would say, arguably in my opinion, all of the common ones that you're likely to want to use or certainly encounter in production. And there's some others that we'll talk about later. But there's plenty of support in there and of course packages as well. Yes, that exists on Vapor.

I'm mentioning it in particular on Hummingbird because I think they do a good job at highlighting lots of key areas. For anybody with a web developer background, you're going to feel comfortable pretty quickly. Okay, so let's talk about how you install and get these set up. We're going to jump in here. Again, we're going to sort of do a comparison between the two. We're not favoring either one. We just want to give you an experience of what it's like to set both of these up. So, Jeff, go for it.

Yeah, and I think both of these, their install process...

goes very much towards their kind of philosophies as a whole. And so, yeah, we'll, we'll see it as, as I described them. So vapor has this command line tool. It's literally just called vapor and you install that tool on Mac OS. People are going to be well familiar with this. It's just brew install vapor on Linux. If you're building from Linux, you actually have to build it from source, but it seems like it's fairly simple. You just get checkout and run, make install. And that's,

If you are running on Linux and you don't want to have to deal with the make install stuff, you can also have a Docker image and that Docker image, you just pull it down. You can start building inside the Docker dev container and it just already has vapor installed. So that's another option. It is running in Linux, whether you're running Docker, the host on macOS or on Linux, that is another option there to have it all self-contained.

And from there, you have your tool installed and you can kind of just run Vapor New. And that walks you through this like command line wizard tool. And it says, what do you want to name this? What are you building? Do you need a database connection? Do you need HTML templating? Do you need all of these things? And it will generate a project for you, install the proper libraries, and give you a project folder that you can go ahead and work with.

and it's got all of the structure already built in and it tells you like, oh, here's where you're going to add your controllers. Here's where you're going to do whatever and has a whole project ready for you. With Hummingbird, on the other hand, you have just a simple library and you are on your own to create your own Swift package project exactly the way that you would create any other Swift project. And then you just add the Hummingbird libraries that you need to that existing project.

Alternatively, they do have a Git project template that you can just pull down that project template and start from there. But really, Hummingbird is simple enough that all you do is you create your Swift package project however you want to any other way, and then you just add the library that you need. And you're off and running with Hummingbird project. Yeah, I mean, definitely like this, you know, the Swift package manager, hopefully by now, uh,

We're all feeling reasonably comfortable with it to a certain degree. And that, obviously, with newer versions of Xcode, makes it a lot easier to manage as well. I think when I did it, I think I pulled down the template, if I remember rightly. Yeah.

And I think Vapor may, for one thing, predate Xcode's better handling of Swift Package Manager. But additionally, Vapor also has a lot more individual libraries for handling a lot of smaller particular stuff. And so having that tool there is a lot more helpful for making sure that you have all of the libraries that you need. And so that's why Vapor has this tool, whereas Hummingbird is more just do whatever you want, fork it, grab it, do your project, project build. Yeah.

Yeah, it really is a case of whichever way you want to go, right? Whichever one you're more comfortable with, again, as user developer, you make the decisions for you or, you know, discuss them with your team if you're a team. For sure. Yeah. I would think, though, by the time you get to this install stage, you've probably made a pretty good evaluation of which one you want to go with. However, if you have the time, hey, try them both, right? Yeah.

Yeah, absolutely. I know. Yeah. I mean, it's, it's down to, again, knowing what their philosophies are and knowing which you want between the two. And then when you're ready to deploy the two, both of them are really pretty similar, uh, hit build and run, and you've got a built executable and you could literally just run that executable directly on a server. If you want to, um, you're going to need to install various Swift support things, but,

There's answers to how to do that out there on the web and how to install Swift. But the version that I find is much more useful is both of them include official Docker files that you can use to build a Docker image and then host that anywhere that Docker is supported, which is basically everywhere these days. So that's what I do with my own deploys is I just literally run a Docker build, the flags that are necessary for building for Docker.

Intel based systems, AMD 64 based systems, rather than the ARM systems that everybody's developing on from the Mac. But other than that, you know, you build an AMD 64 image, you put that up on your server, you run it the way that you would run any normal Docker image. And it just works.

And I think that's important right there because for me, you know, my brain switches modes and I start to become very concerned about security at that point. Right. And so, yeah, I like the Docker idea too. For me, now, okay, I get it, folks.

We always say, understand what your code is doing. But for me, I feel more comfortable running a Docker image where hopefully people a lot smarter than me have covered the bases as far as security and good safety checks and all of those kinds of things. Because for me, I want to get on with the business of

making the app or apps and not become a server admin, right? And I'm not suggesting that you need to be a server admin to run either of these. I'm just saying why bring the heartache on yourself and all the pain and trouble? The other advantage with using something like a Docker image is, hey, it's super easy to run that locally before you ship it to production and have an experience that should be predictable at that point, right? Yeah.

And then one other thing worth calling out that I think is a solid question kind of in the deploy area is one thing that Hummingbird does have over Vapor that may actually...

push it for you one way or the other is hummingbird does support running on AWS Lambda as a serverless system. And it does not appear as of this recording that there is really any, even semi-official support for doing that with vapor. Uh, hummingbird has kind of like a, a much quicker startup and running than hummingbird or sorry,

Hummingbird has kind of a much quicker startup and get running than Vapor does. And so I think it is a little bit more suited to being run in a serverless system. And so, yeah, they do have an official extension for running Hummingbird on Lambda, which does not exist on Vapor. So that is another option for having your service deployed. Yeah. And I think that...

I mean, that pretty much covers it, really. The areas I just want to sort of note for the listeners here, the areas we've not covered, sort of the middle ground, right, of, well, how do I build my app and that? We purposefully decided that

Not to dive too deeply there, because at the end of the day, the answer is, well, it's Swift. You build it like you would with Swift, right? And we didn't want to, like, you know, it's kind of like, and this is how you do this thing you already know how to do. Again, if you don't know how to do it, you know, hey, it can be a great introduction to Swift. But in between, all the middleware for your app is basically Swift

put your Swift hat on and away you go, right? Absolutely, yeah. And a lot of what you're doing is you're taking in and returning codable properties. And so if you're running something that's like a API, you're going to take in a codable model. That's your request. You're going to spit out a response. It's probably also a codable model. Each of these has ways of handling things like

You want to return a different header or you want to respond differently based on the header, returning different status codes, that kind of thing. Both of them are very straightforward in how you handle that. So no real huge difference between the two there.

Okay, so I think we've covered the topic here. Don't know. Hey, you know, maybe there's going to be future episodes here where we dive into some particular things, particular aspects or code discussion. But this is how you get up and running with Swift on the server for sure. Certainly something I think is worth your time looking at. Other than that, folks, we've covered this here. Jeff, closing thoughts, where can we find you?

You can find me, as always, at kokotype.com and kokotype on all the socials. All right. And you can find me at peterwhitam.com or compileswift.com and all the socials. That's it, folks. Speak to you in the next episode.