November 24, 2024 • 41 mins
This week, we discuss serverside Swift using Hummingbird. We also discuss Vapor to compare the two experiences.
- (00:00) - Introduction
- (08:44) - Clean My Mac
- (28:20) - Coffee Time
- (34:17) - Cocoatype.com
- (34:57) - Support the podcast
- https://www.compileswift.com/podcast/s06e12/
- https://vapor.codes/
- https://hummingbird.codes/
- Clean My Mac
- flanker
- Jay Wilson
- Adam Wulf
- bitSpectre
Mark as Played
Transcript
Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
Peter (00:02):
What's up everybody? Welcome to the Compile Swift
Podcast. We have another specialepisode here for you. We're
gonna focus on some server siderules today, but first of all,
Geoff, how are you doing?
Geoff (00:14):
Yeah. I got a new release of my app out, actually earlier
than I expected it to. Iaccidentally clicked the
checkbox or left the checkbox onthat was go ahead and roll out
the app as soon as it'savailable. And it went out, and
I didn't expect it to go out. Soeverybody's gonna get the, like,
social media push a couple dayslate.
(00:34):
But, you know, hey, it's notlike anybody reads release notes
anyway. Right?
Peter (00:40):
Right. Right. And and did you have one of those moments
where you're like, oh, wait.Dang. Did I did I publish
everything on the back end?
Is you know, did I take it all?
Geoff (00:49):
Thankfully, there was no back end needed required. But,
yeah, I was actually Sweet. Atlunch with a friend of mine, and
he's like, oh, hey. I saw thenew update was out. And I was
like, oh, you you I think you'reon my test flight.
You asked me in the test flightbuild. And he's like, no. That's
that's not what I mean. And Oh.Yeah.
Sure enough, we looked in theApp Store and yeah. No. It was
in the App Store. So whoops.But, hey.
(01:10):
You know what? It's not the endof the world. You know, I I
didn't didn't get to do my lastminute testing that I wanted to
do. Didn't get to, have myrelease notes up and ready to
go. Didn't have, you know,social media stuff pushed, but
it it you know, people will getthat on the day that it's
supposed to be released, whichis tomorrow as I record.
(01:31):
And, just, you know, I canalways follow-up any bugs that I
didn't catch later. So I wasjust gonna say not the ideal way
to go, but it it could've beenworse.
Peter (01:41):
Well, it's funny because, you know, you can't complain
about these things. Because ifyou used to complain, right,
quite rightly, Apple folks wouldbe like, look, you folks, you
complain when the app review istoo long, so we speed things up
for you. And now you'recomplaining that we do it
efficiently. Which one do youwant? Right?
Geoff (01:59):
No. I I the app review, like, that was exactly why I
submitted it early. It's like Iwant the app review out. I want
it to be ready to go, and then Itake my time after app review to
get everything ready to go. Andthe entire problem was just that
Apple has this checkbox there tosay, once it's ready, let me
click it, or once it's ready, goahead and put it out on your
(02:21):
own.
And I just apparently had it setto go ahead and roll it out
automatically, and that was notwhat I wanted. But, hey. That's
I just need to be able to doublecheck that better next time.
Peter (02:35):
Totally get it because I never as far as I can recall,
which is quite a while now, Ihave never done an automatic
release. I I'm just too afraidof it being at an awkward
moment. You know? I think whathappened was the last release
before that may
Geoff (02:52):
have been, like, a big bug fix release, and I wanted
that one out as soon aspossible. And then I just did
not set the, the checkbox backis what happened, I believe.
Yeah. Because, the release priorto this 24 dot 5 was, the fix
(03:14):
for Apple Watch Sync and forApple Wallet export not working
with a particular set ofbarcodes. And so I was like, oh,
crap.
You know? Apple Wallet was likethis big thing, and then I'm
gonna ship it, and theneverybody's gonna be like, well,
it doesn't work with thisbarcode. Like so I wanted to get
a fix out as fast as I possiblycould. And so I submitted it to
(03:34):
Apple, did the expedited review,and had the checkbox on that go
ahead and ship it immediately assoon as it's done because, you
know, if I'm submitted this andthen I go to bed and Yeah. It's
the middle of the night, I don'twant people to have to wait an
extra 8 hours or whatever.
So, yeah, that one rolled outwhenever it was available. And,
unfortunately, it remembers whatyour preferences was, and that
(03:56):
was not what I wanted this time.
Peter (03:58):
See, it's funny because as you're saying that, I I was
just asking myself, you know, amI am I happy that it remembers
or not? And, honestly, I don'tknow. Yeah. Yeah.
Geoff (04:10):
I I guess it's one
Peter (04:11):
of those times where it's like, no. I think I'd rather be
defaulted to the safest option.But then, I bet there's plenty
of people out there that arelike, just just ship the darn
thing. Alright. Okay.
Let's get into this. So, we arecovering a topic. We've covered
this before on the podcast manytimes, and I wanna give sorry?
(04:34):
You've covered it. I'm trying tobe inclusive.
Geoff (04:38):
Yeah.
Peter (04:39):
Yeah. I'm I'm thinking about your feelings, you know.
Geoff (04:42):
Perfect.
Peter (04:43):
First time ever. Right? It's like, really? Now is the
moment you choose to do that?Yeah.
Really? Yeah. So we've had, youknow, Janis on the show before.
We'll put a link in the shownotes to this from the
Hummingbird, project. And, yes,we are talking about switch on
the server.
We are gonna primarily focus onHummingbird, in this episode.
(05:08):
However, I'm sure many of youout there will be screaming,
what about this? What aboutvapor? What about that? Yes.
And and a lot of those have beencovered before and, of course,
there are many options, But, wehave our reasons for focusing on
this one. Primarily, Geoff hasbeen using this. So let's let's
dive into this here. But like Isay, we'll put a link in the
show notes, to where everythinglike we usually do. But there is
(05:30):
this episode with Janis whereI'm talking about the Swift
server group as well.
A lot of push behind thatproject, but let's dive in here.
You know, let's start at thebeginning, Geoff. So you are
actually using this inproduction. Right? And I think
that's really important to folksbecause we all do this as
developers.
We play with things. Right? Butyou're going up that whole other
(05:51):
level when you're like, okay.It's in production now. So, you
wanna talk about that?
Geoff (05:56):
Yeah. So I'm actually running a couple different
services in production rightnow. I have a mix of both Vapor
Services and Hummingbird, andwe'll get into the difference
between those two projects in abit. But, yeah, my, by far, most
used one is in Hummingbird. Thatis that is the most recent one
that I've done, and it is usedby my, most recent app, Bark.
(06:22):
And so it is seeing a lot moreuse than any of the vapor
services are themselves. But,yeah, I've been I've been
running both of these inproduction for a while now, and
I think I have some, opinions onhow they've worked and how
they've been, done and kind ofthe benefits and drawbacks to
(06:44):
each of them. So
Peter (06:46):
Well, I think, you know, the first natural question and
this always comes up and and tobe fair, this is one that that I
ask myself quite often too,which is why use Swift on the
server at all? Now this is adifficult one to answer, I
think, because it it falls inthat bucket like why use
anything at all on a server.Right? Replace it with language
(07:08):
x and I don't mean that socialmedia website. You know, there's
yeah.
You got a million optionsavailable to you on the web.
Personally, I have not shippedanything with Swift, not because
there's anything against it,but, you know, I'm I'm just so
used to all those other weblanguages having a web
(07:29):
background to begin with. Solet's dive in and talk about,
you know, that that primaryquestion, why use Swift at all
on the server?
Geoff (07:39):
I mean, I think I'm gonna give the easiest possible answer
upfront, and that is it'spersonal preference. I am the
only person who has to work onthis, and therefore, what I say
goes. And therefore, I'mchoosing this particular option
over any of the other optionsthat I have.
Peter (07:56):
So I'm gonna jump in there because, you know, this is
something a lot of folks, youknow, we all know this, Internet
people. Right? Oh, you shoulduse x. Why are you using y?
You've hit on, I think, the keyargument for just about
everything right there.
If you're the one maintaining itand you're the one that's
building it and you're the onewith the knowledge of Swift in
(08:19):
this case, there is no wronganswer for whatever you choose.
And I I just want to jump inthere and point that out because
I'm sure it'll come up. Right?There there there are those
people on the Internet. But Ithink that that is the perfect
answer for so many things as towhy use this at all for
whatever.
So thank you for putting thatout there folks. Right? You
(08:39):
know, you go with what you'recomfortable with. Simple as
that. Don't listen to otherpeople.
Right? What's up everybody? Iwanna tell you about clean my
Mac by Macport. Now I have beenusing this for years. So many
years that I don't even rememberat this point.
But if you're a Mac user and youdon't have this tool, trust me,
(09:00):
you need it. So let me tell youwhat you can do with this. Now,
when I open up the application,not only is the UI absolutely
gorgeous, but I run SmartCareand all I got to do is open the
app, click on SmartCare and hitthe scan button. Now, when I do
that, what's gonna happen it'sgonna analyze my system and it's
(09:22):
gonna go through and it's gonnalook for junk. It's gonna check
to make sure that I don't haveany malware or anything like
that on my Mac.
It's gonna run some performancechecks. It's gonna go through
and check for applicationupdates and then it's also gonna
give me the option to look atwhat I would call the clutter on
my machine, kind of my files,right? The stuff that that I put
(09:44):
there and I'm not kidding you,every time I run this and I run
this at least once a week, itwill find at least a couple of
gigs worth of junk files toclean out. And all I gotta do is
to tell it go ahead and run andit'll clean out the junk files.
The other day when I ran it, itfound 6 gig of files and believe
(10:08):
me when I tell you I ammeticulous about keeping junk
off of my machine and it willjust find this stuff splattered
all over different folders andthen it'll run the performance
checks like I say and it'll justlook and see if there's anything
that it thinks needs to be done.
It'll let me know about any appupdates and I can just have it
(10:29):
update them for me. Now on topof that, there are other tabs.
There's the cleanup tab andit'll go in there and you can
tell it to do various cleanupoperations for you. Again, it's
gonna run an analysis. Asdevelopers, we all know about
Xcode and how much space ittakes up, but you will be amazed
(10:49):
about the amount of files thatcan build up and caches over
time that you just don't thinkabout and you know, they just
don't clean themselves up verywell and again, it'll go through
there and save me gigabytes ofspace.
It's absolutely unbelievable.The performance tab is
fantastic. It'll run things likeflushing the DNS for me and
(11:12):
it'll run the maintenancescripts. It'll check disk
permissions for issues there andall of those things to give you
every ounce of performance outof your machine. And if all of
this sounds good to you and itshould if you're a Mac user,
like I say, I consider this likeone of my first installs.
You can go topetawhidham.comforward/cmm and
(11:33):
that's gonna jump you to theright spot where you can go in
and you can try out Clean MyMac. You'll get a 7 day free
trial. Personally, like I say,every time they bring out a new
version, it's an instant upgradefor me. So again, go to
peterwedham.comforward/ cmm andget started with Clean My Mac
today.
Geoff (11:55):
Yep. Yeah. And so what I'll give is the reasons behind
some of this personalpreference, but again, I am not
out here selling that Swift isthe one best way to do web back
end services because the answeris there is not one best way. It
all comes down to benefits andtrade offs and and all of that.
(12:19):
And you ultimately have to usewhat you or your team or your
company are comfortable with,and what you're doing for that
versus the trade offs that youwould see versus using a
different language.
And so I'm gonna tell you what Ilike about Swift on the server.
But, again, these are there's alot of different projects out
(12:40):
there. There's a lot ofdifferent things that you could
do out there, and it'sultimately gonna come down to
your own calculus as to what youactually use. One of the things
that I really like about Swifton the server versus, some of
the more popular languages outthere for server side back end
stuff is the existence of acompiler. We have a lot of the
(13:02):
web tools out there areinterpreted tools, whether
that's JavaScript or Python, andthere are some languages out
there that are upfront compiled.
So you've got Rust is obviouslythe big hot new thing these
days.
Peter (13:16):
Mhmm.
Geoff (13:16):
And Golang is a little bit, more, it it's not quite as
up and coming as Rust is, butit's definitely around there as
well. Another project that isvery similar to that. And having
a compiler allows for betterperformance overall, because
everything's compiled ahead oftime. It's not being
(13:37):
interpreted, and it allows youto 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 bunchof tests just to make sure that
simple stuff like, oh, thisvariable doesn't actually exist.
You know?
Peter (13:56):
You
Geoff (13:56):
get a lot of that kind of stuff, quote unquote, for free.
Peter (14:00):
And security too.
Geoff (14:02):
Yeah. And so I I like the, benefits of compiled
languages there. And again, likeI said, there's a lot of
compiled languages that you canalso use. So that's just one
thing that I like about Swift,and and obviously with that you
get all of the benefits of theSwift compiler with all of the
type safety, and all of the newconcurrency safety stuff that
(14:24):
you have in Swift 6, that kindof thing, that all of the things
that the Swift compiler helpsyou with for your client side
code, it can also help you withfor your server side code. So
compiler, that's the main thingthat that I love there.
The other thing I I know a lotof people are gonna think about,
and I I have not found thisquite as useful as you might
(14:45):
think ahead of time, but it'sstill worth mentioning, is the
limited potential to share codeacross code bases. And I have
found a little bit of thatpossible in my tools. You can
make Swift packages that arejust regular raw Swift packages
and share them between the twoservices. And I would say that
(15:07):
with that, you get kind of thissliding scale of how well you
can actually share your code.
Peter (15:15):
Mhmm.
Geoff (15:15):
And so models, if you just have, like, a struct that's
got codable conformance, it'spretty easy to share. You just
have a whole library that isjust your models that all
conform to codable. It worksexactly the same on server
versus on your client. Use thatcode directly in both places.
Your business logic, so thiswould be your controller in an
(15:37):
MVC world or your view model inan MVVM world.
Those are dependent on kinda howtightly you couple with the
system, but there is some ofthat there. I have a SVG. Well,
I have an image renderingportion to my server that is run
on both the server and theclient, and I have it going
(16:00):
basically to a intermediatelevel of saying, like, this is
what is represented in thisimage. And from there, I then
split that apart between serverand client. But it does get me a
decent chunk of the way there,and that is something that I can
share across these twolibraries.
And then, obviously, the endresult of an image rendering,
(16:23):
that's your view. That's what'sbeing displayed. That's not
happening. There's not a wholelot of sharing of code view wise
between SwiftUI and Swift on theserver.
Peter (16:33):
Mhmm.
Geoff (16:33):
So, yeah. Like I said, models, super easy. Business
logic, meh. And then views, it'sjust not gonna happen. That's
true of a lot of these kinds ofshared code things.
So if you're sharing codebetween a Rust project, for
example, I feel like a lot ofthe same sort of stuff is gonna
happen. The one contrast wouldbe JavaScript. You have server
(16:54):
side rendering versus clientside rendering. You can actually
share a lot of those codesdepending on the framework that
you're using. If you're usingsomething like React, for
example, I know that you totallycan share Vue code across the 2.
But, a lot of the projects aregonna be more similar to what
Swift does, where, yeah, it'sit's back end type stuff that is
(17:14):
easily shareable between the 2.
Peter (17:16):
Yeah. I mean, you're you know, you're in the Swift
environment. Right? And so,therefore, naturally, you're
gonna be using a lot of thetechniques and skills and, you
know, different architectureways that we are used to using
in Swift is going to apply here.Right?
And so like you say, you know, Ithink it's fair to say there are
(17:37):
some things that don't translateacross to the server side quite
as well as they would with otherlanguages, but that's kind of by
design, I think. Right? For me,when I think about, like, Swift
on the server, my brainautomatically goes to APIs
first, for example.
Geoff (17:55):
And yeah. And so I I think you you hit on something
there, which is, does usingSwift on the server make sense
at all if you're not already inthe Swift ecosystem? And I would
say there's benefits, andthey're the same benefits that
you get from the Swift compileras a whole, but ultimately, I
don't know that I would chooseSwift on the server as my
(18:18):
default given I don't use Swiftanywhere else. It's more just,
hey, I'm familiar with thislanguage. I know the ins and
outs of this language.
I know some of the quirks andoddities, and so I'm much more
comfortable with that than, say,Rust, which I know very little
to nothing about. I'm not gonnapick up that whole language just
(18:39):
to use it on my server. I don'tthink that I would if I were not
somebody who is already familiarwith Swift, I don't know that I
would do the same thing withSwift on the server. I would not
pick up Swift just for servertype stuff.
Peter (18:53):
I do agree with that and I'd throw in there as well if,
you know, because we get askedthis question a lot. If you're
someone who's like, hey, I Idon't know anything about Swift
and I wanna get into Swift, Iwouldn't start with the server
side Swift as a way to kind ofyour gateway into learning
(19:13):
Swift. I I would recommend thatyou go and start building apps
client side first. Learn thosetechniques. And the reason I say
that is, yes, whichever one youdo, you you are learning Swift.
No no question there. But Ithink that you learn some
disciplines and certain ways ofdoing things from client side,
(19:36):
but, I don't know. You maydisagree.
Geoff (19:39):
You do have one nice benefit with Swift on the server
that you don't have with appsper se is that you can start
learning Swift on the serverwithout having a Mac, and that
is something that that is reallya 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 partof what you're trying to learn
(20:03):
there, I would still start withcommand line tools, something
simple. You know, I'm generatinga bunch of text or I'm making an
API request, I'm doing somethingelse with that. I would start
there rather than hoppingstraight into Swift on the
server even if you are wantingto start building Swift and
(20:23):
learning Swift without having aMac. You can get into doing
Swift on Linux for a bunch ofother cool stuff and then build
on the server on top of thatonce you're more familiar with
the language as a whole.
And then, yeah, if youultimately obviously wanna get
into iOS apps or Mac apps,you're gonna need a Mac in order
to do that development on. But,I I think that, yeah, there are
(20:46):
ways to get started with Swifton Linux that are not hopping
straight to running web servers.
Peter (20:52):
Alright. Okay. Fair point. Yeah. Okay.
Yeah. Folks, I'm not saying runout and buy a Mac. Just start
learning Swift that way. The andand, actually, we'll touch on
this more when we get to, youknow, setting this thing up.
But, since you've raised itthere, a key thing to note in in
what Geoff said there is yeah.
(21:13):
Right? You can run this onLinux. Right? In fact, arguably
one of the best ways server sideto do this. You know, again,
there are folks out there whoare always surprised to learn
that Swift is not just an Apple,OS based language.
Yes. You can run it on Windowsand absolutely you can run this
(21:36):
on Linux as well. And I do agreewith you, for example, Swift
scripting. Hey, great way to getinto it from the terminal.
Right?
You you definitely don't have tobe on a Mac for that. Yeah.
Geoff (21:48):
So yeah. Peter, do you wanna talk a little bit about
what the, options are out thereas far as Swift on the server
projects? I know there are kinda2 big projects out there. You
mentioned them already. Do youwanna kinda go into the
differences between them?
Peter (22:03):
Yeah. Sure. So, there are the the 2 big ones that I think,
you know, certainly the mostwell known are Vapor and
Hummingbird. Again, I think I'mI'm trying to recall. I don't
think I've done an episode onVapor but we have certainly
covered Hummingbird with some ofthe Swift Server group before.
(22:24):
Vapor is the one that has beenaround I'm gonna say the longest
of these 2 and I'll explain whyin a second. So therefore, you
know, both of these have goodcommunities. Arguably, Vapor has
a bigger community, which isalways important with these
things just because it's beenaround longer and and certainly
(22:44):
it's the most well knownalthough I think that's changing
now. It is definitely a veryopinionated very structured, way
of doing things. We I would say,with Vapour, the approach is you
are gonna do it the way theywant you to.
That's it. Right? And I'm notsaying that's a bad thing, but
(23:07):
you are definitely gonna have tofollow the rules.
Geoff (23:11):
Right? It definitely gives you more structure to
build on. I I think that is thethe nice way of putting that,
which is Yeah. Yeah. It is verystrongly opinionated, as you
say, but strong opinions meanconstraints, and constraints
make it easy to build in somesense.
So, yeah. Both the benefit andthe the downside to being much
more opinionated.
Peter (23:32):
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 ofdocumentation out there. There
are examples, I would say, ofjust about any, style of app
that you think you might want tobuild.
I'm I'm willing to bet there's acode example out there. Right?
(23:56):
To best of my knowledge as well,you know, Vapor is 1 depending
on how how you want to do this,you can just run it natively.
You can just install we'll getinto the installing process but
you can install it on yourmachine or your server. And
other options, of course, youcan, you know, there are pre
built Docker images, if Iremember rightly, that you can
(24:18):
just spin up and, hey, away yougo.
Right? So you've got those asoptions as well, plus different,
you know, custom ways and butyou're gonna find a lot out
there on that. Now talking aboutHummingbird, Hummingbird is on
version 2 now. It isHummingbird, from what I can
remember talking with Janis is,you know, Hummingbird is very
(24:41):
much inspired by Vapor. And infact, I know from what he was
saying, the 2 groups workclosely together.
Right? It's not like they're incompetition here. They they they
they borrow and learn from eachother. So, you know, whichever
one you go with, you aredefinitely getting into an
ecosystem. And just like so manythings, I will mention this
(25:04):
quickly, on the Swift side,there's there's no competition
here.
There's just a willingness onboth sides to see both projects
succeed because they benefitfrom each other. Right? But
Hummingbird has, in my opinion,really nice documentation, great
explanations and walkthroughsfor getting started. Now I will
(25:29):
say that, you know, you shoulddefinitely have at least a basic
understanding and of Swift. Andwhat I mean by that is you don't
have to have anything fancy.
Right? But you're gonna see alot of code on both of these
thrown at you very quickly. Takeyour time, but Hummingbird has
great series of tutorials. Thereare examples. They do, you know,
(25:53):
the classic to do example,which, hey, at least you're
doing an app that we're allfamiliar with.
Right? It's like the one up fromthe the hello world. Hummingbird
version 2 supports, and andactually draws from quite
heavily. Right? Swift,concurrency.
So Swift 6, for example, right,where, you know, concurrency is
(26:14):
the word of the day, right? And,yes, I know it's been around for
a while in that but theydefinitely draw heavily from
there. So you're getting all ofthe the nice features from the
more recent versions of Swift aswell, but that's kind of the
primarily, the breakdown of bothof them. Now either one is
(26:35):
exceptionally good in in myopinion. Like I said, we're
gonna talk we've we've discussedHummingbird in this one because
that's what we're focusing on,but you are gonna have a great
experience with either of these.
But, Geoff is there anything youwanna throw in there?
Geoff (26:49):
No. Like you said, this they're both great at their job
of being a Swift web server. Itreally is it it really does come
down to whether you like themore structure heavy paradigm of
something like Vapor, or whetheryou prefer the more bring your
own architecture style of designthat Hummingbird has. And really
(27:10):
both have their fan bases, andso they both work great. Another
thing that is great about thesetwo tools kinda bill being built
on a similar foundation isthere's a lot of libraries out
there, and they a lot of themreally do work with both.
They can both talk to thesedatabases through the same ORM,
Fluent, and they just have avery similar way of
(27:33):
communicating with those. Theyboth have their own HTML
templating library. Vapor hasits own kinda more swifty type
one. Hummingbird has one that'sbased on a more open standard
called mustache. They both havetheir own authentication
libraries.
There's a wide set of librariesavailable that you can use with
either one of these frameworksthat are just built for Swift in
(27:57):
general. I know there's some,like, a MongoDB library that you
could just straight up use witheither one, and it doesn't have
a preference to either or theother.
Peter (28:07):
So Yeah.
Geoff (28:08):
Both of these communities work very well together, and I
think that that's a, great forboth of them. I I I'm happy to
see that there are 2 vibrantecosystems out there building
tools for Swift on the server.
Peter (28:21):
Alright. Here it is. The one thing that I cannot do
without every day, and that ismy coffee. Anyone that knows me
or anyone that's listened to anyof my podcasts or anything else
knows that I absolutely cannotoperate without my coffee, and I
love good coffee. So here's thedeal.
I'm gonna give you one free bagof coffee by going to
(28:42):
peterwidham.comforward/coffee.There is a wonderful company out
there that follows the fairtrade practices, helps out a lot
of independent roasters of allsizes, and the operation is
simple. What you do is you'regonna go to to
peterwhidham.comforward/coffee.You sign up there. You get a
(29:02):
free bag of coffee sent to you,yes, in return.
They say thank you to me bygiving me some coffee, but
that's not the reason I'm doingthis. The reason I'm doing this
is because I have found so manygood coffees that I just would
never have come across, heardabout or experienced without
(29:23):
this service. Trade coffee isjust 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 thecoffee. But there is nothing
better than discovering newindependent roasters and
supporting them, discovering newflavors of coffee, new grinds
(29:43):
for You can set it up. It's verysmart. You tell it the kind of
coffee you like and over time itgets better and better as it
trains in on your selections andyour choices and gives you
exactly the coffee you'relooking for and recommending new
ones that that will be verysimilar. Every time I get a new
packet of coffee, I go throughand afterwards I try the coffee,
(30:05):
I go through the service and Isay, look, I loved this coffee.
I thought this coffee was okayor I say, look, I've This was
really not for me. And everytime I do that, it makes the
service a little more accurateon the next selection for me. So
again, just go topeterwhidham.comforward/coffee.
Get your free bag of coffeetoday. If you're a coffee lover,
(30:25):
you're gonna really appreciatethis service.
I have been using it for yearsat this point and thoroughly
recommend it. So for example,Hummingbird, if you go to the
the website, and of course we'llput links in the show notes, but
hummingbird dot codes, there'san ecosystem tab and they list
on there a lot of officialextensions that they have in
(30:47):
there. Just to, you know, giveyou a couple of examples. Right?
Some of these should befamiliar, but should also make
you feel comfortable.
So, WebSockets. Right, Redis,you know, those are in there.
Like you mentioned, there's afluent ORM, covers many
databases. I would say arguably,in my opinion, all of the common
(31:08):
ones that you're likely to wantto use or certainly encounter in
production, and there's someothers that we'll talk about
later but there's plenty ofsupport in there and of course
packages as well. Yes, thatexists on Vapor.
I'm mentioning it in particularon Hummingbird because I think
they do a good job athighlighting lots of key areas
(31:30):
for anybody with a web developerbackground. You're gonna feel
comfortable pretty quickly.Okay. So let's talk about how
you install and get these setup. We're gonna we're gonna jump
in here.
Again, we're gonna sort of do acomparison between the 2. We're
not favoring either one. We justwant to give you an experience
of, what it's like to set bothof these up. So, Geoff, go for
(31:53):
it.
Geoff (31:53):
Yeah. And I I think both of these, their install process
goes very much towards theirkind of philosophies as a whole.
And so, yeah, we'll we'll see itas as, I describe them. So Vapor
has this command line tool. It'sliterally just called Vapor, and
you install that tool on macOS.
People are gonna be wellfamiliar with this. It's just
brew install Vapor. On Linux, ifyou're building from Linux, you
(32:17):
actually have to build it fromsource, but it seems like it's
fairly simple. You just gitcheckout and run make install.
And, if you are running on Linuxand you don't want to have to
deal with the make installstuff, you can also have a
Docker image, and that Dockerimage, you would just pull it
down.
You can start building insidethe Docker dev container, and it
(32:39):
just already has Vaporinstalled. So that's another
option whether you're I'm it isrunning in Linux, whether you're
running Docker, the host onmacOS or on Linux, that is
another option there to have itall self contained. And from
there, you have your toolinstalled, and you can kinda
just run Vapor new, and thatwalks you through this, like,
command line wizard tool, and itsays, do you what do you wanna
(33:01):
name this? What, are youbuilding? Do you need a database
connection?
Do you need HTML templating? Doyou need all of these things?
And it will generate a projectfor you, install all the proper
libraries, and give you aproject folder that you can go
ahead and work with. And it'sgot all of the structure already
built in, and it tells you,like, oh, here's where you're
(33:22):
gonna add your controllers,here's where you're gonna do
whatever, and has a wholeproject ready for you. With
Hummingbird, on the other hand,you have just a simple library,
and you are on your own tocreate your own Swift package
project exactly the way that youwould create any other Swift
project, and then you just addthe Hummingbird libraries that
(33:44):
you need to that existingproject.
Alternatively, they do have agit project template that you
can just pull down that projecttemplate and start from there.
But, really, Hummingbird issimple enough that all you do is
you create your Swift packageproject however you want to any
other way, and then you just addthe library that you need. And
(34:05):
you're off and running with ahummingbird project.
Peter (34:08):
Yeah. I I mean, definitely like this, you know,
the Swift package manager,hopefully, by now, we're we're
all feeling reasonablycomfortable with it to a certain
degree. And and that, obviously,with newer versions of Xcode,
makes it a lot easier to manageas well. I think when I did it,
I think I pulled down thetemplate, if I remember rightly.
Geoff (34:30):
Yeah. And and I think Vapor may, for one thing,
predate Xcode's better handlingof Swift package manager. But,
additionally, Vapor also has alot more individual libraries
for handling a lot of smallerparticular stuff. And so having
that tool there is a lot morehelpful for making sure that you
have all of the libraries thatyou need. And so that's that's
(34:52):
why Vapor has this tool, whereasHummingbird is more just do
whatever you want, fork it, grabit, do your project, project
build.
Peter (35:01):
Yeah. It really is a case of which whichever way you wanna
go. Right? Whichever one you'remore comfortable with. Again, as
you, the developer, you make thedecisions for you or, you know,
discuss them with your team ifyou're a team.
For sure. Yeah. I would thinkthough by the time you get to
this install stage, you'veprobably made a pretty good
(35:22):
evaluation of which one youwanna go with. However, if you
have the time, hey, try themboth. Right?
Geoff (35:28):
Yeah. Absolutely.
Peter (35:29):
I
Geoff (35:29):
know. Yeah. I mean, it's it's down to, again, knowing
what their philosophies are andknowing which you want between
the 2. And then when you'reready to deploy the 2, both of
them are really pretty similar.Hit build and run, and you've
got a built executable.
And you could literally just runthat executable directly on a
(35:50):
server if you want to. You'regonna need to install various
Swift support things, butthere's answers to how to do
that out there on the web, howto install Swift. But the
version that I find is much moreuseful is both of them include
official Docker files that youcan use to build a Docker image
(36:10):
and then host that anywhere theDocker is supported, which is
basically everywhere these days.So that's what I do with my own
deploys is I just literally runa Docker build. The flags that
are necessary for building for,Intel based systems, AMD 64
based systems, rather than theARM systems that, everybody's
(36:33):
developing on from the Mac.
But other than that, you know,you build an AMD 64 image. You
put that up on your server. Yourun it the way that you would
run any normal Docker image,and, it just works.
Peter (36:45):
And I I think that's important right there because
for me, you know, my my brainswitches modes and I start to
become very concerned aboutsecurity at that point. Right?
And so, yeah, I like the Dockeridea too in for me. And now
okay. I get it folks.
You know, we always sayunderstand what your code is
(37:08):
doing. Right? But, for me, Ifeel more comfortable running a
Docker image where hopefully,people a lot smarter than me
have covered the bases as faras, security and, you know, good
safety checks and all of thosekind of things. Because for me,
I wanna get on with the businessof making the app or apps and
(37:32):
not become a server admin.Right?
And and I'm not suggesting thatyou need to be a server admin to
run either of these. I'm justsaying why bring the heartache
on yourself and all the pain andtrouble. The other advantage
with using something like aDocker image is, hey. It's super
easy to run that locally beforeyou ship it to production and
(37:53):
and have an experience thatshould be predictable at that
point. Right?
Geoff (37:57):
And then one other thing worth calling out that I think
is is a solid question kind ofin the Deploy area is one thing
that Hummingbird does have overvapor that may actually, push it
for you one way or the other isHummingbird does support running
on AWS Lambda as a serverlesssystem, and it does not appear
(38:20):
as of this recording that thereis really any even semi official
support for doing that withvapor. Hummingbird has kind of,
like, a a much quicker startupand and running than Hummingbird
or sorry. Hummingbird has kindof a much quicker startup and
get running than Vapor does. Andso I think it is a little bit
(38:41):
more suited to being run-in aserverless system. And so, yeah,
they do have an officialextension for running
Hummingbird on Lambda, whichdoes not exist on Vapor.
So that is another option forhaving your service deployed.
Peter (38:58):
Yeah. And I think that I mean, that pretty much covers
it, really. The areas I justwanna sort of note for the
listeners here. The areas we'venot covered, sort of the middle
ground, right, of well, how do Ibuild my app and that, we
purposefully decided not to divetoo deeply there because at the
(39:18):
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 dothis thing you already know how
to do. Again, if you don't knowhow to do it, you know, hey,
it's it can be a greatintroduction to Swift. But in
(39:38):
between, all the middleware foryour app is basically, put your
Swift hat on, and away you go.Right?
Geoff (39:45):
Absolutely. Yeah. And a lot of what you're doing is
you're taking in and returningcodable properties. And so if
you're running something that'slike a API, you're gonna take in
a codable model. That's yourrequest.
You're gonna spit out aresponse. It's probably also a
codable model. Each of these hasways of handling things like
(40:07):
headers, you you wanna return adifferent header or you wanna
respond differently based on theheader, returning different
status codes, that kind ofthing. Both of them are very
straightforward in how youhandle that. So no real huge
difference between the twothere.
Peter (40:21):
Okay. So I think we've covered the topic here. Don't
know hey. You know, maybethere's gonna be future episodes
here where we dive into someparticular things, particular
aspects or code discussion. Butthis is how you get up and
running with with Swift on theserver for sure.
Certainly something I think isworth your time looking at.
(40:42):
Other than that folks, we'vecovered this here. Geoff closing
thoughts, where can we find you?
Geoff (40:48):
You can find me as always at cocoatype.com and cocoatype
on all the socials.
Peter (40:53):
Alright. And you can find me at peterwitham.com
or compileswift.com and and allthe socials. That's it folks.
Speak to you next episode.
What's up everybody? Welcome to the Compile Swift
Podcast. We have another specialepisode here for you. We're
gonna focus on some server siderules today, but first of all,
Geoff, how are you doing?
Geoff (00:14):
Yeah. I got a new release of my app out, actually earlier
than I expected it to. Iaccidentally clicked the
checkbox or left the checkbox onthat was go ahead and roll out
the app as soon as it'savailable. And it went out, and
I didn't expect it to go out. Soeverybody's gonna get the, like,
social media push a couple dayslate.
(00:34):
But, you know, hey, it's notlike anybody reads release notes
anyway. Right?
Peter (00:40):
Right. Right. And and did you have one of those moments
where you're like, oh, wait.Dang. Did I did I publish
everything on the back end?
Is you know, did I take it all?
Geoff (00:49):
Thankfully, there was no back end needed required. But,
yeah, I was actually Sweet. Atlunch with a friend of mine, and
he's like, oh, hey. I saw thenew update was out. And I was
like, oh, you you I think you'reon my test flight.
You asked me in the test flightbuild. And he's like, no. That's
that's not what I mean. And Oh.Yeah.
Sure enough, we looked in theApp Store and yeah. No. It was
in the App Store. So whoops.But, hey.
(01:10):
You know what? It's not the endof the world. You know, I I
didn't didn't get to do my lastminute testing that I wanted to
do. Didn't get to, have myrelease notes up and ready to
go. Didn't have, you know,social media stuff pushed, but
it it you know, people will getthat on the day that it's
supposed to be released, whichis tomorrow as I record.
(01:31):
And, just, you know, I canalways follow-up any bugs that I
didn't catch later. So I wasjust gonna say not the ideal way
to go, but it it could've beenworse.
Peter (01:41):
Well, it's funny because, you know, you can't complain
about these things. Because ifyou used to complain, right,
quite rightly, Apple folks wouldbe like, look, you folks, you
complain when the app review istoo long, so we speed things up
for you. And now you'recomplaining that we do it
efficiently. Which one do youwant? Right?
Geoff (01:59):
No. I I the app review, like, that was exactly why I
submitted it early. It's like Iwant the app review out. I want
it to be ready to go, and then Itake my time after app review to
get everything ready to go. Andthe entire problem was just that
Apple has this checkbox there tosay, once it's ready, let me
click it, or once it's ready, goahead and put it out on your
(02:21):
own.
And I just apparently had it setto go ahead and roll it out
automatically, and that was notwhat I wanted. But, hey. That's
I just need to be able to doublecheck that better next time.
Peter (02:35):
Totally get it because I never as far as I can recall,
which is quite a while now, Ihave never done an automatic
release. I I'm just too afraidof it being at an awkward
moment. You know? I think whathappened was the last release
before that may
Geoff (02:52):
have been, like, a big bug fix release, and I wanted
that one out as soon aspossible. And then I just did
not set the, the checkbox backis what happened, I believe.
Yeah. Because, the release priorto this 24 dot 5 was, the fix
(03:14):
for Apple Watch Sync and forApple Wallet export not working
with a particular set ofbarcodes. And so I was like, oh,
crap.
You know? Apple Wallet was likethis big thing, and then I'm
gonna ship it, and theneverybody's gonna be like, well,
it doesn't work with thisbarcode. Like so I wanted to get
a fix out as fast as I possiblycould. And so I submitted it to
(03:34):
Apple, did the expedited review,and had the checkbox on that go
ahead and ship it immediately assoon as it's done because, you
know, if I'm submitted this andthen I go to bed and Yeah. It's
the middle of the night, I don'twant people to have to wait an
extra 8 hours or whatever.
So, yeah, that one rolled outwhenever it was available. And,
unfortunately, it remembers whatyour preferences was, and that
(03:56):
was not what I wanted this time.
Peter (03:58):
See, it's funny because as you're saying that, I I was
just asking myself, you know, amI am I happy that it remembers
or not? And, honestly, I don'tknow. Yeah. Yeah.
Geoff (04:10):
I I guess it's one
Peter (04:11):
of those times where it's like, no. I think I'd rather be
defaulted to the safest option.But then, I bet there's plenty
of people out there that arelike, just just ship the darn
thing. Alright. Okay.
Let's get into this. So, we arecovering a topic. We've covered
this before on the podcast manytimes, and I wanna give sorry?
(04:34):
You've covered it. I'm trying tobe inclusive.
Geoff (04:38):
Yeah.
Peter (04:39):
Yeah. I'm I'm thinking about your feelings, you know.
Geoff (04:42):
Perfect.
Peter (04:43):
First time ever. Right? It's like, really? Now is the
moment you choose to do that?Yeah.
Really? Yeah. So we've had, youknow, Janis on the show before.
We'll put a link in the shownotes to this from the
Hummingbird, project. And, yes,we are talking about switch on
the server.
We are gonna primarily focus onHummingbird, in this episode.
(05:08):
However, I'm sure many of youout there will be screaming,
what about this? What aboutvapor? What about that? Yes.
And and a lot of those have beencovered before and, of course,
there are many options, But, wehave our reasons for focusing on
this one. Primarily, Geoff hasbeen using this. So let's let's
dive into this here. But like Isay, we'll put a link in the
show notes, to where everythinglike we usually do. But there is
(05:30):
this episode with Janis whereI'm talking about the Swift
server group as well.
A lot of push behind thatproject, but let's dive in here.
You know, let's start at thebeginning, Geoff. So you are
actually using this inproduction. Right? And I think
that's really important to folksbecause we all do this as
developers.
We play with things. Right? Butyou're going up that whole other
(05:51):
level when you're like, okay.It's in production now. So, you
wanna talk about that?
Geoff (05:56):
Yeah. So I'm actually running a couple different
services in production rightnow. I have a mix of both Vapor
Services and Hummingbird, andwe'll get into the difference
between those two projects in abit. But, yeah, my, by far, most
used one is in Hummingbird. Thatis that is the most recent one
that I've done, and it is usedby my, most recent app, Bark.
(06:22):
And so it is seeing a lot moreuse than any of the vapor
services are themselves. But,yeah, I've been I've been
running both of these inproduction for a while now, and
I think I have some, opinions onhow they've worked and how
they've been, done and kind ofthe benefits and drawbacks to
(06:44):
each of them. So
Peter (06:46):
Well, I think, you know, the first natural question and
this always comes up and and tobe fair, this is one that that I
ask myself quite often too,which is why use Swift on the
server at all? Now this is adifficult one to answer, I
think, because it it falls inthat bucket like why use
anything at all on a server.Right? Replace it with language
(07:08):
x and I don't mean that socialmedia website. You know, there's
yeah.
You got a million optionsavailable to you on the web.
Personally, I have not shippedanything with Swift, not because
there's anything against it,but, you know, I'm I'm just so
used to all those other weblanguages having a web
(07:29):
background to begin with. Solet's dive in and talk about,
you know, that that primaryquestion, why use Swift at all
on the server?
Geoff (07:39):
I mean, I think I'm gonna give the easiest possible answer
upfront, and that is it'spersonal preference. I am the
only person who has to work onthis, and therefore, what I say
goes. And therefore, I'mchoosing this particular option
over any of the other optionsthat I have.
Peter (07:56):
So I'm gonna jump in there because, you know, this is
something a lot of folks, youknow, we all know this, Internet
people. Right? Oh, you shoulduse x. Why are you using y?
You've hit on, I think, the keyargument for just about
everything right there.
If you're the one maintaining itand you're the one that's
building it and you're the onewith the knowledge of Swift in
(08:19):
this case, there is no wronganswer for whatever you choose.
And I I just want to jump inthere and point that out because
I'm sure it'll come up. Right?There there there are those
people on the Internet. But Ithink that that is the perfect
answer for so many things as towhy use this at all for
whatever.
So thank you for putting thatout there folks. Right? You
(08:39):
know, you go with what you'recomfortable with. Simple as
that. Don't listen to otherpeople.
Right? What's up everybody? Iwanna tell you about clean my
Mac by Macport. Now I have beenusing this for years. So many
years that I don't even rememberat this point.
But if you're a Mac user and youdon't have this tool, trust me,
(09:00):
you need it. So let me tell youwhat you can do with this. Now,
when I open up the application,not only is the UI absolutely
gorgeous, but I run SmartCareand all I got to do is open the
app, click on SmartCare and hitthe scan button. Now, when I do
that, what's gonna happen it'sgonna analyze my system and it's
(09:22):
gonna go through and it's gonnalook for junk. It's gonna check
to make sure that I don't haveany malware or anything like
that on my Mac.
It's gonna run some performancechecks. It's gonna go through
and check for applicationupdates and then it's also gonna
give me the option to look atwhat I would call the clutter on
my machine, kind of my files,right? The stuff that that I put
(09:44):
there and I'm not kidding you,every time I run this and I run
this at least once a week, itwill find at least a couple of
gigs worth of junk files toclean out. And all I gotta do is
to tell it go ahead and run andit'll clean out the junk files.
The other day when I ran it, itfound 6 gig of files and believe
(10:08):
me when I tell you I ammeticulous about keeping junk
off of my machine and it willjust find this stuff splattered
all over different folders andthen it'll run the performance
checks like I say and it'll justlook and see if there's anything
that it thinks needs to be done.
It'll let me know about any appupdates and I can just have it
(10:29):
update them for me. Now on topof that, there are other tabs.
There's the cleanup tab andit'll go in there and you can
tell it to do various cleanupoperations for you. Again, it's
gonna run an analysis. Asdevelopers, we all know about
Xcode and how much space ittakes up, but you will be amazed
(10:49):
about the amount of files thatcan build up and caches over
time that you just don't thinkabout and you know, they just
don't clean themselves up verywell and again, it'll go through
there and save me gigabytes ofspace.
It's absolutely unbelievable.The performance tab is
fantastic. It'll run things likeflushing the DNS for me and
(11:12):
it'll run the maintenancescripts. It'll check disk
permissions for issues there andall of those things to give you
every ounce of performance outof your machine. And if all of
this sounds good to you and itshould if you're a Mac user,
like I say, I consider this likeone of my first installs.
You can go topetawhidham.comforward/cmm and
(11:33):
that's gonna jump you to theright spot where you can go in
and you can try out Clean MyMac. You'll get a 7 day free
trial. Personally, like I say,every time they bring out a new
version, it's an instant upgradefor me. So again, go to
peterwedham.comforward/ cmm andget started with Clean My Mac
today.
Geoff (11:55):
Yep. Yeah. And so what I'll give is the reasons behind
some of this personalpreference, but again, I am not
out here selling that Swift isthe one best way to do web back
end services because the answeris there is not one best way. It
all comes down to benefits andtrade offs and and all of that.
(12:19):
And you ultimately have to usewhat you or your team or your
company are comfortable with,and what you're doing for that
versus the trade offs that youwould see versus using a
different language.
And so I'm gonna tell you what Ilike about Swift on the server.
But, again, these are there's alot of different projects out
(12:40):
there. There's a lot ofdifferent things that you could
do out there, and it'sultimately gonna come down to
your own calculus as to what youactually use. One of the things
that I really like about Swifton the server versus, some of
the more popular languages outthere for server side back end
stuff is the existence of acompiler. We have a lot of the
(13:02):
web tools out there areinterpreted tools, whether
that's JavaScript or Python, andthere are some languages out
there that are upfront compiled.
So you've got Rust is obviouslythe big hot new thing these
days.
Peter (13:16):
Mhmm.
Geoff (13:16):
And Golang is a little bit, more, it it's not quite as
up and coming as Rust is, butit's definitely around there as
well. Another project that isvery similar to that. And having
a compiler allows for betterperformance overall, because
everything's compiled ahead oftime. It's not being
(13:37):
interpreted, and it allows youto 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 bunchof tests just to make sure that
simple stuff like, oh, thisvariable doesn't actually exist.
You know?
Peter (13:56):
You
Geoff (13:56):
get a lot of that kind of stuff, quote unquote, for free.
Peter (14:00):
And security too.
Geoff (14:02):
Yeah. And so I I like the, benefits of compiled
languages there. And again, likeI said, there's a lot of
compiled languages that you canalso use. So that's just one
thing that I like about Swift,and and obviously with that you
get all of the benefits of theSwift compiler with all of the
type safety, and all of the newconcurrency safety stuff that
(14:24):
you have in Swift 6, that kindof thing, that all of the things
that the Swift compiler helpsyou with for your client side
code, it can also help you withfor your server side code. So
compiler, that's the main thingthat that I love there.
The other thing I I know a lotof people are gonna think about,
and I I have not found thisquite as useful as you might
(14:45):
think ahead of time, but it'sstill worth mentioning, is the
limited potential to share codeacross code bases. And I have
found a little bit of thatpossible in my tools. You can
make Swift packages that arejust regular raw Swift packages
and share them between the twoservices. And I would say that
(15:07):
with that, you get kind of thissliding scale of how well you
can actually share your code.
Peter (15:15):
Mhmm.
Geoff (15:15):
And so models, if you just have, like, a struct that's
got codable conformance, it'spretty easy to share. You just
have a whole library that isjust your models that all
conform to codable. It worksexactly the same on server
versus on your client. Use thatcode directly in both places.
Your business logic, so thiswould be your controller in an
(15:37):
MVC world or your view model inan MVVM world.
Those are dependent on kinda howtightly you couple with the
system, but there is some ofthat there. I have a SVG. Well,
I have an image renderingportion to my server that is run
on both the server and theclient, and I have it going
(16:00):
basically to a intermediatelevel of saying, like, this is
what is represented in thisimage. And from there, I then
split that apart between serverand client. But it does get me a
decent chunk of the way there,and that is something that I can
share across these twolibraries.
And then, obviously, the endresult of an image rendering,
(16:23):
that's your view. That's what'sbeing displayed. That's not
happening. There's not a wholelot of sharing of code view wise
between SwiftUI and Swift on theserver.
Peter (16:33):
Mhmm.
Geoff (16:33):
So, yeah. Like I said, models, super easy. Business
logic, meh. And then views, it'sjust not gonna happen. That's
true of a lot of these kinds ofshared code things.
So if you're sharing codebetween a Rust project, for
example, I feel like a lot ofthe same sort of stuff is gonna
happen. The one contrast wouldbe JavaScript. You have server
(16:54):
side rendering versus clientside rendering. You can actually
share a lot of those codesdepending on the framework that
you're using. If you're usingsomething like React, for
example, I know that you totallycan share Vue code across the 2.
But, a lot of the projects aregonna be more similar to what
Swift does, where, yeah, it'sit's back end type stuff that is
(17:14):
easily shareable between the 2.
Peter (17:16):
Yeah. I mean, you're you know, you're in the Swift
environment. Right? And so,therefore, naturally, you're
gonna be using a lot of thetechniques and skills and, you
know, different architectureways that we are used to using
in Swift is going to apply here.Right?
And so like you say, you know, Ithink it's fair to say there are
(17:37):
some things that don't translateacross to the server side quite
as well as they would with otherlanguages, but that's kind of by
design, I think. Right? For me,when I think about, like, Swift
on the server, my brainautomatically goes to APIs
first, for example.
Geoff (17:55):
And yeah. And so I I think you you hit on something
there, which is, does usingSwift on the server make sense
at all if you're not already inthe Swift ecosystem? And I would
say there's benefits, andthey're the same benefits that
you get from the Swift compileras a whole, but ultimately, I
don't know that I would chooseSwift on the server as my
(18:18):
default given I don't use Swiftanywhere else. It's more just,
hey, I'm familiar with thislanguage. I know the ins and
outs of this language.
I know some of the quirks andoddities, and so I'm much more
comfortable with that than, say,Rust, which I know very little
to nothing about. I'm not gonnapick up that whole language just
(18:39):
to use it on my server. I don'tthink that I would if I were not
somebody who is already familiarwith Swift, I don't know that I
would do the same thing withSwift on the server. I would not
pick up Swift just for servertype stuff.
Peter (18:53):
I do agree with that and I'd throw in there as well if,
you know, because we get askedthis question a lot. If you're
someone who's like, hey, I Idon't know anything about Swift
and I wanna get into Swift, Iwouldn't start with the server
side Swift as a way to kind ofyour gateway into learning
(19:13):
Swift. I I would recommend thatyou go and start building apps
client side first. Learn thosetechniques. And the reason I say
that is, yes, whichever one youdo, you you are learning Swift.
No no question there. But Ithink that you learn some
disciplines and certain ways ofdoing things from client side,
(19:36):
but, I don't know. You maydisagree.
Geoff (19:39):
You do have one nice benefit with Swift on the server
that you don't have with appsper se is that you can start
learning Swift on the serverwithout having a Mac, and that
is something that that is reallya 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 partof what you're trying to learn
(20:03):
there, I would still start withcommand line tools, something
simple. You know, I'm generatinga bunch of text or I'm making an
API request, I'm doing somethingelse with that. I would start
there rather than hoppingstraight into Swift on the
server even if you are wantingto start building Swift and
(20:23):
learning Swift without having aMac. You can get into doing
Swift on Linux for a bunch ofother cool stuff and then build
on the server on top of thatonce you're more familiar with
the language as a whole.
And then, yeah, if youultimately obviously wanna get
into iOS apps or Mac apps,you're gonna need a Mac in order
to do that development on. But,I I think that, yeah, there are
(20:46):
ways to get started with Swifton Linux that are not hopping
straight to running web servers.
Peter (20:52):
Alright. Okay. Fair point. Yeah. Okay.
Yeah. Folks, I'm not saying runout and buy a Mac. Just start
learning Swift that way. The andand, actually, we'll touch on
this more when we get to, youknow, setting this thing up.
But, since you've raised itthere, a key thing to note in in
what Geoff said there is yeah.
(21:13):
Right? You can run this onLinux. Right? In fact, arguably
one of the best ways server sideto do this. You know, again,
there are folks out there whoare always surprised to learn
that Swift is not just an Apple,OS based language.
Yes. You can run it on Windowsand absolutely you can run this
(21:36):
on Linux as well. And I do agreewith you, for example, Swift
scripting. Hey, great way to getinto it from the terminal.
Right?
You you definitely don't have tobe on a Mac for that. Yeah.
Geoff (21:48):
So yeah. Peter, do you wanna talk a little bit about
what the, options are out thereas far as Swift on the server
projects? I know there are kinda2 big projects out there. You
mentioned them already. Do youwanna kinda go into the
differences between them?
Peter (22:03):
Yeah. Sure. So, there are the the 2 big ones that I think,
you know, certainly the mostwell known are Vapor and
Hummingbird. Again, I think I'mI'm trying to recall. I don't
think I've done an episode onVapor but we have certainly
covered Hummingbird with some ofthe Swift Server group before.
(22:24):
Vapor is the one that has beenaround I'm gonna say the longest
of these 2 and I'll explain whyin a second. So therefore, you
know, both of these have goodcommunities. Arguably, Vapor has
a bigger community, which isalways important with these
things just because it's beenaround longer and and certainly
(22:44):
it's the most well knownalthough I think that's changing
now. It is definitely a veryopinionated very structured, way
of doing things. We I would say,with Vapour, the approach is you
are gonna do it the way theywant you to.
That's it. Right? And I'm notsaying that's a bad thing, but
(23:07):
you are definitely gonna have tofollow the rules.
Geoff (23:11):
Right? It definitely gives you more structure to
build on. I I think that is thethe nice way of putting that,
which is Yeah. Yeah. It is verystrongly opinionated, as you
say, but strong opinions meanconstraints, and constraints
make it easy to build in somesense.
So, yeah. Both the benefit andthe the downside to being much
more opinionated.
Peter (23:32):
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 ofdocumentation out there. There
are examples, I would say, ofjust about any, style of app
that you think you might want tobuild.
I'm I'm willing to bet there's acode example out there. Right?
(23:56):
To best of my knowledge as well,you know, Vapor is 1 depending
on how how you want to do this,you can just run it natively.
You can just install we'll getinto the installing process but
you can install it on yourmachine or your server. And
other options, of course, youcan, you know, there are pre
built Docker images, if Iremember rightly, that you can
(24:18):
just spin up and, hey, away yougo.
Right? So you've got those asoptions as well, plus different,
you know, custom ways and butyou're gonna find a lot out
there on that. Now talking aboutHummingbird, Hummingbird is on
version 2 now. It isHummingbird, from what I can
remember talking with Janis is,you know, Hummingbird is very
(24:41):
much inspired by Vapor. And infact, I know from what he was
saying, the 2 groups workclosely together.
Right? It's not like they're incompetition here. They they they
they borrow and learn from eachother. So, you know, whichever
one you go with, you aredefinitely getting into an
ecosystem. And just like so manythings, I will mention this
(25:04):
quickly, on the Swift side,there's there's no competition
here.
There's just a willingness onboth sides to see both projects
succeed because they benefitfrom each other. Right? But
Hummingbird has, in my opinion,really nice documentation, great
explanations and walkthroughsfor getting started. Now I will
(25:29):
say that, you know, you shoulddefinitely have at least a basic
understanding and of Swift. Andwhat I mean by that is you don't
have to have anything fancy.
Right? But you're gonna see alot of code on both of these
thrown at you very quickly. Takeyour time, but Hummingbird has
great series of tutorials. Thereare examples. They do, you know,
(25:53):
the classic to do example,which, hey, at least you're
doing an app that we're allfamiliar with.
Right? It's like the one up fromthe the hello world. Hummingbird
version 2 supports, and andactually draws from quite
heavily. Right? Swift,concurrency.
So Swift 6, for example, right,where, you know, concurrency is
(26:14):
the word of the day, right? And,yes, I know it's been around for
a while in that but theydefinitely draw heavily from
there. So you're getting all ofthe the nice features from the
more recent versions of Swift aswell, but that's kind of the
primarily, the breakdown of bothof them. Now either one is
(26:35):
exceptionally good in in myopinion. Like I said, we're
gonna talk we've we've discussedHummingbird in this one because
that's what we're focusing on,but you are gonna have a great
experience with either of these.
But, Geoff is there anything youwanna throw in there?
Geoff (26:49):
No. Like you said, this they're both great at their job
of being a Swift web server. Itreally is it it really does come
down to whether you like themore structure heavy paradigm of
something like Vapor, or whetheryou prefer the more bring your
own architecture style of designthat Hummingbird has. And really
(27:10):
both have their fan bases, andso they both work great. Another
thing that is great about thesetwo tools kinda bill being built
on a similar foundation isthere's a lot of libraries out
there, and they a lot of themreally do work with both.
They can both talk to thesedatabases through the same ORM,
Fluent, and they just have avery similar way of
(27:33):
communicating with those. Theyboth have their own HTML
templating library. Vapor hasits own kinda more swifty type
one. Hummingbird has one that'sbased on a more open standard
called mustache. They both havetheir own authentication
libraries.
There's a wide set of librariesavailable that you can use with
either one of these frameworksthat are just built for Swift in
(27:57):
general. I know there's some,like, a MongoDB library that you
could just straight up use witheither one, and it doesn't have
a preference to either or theother.
Peter (28:07):
So Yeah.
Geoff (28:08):
Both of these communities work very well together, and I
think that that's a, great forboth of them. I I I'm happy to
see that there are 2 vibrantecosystems out there building
tools for Swift on the server.
Peter (28:21):
Alright. Here it is. The one thing that I cannot do
without every day, and that ismy coffee. Anyone that knows me
or anyone that's listened to anyof my podcasts or anything else
knows that I absolutely cannotoperate without my coffee, and I
love good coffee. So here's thedeal.
I'm gonna give you one free bagof coffee by going to
(28:42):
peterwidham.comforward/coffee.There is a wonderful company out
there that follows the fairtrade practices, helps out a lot
of independent roasters of allsizes, and the operation is
simple. What you do is you'regonna go to to
peterwhidham.comforward/coffee.You sign up there. You get a
(29:02):
free bag of coffee sent to you,yes, in return.
They say thank you to me bygiving me some coffee, but
that's not the reason I'm doingthis. The reason I'm doing this
is because I have found so manygood coffees that I just would
never have come across, heardabout or experienced without
(29:23):
this service. Trade coffee isjust 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 thecoffee. But there is nothing
better than discovering newindependent roasters and
supporting them, discovering newflavors of coffee, new grinds
(29:43):
for You can set it up. It's verysmart. You tell it the kind of
coffee you like and over time itgets better and better as it
trains in on your selections andyour choices and gives you
exactly the coffee you'relooking for and recommending new
ones that that will be verysimilar. Every time I get a new
packet of coffee, I go throughand afterwards I try the coffee,
(30:05):
I go through the service and Isay, look, I loved this coffee.
I thought this coffee was okayor I say, look, I've This was
really not for me. And everytime I do that, it makes the
service a little more accurateon the next selection for me. So
again, just go topeterwhidham.comforward/coffee.
Get your free bag of coffeetoday. If you're a coffee lover,
(30:25):
you're gonna really appreciatethis service.
I have been using it for yearsat this point and thoroughly
recommend it. So for example,Hummingbird, if you go to the
the website, and of course we'llput links in the show notes, but
hummingbird dot codes, there'san ecosystem tab and they list
on there a lot of officialextensions that they have in
(30:47):
there. Just to, you know, giveyou a couple of examples. Right?
Some of these should befamiliar, but should also make
you feel comfortable.
So, WebSockets. Right, Redis,you know, those are in there.
Like you mentioned, there's afluent ORM, covers many
databases. I would say arguably,in my opinion, all of the common
(31:08):
ones that you're likely to wantto use or certainly encounter in
production, and there's someothers that we'll talk about
later but there's plenty ofsupport in there and of course
packages as well. Yes, thatexists on Vapor.
I'm mentioning it in particularon Hummingbird because I think
they do a good job athighlighting lots of key areas
(31:30):
for anybody with a web developerbackground. You're gonna feel
comfortable pretty quickly.Okay. So let's talk about how
you install and get these setup. We're gonna we're gonna jump
in here.
Again, we're gonna sort of do acomparison between the 2. We're
not favoring either one. We justwant to give you an experience
of, what it's like to set bothof these up. So, Geoff, go for
(31:53):
it.
Geoff (31:53):
Yeah. And I I think both of these, their install process
goes very much towards theirkind of philosophies as a whole.
And so, yeah, we'll we'll see itas as, I describe them. So Vapor
has this command line tool. It'sliterally just called Vapor, and
you install that tool on macOS.
People are gonna be wellfamiliar with this. It's just
brew install Vapor. On Linux, ifyou're building from Linux, you
(32:17):
actually have to build it fromsource, but it seems like it's
fairly simple. You just gitcheckout and run make install.
And, if you are running on Linuxand you don't want to have to
deal with the make installstuff, you can also have a
Docker image, and that Dockerimage, you would just pull it
down.
You can start building insidethe Docker dev container, and it
(32:39):
just already has Vaporinstalled. So that's another
option whether you're I'm it isrunning in Linux, whether you're
running Docker, the host onmacOS or on Linux, that is
another option there to have itall self contained. And from
there, you have your toolinstalled, and you can kinda
just run Vapor new, and thatwalks you through this, like,
command line wizard tool, and itsays, do you what do you wanna
(33:01):
name this? What, are youbuilding? Do you need a database
connection?
Do you need HTML templating? Doyou need all of these things?
And it will generate a projectfor you, install all the proper
libraries, and give you aproject folder that you can go
ahead and work with. And it'sgot all of the structure already
built in, and it tells you,like, oh, here's where you're
(33:22):
gonna add your controllers,here's where you're gonna do
whatever, and has a wholeproject ready for you. With
Hummingbird, on the other hand,you have just a simple library,
and you are on your own tocreate your own Swift package
project exactly the way that youwould create any other Swift
project, and then you just addthe Hummingbird libraries that
(33:44):
you need to that existingproject.
Alternatively, they do have agit project template that you
can just pull down that projecttemplate and start from there.
But, really, Hummingbird issimple enough that all you do is
you create your Swift packageproject however you want to any
other way, and then you just addthe library that you need. And
(34:05):
you're off and running with ahummingbird project.
Peter (34:08):
Yeah. I I mean, definitely like this, you know,
the Swift package manager,hopefully, by now, we're we're
all feeling reasonablycomfortable with it to a certain
degree. And and that, obviously,with newer versions of Xcode,
makes it a lot easier to manageas well. I think when I did it,
I think I pulled down thetemplate, if I remember rightly.
Geoff (34:30):
Yeah. And and I think Vapor may, for one thing,
predate Xcode's better handlingof Swift package manager. But,
additionally, Vapor also has alot more individual libraries
for handling a lot of smallerparticular stuff. And so having
that tool there is a lot morehelpful for making sure that you
have all of the libraries thatyou need. And so that's that's
(34:52):
why Vapor has this tool, whereasHummingbird is more just do
whatever you want, fork it, grabit, do your project, project
build.
Peter (35:01):
Yeah. It really is a case of which whichever way you wanna
go. Right? Whichever one you'remore comfortable with. Again, as
you, the developer, you make thedecisions for you or, you know,
discuss them with your team ifyou're a team.
For sure. Yeah. I would thinkthough by the time you get to
this install stage, you'veprobably made a pretty good
(35:22):
evaluation of which one youwanna go with. However, if you
have the time, hey, try themboth. Right?
Geoff (35:28):
Yeah. Absolutely.
Peter (35:29):
I
Geoff (35:29):
know. Yeah. I mean, it's it's down to, again, knowing
what their philosophies are andknowing which you want between
the 2. And then when you'reready to deploy the 2, both of
them are really pretty similar.Hit build and run, and you've
got a built executable.
And you could literally just runthat executable directly on a
(35:50):
server if you want to. You'regonna need to install various
Swift support things, butthere's answers to how to do
that out there on the web, howto install Swift. But the
version that I find is much moreuseful is both of them include
official Docker files that youcan use to build a Docker image
(36:10):
and then host that anywhere theDocker is supported, which is
basically everywhere these days.So that's what I do with my own
deploys is I just literally runa Docker build. The flags that
are necessary for building for,Intel based systems, AMD 64
based systems, rather than theARM systems that, everybody's
(36:33):
developing on from the Mac.
But other than that, you know,you build an AMD 64 image. You
put that up on your server. Yourun it the way that you would
run any normal Docker image,and, it just works.
Peter (36:45):
And I I think that's important right there because
for me, you know, my my brainswitches modes and I start to
become very concerned aboutsecurity at that point. Right?
And so, yeah, I like the Dockeridea too in for me. And now
okay. I get it folks.
You know, we always sayunderstand what your code is
(37:08):
doing. Right? But, for me, Ifeel more comfortable running a
Docker image where hopefully,people a lot smarter than me
have covered the bases as faras, security and, you know, good
safety checks and all of thosekind of things. Because for me,
I wanna get on with the businessof making the app or apps and
(37:32):
not become a server admin.Right?
And and I'm not suggesting thatyou need to be a server admin to
run either of these. I'm justsaying why bring the heartache
on yourself and all the pain andtrouble. The other advantage
with using something like aDocker image is, hey. It's super
easy to run that locally beforeyou ship it to production and
(37:53):
and have an experience thatshould be predictable at that
point. Right?
Geoff (37:57):
And then one other thing worth calling out that I think
is is a solid question kind ofin the Deploy area is one thing
that Hummingbird does have overvapor that may actually, push it
for you one way or the other isHummingbird does support running
on AWS Lambda as a serverlesssystem, and it does not appear
(38:20):
as of this recording that thereis really any even semi official
support for doing that withvapor. Hummingbird has kind of,
like, a a much quicker startupand and running than Hummingbird
or sorry. Hummingbird has kindof a much quicker startup and
get running than Vapor does. Andso I think it is a little bit
(38:41):
more suited to being run-in aserverless system. And so, yeah,
they do have an officialextension for running
Hummingbird on Lambda, whichdoes not exist on Vapor.
So that is another option forhaving your service deployed.
Peter (38:58):
Yeah. And I think that I mean, that pretty much covers
it, really. The areas I justwanna sort of note for the
listeners here. The areas we'venot covered, sort of the middle
ground, right, of well, how do Ibuild my app and that, we
purposefully decided not to divetoo deeply there because at the
(39:18):
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 dothis thing you already know how
to do. Again, if you don't knowhow to do it, you know, hey,
it's it can be a greatintroduction to Swift. But in
(39:38):
between, all the middleware foryour app is basically, put your
Swift hat on, and away you go.Right?
Geoff (39:45):
Absolutely. Yeah. And a lot of what you're doing is
you're taking in and returningcodable properties. And so if
you're running something that'slike a API, you're gonna take in
a codable model. That's yourrequest.
You're gonna spit out aresponse. It's probably also a
codable model. Each of these hasways of handling things like
(40:07):
headers, you you wanna return adifferent header or you wanna
respond differently based on theheader, returning different
status codes, that kind ofthing. Both of them are very
straightforward in how youhandle that. So no real huge
difference between the twothere.
Peter (40:21):
Okay. So I think we've covered the topic here. Don't
know hey. You know, maybethere's gonna be future episodes
here where we dive into someparticular things, particular
aspects or code discussion. Butthis is how you get up and
running with with Swift on theserver for sure.
Certainly something I think isworth your time looking at.
(40:42):
Other than that folks, we'vecovered this here. Geoff closing
thoughts, where can we find you?
Geoff (40:48):
You can find me as always at cocoatype.com and cocoatype
on all the socials.
Peter (40:53):
Alright. And you can find me at peterwitham.com
or compileswift.com and and allthe socials. That's it folks.
Speak to you next episode.
Popular Podcasts
Stuff You Should Know
If you've ever wanted to know about champagne, satanism, the Stonewall Uprising, chaos theory, LSD, El Nino, true crime and Rosa Parks, then look no further. Josh and Chuck have you covered.
My Favorite Murder with Karen Kilgariff and Georgia Hardstark
My Favorite Murder is a true crime comedy podcast hosted by Karen Kilgariff and Georgia Hardstark. Each week, Karen and Georgia share compelling true crimes and hometown stories from friends and listeners. Since MFM launched in January of 2016, Karen and Georgia have shared their lifelong interest in true crime and have covered stories of infamous serial killers like the Night Stalker, mysterious cold cases, captivating cults, incredible survivor stories and important events from history like the Tulsa race massacre of 1921. My Favorite Murder is part of the Exactly Right podcast network that provides a platform for bold, creative voices to bring to life provocative, entertaining and relatable stories for audiences everywhere. The Exactly Right roster of podcasts covers a variety of topics including historic true crime, comedic interviews and news, science, pop culture and more. Podcasts on the network include Buried Bones with Kate Winkler Dawson and Paul Holes, That's Messed Up: An SVU Podcast, This Podcast Will Kill You, Bananas and more.
The Joe Rogan Experience
The official podcast of comedian Joe Rogan.