1 00:00:03,283 --> 00:00:05,803 Leo Dion (host): Welcome to another episode of Empower Apps. 2 00:00:05,863 --> 00:00:07,273 I'm your host, Leo Dion. 3 00:00:07,603 --> 00:00:10,963 Today I'll be talking with Vojtěch and Werner from Cultured 4 00:00:10,963 --> 00:00:12,673 Code, the makers of things. 5 00:00:12,823 --> 00:00:15,883 Gentlemen, thank you so much for joining me for today's episode. 6 00:00:16,602 --> 00:00:17,322 Werner Jainek (guest): Thanks for having us. 7 00:00:18,283 --> 00:00:18,433 Leo Dion (host): Yeah. 8 00:00:19,618 --> 00:00:23,218 Before we begin, I'll let you gentlemen introduce yourself. 9 00:00:24,372 --> 00:00:25,512 Werner Jainek (guest): Okay, so I'm Werner. 10 00:00:25,512 --> 00:00:29,022 I'm, I'm the one of the co-founders and the CEO of cultured code. 11 00:00:30,022 --> 00:00:33,022 Vojtěch Rylko (guest): I am Vojtěch Rylko, but you can call me 12 00:00:33,022 --> 00:00:37,467 Vojtěch and I'm software engineer responsible for things cloud. 13 00:00:38,467 --> 00:00:39,007 Leo Dion (host): Awesome. 14 00:00:39,157 --> 00:00:44,677 So today we're gonna talk about your story moving over to Server Site Swift. 15 00:00:44,707 --> 00:00:47,047 Before we do that, you introduced yourself. 16 00:00:47,077 --> 00:00:49,567 Maybe you wanna introduce things and cultured code and 17 00:00:49,567 --> 00:00:51,217 the story of your company. 18 00:00:52,025 --> 00:00:52,565 Werner Jainek (guest): Sounds great. 19 00:00:53,115 --> 00:00:56,145 Yeah, so currently we're a team of 11 people and we're 20 00:00:56,145 --> 00:00:57,375 spread all over the world. 21 00:00:57,435 --> 00:01:00,435 A fully remote company wasn't always like that. 22 00:01:00,435 --> 00:01:04,215 We have headquarters here in Stuttgart, in Germany, that's in the southern part. 23 00:01:04,705 --> 00:01:07,365 But my, by now there's only three of us going there. 24 00:01:07,365 --> 00:01:09,075 The rest is all over the place. 25 00:01:09,105 --> 00:01:11,295 So we're fully doing that. 26 00:01:11,915 --> 00:01:12,215 Yeah. 27 00:01:12,215 --> 00:01:14,565 And for the past 18 years now. 28 00:01:15,177 --> 00:01:15,467 Leo Dion (host): Whew. 29 00:01:15,565 --> 00:01:17,815 Werner Jainek (guest): We've been working on exactly one product 30 00:01:17,905 --> 00:01:21,445 and it's called things and it's a delightful to-do app that you can 31 00:01:21,445 --> 00:01:23,035 use on all the Apple platforms. 32 00:01:23,095 --> 00:01:23,965 We're on all of them. 33 00:01:24,715 --> 00:01:28,315 And I guess some of the audience members might have heard of it 34 00:01:28,315 --> 00:01:29,755 or maybe even tried it already. 35 00:01:30,155 --> 00:01:33,065 We've been there from the beginning. 36 00:01:33,515 --> 00:01:37,265 The iOS app was there as one of the first 500 apps in the app store 37 00:01:37,605 --> 00:01:39,375 when the app store launched on iOS. 38 00:01:39,900 --> 00:01:43,660 And and then we've continued that, like when the iPad came out, we were there 39 00:01:43,660 --> 00:01:47,950 on day one, and then same for the Apple Watch, and most recently the vision. 40 00:01:48,640 --> 00:01:50,020 So yeah, that's that's things. 41 00:01:50,120 --> 00:01:54,170 We we won two Apple design awards over, I. This course of 42 00:01:54,170 --> 00:01:56,080 time, which made us very proud. 43 00:01:56,680 --> 00:01:58,390 Yeah, very happy about that. 44 00:01:58,490 --> 00:02:01,520 And yeah, the most recent version of the app is things three. 45 00:02:01,520 --> 00:02:05,180 It's been sometimes since we shipped that it was a complete redesign. 46 00:02:05,300 --> 00:02:07,760 So if you go to our website, that's the one you see. 47 00:02:08,350 --> 00:02:13,030 And ever since we've been keeping it updated with all the latest features, 48 00:02:13,030 --> 00:02:16,360 apple ads to their platforms, new features we're building and so forth, 49 00:02:17,202 --> 00:02:17,382 Leo Dion (host): That's 50 00:02:17,590 --> 00:02:18,010 Werner Jainek (guest): and. 51 00:02:19,525 --> 00:02:23,785 So just related to this discussion I guess I should conclude what we've also done 52 00:02:23,785 --> 00:02:29,225 is we have our own sync service, which we dub things cloud and we've been running 53 00:02:29,225 --> 00:02:31,055 that for the past 13 years as well. 54 00:02:31,555 --> 00:02:35,125 Leo Dion (host): Today we're gonna talk about your migration of things, cloud 55 00:02:35,138 --> 00:02:35,558 Werner Jainek (guest): Mm-hmm. 56 00:02:35,845 --> 00:02:39,425 Leo Dion (host): to server side, Swift what's kind of the backstory 57 00:02:39,425 --> 00:02:42,005 of things, cloud and how that worked. 58 00:02:42,725 --> 00:02:48,475 And well also, why have your own syncing service as opposed to iCloud. 59 00:02:50,253 --> 00:02:50,433 Werner Jainek (guest): Yeah. 60 00:02:50,433 --> 00:02:54,653 So back when we started, we've been at it for some time, as I said there 61 00:02:54,653 --> 00:02:58,843 was no iCloud there was on, on iOS. 62 00:02:58,843 --> 00:03:00,853 There wasn't even core data back then. 63 00:03:00,973 --> 00:03:01,063 Hmm. 64 00:03:01,303 --> 00:03:05,663 So when we built our, when we built our app we built our own 65 00:03:05,663 --> 00:03:07,793 layer on top of SQ lite and, uh. 66 00:03:08,343 --> 00:03:08,643 Yeah. 67 00:03:08,883 --> 00:03:12,873 And there we were, and our customers demanded that the to-do sync, of 68 00:03:12,873 --> 00:03:14,613 course, between the platforms. 69 00:03:15,123 --> 00:03:18,243 So we had to sit down and develop it ourselves. 70 00:03:18,903 --> 00:03:19,683 And so we did. 71 00:03:19,863 --> 00:03:23,073 And the first version of the cloud shipped 2012. 72 00:03:23,660 --> 00:03:23,950 Leo Dion (host): Okay. 73 00:03:24,523 --> 00:03:25,783 Werner Jainek (guest): Been running it ever since. 74 00:03:26,353 --> 00:03:29,993 And we're quite happy how it worked out like later in the game. 75 00:03:30,023 --> 00:03:33,023 Apple, of course, introduced other technologies we could have. 76 00:03:33,578 --> 00:03:34,628 Right to use. 77 00:03:35,088 --> 00:03:38,988 But, but at that time we already had a, a great running system. 78 00:03:39,378 --> 00:03:43,288 We actually invested quite some time making it basing it on a 79 00:03:43,288 --> 00:03:47,398 very clear theoretical foundation that we're quite proud of as well. 80 00:03:47,938 --> 00:03:51,908 And, it had proven itself already, like our customers loved it from 81 00:03:51,908 --> 00:03:55,448 the day we we, we shipped it and it's, you know, they praised it 82 00:03:55,448 --> 00:03:56,768 for its stability and everything. 83 00:03:57,428 --> 00:03:58,688 And so why change that, right? 84 00:03:58,748 --> 00:04:02,558 Like today we're very happy to own this piece of technology. 85 00:04:02,898 --> 00:04:04,248 It feels great. 86 00:04:04,398 --> 00:04:05,088 So here we 87 00:04:05,300 --> 00:04:09,500 Leo Dion (host): Yeah, I mean, you'd be handcuffing yourself, like basically, 88 00:04:09,530 --> 00:04:13,400 or restraining yourself to, if you ever moved over to iCloud at this point. 89 00:04:13,430 --> 00:04:14,660 'cause you have so many. 90 00:04:14,930 --> 00:04:17,750 We'll talk about some of the features you guys have with the syncing tool. 91 00:04:17,750 --> 00:04:21,230 But yeah, it's pretty, it's pretty sophisticated stuff. 92 00:04:21,820 --> 00:04:23,290 Yeah, so let's get into it. 93 00:04:23,410 --> 00:04:28,820 What, what was it built with and then why did you migrate off of that to Swift? 94 00:04:30,720 --> 00:04:31,890 Vojtěch Rylko (guest): Yeah, it was, yeah. 95 00:04:32,170 --> 00:04:37,420 The legacy system was built using Python two and run in Google App Engine. 96 00:04:38,420 --> 00:04:42,990 And how, while it was pretty reliable, there were various issues. 97 00:04:42,990 --> 00:04:49,640 We, we had like the unpredictable performance, pretty long latencies, 98 00:04:49,670 --> 00:04:51,770 like the Python was not that performant. 99 00:04:51,920 --> 00:05:01,160 That led to pretty high monthly bill and then the, it was pretty old, and then some 100 00:05:01,160 --> 00:05:05,790 several deprecation loomed and we had to. 101 00:05:06,290 --> 00:05:09,050 Decide what to do next, like, 102 00:05:09,070 --> 00:05:10,270 Leo Dion (host): say deprecation? 103 00:05:10,270 --> 00:05:10,870 What do you mean 104 00:05:11,030 --> 00:05:11,420 Vojtěch Rylko (guest): yeah. 105 00:05:12,320 --> 00:05:12,500 Yeah. 106 00:05:12,500 --> 00:05:17,290 So, obviously Python two became deprecated a few years ago. 107 00:05:18,130 --> 00:05:20,200 That was the, the biggest thing. 108 00:05:20,780 --> 00:05:25,580 But was there was, it was not only Python two, it were also some frameworks we 109 00:05:25,580 --> 00:05:29,580 were relying on and other technologies. 110 00:05:30,030 --> 00:05:30,120 So. 111 00:05:30,620 --> 00:05:36,410 The simple path forward to just rewrite to Python three was not possible. 112 00:05:36,410 --> 00:05:40,550 We had to like rewrite through, truly rewrite entire, entire cloud. 113 00:05:41,770 --> 00:05:42,550 Leo Dion (host): That makes sense. 114 00:05:43,280 --> 00:05:46,515 What was that decision process like as far as what you were gonna do next? 115 00:05:47,515 --> 00:05:47,635 Vojtěch Rylko (guest): cool. 116 00:05:47,750 --> 00:05:47,990 Yeah. 117 00:05:47,990 --> 00:05:52,150 So, yeah, we, we sit down on top took blank paper. 118 00:05:52,675 --> 00:05:59,035 And started from scratch, like thinking about which language to use and all 119 00:05:59,035 --> 00:06:05,055 the options were on table, like we're thinking J Java, obviously Coline go. 120 00:06:05,115 --> 00:06:10,425 We are also considered, again, the Python three and even c plus plus. 121 00:06:10,975 --> 00:06:18,446 Part 10 we realized that the Swift is also the option, like it was not a. 122 00:06:18,970 --> 00:06:22,870 Some knowledge back at the time, like we are talking about like four years ago 123 00:06:22,870 --> 00:06:29,050 when we were making this decision and you didn't hear about people using Swift on 124 00:06:29,050 --> 00:06:32,950 server, like the, the kind of companies. 125 00:06:33,160 --> 00:06:33,400 Yeah. 126 00:06:33,400 --> 00:06:37,540 Not lot like the, the kind of companies like we are small indie developers. 127 00:06:38,040 --> 00:06:40,380 There were zero success stories back at the time. 128 00:06:41,535 --> 00:06:45,975 We heard about Apple, for example, using that successfully internally, 129 00:06:46,125 --> 00:06:50,295 but it's a company with different kind of resources than we are. 130 00:06:50,845 --> 00:06:58,005 So, so we looked at the, at the Swift and its ability to run on server and we 131 00:06:58,005 --> 00:07:02,385 are nicely surprised that it seems like it is possible and not only possible. 132 00:07:02,385 --> 00:07:07,125 It compiled on Linux for many years already and there was. 133 00:07:07,995 --> 00:07:11,775 Server side work group, which was pretty established. 134 00:07:12,225 --> 00:07:17,755 And we started to get a little bit excited about this this proposition. 135 00:07:18,595 --> 00:07:26,125 And, but of course we also pretty worried because the ecosystem felt 136 00:07:26,155 --> 00:07:29,845 not major at the time, like in comparison with, let's say Java. 137 00:07:30,395 --> 00:07:32,465 It was a still young technology. 138 00:07:33,035 --> 00:07:35,315 So we approach that with. 139 00:07:36,350 --> 00:07:40,250 A caution and but there were clear benefits to that. 140 00:07:40,250 --> 00:07:44,240 Like the Swift, we've been already using that for our client side 141 00:07:44,240 --> 00:07:45,770 development for many years. 142 00:07:45,770 --> 00:07:48,350 We, we are used to, to that. 143 00:07:48,900 --> 00:07:51,060 It's, it's fast language. 144 00:07:51,180 --> 00:07:52,380 It performs well. 145 00:07:53,040 --> 00:07:58,210 It has, automatic reference counting for memory management, which makes 146 00:07:58,210 --> 00:07:59,680 memory managements predictable. 147 00:08:00,230 --> 00:08:04,700 And it is a nice language, nice expressive type system. 148 00:08:05,630 --> 00:08:12,410 Strong type system, which is great for a maintainability of these larger systems. 149 00:08:13,310 --> 00:08:20,875 So all these benefits together, took our attention and we started 150 00:08:20,875 --> 00:08:22,585 to evaluate Swift on server. 151 00:08:22,945 --> 00:08:27,525 We, we started gradually we started to play with some experiments. 152 00:08:27,855 --> 00:08:31,665 We're trying to run it, build some prototypes, proof of concepts. 153 00:08:32,165 --> 00:08:37,115 Always worried that we will hit some roadblock, some I missing library. 154 00:08:37,865 --> 00:08:39,425 But that was interesting. 155 00:08:39,425 --> 00:08:40,265 That didn't happen. 156 00:08:40,385 --> 00:08:43,055 Like all these libraries were available. 157 00:08:43,295 --> 00:08:44,735 Minuscule readies. 158 00:08:45,260 --> 00:08:51,630 AWS encryption, like everything was available and it worked well. 159 00:08:52,530 --> 00:09:00,360 And so we started gradual building stuff and over the course of three years, 160 00:09:01,620 --> 00:09:06,760 we were basically done with rewrite and so that's why we got to Swift. 161 00:09:07,962 --> 00:09:10,352 Werner Jainek (guest): And maybe one, one thing I, I should add just to 162 00:09:10,952 --> 00:09:16,922 paint a fuller picture of the past the technology on, on Google side was. 163 00:09:17,012 --> 00:09:21,482 Google App Engine and that is a very high level turnkey solution. 164 00:09:21,982 --> 00:09:26,182 And it served us very well in the beginning 'cause you can get something 165 00:09:26,182 --> 00:09:28,162 going fast, which is what we needed. 166 00:09:28,702 --> 00:09:33,062 But over the time as we were adding more features to the cloud we 167 00:09:33,062 --> 00:09:35,252 kept hitting roadblocks where the. 168 00:09:35,477 --> 00:09:37,337 Black box nature really was in the way. 169 00:09:37,797 --> 00:09:40,317 There were performance issues that we couldn't explain. 170 00:09:40,377 --> 00:09:46,317 It was just lagging while accessing some data or a transaction sizes. 171 00:09:46,317 --> 00:09:49,677 There were various limits that we weren't fully aware of when we 172 00:09:49,917 --> 00:09:53,007 originally built it, and then we had to build workarounds for that 173 00:09:53,007 --> 00:09:55,167 in the old system and, and so forth. 174 00:09:55,167 --> 00:09:59,997 It's like, it really dragged us down by had to implement one such workaround and. 175 00:10:00,692 --> 00:10:01,592 It was nice. 176 00:10:02,042 --> 00:10:06,692 So we were in high demand internally for more control. 177 00:10:06,782 --> 00:10:09,302 I think that's, it's not just about the language, right? 178 00:10:09,302 --> 00:10:10,802 Like the entire stack. 179 00:10:10,802 --> 00:10:12,302 We wanted to be more in control of. 180 00:10:12,974 --> 00:10:14,384 Leo Dion (host): Yeah, I wanted to ask about that. 181 00:10:14,384 --> 00:10:17,774 Like could you even like run Swift in Google App Engine? 182 00:10:17,864 --> 00:10:19,694 I mean, maybe now, but not at the time. 183 00:10:19,694 --> 00:10:20,594 I would assume. 184 00:10:21,452 --> 00:10:21,932 Werner Jainek (guest): Good question. 185 00:10:21,932 --> 00:10:22,262 I don't know. 186 00:10:22,780 --> 00:10:22,960 Vojtěch Rylko (guest): I don't. 187 00:10:23,249 --> 00:10:23,639 Leo Dion (host): Okay. 188 00:10:24,092 --> 00:10:24,452 Werner Jainek (guest): Probably. 189 00:10:24,629 --> 00:10:26,759 Leo Dion (host): but that, I mean, that sounds like the basic motivation 190 00:10:26,759 --> 00:10:28,139 to get off a Google app engine. 191 00:10:28,144 --> 00:10:31,499 What, what s so you you did end up going with Amazon. 192 00:10:31,599 --> 00:10:35,049 What were, what were the other considerations you made as 193 00:10:35,049 --> 00:10:36,459 far as hosting was concerned? 194 00:10:36,759 --> 00:10:40,269 You, you had made the decision you wanted to host, you wanna do Swift 195 00:10:40,599 --> 00:10:43,359 and that was like, okay, where are we gonna actually host this? 196 00:10:43,419 --> 00:10:45,729 Like, what was your decision process there? 197 00:10:47,180 --> 00:10:50,105 Vojtěch Rylko (guest): Yeah, so I think the AWS is. 198 00:10:50,960 --> 00:10:57,260 Kind of obvious leader here or that, how we perceive that, and it felt stable. 199 00:10:57,320 --> 00:10:59,720 Although it feels like they take that seriously. 200 00:10:59,900 --> 00:11:06,500 They Mm. And I think the question is more like, why not to use AWS? 201 00:11:06,710 --> 00:11:08,870 Like what would be the reason to not, to not to use that? 202 00:11:09,020 --> 00:11:12,850 We, and also we already had experience with AWS good experience. 203 00:11:12,850 --> 00:11:13,960 We run some 204 00:11:14,114 --> 00:11:15,134 Leo Dion (host): that's a big factor. 205 00:11:15,164 --> 00:11:15,644 Yes. 206 00:11:15,850 --> 00:11:16,710 Vojtěch Rylko (guest): so, and. 207 00:11:17,220 --> 00:11:21,960 So we are familiar with that and also they're offering met 208 00:11:22,050 --> 00:11:23,700 our requirements like we had. 209 00:11:24,630 --> 00:11:29,460 We are looking for where to run Swift and where to store data and 210 00:11:29,460 --> 00:11:33,780 the database they of offered and the way how they provide Kubernetes. 211 00:11:34,050 --> 00:11:36,060 They made everything made sense for us. 212 00:11:36,120 --> 00:11:38,070 So we went with AWS. 213 00:11:38,600 --> 00:11:40,430 Leo Dion (host): Yeah, that makes complete sense. 214 00:11:40,460 --> 00:11:45,350 And so, what, what's, did you use EC2 or what did you end up doing 215 00:11:45,350 --> 00:11:47,250 as far as like actually hosting it? 216 00:11:47,845 --> 00:11:48,175 Vojtěch Rylko (guest): yeah. 217 00:11:48,295 --> 00:11:48,565 Yeah. 218 00:11:48,895 --> 00:11:55,305 So, we are using Kubernetes, but the EKS, the managed one, so A AWS 219 00:11:55,305 --> 00:12:00,075 takes care for running Kubernetes cluster for us, and we are basically 220 00:12:00,075 --> 00:12:02,985 just plugging in EC2 instances. 221 00:12:03,535 --> 00:12:07,075 Currently we have four EC2 instances for some extra processing. 222 00:12:07,075 --> 00:12:08,425 We can always scale up. 223 00:12:08,425 --> 00:12:10,045 It's pretty convenient. 224 00:12:11,155 --> 00:12:15,295 And yeah, so it is running on top of EC2 instances in the Docker image. 225 00:12:15,345 --> 00:12:18,615 We compile Swift and bundle into the Docker images, which 226 00:12:18,615 --> 00:12:20,985 run in the Kubernetes cluster. 227 00:12:21,525 --> 00:12:23,535 And yeah, it, it's com complex. 228 00:12:23,535 --> 00:12:26,805 The Kubernetes is complex, but it works well for us. 229 00:12:28,115 --> 00:12:30,545 Leo Dion (host): I want to take a step back 'cause I know there's a lot of 230 00:12:30,545 --> 00:12:32,555 iOS developers who listen to this. 231 00:12:33,215 --> 00:12:34,595 Docker is kinda like a vm. 232 00:12:35,435 --> 00:12:41,015 Basically a virtual machine that runs the application, essentially. 233 00:12:41,015 --> 00:12:42,995 Command line app, that's a server. 234 00:12:43,495 --> 00:12:44,605 And then Kubernetes. 235 00:12:44,605 --> 00:12:50,515 Is that like a way to run multiple Docker images and manage 'em, or what, 236 00:12:50,575 --> 00:12:52,135 how does Kubernetes fit into that? 237 00:12:52,895 --> 00:12:55,355 Vojtěch Rylko (guest): Yeah, so I would say. 238 00:12:56,615 --> 00:13:00,185 Is like operating system, which spans multiple machines. 239 00:13:00,485 --> 00:13:04,595 So Kubernetes takes care of multiple, easy two instances. 240 00:13:05,165 --> 00:13:10,245 It manages them, it knows which are fine, which are crashing, for example. 241 00:13:10,845 --> 00:13:17,255 And if you tell Kubernetes to run this Swift executable five 242 00:13:17,255 --> 00:13:21,275 times, it'll distribute it on the machines and make sure the. 243 00:13:21,775 --> 00:13:25,945 Networking is correctly set up so they see what they should see and the 244 00:13:25,945 --> 00:13:29,100 traffic is reaching them as you wish, so 245 00:13:29,190 --> 00:13:29,520 Leo Dion (host): Okay. 246 00:13:30,020 --> 00:13:32,710 Werner Jainek (guest): And maybe in addition what it also handles 247 00:13:32,710 --> 00:13:35,980 is the orchestration of when you're deploying a new update, right? 248 00:13:36,040 --> 00:13:40,390 There's a whole complex procedure where you have to stop traffic to the existing 249 00:13:40,420 --> 00:13:42,940 binary, bring up the new things already. 250 00:13:42,990 --> 00:13:44,790 Redirect traffic and so forth. 251 00:13:44,820 --> 00:13:50,570 Like, all of this management is handled and Kubernetes is usually like, if 252 00:13:50,570 --> 00:13:53,810 you want to run that yourself, it's a whole team in your company doing that. 253 00:13:54,290 --> 00:13:57,410 So, and for us it's two people on, on the backend. 254 00:13:57,410 --> 00:14:00,320 Your VTECH is one, and then team is the other guy. 255 00:14:00,920 --> 00:14:06,200 So that was not an option, but it being managed was certainly interesting and 256 00:14:06,250 --> 00:14:07,925 it, it works fine for us, I would say. 257 00:14:08,647 --> 00:14:08,977 Leo Dion (host): Okay. 258 00:14:09,667 --> 00:14:13,057 What were some of the challenges you initially ran 259 00:14:13,057 --> 00:14:15,127 into in your rewrite to Swift? 260 00:14:16,207 --> 00:14:19,597 That you had to like wrap your head around that Python made easy, 261 00:14:19,597 --> 00:14:20,407 Werner Jainek (guest): no, not really. 262 00:14:20,407 --> 00:14:20,707 Right? 263 00:14:20,707 --> 00:14:22,277 Like there wasn't I mean, you 264 00:14:22,368 --> 00:14:25,128 Leo Dion (host): how was the, so how was the maturity of other 265 00:14:25,128 --> 00:14:28,818 Swift packages compared to the libraries that Python provides? 266 00:14:28,818 --> 00:14:30,588 Like I would assume that would've been 267 00:14:31,094 --> 00:14:32,894 Vojtěch Rylko (guest): Yeah, like, yeah. 268 00:14:32,894 --> 00:14:37,764 So the challenge was our uncertainty about entire ecosystem. 269 00:14:37,764 --> 00:14:42,294 At the beginning we were approaching the, the Swift, we didn't know much about that. 270 00:14:42,354 --> 00:14:47,974 And we are very worried about, as you say about maturity of third party libraries. 271 00:14:48,484 --> 00:14:49,444 Leo Dion (host): Party libraries. 272 00:14:49,444 --> 00:14:53,074 'cause a lot of them are Apple or like, yeah, right. 273 00:14:53,669 --> 00:14:54,464 Vojtěch Rylko (guest): Yeah, you are right 274 00:14:54,634 --> 00:14:57,064 Leo Dion (host): Second, let's call 'em second party libraries. 275 00:14:57,064 --> 00:14:57,484 Yeah. 276 00:14:58,262 --> 00:15:00,002 Werner Jainek (guest): Well, but let me quickly interject. 277 00:15:00,072 --> 00:15:04,122 Like you're right, Swift, Neo, of course, is provided by Apple and I, I should 278 00:15:04,122 --> 00:15:09,342 say knowing that Apple provided that base layer of what we're building on top 279 00:15:09,342 --> 00:15:11,352 of was very important in our decision. 280 00:15:11,352 --> 00:15:13,242 Like that gave us a lot of confidence. 281 00:15:13,289 --> 00:15:15,719 Leo Dion (host): They actually use it day to day in 282 00:15:15,807 --> 00:15:16,437 Werner Jainek (guest): Exactly. 283 00:15:16,617 --> 00:15:17,727 Yeah, exactly. 284 00:15:17,787 --> 00:15:18,087 Yeah. 285 00:15:18,357 --> 00:15:19,647 So that's great. 286 00:15:19,737 --> 00:15:22,677 And then, but there are other libraries from third parties that 287 00:15:22,707 --> 00:15:25,177 we're using and that is unclear, right? 288 00:15:25,177 --> 00:15:26,677 Like, how good will they work? 289 00:15:26,737 --> 00:15:29,377 Are they full of bugs, are they crashing all the time and so 290 00:15:29,377 --> 00:15:31,087 forth that we didn't know right? 291 00:15:31,644 --> 00:15:32,394 Leo Dion (host): Right, right. 292 00:15:32,454 --> 00:15:36,659 So like, what which framework did you end up using to, to, for your server? 293 00:15:37,974 --> 00:15:40,284 Vojtěch Rylko (guest): And so, there was almost obvious 294 00:15:40,284 --> 00:15:42,234 choice to use Vapor back then. 295 00:15:43,464 --> 00:15:46,494 And that got us pretty quick up and running. 296 00:15:46,644 --> 00:15:48,234 It was very con, very convenient. 297 00:15:48,624 --> 00:15:53,034 Now we are, I think, a little bit outgrowing it and maybe 298 00:15:53,034 --> 00:15:57,894 it's time to, to do it ourselves to not use framework anymore. 299 00:15:57,894 --> 00:15:59,884 And but it still serves well. 300 00:15:59,914 --> 00:16:01,054 Like to, to this day. 301 00:16:01,114 --> 00:16:02,644 We, we are happy with that. 302 00:16:02,974 --> 00:16:05,314 And it's great for, for quick start. 303 00:16:06,194 --> 00:16:08,894 Leo Dion (host): Yes, I was gonna say that if you're looking to start, 304 00:16:09,274 --> 00:16:09,994 Vojtěch Rylko (guest): Yeah, that's. 305 00:16:10,034 --> 00:16:11,204 Leo Dion (host): highly recommend Vapor. 306 00:16:11,204 --> 00:16:13,964 It does a lot of handholding for you to get up and running. 307 00:16:14,514 --> 00:16:18,894 Speaking of frameworks that you use, what other services are you using on 308 00:16:18,894 --> 00:16:23,874 Amazon for your application and how do, how does Swift, Swift fit into that? 309 00:16:24,399 --> 00:16:24,819 Vojtěch Rylko (guest): Mm-hmm. 310 00:16:25,214 --> 00:16:25,454 Yeah. 311 00:16:26,444 --> 00:16:31,644 So, the most important service is probably our database, and that is 312 00:16:31,974 --> 00:16:36,414 my school, Aurora, which is kind of. 313 00:16:37,419 --> 00:16:38,079 Different. 314 00:16:38,139 --> 00:16:46,329 My SQL managed and modified by a Amazon by AWS team, and it has different storage 315 00:16:46,329 --> 00:16:54,669 layer for data, which means that the data stored in SQ Aurora are more durable. 316 00:16:54,729 --> 00:16:58,809 They are stored in distributed storage, and that was very 317 00:16:59,234 --> 00:17:02,384 Leo Dion (host): But it's, but it's still relational, which I think is 318 00:17:02,439 --> 00:17:02,829 Vojtěch Rylko (guest): yes. 319 00:17:02,929 --> 00:17:05,059 Leo Dion (host): Big difference from, I don't know what the 320 00:17:05,059 --> 00:17:07,759 Amazon one is, not Dynamo, is it? 321 00:17:07,879 --> 00:17:08,329 Simple. 322 00:17:08,359 --> 00:17:08,989 Simple. 323 00:17:08,989 --> 00:17:13,879 Or what's the Amazon one that's just distributed, but simple key value stuff. 324 00:17:13,909 --> 00:17:18,559 I forgot the name of it, but this is an actual relational database. 325 00:17:19,514 --> 00:17:19,994 Vojtěch Rylko (guest): exactly. 326 00:17:19,994 --> 00:17:23,964 It's for, for the developer's point of view, it is a regular, 327 00:17:23,964 --> 00:17:26,604 my SQL with transactions. 328 00:17:27,909 --> 00:17:30,669 Atomic commit installation. 329 00:17:30,699 --> 00:17:31,839 They're very nice features. 330 00:17:31,839 --> 00:17:32,769 Like we, we love them. 331 00:17:32,769 --> 00:17:36,129 That's why we wanted to use relational database. 332 00:17:36,879 --> 00:17:41,749 But we also wanted to have some guarantees about the durability of data. 333 00:17:42,289 --> 00:17:44,479 And there's not many databases with such 334 00:17:47,184 --> 00:17:48,264 guarantees like the Aurora. 335 00:17:49,014 --> 00:17:50,029 This is very nice. 336 00:17:50,079 --> 00:17:52,359 Leo Dion (host): durability, what do you mean by durability? 337 00:17:52,549 --> 00:17:56,359 Vojtěch Rylko (guest): So if the, if you commit a transaction and main 338 00:17:56,359 --> 00:18:01,939 instance crashes, you, you still have enough copies of your data. 339 00:18:02,389 --> 00:18:07,489 They are, so Aurora has a different storage layer where they write 340 00:18:07,519 --> 00:18:10,099 your data on to multiple locations, 341 00:18:10,574 --> 00:18:10,994 Leo Dion (host): Mm-hmm. 342 00:18:11,539 --> 00:18:13,309 Vojtěch Rylko (guest): and that's a great features. 343 00:18:13,309 --> 00:18:17,689 Like the regular setup of my sql if you want to achieve something like that, is to 344 00:18:17,689 --> 00:18:24,859 have two instances running and you have a. Main writer instance and it you are, you 345 00:18:24,859 --> 00:18:29,119 have some follower reader instance, which is, which is building a copy of your data. 346 00:18:29,939 --> 00:18:30,229 Leo Dion (host): Yeah. 347 00:18:30,499 --> 00:18:33,049 Vojtěch Rylko (guest): But if your main instance crashes now, you have 348 00:18:33,049 --> 00:18:38,509 only one copy of data often, and yeah, so that's what I'm talking 349 00:18:38,509 --> 00:18:44,659 about, like the Aurora comes with guarantees, which are true all the time. 350 00:18:45,659 --> 00:18:48,959 Leo Dion (host): And then my, so I wanna cover, had a question about 351 00:18:48,959 --> 00:18:52,409 any particular reason you went with MySQL instead of Postgres. 352 00:18:52,959 --> 00:18:53,319 Well. 353 00:18:53,574 --> 00:18:58,104 Is it because Aurora is a fork of MySQL, that that's why you ended 354 00:18:58,104 --> 00:19:00,864 up going with MySQL and Aurora. 355 00:19:01,234 --> 00:19:02,804 Vojtěch Rylko (guest): So that's the main point, like, there is our. 356 00:19:03,614 --> 00:19:08,914 For Postgres and for my SQL, but for my SQL that one has been around 357 00:19:08,914 --> 00:19:13,894 for longer, so we felt it is more mature back back at the time. 358 00:19:14,044 --> 00:19:19,744 So that's why we prefer my sq l And also we were thinking that my sq l 359 00:19:19,744 --> 00:19:24,184 should better handle frequent rights. 360 00:19:24,644 --> 00:19:28,784 When you have wider table and you modify just a few cells here and there. 361 00:19:29,784 --> 00:19:33,774 My should be more performant in this scenario, but I'm not sure if 362 00:19:33,774 --> 00:19:37,344 it's true even now, like this year. 363 00:19:38,219 --> 00:19:41,009 Leo Dion (host): So you might like, if you were gonna do it today, you might 364 00:19:41,009 --> 00:19:42,899 consider switching over to Postgres. 365 00:19:43,434 --> 00:19:44,034 Vojtěch Rylko (guest): Oh yeah. 366 00:19:44,034 --> 00:19:44,035 Yeah. 367 00:19:44,040 --> 00:19:45,174 Like I, I would 368 00:19:45,179 --> 00:19:45,539 Leo Dion (host): Okay? 369 00:19:46,134 --> 00:19:47,934 Vojtěch Rylko (guest): consider that I love Postgres, so. 370 00:19:48,119 --> 00:19:48,299 Leo Dion (host): Okay. 371 00:19:48,452 --> 00:19:50,692 Werner Jainek (guest): but also, I guess we should say that we 372 00:19:50,692 --> 00:19:53,752 didn't run into major issues. 373 00:19:53,822 --> 00:19:57,622 I guess, we did have an issue with the size of the database, but I'm not sure if 374 00:19:57,652 --> 00:20:00,202 Postgres would've been much better there. 375 00:20:00,752 --> 00:20:04,292 Like that, that's one of the surprising things we found is like, you would 376 00:20:04,292 --> 00:20:07,022 assume that a few terabytes of data. 377 00:20:07,807 --> 00:20:10,357 Can be handled by these databases these days. 378 00:20:10,417 --> 00:20:13,567 I dunno, that was my naive thinking going into this. 379 00:20:14,027 --> 00:20:17,997 But we found out that no, actually you can't store terabytes of data. 380 00:20:18,057 --> 00:20:21,267 I mean, you can, but then you can't upgrade the instance, for 381 00:20:21,267 --> 00:20:22,527 instance, to a newer version. 382 00:20:23,047 --> 00:20:25,147 'cause it just crashes while the update is going. 383 00:20:26,704 --> 00:20:28,834 Leo Dion (host): So how are you gonna do that when they deprecate 384 00:20:28,834 --> 00:20:30,049 what you're currently using? 385 00:20:30,572 --> 00:20:31,322 Werner Jainek (guest): Yeah, exactly. 386 00:20:31,532 --> 00:20:35,762 So this is one of the surprises we encountered along the way. 387 00:20:35,762 --> 00:20:38,312 And then it's like, okay, I guess we have to solve this. 388 00:20:38,342 --> 00:20:42,802 And we went ahead and solved it by building a bottomless database thing. 389 00:20:42,922 --> 00:20:43,162 What I, 390 00:20:43,489 --> 00:20:44,329 Vojtěch Rylko (guest): Yeah, we, 391 00:20:44,362 --> 00:20:45,112 Werner Jainek (guest): He did, he did it. 392 00:20:45,679 --> 00:20:48,199 Vojtěch Rylko (guest): yeah, we it was pretty late when we found this issue. 393 00:20:48,689 --> 00:20:52,079 Only once we had, in our data in our database, we found we are not 394 00:20:52,079 --> 00:20:54,629 able to upgrade, upgrade it anymore. 395 00:20:55,259 --> 00:21:01,669 So, we built mechanism for offloading of data from database to S3, which is 396 00:21:01,669 --> 00:21:05,699 like, which we try to be opaque from the, from the code point of view. 397 00:21:06,449 --> 00:21:14,049 And now we have a parameter which you are basically by this parameter you are 398 00:21:14,139 --> 00:21:18,639 changing how much of data we store in database and how much data we store in S3. 399 00:21:19,139 --> 00:21:21,629 Because storing it as three is more expensive. 400 00:21:21,659 --> 00:21:24,929 It's, there is more latency when you are getting the data. 401 00:21:25,429 --> 00:21:28,759 So we don't want to put all, all data there. 402 00:21:29,959 --> 00:21:33,169 So we have a parameter and if we need to upgrade the database, 403 00:21:33,409 --> 00:21:36,059 we we adjust this parameter. 404 00:21:36,569 --> 00:21:42,599 It brings the database off, uploads the data to S3, and then we can upgrade. 405 00:21:43,239 --> 00:21:45,549 But yeah, it was quite complex process. 406 00:21:45,919 --> 00:21:49,689 We had to build, which we didn't foreseen back then. 407 00:21:52,812 --> 00:21:55,602 Werner Jainek (guest): And maybe I should say like when we're trying 408 00:21:55,602 --> 00:21:58,752 to solve these kinds of issues, I, I said in the beginning that we're very, 409 00:21:58,752 --> 00:22:00,882 quite proud of the way the syn works. 410 00:22:01,412 --> 00:22:06,602 And the, our whole approach to how we built it is to. 411 00:22:06,992 --> 00:22:12,692 Try to get to a hundred percent correctness, not 99.9, because 412 00:22:12,692 --> 00:22:16,502 if you're a thousandth to do, doesn't sync, that's a problem, you 413 00:22:16,524 --> 00:22:17,059 Leo Dion (host): Right, right. 414 00:22:17,192 --> 00:22:20,982 Werner Jainek (guest): And so we, we care very much about correctness and this 415 00:22:20,982 --> 00:22:22,752 now extends all the way to the cloud. 416 00:22:22,872 --> 00:22:27,522 And when you're offloading data from a transactional database into a different 417 00:22:27,522 --> 00:22:32,112 system you have to be very careful to not accidentally break the transactionality 418 00:22:32,172 --> 00:22:34,542 here and the consistency of the data. 419 00:22:34,942 --> 00:22:39,442 And so we did spend quite some time engineering that, and it works great. 420 00:22:39,542 --> 00:22:43,532 Like another challenge is that in the database, each row is very small, right? 421 00:22:43,532 --> 00:22:46,682 And you can't just put each row individually into, into S3. 422 00:22:46,682 --> 00:22:47,642 That would be insane. 423 00:22:48,032 --> 00:22:50,552 So we compacted them together and so forth. 424 00:22:50,652 --> 00:22:55,062 Yeah, so it's funny, I, as I said, I didn't think we needed to 425 00:22:55,062 --> 00:22:56,982 solve that problem, but we had to. 426 00:22:57,252 --> 00:22:57,492 So. 427 00:22:57,644 --> 00:22:59,054 Leo Dion (host): It's, it's, yeah. 428 00:22:59,634 --> 00:23:03,879 So the database is in the server, but what, what, sorry, what 429 00:23:03,879 --> 00:23:08,199 part is an S3 and what part is in the actual Docker instance? 430 00:23:09,534 --> 00:23:13,134 Or Aurora I should say, or do you use Aurora and then you have the files 431 00:23:13,134 --> 00:23:14,964 in S3, or how does that work exactly? 432 00:23:15,349 --> 00:23:15,679 Vojtěch Rylko (guest): Yeah. 433 00:23:15,829 --> 00:23:16,009 Yeah. 434 00:23:16,009 --> 00:23:21,199 So, we basically store all data in, in database, and there are like two 435 00:23:21,199 --> 00:23:23,899 parts, like two main categories of data. 436 00:23:24,259 --> 00:23:30,559 One part is the regular relational stuff, like user accounts, usernames, 437 00:23:30,559 --> 00:23:32,299 and like this obvious stuff. 438 00:23:32,599 --> 00:23:35,569 And then there's actual user data there to do. 439 00:23:36,879 --> 00:23:37,379 Leo Dion (host): Oh, okay. 440 00:23:38,389 --> 00:23:43,029 Vojtěch Rylko (guest): these guys, this to produce this content of for users. 441 00:23:43,299 --> 00:23:46,479 We don't care about the content on the server. 442 00:23:46,809 --> 00:23:50,889 It's, it's a, for us, for the search server, this is like binary block. 443 00:23:51,519 --> 00:23:57,409 As soon as possible, we compress and encrypt that and store in 444 00:23:57,409 --> 00:24:02,419 database and we don't ever change, we don't ever mutate this data. 445 00:24:02,569 --> 00:24:04,514 So when user changes their to do. 446 00:24:05,149 --> 00:24:13,619 We just add another record about send, about a change on top of previous changes. 447 00:24:13,619 --> 00:24:17,279 So we are like building app and only log for every single user. 448 00:24:18,359 --> 00:24:21,719 And that's, that is a nice property because if you don't 449 00:24:21,719 --> 00:24:26,999 mutate this thesis, you can put them somewhere else eventually. 450 00:24:27,929 --> 00:24:31,709 So if, if, if you have, yeah, if you have enough of this. 451 00:24:32,204 --> 00:24:34,394 So they're worth putting to S3. 452 00:24:34,394 --> 00:24:40,484 You take them, put them together in our, some binary format we made and 453 00:24:40,484 --> 00:24:46,814 we put them to S3 storage where they are guaranteed to exist forever. 454 00:24:47,774 --> 00:24:53,724 And you can basically put a pointer to database in database to to S3. 455 00:24:54,654 --> 00:24:58,944 Yeah, if you want to read the data now, you need to go through S3, which 456 00:24:59,064 --> 00:25:03,084 is slower, is more expensive, and you need to think about transactionality 457 00:25:03,324 --> 00:25:04,974 of whatever you are doing. 458 00:25:05,524 --> 00:25:09,154 Leo Dion (host): So you like all the to-do data is actually 459 00:25:09,154 --> 00:25:10,744 encrypted, is that what I'm hearing 460 00:25:11,744 --> 00:25:12,795 Vojtěch Rylko (guest): Oh, yeah, yeah. 461 00:25:12,884 --> 00:25:17,464 Like, we the way how things thinks is that the server. 462 00:25:18,529 --> 00:25:21,079 Doesn't do much about with data. 463 00:25:21,499 --> 00:25:28,339 Like it's all up to clients how to, to understand data, to, to 464 00:25:28,339 --> 00:25:30,379 resolve conflicting situations. 465 00:25:31,039 --> 00:25:35,779 And the backend is like dump stor, dump storage. 466 00:25:35,779 --> 00:25:37,639 Like it doesn't look into to those. 467 00:25:37,639 --> 00:25:39,629 There is nothing what we need to do there. 468 00:25:40,049 --> 00:25:42,839 So immediately when the change from user arrives. 469 00:25:43,409 --> 00:25:47,909 We just compress and encrypt that and put it into databases, binary block, 470 00:25:48,749 --> 00:25:51,959 and never need look inside anymore. 471 00:25:52,049 --> 00:25:57,634 Like only when another client wants that, that the client will read the data. 472 00:25:57,744 --> 00:25:58,394 Look inside. 473 00:25:59,449 --> 00:25:59,779 Leo Dion (host): Okay. 474 00:26:00,409 --> 00:26:01,219 That's amazing. 475 00:26:01,324 --> 00:26:01,544 Wow. 476 00:26:02,044 --> 00:26:06,874 So you mentioned that you use S3, you also use Lamb does Right? 477 00:26:06,874 --> 00:26:07,984 For some stuff. 478 00:26:09,317 --> 00:26:10,127 Werner Jainek (guest): Oh, that's a good point. 479 00:26:10,127 --> 00:26:10,457 Yeah. 480 00:26:10,894 --> 00:26:11,254 Leo Dion (host): Yeah. 481 00:26:11,254 --> 00:26:11,584 How does 482 00:26:11,687 --> 00:26:13,607 Werner Jainek (guest): that we needed from, from Python. 483 00:26:14,764 --> 00:26:15,214 Leo Dion (host): Okay. 484 00:26:15,394 --> 00:26:15,784 Okay. 485 00:26:15,842 --> 00:26:16,042 Werner Jainek (guest): go. 486 00:26:17,099 --> 00:26:17,219 Vojtěch Rylko (guest): Yeah. 487 00:26:17,219 --> 00:26:19,729 So, we have a feature called mail to Things. 488 00:26:20,209 --> 00:26:25,364 So every every user of things cloud gets a special email address 489 00:26:25,624 --> 00:26:25,914 Leo Dion (host): Yeah. 490 00:26:26,294 --> 00:26:27,969 Vojtěch Rylko (guest): where when they can, when they send the 491 00:26:28,094 --> 00:26:32,594 email there, it will appear as a, to-do in their things inbox. 492 00:26:33,344 --> 00:26:36,844 So, we are receiving these emails and. 493 00:26:37,564 --> 00:26:43,954 We need to process them somehow on server to create a, to-do for, for the user. 494 00:26:44,374 --> 00:26:48,874 And processing emails is a ma that's a mess. 495 00:26:49,084 --> 00:26:54,104 Like, so we so we are using, we are processing incoming emails with Lambda, 496 00:26:54,104 --> 00:26:59,024 where we run a Python three script because Python has the best libraries 497 00:26:59,024 --> 00:27:02,384 for this kind of like messy, messy work. 498 00:27:03,854 --> 00:27:08,174 Where there are internet standards, but nobody really follows them. 499 00:27:08,594 --> 00:27:12,284 So you need very major libraries to be able to parse 500 00:27:12,344 --> 00:27:15,404 any email, any incoming email. 501 00:27:15,794 --> 00:27:18,404 So yeah, so we are, we still have some Python around. 502 00:27:19,292 --> 00:27:20,882 Werner Jainek (guest): But it's very much a satellite, right? 503 00:27:21,032 --> 00:27:23,952 Like, it's just this little thing that runs in Zam. 504 00:27:24,312 --> 00:27:28,572 The majority of the code is in Swift inside Docker, running on 505 00:27:28,572 --> 00:27:30,912 Kubernetes, or managed by Kubernetes. 506 00:27:31,272 --> 00:27:31,452 Yeah, 507 00:27:32,219 --> 00:27:34,319 Leo Dion (host): Is that the only lambda you have? 508 00:27:34,999 --> 00:27:35,839 Is the email? 509 00:27:35,869 --> 00:27:36,259 Okay. 510 00:27:36,649 --> 00:27:36,979 Okay. 511 00:27:37,669 --> 00:27:38,569 That makes sense. 512 00:27:38,669 --> 00:27:42,959 Yeah, we did the episode with Sebastian talking about, lamb done Swift stuff, 513 00:27:42,959 --> 00:27:46,529 so it's a pretty powerful tool. 514 00:27:46,589 --> 00:27:49,619 You have also like some background processes as well. 515 00:27:49,619 --> 00:27:50,939 Those are written in Swift. 516 00:27:51,269 --> 00:27:54,564 How does that, how does that work or, and what do you use it for? 517 00:27:55,524 --> 00:27:55,854 Vojtěch Rylko (guest): Yeah. 518 00:27:55,887 --> 00:27:56,217 Werner Jainek (guest): Mm-hmm. 519 00:27:56,717 --> 00:28:00,587 Vojtěch Rylko (guest): So we have bunch of background workers and they 520 00:28:00,587 --> 00:28:06,377 run in our Kubernetes cluster as every other, as every other staff. 521 00:28:07,687 --> 00:28:13,957 And what's maybe interesting is that we have one code base and one shirt 522 00:28:13,957 --> 00:28:16,177 coat, and we are building just one. 523 00:28:17,017 --> 00:28:23,267 Binary, but it can be configured to run as API or as the worker 524 00:28:23,867 --> 00:28:25,907 of type A or another worker. 525 00:28:26,057 --> 00:28:29,747 And one of these workers is exactly that database of uploading. 526 00:28:30,167 --> 00:28:36,007 So, there is a worker, which is reading the database, looking for data which 527 00:28:36,007 --> 00:28:39,517 can, which it can offload and put to S3. 528 00:28:39,697 --> 00:28:41,317 So this is one of these workers. 529 00:28:41,317 --> 00:28:42,187 So is the Swift. 530 00:28:42,247 --> 00:28:51,547 So the guy another, another is the worker, which takes these processed 531 00:28:51,547 --> 00:28:57,007 emails by Python and actually creates the, to-do for particular user, like 532 00:28:57,157 --> 00:29:00,667 looks for the user and creates to, and so, and we have a bunch of such workers. 533 00:29:01,667 --> 00:29:04,417 Leo Dion (host): Do you use, like, what is it, service lifecycle stuff 534 00:29:04,447 --> 00:29:08,407 or how do you, how do you trigger that or how do you get it running? 535 00:29:09,018 --> 00:29:11,208 Vojtěch Rylko (guest): Yeah, that would be great. 536 00:29:11,208 --> 00:29:14,918 Like, we would love to use this, but we, we still have some legacy stuff 537 00:29:14,918 --> 00:29:19,148 built on top of Evan Loops and it's a little, that part is a little bit messy. 538 00:29:19,698 --> 00:29:22,848 Leo Dion (host): I will, I will ask later about Swift six, but before I 539 00:29:22,848 --> 00:29:26,808 get into that, I think one question I should ask that I think is important 540 00:29:26,808 --> 00:29:33,588 is, you've got an app in the app store, you've got a server on AWS, how are 541 00:29:33,588 --> 00:29:35,538 you sharing code between the two? 542 00:29:36,348 --> 00:29:42,528 And like, do you have, do you have, have you seen advantages with that? 543 00:29:42,528 --> 00:29:45,828 I guess because that's the big question is like, okay, you've written in an iOS 544 00:29:45,828 --> 00:29:47,628 app, you have the backend and Swift too. 545 00:29:48,198 --> 00:29:53,298 Where's, is there any shared code in that, in that instance between the two? 546 00:29:53,298 --> 00:29:55,818 Or what advantages have you seen in that, in that way? 547 00:29:57,256 --> 00:29:58,546 Werner Jainek (guest): Yeah, so that's very interesting. 548 00:29:58,576 --> 00:30:00,916 Like, even on the client side, right? 549 00:30:00,916 --> 00:30:04,636 It's not just one app, it's multiple apps that we were shipping, one for 550 00:30:04,636 --> 00:30:07,876 the Mac, one for iOS, one for visional. 551 00:30:08,386 --> 00:30:12,856 And even there, the stories that the code bases have started out quite separate. 552 00:30:12,886 --> 00:30:16,996 Like we used core data on the Mac, but our own thing on iOS and 553 00:30:17,026 --> 00:30:18,796 hence entirely different models. 554 00:30:18,806 --> 00:30:21,176 And entirely different view stacks and so forth. 555 00:30:21,536 --> 00:30:26,556 And so in the past ever since we've been around we had this effort of unifying 556 00:30:26,556 --> 00:30:28,626 more and more of the code base like today. 557 00:30:29,026 --> 00:30:30,676 The same model runs everywhere 558 00:30:31,103 --> 00:30:31,433 Leo Dion (host): Right. 559 00:30:31,433 --> 00:30:31,553 That 560 00:30:31,696 --> 00:30:32,056 Werner Jainek (guest): the way. 561 00:30:32,506 --> 00:30:32,806 Yeah. 562 00:30:33,196 --> 00:30:37,676 And even a lot of the controller code all the logic code the sim code of 563 00:30:37,676 --> 00:30:39,416 course is shared across the platforms. 564 00:30:39,476 --> 00:30:42,196 And there's even more we want to do on the clients. 565 00:30:42,726 --> 00:30:47,366 And back when we decided to try out Swift on the server the 566 00:30:47,396 --> 00:30:51,626 possibility of co-chairing was certainly a, an interesting prospect. 567 00:30:51,986 --> 00:30:57,176 And so that was part of the reason why we were excited to use it on the server. 568 00:30:57,566 --> 00:30:59,696 Now so far, that has not come to. 569 00:31:00,176 --> 00:31:04,436 Realization, like we're not sharing code, maybe one or two files that I forgot. 570 00:31:04,966 --> 00:31:06,816 But the majority isn't shared. 571 00:31:07,216 --> 00:31:11,166 However, we think in the future there will be quite some opportunities for 572 00:31:11,166 --> 00:31:15,836 co-chairing and so I guess we'll have to chat again in few years and then we have 573 00:31:15,836 --> 00:31:18,566 a, a more interesting perspective on that. 574 00:31:18,626 --> 00:31:19,796 I think how that 575 00:31:19,873 --> 00:31:22,273 Leo Dion (host): Yeah, I think like for me, it's always ended 576 00:31:22,273 --> 00:31:24,373 up with like simple data models. 577 00:31:24,723 --> 00:31:27,723 Tho those are the ones that end up being shared or maybe like some 578 00:31:27,723 --> 00:31:29,583 utility functions and things like that. 579 00:31:29,583 --> 00:31:35,613 But yeah, I mean, your, your business logic is different on both and Yeah, 580 00:31:35,613 --> 00:31:41,493 I could see how, how that would not be as, as useful as you might think. 581 00:31:42,063 --> 00:31:43,923 Is there, is everything in one, sorry? 582 00:31:44,073 --> 00:31:48,783 Is everything in like one Xcode project or multi repo mono repo. 583 00:31:49,306 --> 00:31:50,926 Werner Jainek (guest): I mean, for the server it's all in one. 584 00:31:51,256 --> 00:31:52,996 And then for the clients it's all in one. 585 00:31:53,568 --> 00:31:53,838 Leo Dion (host): Okay. 586 00:31:53,838 --> 00:31:55,848 So you've ke kept that totally separate. 587 00:31:55,878 --> 00:31:56,268 Okay. 588 00:31:56,658 --> 00:31:57,258 Interesting. 589 00:31:57,716 --> 00:31:58,136 Werner Jainek (guest): Mm-hmm. 590 00:31:58,288 --> 00:32:01,198 Leo Dion (host): So I'm gonna ask a awkward question here. 591 00:32:01,258 --> 00:32:02,308 Swift six. 592 00:32:02,788 --> 00:32:04,648 Where, where are you with that? 593 00:32:04,918 --> 00:32:05,968 Are you excited? 594 00:32:05,968 --> 00:32:07,618 Are you scared? 595 00:32:08,198 --> 00:32:11,528 What, what's kind of the thought process with Swift six? 596 00:32:12,528 --> 00:32:16,348 Vojtěch Rylko (guest): Oh, actually we just recently, we switched to Swift six 597 00:32:16,892 --> 00:32:17,312 Leo Dion (host): Oh wow. 598 00:32:17,338 --> 00:32:18,598 Vojtěch Rylko (guest): and Yeah. 599 00:32:18,598 --> 00:32:19,838 And we like that 600 00:32:19,902 --> 00:32:21,192 Leo Dion (host): Both client and server. 601 00:32:21,968 --> 00:32:22,628 Vojtěch Rylko (guest): yeah. 602 00:32:22,780 --> 00:32:23,050 Werner Jainek (guest): Yep. 603 00:32:23,682 --> 00:32:23,862 Leo Dion (host): Okay. 604 00:32:24,023 --> 00:32:27,983 Vojtěch Rylko (guest): for, for, for server, like we, we, the, we adopted 605 00:32:28,383 --> 00:32:30,693 structure concurrency everywhere. 606 00:32:31,143 --> 00:32:36,123 Now we are just waiting for that few remaining dependencies to, to catch up. 607 00:32:36,613 --> 00:32:42,393 We adopted, we, we completely switched to Swift testing and it went pretty well. 608 00:32:42,393 --> 00:32:47,023 Like, I don't know, like we spent like one or two weeks adopting 609 00:32:47,023 --> 00:32:48,583 this structured concurrency. 610 00:32:48,583 --> 00:32:49,693 I. There were 611 00:32:49,790 --> 00:32:50,540 Werner Jainek (guest): On the server 612 00:32:51,013 --> 00:32:52,483 Vojtěch Rylko (guest): on the server speaking about server. 613 00:32:52,903 --> 00:32:57,733 And there were no major roadblock or something, just like some send ups 614 00:32:57,913 --> 00:33:05,413 here and there some changes, but it was pretty nice experience on the server. 615 00:33:05,912 --> 00:33:07,952 Leo Dion (host): almost easier on the server than it is on the 616 00:33:08,130 --> 00:33:10,200 Werner Jainek (guest): It is certainly like, that's why I was 617 00:33:10,200 --> 00:33:11,790 correcting like only on the server. 618 00:33:11,790 --> 00:33:13,320 It took two weeks I think on the client. 619 00:33:13,320 --> 00:33:14,430 We invested more. 620 00:33:15,000 --> 00:33:18,750 And it was certainly more in the way on the client, I would say, on the server. 621 00:33:18,750 --> 00:33:19,680 It's very natural. 622 00:33:19,750 --> 00:33:21,910 'cause already the structure is like you're getting the 623 00:33:21,910 --> 00:33:23,830 requests, you're isolated and 624 00:33:24,027 --> 00:33:24,387 Leo Dion (host): Yeah. 625 00:33:24,387 --> 00:33:26,577 We've had that for a while, so it's like, yeah. 626 00:33:27,077 --> 00:33:31,427 Let's talk about, well, is there anything you're interested in 627 00:33:31,427 --> 00:33:32,927 when it comes to Swift 6.1? 628 00:33:32,927 --> 00:33:35,957 I may may as well ask that if you've even looked at it. 629 00:33:36,957 --> 00:33:39,237 Vojtěch Rylko (guest): Yeah, not I'm not particularly like 630 00:33:39,807 --> 00:33:41,967 excited about any, any features. 631 00:33:42,297 --> 00:33:47,597 What I liked is that Swift language committee acknowledged that this 632 00:33:47,597 --> 00:33:51,857 concurrency is sometimes a little bit tricky, and they are trying to work on 633 00:33:51,857 --> 00:33:54,387 more approachable Swift concurrency. 634 00:33:54,747 --> 00:33:56,577 And that, that excites me. 635 00:33:56,667 --> 00:33:58,567 I think that's a good direction. 636 00:33:59,307 --> 00:33:59,727 Leo Dion (host): Yeah. 637 00:33:59,847 --> 00:34:00,087 Yeah. 638 00:34:00,087 --> 00:34:00,507 Agreed. 639 00:34:00,537 --> 00:34:01,047 Agreed. 640 00:34:01,547 --> 00:34:04,427 Let's talk about logging and metrics. 641 00:34:04,427 --> 00:34:08,597 How important is that when running a server application and where did 642 00:34:08,597 --> 00:34:11,177 that fit when it came to Swift? 643 00:34:12,027 --> 00:34:14,072 Vojtěch Rylko (guest): Oh, that's, that's super important. 644 00:34:14,182 --> 00:34:17,512 Like without being able to observe what's happening. 645 00:34:18,012 --> 00:34:20,442 We are not able to, to detect that something's wrong. 646 00:34:20,922 --> 00:34:26,172 So, as Werner said we are team of just two on, on, on backend. 647 00:34:26,722 --> 00:34:30,712 But we, we have pretty high standard even for such small team. 648 00:34:31,012 --> 00:34:33,232 So for example, we have we have pager duties. 649 00:34:33,232 --> 00:34:37,022 So we have, um, or all the call duties. 650 00:34:37,442 --> 00:34:42,692 So we have like, we have monitoring which triggers incidents, and that 651 00:34:42,692 --> 00:34:50,052 incidents wake up current developer who currently has on-call duty and for that 652 00:34:50,142 --> 00:34:55,812 to work towards, well, we need grade monitoring, logging metrics, everything. 653 00:34:56,197 --> 00:35:03,252 So we can set up incidents which notify us only with something's really wrong. 654 00:35:04,142 --> 00:35:04,362 Leo Dion (host): Hmm. 655 00:35:04,437 --> 00:35:07,737 Vojtěch Rylko (guest): And we need to be able to detect all the potential issues. 656 00:35:08,217 --> 00:35:15,397 So, I think the logging is our, the, like, that's probably the, even the 657 00:35:15,607 --> 00:35:19,627 biggest part of our cloud bill currently, like the logging and metrics, that's 658 00:35:19,627 --> 00:35:21,907 the most expensive part currently. 659 00:35:23,002 --> 00:35:27,472 So we take that pretty seriously and we are using custom custom json logger 660 00:35:27,532 --> 00:35:33,322 we, we built and we are using the Swift Prometheus library or package, which is 661 00:35:33,322 --> 00:35:36,922 available and which ships the metrics. 662 00:35:37,922 --> 00:35:39,992 And we are watching. 663 00:35:41,147 --> 00:35:45,767 The efforts about s pricing and, and, and other stuff. 664 00:35:45,767 --> 00:35:49,607 I think currently there are some people working on this. 665 00:35:50,117 --> 00:35:51,407 So it's on our radar. 666 00:35:52,387 --> 00:35:53,842 Leo Dion (host): What is Prometheus? 667 00:35:55,007 --> 00:35:55,247 Vojtěch Rylko (guest): Yeah. 668 00:35:55,277 --> 00:36:00,507 Protive is a way how to, it's about metrics. 669 00:36:00,987 --> 00:36:02,307 It's, it is about metrics. 670 00:36:02,357 --> 00:36:05,837 So currently we've switched from itus package. 671 00:36:07,217 --> 00:36:14,237 Our code is able to provide various metrics and these are then digested 672 00:36:14,777 --> 00:36:19,937 to CloudWatch, AWS CloudWatch, and then where we can see nice graphs 673 00:36:20,567 --> 00:36:25,507 and we can we can set up some, I dunno, incidents if something is 674 00:36:25,507 --> 00:36:27,367 over some threshold and so on. 675 00:36:28,792 --> 00:36:29,082 Leo Dion (host): Okay. 676 00:36:30,082 --> 00:36:30,802 Let's. 677 00:36:31,687 --> 00:36:34,207 So there was something you mentioned. 678 00:36:34,207 --> 00:36:39,067 I really picked my interest, speaking of listening to issues and errors and things, 679 00:36:39,067 --> 00:36:42,187 is this thing called a chaos engine. 680 00:36:42,787 --> 00:36:44,917 What, what is that exactly? 681 00:36:44,917 --> 00:36:46,867 What, what's going on there? 682 00:36:47,982 --> 00:36:48,647 Vojtěch Rylko (guest): Yeah, I do. 683 00:36:49,187 --> 00:36:51,827 I think the best testing is testing on production. 684 00:36:52,202 --> 00:36:57,182 So, so the chaos testing is a way how to test the infrastructure and little 685 00:36:57,182 --> 00:36:59,262 bit also the code on production. 686 00:37:00,222 --> 00:37:08,232 It's about introducing virus faults, injecting faults into, into 687 00:37:08,232 --> 00:37:10,062 the code or into infrastructure. 688 00:37:10,062 --> 00:37:15,252 So, for example, every morning the chaos engine we have inject 689 00:37:15,252 --> 00:37:17,422 some fault into into cluster. 690 00:37:17,422 --> 00:37:18,202 It can be. 691 00:37:18,702 --> 00:37:22,272 That some of instances crashes. 692 00:37:22,272 --> 00:37:28,392 Like we've, we force instance to crash and we observe if it auto heals and 693 00:37:28,392 --> 00:37:35,492 cluster like gas into the health state again, or we, we have some part in the 694 00:37:35,492 --> 00:37:42,482 code where we force unwrap nil, and we do that ev every now and then and see. 695 00:37:43,082 --> 00:37:49,832 If we are properly notified about this happening and that no no issue 696 00:37:49,832 --> 00:37:55,832 happens, like to data or like everything gracefully recovers again, so, 697 00:37:56,062 --> 00:37:59,242 Leo Dion (host): So is this like, is this like CR job and is this all 698 00:37:59,242 --> 00:38:01,462 written in Swift or what exactly. 699 00:38:01,902 --> 00:38:03,487 Vojtěch Rylko (guest): So it's quite, is quiet. 700 00:38:04,272 --> 00:38:05,322 Weird beast. 701 00:38:05,322 --> 00:38:06,602 So it's powered Byron. 702 00:38:07,022 --> 00:38:13,472 So every, every day it starts and it's like a shell script with shell scripts. 703 00:38:13,532 --> 00:38:17,282 And we are using various ways. 704 00:38:17,492 --> 00:38:22,032 There's for example AWS service, which helps you to 705 00:38:22,057 --> 00:38:24,852 inject particular SubT errors. 706 00:38:25,002 --> 00:38:26,652 For example, networking errors. 707 00:38:27,202 --> 00:38:28,822 And that's very useful to test. 708 00:38:28,822 --> 00:38:31,372 Like you can test the split brain scenario. 709 00:38:31,582 --> 00:38:36,742 Like what if you disconnect your cluster to two parts, what, what will happen? 710 00:38:37,612 --> 00:38:40,462 So all of that is super, super interesting. 711 00:38:41,860 --> 00:38:44,410 Werner Jainek (guest): And maybe I should, I I, I'd like to add to 712 00:38:44,410 --> 00:38:49,500 that like before we said Google App Engine was a, a black box for us. 713 00:38:49,990 --> 00:38:51,100 That was the downside. 714 00:38:51,130 --> 00:38:54,520 The upside is that they did a pretty good job, at having a great 715 00:38:54,550 --> 00:38:56,590 uptime of the things cloud service. 716 00:38:57,040 --> 00:39:00,410 And so throughout the years we've been using that the uptime. 717 00:39:00,440 --> 00:39:01,730 Uptime was phenomenal. 718 00:39:02,600 --> 00:39:06,920 And so when switching over to this entirely new cloud where we wanted to 719 00:39:06,920 --> 00:39:09,860 have more control, one of our worries was. 720 00:39:09,940 --> 00:39:13,420 Well, we better make sure that we have the same level of quality 721 00:39:13,420 --> 00:39:15,160 that we're delivering to our users. 722 00:39:15,640 --> 00:39:18,580 And we, we went at great lengths to ensuring that the 723 00:39:18,580 --> 00:39:20,080 chaos testing is part of it. 724 00:39:20,140 --> 00:39:23,290 Like, how do you know how your system behaves if things go wrong, 725 00:39:23,530 --> 00:39:25,390 if you don't make them go wrong? 726 00:39:25,570 --> 00:39:25,810 Right? 727 00:39:25,810 --> 00:39:26,950 So we try to do that. 728 00:39:27,490 --> 00:39:32,050 And then the other part, of course is it's an entirely new stack, entirely new 729 00:39:32,050 --> 00:39:34,660 code base new technologies everywhere. 730 00:39:34,940 --> 00:39:39,680 How do we know, that it, that it works well, you know, that we're not constantly 731 00:39:39,680 --> 00:39:41,510 having some crashes and so forth. 732 00:39:41,880 --> 00:39:43,860 And that was a big challenge when developing. 733 00:39:44,030 --> 00:39:48,200 And we can get into that if you like but we, we went at quite some 734 00:39:48,200 --> 00:39:52,260 lengths to ensure that on day one the new version we're shipping 735 00:39:52,660 --> 00:39:54,820 is already tested in production. 736 00:39:54,940 --> 00:39:58,270 So yeah, let, just as a small side that, that we basically 737 00:39:58,270 --> 00:40:00,010 ran both versions side by side. 738 00:40:00,040 --> 00:40:01,390 That was the, the trick there. 739 00:40:02,487 --> 00:40:03,507 Leo Dion (host): How did that work out? 740 00:40:03,507 --> 00:40:05,877 Like, or how did you keep both in sync and stuff? 741 00:40:06,400 --> 00:40:07,990 Werner Jainek (guest): Yeah, it's quite, quite cool. 742 00:40:08,050 --> 00:40:09,040 We think that's quite cool. 743 00:40:09,040 --> 00:40:09,250 So. 744 00:40:10,447 --> 00:40:16,097 Vojtěch Rylko (guest): Yeah, so when we're developing new system we, our goal 745 00:40:16,097 --> 00:40:19,667 was to not disrupt users on day one. 746 00:40:19,757 --> 00:40:24,737 Like we, we, we needed the new system to be very robust and proven, 747 00:40:24,737 --> 00:40:27,342 already proven before releasing. 748 00:40:27,962 --> 00:40:32,692 And we found that the only way how to make make it is to to run it actually. 749 00:40:33,412 --> 00:40:34,252 And so we. 750 00:40:34,987 --> 00:40:40,027 We had a legacy system running and we started to run a new system alongside 751 00:40:40,537 --> 00:40:46,777 and we piped all the traffic through the new system where it executed its 752 00:40:46,777 --> 00:40:53,047 own logic, its own database access, its stored data, performed all the Swift code 753 00:40:53,047 --> 00:40:59,857 there, but it also forwarded the requests to the legacy system and that were. 754 00:41:00,272 --> 00:41:01,862 This was authoritative. 755 00:41:02,282 --> 00:41:05,492 So the response from legacy system got back to user. 756 00:41:06,752 --> 00:41:11,282 We, it is impossible to keep this two system completely in sync. 757 00:41:11,912 --> 00:41:17,162 So they they diverged in the data, like was in database, but that was not 758 00:41:17,162 --> 00:41:19,892 really, that was not really important. 759 00:41:19,892 --> 00:41:21,632 Like to the correctness. 760 00:41:21,662 --> 00:41:26,472 We tested the correctness and behavior manually and by other ways. 761 00:41:26,982 --> 00:41:32,802 But the fact that it worked all the time, like for a year without downtime, without 762 00:41:33,012 --> 00:41:40,382 crashing, without performance issues that gave us confidence that once we turn 763 00:41:40,382 --> 00:41:44,012 off legacy system, it will work fine. 764 00:41:44,462 --> 00:41:48,902 And to make even more sure, we employ the chaos testing where we not only. 765 00:41:49,487 --> 00:41:53,477 Led the new system running, but we were also poking into that and 766 00:41:53,477 --> 00:41:58,517 seeing like if it auto recovers, how does it behave under extra load. 767 00:41:59,147 --> 00:42:02,567 And similarly, and we're observing the system for months and months 768 00:42:03,047 --> 00:42:07,777 before we got enough confidence to actually switch over to it. 769 00:42:08,777 --> 00:42:09,067 Leo Dion (host): Okay. 770 00:42:10,512 --> 00:42:10,812 Yeah. 771 00:42:10,872 --> 00:42:11,562 That's awesome. 772 00:42:11,932 --> 00:42:16,242 So before we close out, I had one more question was how do you actually deploy. 773 00:42:16,872 --> 00:42:17,772 Your server app. 774 00:42:18,252 --> 00:42:22,572 So those of us who are iOS developers are quite familiar with, dealing with the 775 00:42:22,572 --> 00:42:26,022 app store server side is a bit different. 776 00:42:26,082 --> 00:42:29,292 And I know you talked about using GitHub actions and things like that. 777 00:42:29,682 --> 00:42:34,512 You wanna explain how deployment works when you want to update the server. 778 00:42:35,828 --> 00:42:37,073 Vojtěch Rylko (guest): It is actually pretty boring. 779 00:42:37,133 --> 00:42:38,803 So, GitHub actions, they 780 00:42:38,912 --> 00:42:40,442 Leo Dion (host): a good thing sometimes, right? 781 00:42:41,653 --> 00:42:42,013 Vojtěch Rylko (guest): right. 782 00:42:42,653 --> 00:42:47,963 So we compile our Swift code or using GitHub actions. 783 00:42:48,513 --> 00:42:49,893 Of course it could be faster. 784 00:42:49,893 --> 00:42:54,363 That would be very nice, but it's about 10 minutes and that 785 00:42:54,487 --> 00:42:55,777 Leo Dion (host): you run their server? 786 00:42:55,777 --> 00:42:57,367 Do you run their, well, no. 787 00:42:57,367 --> 00:43:01,117 I guess you run, you run Linux, so you don't even, like, 788 00:43:01,357 --> 00:43:03,067 you don't even need a Mac. 789 00:43:03,682 --> 00:43:04,032 Right. 790 00:43:04,368 --> 00:43:06,798 Vojtěch Rylko (guest): like, GitHub provides you with runtime. 791 00:43:06,798 --> 00:43:10,488 So you just like create small YAML file where you specify a 792 00:43:10,488 --> 00:43:12,768 few steps and they are executed. 793 00:43:13,308 --> 00:43:14,478 It's very convenient. 794 00:43:14,898 --> 00:43:19,828 And so we build our Swift code base there inside the docker. 795 00:43:19,828 --> 00:43:21,478 So that creates a Docker image. 796 00:43:21,988 --> 00:43:23,128 And that got. 797 00:43:23,803 --> 00:43:24,793 Upload it in. 798 00:43:24,793 --> 00:43:29,833 So like in a fancy storage like Docker registry, but it's just like you 799 00:43:29,833 --> 00:43:35,743 put it somewhere and it has a tech attached, like some name, some tech. 800 00:43:36,463 --> 00:43:41,608 And then when we want to deploy that thing, we basically tell Kubernetes to, 801 00:43:42,973 --> 00:43:45,433 to use a new tech, to this new tech. 802 00:43:45,983 --> 00:43:49,763 And Kubernetes tags the image. 803 00:43:50,378 --> 00:43:56,918 Starts down the old running service and starts a new one, basically. 804 00:43:57,878 --> 00:44:00,908 Or you can do, it can make it also gradually, it can 805 00:44:00,998 --> 00:44:03,188 like keep old stuff running. 806 00:44:03,788 --> 00:44:07,958 Starts also new stuff and starts switching the traffic so you have no downtime. 807 00:44:08,458 --> 00:44:09,988 That's also sometimes useful. 808 00:44:10,802 --> 00:44:11,492 Leo Dion (host): That's awesome. 809 00:44:11,992 --> 00:44:14,717 Before we close out, was there anything else you wanted to talk about? 810 00:44:15,717 --> 00:44:18,587 Werner Jainek (guest): I mean, maybe, just throwing a top level 811 00:44:18,797 --> 00:44:20,567 light on this whole endeavor, right? 812 00:44:20,567 --> 00:44:21,617 Like, why are we here? 813 00:44:22,187 --> 00:44:27,292 We, we feel that back when we started this project, as Tex said in the 814 00:44:27,292 --> 00:44:29,462 beginning, it was quite uncertain thing. 815 00:44:29,462 --> 00:44:30,482 Like, will it work out? 816 00:44:30,482 --> 00:44:31,172 Will it not work 817 00:44:31,409 --> 00:44:31,759 Leo Dion (host): Right. 818 00:44:32,002 --> 00:44:35,312 Werner Jainek (guest): And I guess along the way we grew in confidence. 819 00:44:35,312 --> 00:44:37,982 Like there was no roadblock along the way. 820 00:44:38,102 --> 00:44:40,772 All the, there were no problems to speak of. 821 00:44:40,802 --> 00:44:43,952 And now even in production, it's been in production for a year. 822 00:44:43,952 --> 00:44:44,882 We haven't said that yet. 823 00:44:45,002 --> 00:44:46,712 Like we switched early last year. 824 00:44:47,912 --> 00:44:49,202 And it's been running great. 825 00:44:49,652 --> 00:44:54,272 So we considered this a great success story for Swift on the server. 826 00:44:54,502 --> 00:44:58,322 And we felt that it's important to get the word out 'cause 827 00:44:58,322 --> 00:45:00,512 there's not that many still. 828 00:45:00,562 --> 00:45:03,852 Great use cases out that people can listen to, right? 829 00:45:03,852 --> 00:45:07,572 So that's why we went to the Swift on server conference and had a 830 00:45:07,632 --> 00:45:10,152 short talk there to tell people, it's like, Hey, it's working. 831 00:45:10,362 --> 00:45:10,722 Like 832 00:45:10,859 --> 00:45:10,909 Leo Dion (host): Yeah. 833 00:45:10,909 --> 00:45:11,389 Yeah. 834 00:45:11,592 --> 00:45:14,202 Werner Jainek (guest): if you find yourself in a similar position as 835 00:45:14,202 --> 00:45:18,602 us maybe you already have a, a Swift code base and you need a server 836 00:45:18,602 --> 00:45:20,552 component, this is definitely an option. 837 00:45:21,212 --> 00:45:22,082 Go try it. 838 00:45:22,232 --> 00:45:22,562 Right? 839 00:45:22,592 --> 00:45:24,212 Like, or at least consider it. 840 00:45:24,954 --> 00:45:26,829 Leo Dion (host): And we will have links to your talk. 841 00:45:26,889 --> 00:45:31,929 And my, my success story from Swifton Server as well and some other folks. 842 00:45:32,249 --> 00:45:33,479 Definitely check that out. 843 00:45:34,079 --> 00:45:34,499 Werner Jainek (guest): Are some. 844 00:45:34,589 --> 00:45:35,009 Of course. 845 00:45:35,009 --> 00:45:35,189 Yeah. 846 00:45:35,701 --> 00:45:36,601 Leo Dion (host): Yeah, yeah, yeah. 847 00:45:36,691 --> 00:45:37,081 Alright. 848 00:45:37,111 --> 00:45:42,481 But everybody knows things, so that's, I think that's a big, big defining feature. 849 00:45:42,571 --> 00:45:47,101 For your, the part of your story is, is that I don't know how many 850 00:45:47,101 --> 00:45:49,381 users, gazillion users use things. 851 00:45:49,381 --> 00:45:50,971 So we know it works. 852 00:45:50,971 --> 00:45:51,361 We know it 853 00:45:51,479 --> 00:45:52,349 Werner Jainek (guest): That's about the number. 854 00:45:52,349 --> 00:45:52,559 Yeah. 855 00:45:52,921 --> 00:45:53,161 Leo Dion (host): Yeah. 856 00:45:53,161 --> 00:45:53,461 Yeah. 857 00:45:53,581 --> 00:45:54,721 It's a scientific number. 858 00:45:54,831 --> 00:45:55,041 Werner Jainek (guest): Yeah. 859 00:45:55,041 --> 00:45:55,042 Yeah. 860 00:45:55,633 --> 00:45:59,053 Leo Dion (host): For someone who is an iOS developer, which is the vast majority 861 00:45:59,053 --> 00:46:01,543 of Swift developers, they want to. 862 00:46:02,263 --> 00:46:03,643 Maybe they won't need a server. 863 00:46:03,643 --> 00:46:06,883 Maybe they're just kinda curious about having a server. 864 00:46:07,243 --> 00:46:12,913 How, how, why should they get started on Server side Swift, and how should 865 00:46:12,913 --> 00:46:14,263 they get started on server side? 866 00:46:14,263 --> 00:46:14,713 Swift, 867 00:46:15,713 --> 00:46:16,478 Vojtěch Rylko (guest): that is interesting. 868 00:46:16,478 --> 00:46:20,468 Like, I'm not sure that we are in position that we could give good 869 00:46:20,468 --> 00:46:26,448 advice here because we are the quite a backend people like me and my 870 00:46:26,448 --> 00:46:31,028 colleague, so who, who just know Swift. 871 00:46:31,868 --> 00:46:36,203 So we use Kubernetes and everything, but I. And recommend it for 872 00:46:36,263 --> 00:46:38,393 anyone who just want to try. 873 00:46:38,753 --> 00:46:44,453 It's pretty complex and it took us lots of time to set up it's like full blown, 874 00:46:44,453 --> 00:46:46,973 like full in solution, full in approach. 875 00:46:47,343 --> 00:46:51,303 For somebody who just starts out, I don't know, maybe you already said 876 00:46:51,303 --> 00:46:55,923 about something about the, lambda now, now you can run Swift on Lambda. 877 00:46:55,923 --> 00:47:00,333 So maybe for some small minor server processing that makes sense with 878 00:47:00,333 --> 00:47:04,353 some managed database, some key value store that could be maybe interesting. 879 00:47:04,563 --> 00:47:08,283 But I would definitely, if I would be just, I would, I would be, I 880 00:47:08,283 --> 00:47:14,013 always developer who just want to try out, I would be looking for some. 881 00:47:14,478 --> 00:47:18,888 Managed solution where I don't need to care about easy two instances 882 00:47:18,888 --> 00:47:20,898 and Kubernetes and like no, 883 00:47:20,903 --> 00:47:22,763 Leo Dion (host): big, I'm, I like Heroku. 884 00:47:22,823 --> 00:47:25,373 We use, I've used Heroku for most of my stuff. 885 00:47:25,403 --> 00:47:27,893 You just get a Vapor app, put it, put it up. 886 00:47:27,893 --> 00:47:29,453 It's pretty easy to get started. 887 00:47:29,453 --> 00:47:31,883 Vapor is super, a lot of handholding. 888 00:47:31,883 --> 00:47:33,203 Great documentation. 889 00:47:33,773 --> 00:47:34,063 Yeah, 890 00:47:35,701 --> 00:47:36,451 Werner Jainek (guest): Yeah, definitely. 891 00:47:36,451 --> 00:47:38,791 I mean, we, we, that's how we got started as well. 892 00:47:38,791 --> 00:47:39,571 And it was great 893 00:47:39,781 --> 00:47:42,181 Leo Dion (host): right before d before going down the rabbit hole of 894 00:47:42,211 --> 00:47:43,831 Docker and Kubernetes and all that 895 00:47:44,006 --> 00:47:46,321 Vojtěch Rylko (guest): Yeah, I think there's a great 896 00:47:46,351 --> 00:47:48,751 Leo Dion (host): And I do think like having some experience with 897 00:47:48,751 --> 00:47:50,221 server side development is helpful. 898 00:47:50,221 --> 00:47:54,271 Just getting that perspective as far as like what, what the other side 899 00:47:54,481 --> 00:47:59,311 does as you know, besides doing just table view controllers all the time. 900 00:47:59,311 --> 00:48:01,711 There's, there's more to it on outside of that. 901 00:48:01,711 --> 00:48:04,141 Gentlemen, thank you so much for coming on. 902 00:48:04,141 --> 00:48:05,101 I really appreciate it. 903 00:48:05,101 --> 00:48:08,221 This has been fantastic to hear your story, your success story 904 00:48:08,221 --> 00:48:11,226 with Server Side, Swift where can people find you online? 905 00:48:13,229 --> 00:48:13,829 Werner Jainek (guest): Good question. 906 00:48:13,969 --> 00:48:14,989 Cultured code.com. 907 00:48:15,049 --> 00:48:16,999 I guess us personally ek, I dunno, 908 00:48:19,156 --> 00:48:20,926 Vojtěch Rylko (guest): Best site com. 909 00:48:21,771 --> 00:48:22,161 Leo Dion (host): Awesome. 910 00:48:22,281 --> 00:48:25,641 And we'll put links to your social stuff in the notes too. 911 00:48:25,671 --> 00:48:27,171 So, yeah. 912 00:48:27,351 --> 00:48:29,081 Werner Jainek (guest): I mean, you should follow the, the company. 913 00:48:29,111 --> 00:48:30,311 That's where we communicate. 914 00:48:30,371 --> 00:48:33,161 Like I, I technically have a social account, but I'm 915 00:48:33,161 --> 00:48:34,301 not really using that much. 916 00:48:34,661 --> 00:48:34,811 So 917 00:48:37,813 --> 00:48:38,983 Leo Dion (host): Thank you so much, gentlemen. 918 00:48:38,983 --> 00:48:40,243 It's been fantastic. 919 00:48:40,481 --> 00:48:40,631 Werner Jainek (guest): you. 920 00:48:40,661 --> 00:48:41,501 Thanks for having us. 921 00:48:42,238 --> 00:48:44,548 Leo Dion (host): People can find me@brightdigit.com. 922 00:48:44,738 --> 00:48:51,658 My social is at Leo g Dion on all the socials at Leo g Dion at C dot. 923 00:48:51,658 --> 00:48:52,858 I am on Mastodon. 924 00:48:53,338 --> 00:48:54,208 Thank you again. 925 00:48:54,268 --> 00:48:56,683 I look forward to talking to you in the next episode. 926 00:48:56,703 --> 00:48:57,243 Bye everybody. 927 00:48:59,468 --> 00:48:59,888 Vojtěch Rylko (guest): Bye. 928 00:48:59,953 --> 00:49:00,073 Leo Dion (host): But