Leo Dion (host): Hello and welcome to another episode of Empower Apps.
I'm your host, Leo Dion.
Today I'm joined with Joannis Orlandos.
Joannis, thank you so much for coming on.
Joannis Orlandos (guest): Hey, thanks for having me on Yeah,
Leo Dion (host): for those who don't know, I've known Joannis for quite a while.
We've collaborated quite a bit.
So, this is nothing.
I've known Joannis for a while, so I'm super happy to finally have an opportunity
to have him on and to talk about all the server side workgroup stuff today.
Joannis, I think you're Dutch guest number
seven maybe or
Joannis Orlandos (guest): seven.
I'm
Leo Dion (host): Lucky number seven, I think so.
I'll have to look in the show notes again and see.
So, I'm super happy to have another friend of the show from Netherlands on the show.
Before we get going into the server side working group, I'll let you
go ahead and introduce yourself.
Joannis Orlandos (guest): Yeah.
So I'm Joannis Orlandos.
As he said, as you said, based in the Netherlands I actually started
with server side Swift in 2015 when Swift was just released on Linux.
Just I think it was a preview to Swift 2.
2 or 2.
3.
And Before that moment, I didn't even know about Swift.
Like a friend of mine, Robert Bransma, actually introduced me to
to Swift when it was open sourced.
I was a Linux user, didn't even have a Mac or an iPhone never
even considered it to be honest.
So, I actually started server side Swift when that was first possible.
Leo Dion (host): that's awesome.
Joannis Orlandos (guest): over the years you didn't know.
Leo Dion (host): Oh, I didn't know that you were a Linux user.
So what did you what distri were you running, like, Linux on a desktop?
Joannis Orlandos (guest): Yeah.
Yeah.
I had a custom made laptop and I used Arch Linux, you know, when you use Arch
Linux, you have to tell everyone it's a
Leo Dion (host): I actually had a desktop with Arch Linux before I went whole hog
into development in the Apple space.
So that's hilarious.
Yeah.
So were you, what were you using for server side Swift development then?
Joannis Orlandos (guest): actually I tried getting it set up on
Linux and it was barely doable.
So, when I first tried when I first tried Swift on Linux I was a little bit
disappointed, but I understood it was very early, you know, and a friend of
mine actually had a second Mac that he used, he had an iMac and a MacBook Air.
And I borrowed his MacBook Air to start developing Swift.
So, back in the day, there were actually, there was only one framework Prepared
well in advance, which was perfect, but I didn't really like their framework.
They didn't feel swift ish, swifty.
Like their APIs weren't quite up to the standards that I hoped for
when I was getting used to Apple's APIs, foundation and the like.
So, actually came across the, I actually had this crazy idea.
Let's just build our web framework ourselves from scratch.
And yeah, that proved a little bit more difficult than we anticipated
back then, because there were, there was no, nothing, right.
There is
Leo Dion (host): Right, right.
There's probably not even a Swift Nio at that point.
Joannis Orlandos (guest): Swift Nio didn't exist for years to come.
So, yeah.
So all we knew that it was that there was perfect, which we didn't like using.
And then there was this whole new space with new things to explore.
So we started building our web server and and a database driver, which
was Mongo Kitten, it still exists.
It's still being maintained to this day.
And we got in touch with these people called Zeebo and they were
building a web server and all the things from scratch as well, and
they had a really different approach.
They really wanted to have this Swift ecosystem that felt like Swift.
So, We started working with them and Vapor came along, Tenor,
around, I think, March 2016.
And things went on from there.
I've never left the ecosystem since.
Leo Dion (host): That's awesome.
I don't know if I've mentioned this to you or to other folks on the show,
but my introduction to server side Swift was TrySwift 2018 when the IBM
guys did a workshop on Katura, and yeah, and I was like, oh, this is cool.
I mean, there's a lot of stuff here to set up, and it's A little bit overly
complicated, but this is interesting and then I like was like, let's try
this vapor thing and I was like, whoa This is like so much easier
to get going and it's so amazing.
And yeah, i've been sucked into it since but yeah, that's
Joannis Orlandos (guest): was it for Vapor?
Was it Vapor 3 or like 3 major
Leo Dion (host): think it was three.
It was
Joannis Orlandos (guest): a beta?
Leo Dion (host): It was
Joannis Orlandos (guest): Was it a beta?
Leo Dion (host): I don't know if it was a beta.
I don't think they had, I don't think they had property wrappers
Joannis Orlandos (guest): No, no.
There were no property wrappers back then, but
Leo Dion (host): Right.
But yeah, that's amazing.
Joannis Orlandos (guest): what what month specifically, because I have a
bit of a story about Vapor 3 if you,
Leo Dion (host): That would have been September of 18.
Joannis Orlandos (guest): Cool.
So in June of 2017, there was Vapor 2 and Vapor 2 was no Swift Nio.
There were no, there was no concept of asynchronous.
Behavior.
And I was doing some performance benchmarks for one of my clients back
in the day, and they said that our database driver Mongo Kitton was not
as fast as they hoped it would be.
So I started researching event loops.
Basically other ecosystems, specifically Node.
js and this ecosystem in Kotlin called Vertex and we started building, I started
building this thing called an event loop, which nowadays it's a common term, but
I started building this idea of an event loop where we try to optimize these.
IO in a single place.
And we delegate those events from like reads and writes from a single place.
And then on the higher level APIs we still had the blocking.
I still had a blocking API where you could send a query and it would come back.
But it used promises to make sure that the event loop kept
functioning on its own thread.
And when I showed it off to Tanner back in Vapor 2, he said, Whoa, this is great.
The performance you can achieve with this is Miles ahead of what
we could do back in the day.
So he actually invited me to help build Favor Tree.
And that's where the E Promises came from.
Leo Dion (host): Yeah.
Vapor III was amazing.
I love the event loop stuff, event loop futures and all that stuff.
I think it was ahead of its time and obviously with Async
Away, it was like, you know.
Now it's a breath of fresh air because it's all behind the scenes more or less.
So yeah,
Joannis Orlandos (guest): it's under the hood.
The,
Leo Dion (host): right, right.
Yeah.
Okay.
Let's get into the main topic of today.
So you, how long have you been with the server side working group?
Joannis Orlandos (guest): actually not too long.
So the Swift Server Work Group was actually created as a result of Zewo.
So there Zewo had a primary I'D call a project lead called Paulo Faria.
Leo Dion (host): Okay.
Joannis Orlandos (guest): And Paolo had the back in the day
revolutionary idea that we needed a foundation for Swift on the server.
But when we looked at Swift foundation, the foundation that you import when
you import foundation, there was, it wasn't really usable on Linux.
It kept crashing, half of the features were missing, if not more.
Set this idea to start an organization called Swift standards S4 and every
major library offer like Mongo Kitten had it, but Vapor and Zewo and others were
also invited like Perfect and Kitora.
And everyone could chip in their dependencies that they wanted to
share and wanted to common ground on, and we started developing.
The package is there and then the WWDC of 2016 Paolo visited the WWDC and he said
Leo Dion (host): Back when people actually visited WWDC.
Heh
Joannis Orlandos (guest): before COVID and all, but and yeah, he
visited WWDC and he talked to Chris Ladner and said to Chris Ladner.
You know, this community is growing and Swift on the server is, has
a real active ecosystem that people are getting interested in.
So he wanted this if informal collaboration between library
offers to become more formal.
And that's actually the foundation of the Swift server work group
as it was back in the day.
I actually didn't join until March this year.
I've always had this love hate relationship with the Swift
Server Workgroup back in the day.
I didn't understand some of its purposes.
But I think that's really due to a lack of communication on behalf of the
Swift Server Workgroup here and there.
And it's a, now that I'm a, now that I'm a member, I understand the...
The reasons behind some of the communication a little bit more, but
we're actually actively working on improving that through Empirius means,
so the SwiftServer workgroup has only been in I guess I'm only a member of the
SwiftServer workgroup for a couple of months now, though I've been involved
on multiple occasions to be sure.
Leo Dion (host): So, like, one of the things they talk about is finding
out the community and what it needs.
What, like, how does it do that and what's kind of an example of
something they've done recently that's kind of addressed that?
Joannis Orlandos (guest): The best example that I can give you is actually
something that we're doing shortly.
So we're currently setting up a couple, a questionnaire that we will
send out to the public and people can leave their opinions in there.
This is very much still work in progress.
We're fletching it out as we speak, but the Swift server work group is, that's
one of the avenues that we are currently.
Working on to get active feedback.
As it stands, the Swift server work group has well, members from
a couple of parties, such as the Vapor framework and Hummingbird.
Amazon has some, has members, two of them, and Apple does, and myself, and basically
from all these different perspectives, we are bringing in feedback from our
customers, from the people around us, our colleagues people that we support on
forums and in this court slack as well.
We, there's a swift open source slack that.
People are actively engaging in and that you can ask questions and
essentially as an aggregate of every interaction that we have throughout
our work we bring in the things that we deem most important or most urgent.
And that's basically, yeah, that's basically how we go about things.
Leo Dion (host): Let's take, for instance, something recent, the HTTP
types that we recently released.
How did that incubation process work as far as going from the
idea to like defining as a best practice that everybody can use.
Joannis Orlandos (guest): So the HTTP types actually originate
from two different perspectives.
So there is a demand for a shared HTTP type between iOS and.
The backend a lot of people that develop Swift on the server also
have an iOS app that they want to support using a URL session.
And this is a demand that, that various clients of mine have to deal with, that
various clients of other project offers have to deal with, but also that Apple
itself is running into on a daily basis.
Because Apple is actively using Swift on the server, as they have
presented on the server side Swift conference, which they also sponsored.
They actually got there with a team of 20.
So, as part of the daily working process, we, they, the, the Swift core team and
the Swift server workgroup members.
Yeah, we run into these issues through our colleagues and.
And by the HTTP types actually aren't something that the Swift
server work group developed.
But we were aware of it because there was a demand from us
that we pitched through Apple.
Leo Dion (host): Let's just deep dive into that a little bit more.
What's your favorite part about the HTTP types?
Joannis Orlandos (guest): So I personally have a strong desire to.
Unify all of my business logic and domain specific code in a
swift module, preferably without too much, too many dependencies.
Right?
So, the ultimate dream is that I could write a small core of business
logic for frontends and swift.
And through Swift WebAssembly, I could share it with web, I could
use it on iOS, I could use it on Android through GNI bindings.
That's the ideal situation that I envision that you define your
business logic in Swift once and you use them on the various platforms.
If you have a platform neutral package, such as a GTP types you could then,
Represent these in various, create these through various means, right?
So Swift Nio could this information into an HTTP type, which you use
on Swift on the server, and then any business logic that creates or
processes HTTP requests could be done through just a single code base.
So there is no need for abstraction layers.
Leo Dion (host): Yeah, exactly.
It's boilerplate code that I've written so many times that has
Joannis Orlandos (guest): think you're, you're many.
Yeah.
Leo Dion (host): So yeah, I totally get it.
There's a couple of, so there was a couple of questions I wanted to ask.
How much you know about it?
So feel free to just say, Oh, I really am not.
Aware of that, but you mentioned WebAssembly, how is that coming along
as far as like Swift to WebAssembly for web, you know, essentially
web pages, web applications, where does that stand right now?
Joannis Orlandos (guest): So Swift WebAssembly has gotten pretty mature,
although they have taken a bit of a an unexpected hit when it comes to
the development of the entire thing.
So one of the project leads actually started working for Apple.
So by, by doing so, they, I mean, the project lead gets to work on a lot
of the a lot of similar problems that Swift WebAssembly used to run into,
Leo Dion (host): Mm hmm.
Joannis Orlandos (guest): support in, in, in Xcode and a Swift package manager.
You can see his pull request in public and he's doing similar work.
Now you could conclude that Apple is working on Swift WebAssembly,
or you could think that Apple just has similar interests.
I, I don't know, but, and even if I would know, I probably couldn't share,
Leo Dion (host): Yeah
Joannis Orlandos (guest): I mean, that's the truth, but yeah,
Leo Dion (host): you played around with it at all?
Joannis Orlandos (guest): I have, yes.
One of the main problems with Swift WebAssembly is not the WebAssembly itself.
So Swift WebAssembly actually works really well and it's up
to date, even with Swift 5.
9.
So even as the new features like parameter packs and macros are
coming out, they support it.
The main issue with Swift WebAssembly as it stands is
just the ecosystem of libraries.
So I think where Swift.
On the server was in 2017, 2016 ish.
That's where I guess Swift WebAssembly is ahead of there in the sense that
they have a larger language support base, but it lacks that in libraries.
Leo Dion (host): Sorry, I want to go down.
I want to keep going to this rabbit hole my biggest problem with WebAssembly has
been just like trying to get the tooling to even like Make that first step.
It was a lot of like custom tooling to get it going.
Whereas with like vapor, it was, it's just running Swift to compile it.
Like you could run it in Xcode.
There wasn't, you just bring in the Swift package and you're good to go.
Whereas with WebAssembly, there's like a lot of tooling
prep that I had to get going.
Is that still the case?
Joannis Orlandos (guest): That is still the case.
Leo Dion (host): Yeah.
Okay.
Joannis Orlandos (guest): are limitations that maxes you out of
the previous offer of Swift web assembly and currently work at Apple.
That guy is working on that as we speak.
And on similar problems as well.
Like there has more projects under his belt.
Yeah, but in general that's definitely one of the main issues that we are,
that we're currently facing, but I've recently started adopting the
visual studio code plugin a little bit more, we're actually using that.
For everything, except I always in my company right now.
And yeah, as long as you, you set up the right tool chain and have carton running
in the background, it works really well.
Leo Dion (host): Okay.
So one thing I wanted to talk maybe about so.
Here's a question a lot.
I mentioned this before, like you'll see stuff that Apple kind of like
sneakily puts into Swift because they're going to release something big.
So like DSL, Swift UI, macros, Swift data, and observe observation
and things like that what has kind of been things that you've seen?
Added to Swift language features that have kind of been necessary,
maybe not necessary, but like heavily influenced by the server team.
Does that make sense?
Joannis Orlandos (guest): So there are actually more recent examples
that I think are almost purely.
Released for server side Swift.
One of the big things that server side Swift has really, yeah, brought live
into, I think is distributed actors.
Well distributed actors definitely has a place on an iPhone app.
I think it's extremely niche.
One example of distributed, for those who don't know, a
distributed actor is similar to
Leo Dion (host): That's like most people listening probably don't know.
So you're going to have to like really do the ELI5 here, but go ahead.
Joannis Orlandos (guest): so a distributed actor.
Starts as an actor.
An actor is fundamentally in as a swift principle, not
something that lives on a thread.
It lives somewhere in, in your memory space.
And it's isolated.
So when you send you, when you access a variable or a function, it has
to happen from within that actors.
Domain, whether that actor's domain is a main thread or a different thread is
for all intents and purposes irrelevant.
When you are within that actor's space, you can access properties and call
functions synchronously, like without an await keyword, but when you move from
outside of that actor space into that actor space, you have to use, or possibly
within that actor space, you have to use the await keyword because it has to.
Offload that yeah that it has to basically send it to another thread
Leo Dion (host): Yeah.
Kind of like when you're running something on main actor, you
need to basically do a way.
Joannis Orlandos (guest): it's exactly that.
Yeah, so you have to start it You have to queue it on the main thread like you
would dispatch queue Main, but because the result happens on a different thread
your current thread has to move on with different tasks You don't want to block
like with dispatch queue sync because if you do that On on the wrong thread, like
the main thread, you would block your UI.
It would be a disastrous experience.
So this fundamentally means that wherever that actor lives.
It could be any thread you don't manage this distributed actors actually take
this one step for further where they say This not necessarily district lives
on this actor lives on a different thread or any thread But at this
point a distributed actor lives on any machine So that could be your phone.
It could be the iPhone of your Friend, it could be an iPad in the same room
or a server on the other side of the world, or maybe even a MacBook
on the other side of the world.
It could be any computer that you are in contact with.
So instead of adding the await keyword, this now introduces
the try keyword as well.
So you have to try await every call because every call could be a network
call over Bluetooth, over the internet, but it could also be the local device.
And the beauty of this concept is that you can write the same business logic
in the same way you would on your local machine as if it were anywhere and this.
Really simplifies the process of, yeah, it basically introduces the concept
of translocation transparency, like it's a location independent object.
If we take this into consideration in the iPhone app, it would be a game
you're writing a game like Minecraft a multiplayer game with blocks.
And as if you're playing single player, you simply create a level object,
this level object has functions and properties like where the blocks
are, which what entities are mobs are monsters are in the world, hunting you.
And all of this logic happens on that object on that class,
essentially on that actor.
And by.
Accessing this a function or a property on that actor, you would now have to do a
try away because it's a distributed actor.
So because it's a location transparent object, you don't know if it will be
local or remote, but because you write your logic as a location independent
object, the only thing you need to do to create this world in a multiplayer
setting, aside from adding the business logic to support multiple players,
is Sharing this object with another user and you do this by creating a,
providing a transport means, which is a transfer actor transport system.
And the idea is that you can have an off the shelf on app provided by Apple in
which they have a library for or your own.
And by providing this networking code globally as a static object once you can
share this one object with anyone and they will instantly join your multiplayer
session without added code on your behalf.
Leo Dion (host): That's
Joannis Orlandos (guest): So it just, it just transforms the entire concept of,
of multiplayer, but there's ultimately the same concept translates better
to servers because there is a lot of clustering happening in servers.
Think of your database cluster, think of a Redis for instance, for
example, or the key values of a Redis server could also be a Swift service.
Yeah.
Leo Dion (host): Yeah, that's crazy.
Could it be useless like an abstraction from like manually going back to
our discussion about HTTP types?
Could it be like an abstraction of like doing Rust calls as opposed to doing
something local or doing something remote?
You don't know and you don't care because it's all distributed.
Joannis Orlandos (guest): Yes, so it's possible with HTTP,
although HTTP itself doesn't really lend itself for this use case.
I already have a couple example code bases where a distributed
actor replaces an HTTP call.
The main issue with this is that HTTP calls have a pretty clean format.
So you have REST calls where you have a clearly defined namespace, like slash
users is a user object you call login, I don't know, or get their profile.
But in a distributed actor setting it's a bit of manual labor to make these pretty
nice syntactical, you know what I mean?
Like to make it syntactically pleasing, to have a clean route, it's a bit of
a, it's not really supported very well.
Leo Dion (host): Yep.
Yep.
No, I totally get it.
It's as much as we like event loop futures, like a say a sink away really
like abstracted that made a lot cleaner.
So no, I totally get those use cases.
I wanted you talked a little bit about login and I figured
now is a good opportunity to address Mikaela's no, I'm good.
question about sign in with Apple.
Well, let's start off with sign in with Apple, something we're both quite
familiar with having worked on it.
But she had a question on Twitter about just JWT and sign in with
Apple and Vapor and how that works.
I figured I'd give you the opportunity to address it.
Joannis Orlandos (guest): so signing with Apple actually is pretty easy to
implement with Vapor because under, if you import the Vapor JWT package if
you access your request or application, there is now a JWT object and this
JWT object is a list of signers.
So it could be your signer with your own.
Secure, like your own secure key.
But it could also be anyone else's signer that is listed there.
So they have a couple implementations off the bat for popular vendors like
Apple, Google, Firebase Microsoft.
And whenever either of these common providers provides a
token, you can access request.
jwt.
apple and verify the token there using their signer.
So this will actually verify that the.
Token is signed by Apple and instead of providing your JWT object, they will
provide, Vapor provides its own Apple token, and it contains all the information
you need for signing with Apple.
So all you need to do is pass the JWT token that signing
with Apple gives the iOS user.
You send it over to the server, and when the server receives
it, you pass it into the JWT.
Apple.
Signer and you get the, well, everything you need basically, like their user
ID, which is unique to your app.
You can validate it against your bundle ID.
Yeah.
Leo Dion (host): There's some other JWT support in Vapor as well,
besides sign in with Apple, right?
Joannis Orlandos (guest): Yeah.
So they provide a lot of vendors that you can interface with, common vendors, but
they also allow you to add custom vendors or your create your own vendor from,
Leo Dion (host): So like, what are the examples of other
renders they support on Vapor?
Joannis Orlandos (guest): Microsoft Google yeah.
Mainly big parties that the people commonly interface with.
So if you log in with your Microsoft account through, through any of
their services, you could validate that Microsoft has authorized
this token to represent the user.
Leo Dion (host): so basically the big one's Twitter, whatever.
And then the other one she asked about, and I kind of know this has
been a work in progress, is Passkeys.
When is Vapor going to support Passkeys, Giannis?
Joannis Orlandos (guest): So first of all, there's a Swift server package,
the way which is Swift server working group is working on, primarily Tim is.
And it, it's mostly done.
I believe it's in a testing documentation phase, so final steps.
But yeah, like I can't, I can't fill in this agenda, of course, but I think it's
pretty close, like estimation one for two
Leo Dion (host): does Ti
Joannis Orlandos (guest): my estimation.
But.
Leo Dion (host): can people help if they are interested in testing it out?
Yeah,
Joannis Orlandos (guest): Totally.
So one of the main things that people ask when they want the new feature in the
Swift server ecosystem is usually yeah, like one, when can I start using it?
And most of the time, the answer is you can already start using it, but there is
a possibility that the API will break.
And well, that's a, yeah, breaking changes are scary, you know, but if you
depend on an exact version and test that, so you would rely on a specific tag,
you're guaranteed that for the time your application will stay working source code
compatible, but it won't get any updates.
However the more people that adopt these, or at least attempt to adopt these
packages that are in pre release, the faster we get the feedback, the faster
that we get the feedback, the earlier we feel comfortable releasing a package.
So I wouldn't use this in production, but yeah, it definitely helps
Leo Dion (host): in production, but a lot of people would.
So, you know, if you could, maybe you could supply the repo URL
and then we could put that in the show notes, that'd be great.
Yeah, that's funny.
Cause we've done a lot of work where we've used, we've dealt with the
breaking changes Redis, your, you've picked that project up recently.
We're in an exact version with that.
And then with APNS push notification support and vapor, which is really solid.
I love it.
There's been breaking changes there, so yeah, I totally get it.
That's, that's the fun stuff to deal with.
Was there anything else you want to talk about when it came to authentication?
Joannis Orlandos (guest): Hmm.
No, I don't, I don't think so.
No.
Leo Dion (host): Okay, I just, I see all of Ricky's posts on Mastodon
and Twitter and I'm just like, when can I try that out on my server?
So, yeah, that's exciting to hear.
Let's talk about, actually let's talk about, The, the one presentation we got
at dub dub this year that we can talk about, that's the new open API kit.
You want to explain what this new new thing is that they
revealed at dub dub this year.
Joannis Orlandos (guest): Sure.
So, OpenAPI kit is actually not an Apple library.
It's a community library that Apple adopted and an OpenAPI kit fundamentally
is just the specific, the codable set of codable types that libraries can
use to support OpenAPI and supporting OpenAPI actually can go in two ways.
So you have generators and.
Serializers.
But the traditional way that Vapor users used to do open a p i is
by generating their open API I documentation from their source code.
In this case, the Swift source code is leading so you define your codeable types.
Usually in the, in most li use cases, you would use codeable to.
Reflect through the object and it would generate the open API specification from
the each of the properties your model has.
The nice thing about this project Pro the way that these people tackled open
API with open a p i kit is that you, you have an existing code base without open
a p i, you do a couple minor changes.
Maybe a couple hours of work and you can introduce a open API into your project.
You can set up a new route and it generates the YAML or JSON.
And we actually implemented it in one of our projects as well, Leo
as you might definitely remember.
But one of the problems that we also experienced in that problem in that
implementation is that because it uses codable for reflection it's
pretty difficult, if not impossible to document everything thoroughly.
So if you want to have a username property or an email address, and you
want to annotate this username as case insensitive there is no way currently to
add these comments in an easy way because it uses codable and there is no way.
At least not pre Swift 5.
9, to annotate types or variables.
So,
Leo Dion (host): You couldn't like, you couldn't like hijack the DoCC
Joannis Orlandos (guest): no, you couldn't hijack the DoCC.
You can with 5.
9, which is a separate topic, I think, entirely, macros.
But in, in the current state of affairs, before 5.
9, you couldn't do that.
So, You're very limited in the quality of documentation you can provide.
Apple actually tackled it the other way around.
So they say, you document your document, your API and open API using one of the,
you know, the swagger browser, or there is a lot of tools for open API that
allow you to build this documentation.
And instead of.
Documenting your Swift code, you generate Swift code from your open API.
And it sets up the routes, you can set up the routes in any framework,
Vapor, Hummingbird even Amazon smoke supported, I believe now.
And.
All those routes are automatically registered for you to the
framework and that's the inverse.
So they think the Apple things, and I think technically it's the most
correct way to do things where you document it once in OpenAPI and then
you generate your routes from there.
Leo Dion (host): I don't know if you mentioned it, but like, so there's like
a vapor plugin, right, where you throw in the open the YAML more or less, and
it hooks up to your vapor, but there's also you throw in the open API for your
iOS app and it produces the network calls that you can make in the iOS app as well.
So it works on both the server and the client, I believe.
Right.
Joannis Orlandos (guest): Yeah.
So OpenAPI in the broader sense ports all ecosystems.
The way apple's setup works is that because the ecosystem for Open API is
so enormous you simply need just the documentation that you have already
created to import it into Postman, and all of the sudden you have the entire
Postman collection with all your APIs available, and with the same click of
a button, you can generate your Android client or your web client for U G s.
Leo Dion (host): yes,
Joannis Orlandos (guest): There's, it's only one step really that you need to do.
Once you have the documentation,
Leo Dion (host): And with HTTP types and this, they pretty much killed
two of my side projects I've been working on for the last year or
Joannis Orlandos (guest): I'm sorry to hear that
Leo Dion (host): It's like, I've been developer Sherlocked, so.
Oh well.
Yeah.
I mean, I think it's, there's a big future in for it and you do think
that it's better to go start with documentation as opposed to with
code and going the other way around.
Joannis Orlandos (guest): in an ideal use case.
Yes, but I mean, I do think that the original open API kit for vapor
has its place because existing Swift implementations might not
have started from an open API and still need documentation.
Leo Dion (host): So there is one, so there's a way you can
take existing Vapor apps and then generate the open API YAML now as
Joannis Orlandos (guest): Yeah.
So actually two ways to do this.
One of them is currently existing which is a vapor open API kit.
Although it's a little bit of a game, a little, it changes your code base a
little bit in a way that that I don't like because it actually wraps all the objects
at vapor presents that give paper gives you a specifically or the request type.
So you have to write a lot of boilerplate.
Yeah it adds a lot of boilerplate to your project, unfortunately, but there's
no, there was no way around that.
And the second way to do that is to use macros.
Although I didn't publish it yet.
I currently have a working setup where you add a an annotation, a
macro to your types, your DTOs, your request input and your responses.
Leo Dion (host): Okay.
Joannis Orlandos (guest): And these bodies are documented using the commons.
Because as part of the macros, you can actually read the comments
of your types and variables.
So this, I feel is a slightly cleaner approach, a
Leo Dion (host): Yeah,
Joannis Orlandos (guest): bit less boilerplatey, but yeah.
Leo Dion (host): yeah, well, let's get a little bit more into macros.
How do you think macros will affect the future development of server side Swift?
Joannis Orlandos (guest): Well, in the broader sense of
the word, I, we're all sorry.
In the broader sense of.
The concept of, of macros, it will change everything like when it comes
to Swift, there are so many examples of boilerplate that can be simplified
now, and there are already a couple examples of macros that we have had for
years and specifically Codable, because Codable It's a magical protocol, so to
Leo Dion (host): it is.
It is.
Joannis Orlandos (guest): a step, yeah,
Leo Dion (host): Yeah, it's all done before you even compile.
Like, I've always been interested in looking at what's going on behind the
scenes, and it's like, Yeah, no, that's, the compiler's doing all that for you.
Joannis Orlandos (guest): Yeah, it's a, it's essentially what Codable is,
is it takes away boilerplate for you.
So it generates three things.
Well, first of all, Codable generally has two components.
It has the encodable and the decodable protocols.
Codable itself is not a protocol.
Leo Dion (host): Yeah, it's
Joannis Orlandos (guest): But encodable generates the coding keys and a
coding key is generated as an enum.
So it's generally, it's a private enum that's generated for each of
the properties in your in your type.
And it works for.
A lot of use cases.
So it even works for enums where if you have a raw representable enum, like a
string, it will take the string value of the type and the same for integers.
But for structs, it will take a case for each of the values and encode
them as each key in JSON and decoder will does the same thing, but inverse
and generates an initializer for you.
And that's all that's all Codable really is.
It's a lot of, it's a protocol with a code, with an encode
and decode requirement.
And if the type of function doesn't exist, Swift generates one for you.
And this is all nice until you want to spell one of the keys differently
from how you write them in JSON.
At which point
Leo Dion (host): Then you have to manually
Joannis Orlandos (guest): code decoder or the, yeah, exactly.
So, but sometimes you don't want to.
Do all of that manually just because one variable changed, right?
Because one property is slightly differently from
what you expected in Swift.
So, one of the one of the Apple developers, I believe it was Joe.
Joe Gro he published a set of example macros and one of them
was a codeable macro, which implements a codeable for you.
But it had these, I guess, empty macros as annotations on top of them where you could
customize just one coding key or custom, a customized one small part of the process.
And I think just.
In that sense, it will replace a lot of magic that we had before with,
I guess, a new kind of magic, but at least it's a magic that everyone
can understand if they learn macros,
Leo Dion (host): Yeah.
I mean, it's like apples give us the keys to the car and now
we can like do what we want
Joannis Orlandos (guest): and now we can
Leo Dion (host): like we can build our own stuff, which is amazing.
So you have you start, I guess you've started building your own custom macros.
Is that correct?
Joannis Orlandos (guest): Yeah, so one of the first macros that
I created was actually for enums.
Because when you have an enum most people might not notice, but Apple
generates some pretty ugly JSON for you.
When you have like an enum case, it generates this underscore zero.
And in there, it does like the type name and it's pretty horrible.
So what I created is a small macro that takes the enum case name.
So if you have an enum user type with three types, a user.
An admin or a moderator and each of these types has their
own set of associated values.
It will generate a type called you with the value user admin or moderator
And then it puts the rest of the model with the model underneath
Leo Dion (host): Yeah, nice.
I like
Joannis Orlandos (guest): And and it's just a lot cleaner than what apple
provided out of the box But we also have like documentation macros, like
I said for open api And currently we are working on new macros as well to
remove boilerplate, such as mocking.
When you write a, we have a lot of mocking in some of our code bases.
So, for example, you have a struct for some business logic, but you
want to mock that business logic.
So now you have to write a protocol with all the same properties and functions.
And then you have to write a mock class with all the same
properties and functions.
We generate those now, both
Leo Dion (host): That's awesome.
What else do you want to talk about before we close out?
We have a few minutes left.
Joannis Orlandos (guest): Yeah I guess the most important bit is
yeah, the packages that we're working with the Swift Server Workgroup.
I want to highlight those a little bit more
Leo Dion (host): Yeah,
Joannis Orlandos (guest): you mentioned the HTTP types, but there's
a couple other big innovations that are happening right now.
For example In, in, in specifically Hummingbird, there is currently a 2.
0 going on.
So Hummingbird has added 1.
0 release early this year, and there were a couple of major changes in the
ecosystem, particularly a couple of new libraries that the Swift server
workgroup has started working on.
HTTP types is one of them, but we are also working on a standardized
HTTP server that all frameworks can share and generalize macro system.
And there were a lot of existing libraries that were at least for
Swift, like distributed chasing and logging was improved and metrics.
So all of these libraries that are currently being released are pretty
hard to adopt an existing frameworks like Hummingbird 1 and Vapor 4.
So everyone is looking to up their Major not in a majorly breaking way, but in
the, in a technically breaking way.
So we try to keep everyone key tries to keep the APIs as compatible as possible.
I'll still able, I'll still wanting to release new features that the
ecosystem can finally make use of.
Leo Dion (host): Awesome.
Joannis Orlandos (guest): The best thing I can recommend everyone to
do is to hop on the vapor discord or the hummingbird discord and
leave your use cases and opinions.
I think one of the main Troubles that Vapor and Hummingbird both are having
is that there are a lot of users out there, including customers of
mine that are using Vapor actively.
Some of them even have 15 developers using just on Vapor and they're not on Discord.
I'm not leaving their opinion, not interacting with the community, not
sharing that they are using Vapor.
And I think it's just a real big boost of the ecosystem
to have some more engagement.
Even sharing just what you're running into some small issues
or questions would really.
Helps in ways that you might not expect
Leo Dion (host): We'll put links to those discords and to the, is it the
server side Swift or open source Swift?
Joannis Orlandos (guest): swift opens for slack.
Yes.
Leo Dion (host): Okay.
We'll put links to those in the show notes as well.
Anything else you want to mention?
Any cool projects you're working on any other ways people can
help the server side work group?
Joannis Orlandos (guest): Yeah.
So actually there's two projects that I'm starting to work on.
Now.
The one is but as you said, the Redis driver recently Nathan stepped
down from the Redis driver and wanted to focus on different things.
In his place, I stepped up together with Fabian from Apple.
And we're building some new features such as cluster support, username support.
Also really cool new features when it comes to performance
optimizations and Redis pops up.
On the other hand, there is a new project that I'm actually planning to formally
announce next week, which is Mongo Nio.
Nice.
Nio is a new foundation live, basically Postgres Nio, a foundation library for
people that want to work with MongoDB.
It will remove all of the high level APIs that Mongo Kitten offers and
just focuses on the core so that other people can vendor their own
MongoDB based implementations on top.
Leo Dion (host): Cool.
That will be announced probably around the time I release this.
So, perfect.
Giannis, thank you so much for coming on.
I really appreciate it.
It was good to finally have you on the show.
Where can people find you online?
Joannis Orlandos (guest): I'm mainly active on Twitter at Joannis Orlandos.
You can also find me on GitHub with my first name.
Yeah.
Nice.
J.
O.
A.
N.
I.
S.
Leo Dion (host): People can find me on Twitter at LeoGDion.
Mastodon at LeoGDion.
Dot at C dot I M.
If you're watching us on YouTube, please like and subscribe.
And if you're listening to this podcast, please give me a review.
If there's something you want to talk about or something you want to
hear about, let me know, send me a tweet or two or email or whatever.
Thank you so much, everybody for joining me.
And I look forward to talking to you again.
Bye.
Joannis Orlandos (guest): Bye.