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.
