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.

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.

J.

O.

A.

N.

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.