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.