WEBVTT 1 00:00:06.240 --> 00:00:10.000 Hey everybody, and welcome to another episode of Alixer Mix. 2 00:00:10.480 --> 00:00:13.000 This week on our panel we have Sasha Wolf. 3 00:00:13.039 --> 00:00:14.400 Hello everybody, I'm. 4 00:00:14.320 --> 00:00:17.239 Charles Maxwood from devchat dot TV. And this week we 5 00:00:17.320 --> 00:00:20.640 have a special guest, and that's Ivan Rubelog. Did I 6 00:00:20.719 --> 00:00:22.519 get anywhere close to saying your name right? 7 00:00:23.000 --> 00:00:24.839 Yes, that's right. Hello, every bunny. 8 00:00:25.160 --> 00:00:27.280 Do you want to introduce yourself real quick? Let people 9 00:00:27.280 --> 00:00:28.879 know who you are and why you're famous? 10 00:00:29.120 --> 00:00:32.799 Yeah? Sure, thanks to work for kind words. So, Hi, 11 00:00:32.920 --> 00:00:36.920 I'm Ivan. I'm originally I'm from Russia, but for three 12 00:00:37.000 --> 00:00:40.520 years we with my family live in Humburg, Germany. So 13 00:00:41.000 --> 00:00:47.079 I'm software back at Elixir, engineer, working in business domains 14 00:00:47.759 --> 00:00:51.960 real estate and currently in B two B business. Yeah, 15 00:00:52.119 --> 00:00:52.960 so that's cool. 16 00:00:53.719 --> 00:00:57.920 And yeah, I was looking at this Domo library that 17 00:00:58.000 --> 00:01:01.000 you wrote. I have to admit I'm I'm still green 18 00:01:01.079 --> 00:01:03.359 when it comes to some of this stuff. So and 19 00:01:03.560 --> 00:01:04.959 follow all of it. But do you want to give 20 00:01:05.000 --> 00:01:07.239 us kind of the ten thousand view on what domo 21 00:01:07.400 --> 00:01:08.200 is and what it does? 22 00:01:08.400 --> 00:01:08.640 Yeah? 23 00:01:08.680 --> 00:01:13.920 Sure, that started like about a year ago, and I 24 00:01:14.000 --> 00:01:17.840 usually had the impressions that I miss something within Elixir 25 00:01:18.799 --> 00:01:23.000 and when I look at the structure and especially type 26 00:01:23.040 --> 00:01:26.400 definitions of the structure. Of course, there is a dialyzer 27 00:01:26.519 --> 00:01:31.040 tool that helps us to check validity of the source 28 00:01:31.079 --> 00:01:34.280 code program same time, it doesn't work at run time, 29 00:01:34.480 --> 00:01:38.719 and vilizer is quite heavy too, to be honest. So 30 00:01:39.400 --> 00:01:43.680 and I was missing these things. That's okay. Elixir is 31 00:01:44.120 --> 00:01:49.359 dynamically type language, and on the other hand, the type definition, 32 00:01:49.840 --> 00:01:53.120 maybe I can do something about that. And then pandemic 33 00:01:53.159 --> 00:01:57.920 started and I've got some free time, and I just 34 00:01:58.640 --> 00:02:05.640 kick it off. Made these libraries that basically validates the 35 00:02:05.680 --> 00:02:10.560 structure against the type definition and return meaningful errors about 36 00:02:10.680 --> 00:02:14.039 the fields. Okay, here you define that this field should 37 00:02:14.039 --> 00:02:17.319 be a string, and you have some number in this 38 00:02:17.400 --> 00:02:21.400 field in the structure. So these aims to keep the 39 00:02:21.840 --> 00:02:26.360 state valid because many software errors comes from invalid state 40 00:02:26.680 --> 00:02:32.759 in the memory, and structures looks like a good place 41 00:02:32.879 --> 00:02:36.639 for keeping the state. So that was my thought, Okay, 42 00:02:36.759 --> 00:02:40.919 let's make a tool that validates a state within the structure. 43 00:02:41.199 --> 00:02:44.319 Was prompted by like a concrete, like if use case 44 00:02:44.400 --> 00:02:46.560 you had, like for example, at work, you had some 45 00:02:46.599 --> 00:02:49.080 issues or what was just like an just an academic 46 00:02:49.159 --> 00:02:52.039 idea at the beginning, and you were curious to try 47 00:02:52.080 --> 00:02:52.680 somethings out. 48 00:02:53.000 --> 00:02:57.120 Well, yeah, it was mostly inspired by book The Main 49 00:02:57.159 --> 00:03:01.599 Dream Design by Eric Evans and more. It was more 50 00:03:01.759 --> 00:03:07.960 like in academic inspiration, let's say. And yeah, so I've 51 00:03:07.960 --> 00:03:12.000 got this feelings that there are lots of trials and 52 00:03:12.159 --> 00:03:16.439 terrors around. So we know that there are other libraries 53 00:03:16.520 --> 00:03:23.199 like norm that aiming the validation and other attempts to 54 00:03:23.240 --> 00:03:28.120 make to introduce types in Elixir to get these benefits 55 00:03:28.159 --> 00:03:32.919 of checking and some time nothing what I meant before 56 00:03:33.080 --> 00:03:36.800 suit mean well, and because of that I decided, okay, 57 00:03:36.879 --> 00:03:39.240 maybe I should give it a try and do some 58 00:03:40.159 --> 00:03:43.599 not full fledged type system or something, because Elixir is 59 00:03:43.599 --> 00:03:46.199 not such kind of thing but a very little, tiny 60 00:03:46.879 --> 00:03:51.879 specific library that does on the validation of the structures 61 00:03:52.280 --> 00:03:54.599 and basically keeping invariants. 62 00:03:54.840 --> 00:03:55.080 Yeah. 63 00:03:55.400 --> 00:03:58.960 So, answering your question directly, no, it wasn't inspired by 64 00:03:59.080 --> 00:04:03.639 any and create task at the office. So it was 65 00:04:03.680 --> 00:04:07.159 more like general ideas that I would like to have 66 00:04:07.319 --> 00:04:07.879 such a thing. 67 00:04:08.479 --> 00:04:11.800 And are you not using it in like any production scenarios? 68 00:04:11.840 --> 00:04:14.280 I mean you said it comes from an academic background, sure, 69 00:04:14.319 --> 00:04:16.560 but do you know that like anybody is using it 70 00:04:16.600 --> 00:04:17.800 in production? Yeah? 71 00:04:17.879 --> 00:04:23.839 Well sure, so I checked it's with current real projects 72 00:04:23.839 --> 00:04:28.720 that we have and it works well. So and it's 73 00:04:29.279 --> 00:04:33.480 kind of at early stage, so of course it's in 74 00:04:33.519 --> 00:04:36.600 development for about a year, but only a couple of 75 00:04:36.639 --> 00:04:40.399 days ago I can say okay that final things were 76 00:04:40.439 --> 00:04:43.480 fixed and now it can be widely adopted. 77 00:04:43.959 --> 00:04:48.319 Okay, Well, would you see like DOMO being used most 78 00:04:48.360 --> 00:04:51.439 likely any specific use cases where you say, hey, that's 79 00:04:51.879 --> 00:04:55.000 like a pretty good fit for DOMO where I saw 80 00:04:55.120 --> 00:04:58.439 personal success and using it, Like when more people reach 81 00:04:58.480 --> 00:05:00.920 for DOMO compared to something like for example, norm as 82 00:05:00.920 --> 00:05:03.240 you mentioned earlier, because just to give them context for 83 00:05:03.399 --> 00:05:06.639 listeners like NORMS, this data validation library where you specify 84 00:05:06.720 --> 00:05:09.839 schemas like in code, like it doesn't use the type specs, 85 00:05:09.839 --> 00:05:13.480 but like you can basically use functions and stuff from 86 00:05:13.560 --> 00:05:16.319 norm to say okay, the data should conform to this 87 00:05:16.480 --> 00:05:20.680 schema and mean demo that uses the typespecs. So when 88 00:05:20.680 --> 00:05:23.480 would you say, is like it's a scenario where somebody 89 00:05:23.519 --> 00:05:26.040 would like to use DOMO any specific. 90 00:05:27.600 --> 00:05:31.360 Yeah, sure, that's an amazing question. Thanks a lot. So 91 00:05:32.399 --> 00:05:36.639 there is another component in DOMO. It's that I haven't 92 00:05:36.680 --> 00:05:41.079 mentioned before. So it it's not only validating the data 93 00:05:41.120 --> 00:05:45.079 against the type definition TYPESPEC, but it also has these 94 00:05:45.240 --> 00:05:50.519 pre condition functions attached to the type, so meaning that 95 00:05:50.920 --> 00:05:53.519 for example, if you have the type definition for a 96 00:05:53.560 --> 00:05:57.120 field of your structure, you can also add a pre 97 00:05:57.240 --> 00:06:01.240 condition function to this type that the normal library would 98 00:06:01.319 --> 00:06:05.279 call and if this function returns okay, then it would 99 00:06:05.319 --> 00:06:08.279 consider that the value is not only of that type, 100 00:06:08.279 --> 00:06:11.279 but it's also of a for example, right format that 101 00:06:11.360 --> 00:06:16.480 you expect. So and saying that I can point out 102 00:06:16.560 --> 00:06:20.959 to the concrete scenario. So for example, if you know 103 00:06:21.079 --> 00:06:25.360 that you have an identifier in your system for your order. 104 00:06:25.480 --> 00:06:28.759 For example, let's say you build e commerce system right 105 00:06:29.240 --> 00:06:32.879 some websites the e commerce website, and you know that 106 00:06:33.000 --> 00:06:37.000 in your system this identifiers have specific format for example 107 00:06:37.360 --> 00:06:41.480 AA letter in the beginning and some numbers afterwards. You 108 00:06:41.519 --> 00:06:45.639 can just define the type okay my ideas of string 109 00:06:45.800 --> 00:06:50.680 type and add a precondition function to this, so saying 110 00:06:51.079 --> 00:06:54.680 that the value should begins with A and then using 111 00:06:54.720 --> 00:06:59.040 this type across any structures in your application. You would 112 00:06:59.040 --> 00:07:04.279 have these automatically validated whenever the structure is created with 113 00:07:05.079 --> 00:07:09.240 a construction function added by dormal library, and the DOMO 114 00:07:09.319 --> 00:07:13.000 will guarantee you that you will have valid values for 115 00:07:13.040 --> 00:07:19.000 this id type across your application and that in this 116 00:07:19.120 --> 00:07:23.160 regards the state would be valid. So yeah, this is 117 00:07:23.240 --> 00:07:26.720 one of scenarios, and it can go even more. Like 118 00:07:27.000 --> 00:07:30.959 we can go further. We can define with normal library, 119 00:07:30.959 --> 00:07:35.800 it's possible to define the precondition for the struct type. 120 00:07:36.079 --> 00:07:39.399 You know, when you write this type T for your structure, 121 00:07:40.040 --> 00:07:42.560 and you can say, okay, for this type T, the 122 00:07:42.639 --> 00:07:47.279 miprecondition function will be this one you name it. And 123 00:07:48.199 --> 00:07:51.680 let's say you would like to have some relations check 124 00:07:51.800 --> 00:07:56.720 between fields of this structure, saying that if this is 125 00:07:56.759 --> 00:07:59.199 the order structure for e commerce website, that you have 126 00:07:59.279 --> 00:08:03.120 some allowed amount or of the order in terms of money, 127 00:08:03.800 --> 00:08:07.399 and you would like to have the sum of all 128 00:08:07.560 --> 00:08:10.560 line items in this order to be not higher than 129 00:08:10.639 --> 00:08:16.439 this given amount. So this precondition function attached to the 130 00:08:16.519 --> 00:08:21.160 type of the structure can validate that and give some 131 00:08:21.560 --> 00:08:26.639 meaningful error bag that okay, you should have the summary 132 00:08:26.639 --> 00:08:31.120 amount less than a lot. And that's as a scenario. 133 00:08:31.120 --> 00:08:37.639 When DOMO gives you a consistency of your structure or 134 00:08:37.759 --> 00:08:41.399 more higher level let's say so so it allows to 135 00:08:41.799 --> 00:08:46.919 follow business rules of the system implementing. So this is 136 00:08:46.919 --> 00:08:47.799 the second scenario. 137 00:08:48.200 --> 00:08:52.399 So that's I guess that could make sense to use Thermo. 138 00:08:52.480 --> 00:08:55.159 For example, at the edges of my system. When I 139 00:08:55.159 --> 00:08:57.960 say I have a Phoenix API, for example, getting some 140 00:08:58.080 --> 00:09:01.399 jacon in and I want to verify that the user 141 00:09:01.440 --> 00:09:06.279 actually like the information the user gave me, conforms to 142 00:09:06.600 --> 00:09:10.480 a certain data schema to like to the to the 143 00:09:10.519 --> 00:09:15.039 requests objects I expect, and that I then can use 144 00:09:15.120 --> 00:09:17.840 that to forward it to the rest of my application, 145 00:09:18.000 --> 00:09:21.519 being sure that, Yeah, as you said, preconditions are met. 146 00:09:21.759 --> 00:09:23.799 Is that right? Is that like a scenario where you 147 00:09:23.840 --> 00:09:25.240 would say DOMO is applicable. 148 00:09:25.440 --> 00:09:29.720 Yes, is one of scenarios where DOMO can can play 149 00:09:30.200 --> 00:09:35.480 and it's like equivalent to what can be implemented with norm. Right, 150 00:09:35.600 --> 00:09:39.000 So you can define the schema and validate the adjacent 151 00:09:39.080 --> 00:09:42.240 on the let's say boundary of your application, and then 152 00:09:42.360 --> 00:09:46.799 be sure that the data that you operate on is valid. 153 00:09:47.799 --> 00:09:51.759 And yeah, there's definitely one of the possible scenarios. On 154 00:09:51.840 --> 00:09:56.120 the other hand, there are other scenarios. It's when you 155 00:09:56.159 --> 00:10:00.159 work with a pure core having only pure functions and 156 00:10:00.320 --> 00:10:05.080 structures in it, and you would like to follow to 157 00:10:05.200 --> 00:10:08.559 make it follow some business rules that should be executed 158 00:10:08.600 --> 00:10:12.600 in your system. So, for example, it's from the domain 159 00:10:12.960 --> 00:10:17.080 domain driven design framework. Right, So when you have a 160 00:10:17.159 --> 00:10:20.200 set of business rules, you can define them with normal 161 00:10:20.279 --> 00:10:24.679 precondition functions page to the type and have this business 162 00:10:24.759 --> 00:10:29.399 rule fulfilled everywhere you use these values of these type 163 00:10:29.440 --> 00:10:35.159 in structures. So, for example, as I mentioned this before 164 00:10:35.320 --> 00:10:39.720 with order, right, so you can have the order structure 165 00:10:39.799 --> 00:10:46.480 in your core and have these values dependency between items 166 00:10:46.519 --> 00:10:52.240 of this order and allowed amount the same invariants, same 167 00:10:52.320 --> 00:10:58.720 kind of invariants may be for other structures that participate 168 00:10:58.759 --> 00:11:01.399 in the business logic of your application. 169 00:11:02.120 --> 00:11:02.399 Right. 170 00:11:03.080 --> 00:11:07.360 And instead of the okay, this can be compared that 171 00:11:07.759 --> 00:11:10.559 you can say, hey, I can write this in any module, 172 00:11:10.759 --> 00:11:17.080 write this verification that my structure have a valid number 173 00:11:17.120 --> 00:11:21.320 of items and that there's some is not exceeding the 174 00:11:21.720 --> 00:11:26.159 allowed amount for this order. And the interesting part here 175 00:11:26.360 --> 00:11:29.440 is that if you do this with DOMO, by using 176 00:11:29.480 --> 00:11:33.120 this precondition function attached to the type, you can have 177 00:11:33.279 --> 00:11:37.080 this validation not only in this structure but in any 178 00:11:37.200 --> 00:11:41.320 other kind of structures using this type. So it goes 179 00:11:41.960 --> 00:11:46.679 like automatically in these places and you don't need to 180 00:11:47.080 --> 00:11:51.720 think twice about if I forgot any validations or you know, 181 00:11:51.879 --> 00:11:56.960 any parts of checking my structures in regards to business 182 00:11:56.960 --> 00:12:01.759 logic of the application, and it even can go further 183 00:12:01.960 --> 00:12:06.120 across the application boundaries. For example, if you have several 184 00:12:06.159 --> 00:12:10.759 micro services that is very common nowadays, you may have 185 00:12:10.879 --> 00:12:14.799 hundreds of them, and if, for example, you share these 186 00:12:14.960 --> 00:12:20.399 type definition and pre condition functions in some model files 187 00:12:20.440 --> 00:12:24.600 across these several applications, due to the normal library, you 188 00:12:24.600 --> 00:12:28.759 can be sure that this would be checked and full filled. 189 00:12:29.679 --> 00:12:38.519 These either these validations for boundary situation or for business 190 00:12:38.559 --> 00:12:40.039 logic in the core. 191 00:12:40.840 --> 00:12:43.559 When you say sharing the model fied, I assume like 192 00:12:43.600 --> 00:12:46.799 in the sense of like a private tax package or 193 00:12:46.840 --> 00:12:48.200 what exactly are you thinking of? 194 00:12:48.440 --> 00:12:52.759 Oh, yeah, sure, it can be a hex package. On 195 00:12:52.840 --> 00:12:56.000 the other hand, it's usually starts like a little you 196 00:12:56.159 --> 00:13:02.480 just have several modules like share models that you can 197 00:13:02.919 --> 00:13:08.799 check out in various repels. So the techniques are various 198 00:13:08.840 --> 00:13:13.559 for that. So for example, you can have shared Git 199 00:13:13.639 --> 00:13:18.759 repository with this model and you can edit as submodules 200 00:13:18.799 --> 00:13:22.600 to other Git repositors or you know, just check it. 201 00:13:22.639 --> 00:13:25.120 But basically you lose like some kind of mechanism to 202 00:13:25.240 --> 00:13:29.519 like get the code into your micro services, be through 203 00:13:29.679 --> 00:13:33.480 x package or like through okay, yeah, that's right, okay, 204 00:13:33.759 --> 00:13:36.159 And I was just thinking because there are also solutions 205 00:13:36.159 --> 00:13:39.679 such as protobaf or others I can think of right now, 206 00:13:40.000 --> 00:13:42.720 which like also follow this idea of having like a 207 00:13:42.759 --> 00:13:45.799 model definition which then can be used to generate some code. 208 00:13:45.840 --> 00:13:49.559 But that's like more agnostic, not really specific to to 209 00:13:49.559 --> 00:13:50.320 to elix here. 210 00:13:50.440 --> 00:13:55.080 Yeah, it's very interesting. Yes, the true protobuffs are very 211 00:13:55.120 --> 00:14:00.919 good to have the intercommunication be validated time. It is 212 00:14:01.240 --> 00:14:05.320 impossible to put function protobize definition. 213 00:14:06.159 --> 00:14:08.399 Which with some might argue is a good thing. 214 00:14:09.639 --> 00:14:10.399 At some scenario. 215 00:14:10.559 --> 00:14:10.759 Yes. 216 00:14:11.159 --> 00:14:13.720 On the other hand, with dormo, you can do that 217 00:14:13.919 --> 00:14:18.360 and do more precise validation like Okay, if that if 218 00:14:18.360 --> 00:14:25.440 these conditions that mad, then these values should be as expected. 219 00:14:25.519 --> 00:14:28.600 On the other hand, if I have another value in 220 00:14:28.639 --> 00:14:32.559 my structure set to this value, then this should be 221 00:14:33.080 --> 00:14:36.320 should be another duly expected. So you can imagine that 222 00:14:36.639 --> 00:14:41.720 it can be quite complex interdependencies between fields of even 223 00:14:41.759 --> 00:14:47.159 one structure, not saying about some nested structures that usually 224 00:14:47.279 --> 00:14:50.639 now can be seen in modern applications. 225 00:14:50.960 --> 00:14:55.320 Okay, to get back to something you said earlier, So 226 00:14:55.360 --> 00:14:58.559 you said that you can reuse like type definitions and 227 00:14:58.720 --> 00:15:01.519 preconditions that attached with that type. So if for example, 228 00:15:01.559 --> 00:15:04.120 I like to get back into an example, you said, like, yeah, 229 00:15:04.120 --> 00:15:07.440 I've a certain identifier, like an order identifier. I could 230 00:15:07.519 --> 00:15:12.679 just specify this type in some module, attach some preconditions 231 00:15:12.720 --> 00:15:15.559 to it, and then use it across my application and 232 00:15:16.000 --> 00:15:19.679 wherever I use DOMO. Basically, I assume then that would 233 00:15:19.679 --> 00:15:24.519 basically reuse these preconditions attached to my order identifier type. 234 00:15:24.600 --> 00:15:27.399 Is that right? Did I get that right? Yeah? That's right? 235 00:15:27.559 --> 00:15:31.399 To Okay, it looks like that. Okay, that's nice. I 236 00:15:31.440 --> 00:15:34.919 guess DOMO boils a bit down to like saying to 237 00:15:34.960 --> 00:15:37.559 avoid a bit of a petition, right, because for example, 238 00:15:37.600 --> 00:15:43.480 if you look at EMO, you acto schemas like like 239 00:15:43.480 --> 00:15:46.200 for at least from my experience, you tend to have 240 00:15:46.799 --> 00:15:48.720 this scenario where you say, okay, this is like my 241 00:15:48.759 --> 00:15:52.720 schema and these my fields. But then it's also helpful 242 00:15:52.840 --> 00:15:54.960 to to have type definition on tops so that you 243 00:15:55.159 --> 00:15:58.080 then just for documentation purposes, right ba, I say okay, 244 00:15:58.519 --> 00:16:00.840 this is like the type of this, and these are 245 00:16:00.919 --> 00:16:03.159 like the sphere as an integer and this field as 246 00:16:03.200 --> 00:16:06.039 a string. And then you also have on the bottom, 247 00:16:06.120 --> 00:16:09.519 like maybe some some ECTO change set validations where they say, okay, 248 00:16:09.679 --> 00:16:12.480 I use the idea needs to start with an AID 249 00:16:12.799 --> 00:16:14.799 or my other ID needs to start with an ASOL. 250 00:16:14.840 --> 00:16:17.279 So I guess DOMO goes a bit in that direction 251 00:16:17.320 --> 00:16:19.679 where they say, okay, I don't want to maintain like 252 00:16:20.200 --> 00:16:23.879 multiple definitions of the same information basically. 253 00:16:23.679 --> 00:16:29.360 Right true true, that's it. And moreover, Domo has support 254 00:16:29.440 --> 00:16:33.240 of ACTO. So if you have these schema defined, and 255 00:16:33.480 --> 00:16:37.440 you have these type defined into the schema, you can 256 00:16:37.639 --> 00:16:41.399 call the change set in the Dormo library and the 257 00:16:41.519 --> 00:16:47.320 function that's named validate type, and DOMO will automatically validate 258 00:16:47.399 --> 00:16:50.440 changes in the Acto change set for you according to 259 00:16:50.519 --> 00:16:56.639 the type you defined. So this is already supported and 260 00:16:56.799 --> 00:16:57.519 quite convenient. 261 00:16:57.799 --> 00:17:02.200 That's nice. I assume that, like to actually reuse a 262 00:17:02.240 --> 00:17:06.359 type for example, such as the order ID, I have 263 00:17:06.440 --> 00:17:09.599 to like use Domo in that place, right, I can't 264 00:17:09.640 --> 00:17:12.720 just use any remote type. I mean that, like, how 265 00:17:12.759 --> 00:17:14.559 does that work? When you say okay, it's like a 266 00:17:14.559 --> 00:17:17.839 string T, then like we probably have some code written 267 00:17:17.839 --> 00:17:20.400 which says, okay, if it's a string, then doing this 268 00:17:20.519 --> 00:17:23.200 and that check. But if I just say I have 269 00:17:23.319 --> 00:17:25.799 like this module over there, which like doesn't use domo 270 00:17:25.839 --> 00:17:29.920 at all, but it specifies my type, I don't know which, 271 00:17:30.359 --> 00:17:33.680 just say like it's a map with like certain certain keys, 272 00:17:33.799 --> 00:17:36.559 and the keys need to be of a certain value. 273 00:17:36.599 --> 00:17:39.240 Is that like something DOMO can can handle them? Or 274 00:17:39.839 --> 00:17:41.880 how exactly can I can I imagine this to work? 275 00:17:42.400 --> 00:17:42.720 Yeah? 276 00:17:42.759 --> 00:17:45.319 Like where are the boundaries? Basically like why does it break? 277 00:17:45.799 --> 00:17:50.000 Okay, so three key questions, so where it's break? Well, 278 00:17:50.519 --> 00:17:53.680 I can say that that's a very good example. And 279 00:17:54.559 --> 00:17:57.240 it was a quite long year. But then here so 280 00:17:57.720 --> 00:18:00.799 I had the time to resolve this and it was 281 00:18:00.960 --> 00:18:05.000 successfully completed. So how DOMA works. If you have remote 282 00:18:05.000 --> 00:18:10.039 type is within some structure or other module that's not 283 00:18:10.240 --> 00:18:14.839 using DOMA at all, library automatically take this type into 284 00:18:16.119 --> 00:18:24.599 validation because more has is shipped with compiler. So when 285 00:18:24.640 --> 00:18:29.799 you add library to the project, it has two pass compilation. 286 00:18:30.440 --> 00:18:33.240 First pass is by alixer and second past of the 287 00:18:33.279 --> 00:18:37.039 compilation is by DOMA compiler that just do the job 288 00:18:37.200 --> 00:18:40.880 by getting all the type definitions from remote modules and 289 00:18:40.960 --> 00:18:44.680 putting them in place where the validation should be performed. 290 00:18:45.079 --> 00:18:49.720 So and moreover, if you change remote type, for example, 291 00:18:49.759 --> 00:18:53.759 you compile your project and you change one of the 292 00:18:53.839 --> 00:18:56.960 keys in this map you mentioned in the remote module, 293 00:18:57.119 --> 00:18:59.839 I mean type definition of the key and you can 294 00:19:00.240 --> 00:19:05.759 again the DOMO will notice that and recompile the module 295 00:19:05.759 --> 00:19:08.559 where you use is remote map definition. 296 00:19:08.759 --> 00:19:14.279 So automatically as signs that compiled time dependency to the remote. 297 00:19:14.000 --> 00:19:18.000 Model, it tracks dependence in between types in your application 298 00:19:18.240 --> 00:19:20.400 and recompiles appropriately. 299 00:19:20.680 --> 00:19:24.160 I assume that this can have a hit on compilation 300 00:19:24.279 --> 00:19:26.400 times because I mean, if you look at what the 301 00:19:26.440 --> 00:19:28.960 Alexi core team and the Phoenix core team has been 302 00:19:29.000 --> 00:19:32.400 doing in the past few months, they very much try 303 00:19:32.440 --> 00:19:37.640 to reduce this kind of like compile time compilation compilation 304 00:19:37.720 --> 00:19:41.759 links between modules which can SUI times. So I assume 305 00:19:41.799 --> 00:19:44.119 that at least like a trade off of using domo 306 00:19:44.160 --> 00:19:46.519 in that fashion is probably that it might impact your 307 00:19:46.559 --> 00:19:47.599 compiled times. 308 00:19:47.359 --> 00:19:50.960 Right, yeah, sure when you comes at price, so definitely 309 00:19:51.200 --> 00:19:56.039 it would increase compilation times. In synthetic tests it was 310 00:19:56.119 --> 00:20:02.680 about maybe twenty percent of increase compilation time. And of 311 00:20:02.759 --> 00:20:07.160 course during the run time it's additional sipute cycles that 312 00:20:07.319 --> 00:20:11.240 are spent on the validation of the data you've got. 313 00:20:11.519 --> 00:20:13.839 I mean, that's your idea, right. 314 00:20:15.119 --> 00:20:18.319 That's true. Yeah. At the same time, I can say 315 00:20:18.359 --> 00:20:23.799 that there is a heavy optimization implemented yet for the 316 00:20:24.000 --> 00:20:29.200 dependency checks it just works. I can say that during 317 00:20:29.279 --> 00:20:33.720 the compilation time, Dormo relies to the pattern matching a lot, 318 00:20:34.680 --> 00:20:38.680 and at least for the part when you have this 319 00:20:38.839 --> 00:20:42.960 validation at run time of your values. It's working on 320 00:20:43.400 --> 00:20:48.240 already optimized code optimized by Elixir and a lung compilers. 321 00:20:48.279 --> 00:20:53.480 Because of pattern matches that automatically generated by Domo, you 322 00:20:53.559 --> 00:20:58.279 can have quite a good performance. Yeah. If you you know, 323 00:20:58.480 --> 00:21:03.160 when we talk about code generation, that definitely happens here 324 00:21:03.200 --> 00:21:06.960 with the dormal library. It's always a question mark, Okay, 325 00:21:07.160 --> 00:21:12.000 what this library generates and how it works in my application, 326 00:21:12.920 --> 00:21:16.359 So you can ask this question at some point in time. 327 00:21:17.200 --> 00:21:22.519 And interesting enough that Domo rights the source code of 328 00:21:22.720 --> 00:21:27.720 this validation into the build folder. So if you add 329 00:21:27.759 --> 00:21:32.160 the type definition to your structure and say use dormo there, 330 00:21:32.680 --> 00:21:36.680 then in underscore build folder you would have a Domo 331 00:21:36.720 --> 00:21:40.440 generated called subfolder where you can see the old source 332 00:21:40.480 --> 00:21:44.559 code that is used to do these run time validations. 333 00:21:44.720 --> 00:21:48.559 So it's yeah, then used as a compilation source or 334 00:21:48.680 --> 00:21:51.279 is it just like for the user's benefit, Well, it's 335 00:21:51.359 --> 00:21:55.440 used as compilation source. The same time, if you change it, 336 00:21:55.440 --> 00:21:59.319 it wouldn't affect anything because it would be overwritten during 337 00:21:59.359 --> 00:22:02.839 the next company, so you can read it, but you 338 00:22:02.920 --> 00:22:09.000 can't affect it much. This add this additional confidence about 339 00:22:09.039 --> 00:22:13.640 what's going on when you call this function validate type 340 00:22:13.680 --> 00:22:18.400 on your structure or constructor function or if you do 341 00:22:18.799 --> 00:22:20.759 a reidate type in ECTO schema. 342 00:22:21.000 --> 00:22:23.400 Okay, I guess the question which for some people might 343 00:22:23.480 --> 00:22:26.039 have like how readable is this code because that code 344 00:22:26.079 --> 00:22:29.839 generation tends to sometimes produce code which is like a 345 00:22:29.839 --> 00:22:33.039 bit not so nice on the ice to say to 346 00:22:33.079 --> 00:22:33.799 phrase it like that. 347 00:22:36.839 --> 00:22:42.359 Yeah, true, there is a four matter run during the 348 00:22:42.359 --> 00:22:48.480 generation of this code, and it's quite readable and quite simple. 349 00:22:48.640 --> 00:22:52.079 So worse, the more fields in your structure you have, 350 00:22:52.200 --> 00:22:56.200 the longer would be the output and the source code file. 351 00:22:57.079 --> 00:22:57.559 Same time. 352 00:22:58.079 --> 00:23:02.720 It's quite straightforward there too, same in functions there that 353 00:23:03.160 --> 00:23:06.599 you just can read and say, okay, here is the validation, 354 00:23:06.799 --> 00:23:09.519 here is the pattern matching. So it's quite simple. 355 00:23:10.359 --> 00:23:13.599 So that means that like domo generates like an additional 356 00:23:13.640 --> 00:23:16.559 module or what which is then used FORUL for type checking. 357 00:23:17.279 --> 00:23:21.519 Yeah, okay, okay, what happens when you use domo at 358 00:23:21.640 --> 00:23:26.359 minimum level? You can just add use domo into your 359 00:23:26.720 --> 00:23:33.640 struct module, right, and then dormo generates a submodule that 360 00:23:33.839 --> 00:23:37.759 is called type ensure. So let's say your module named 361 00:23:37.839 --> 00:23:43.599 car and after DOMA works, you have also in addition 362 00:23:44.319 --> 00:23:49.039 car dot type insure and inside of this type ensure 363 00:23:49.359 --> 00:23:53.599 all validation happened and how it works in regards to 364 00:23:53.720 --> 00:23:57.799 your original car structure. DOMO adds functions to the car 365 00:23:57.880 --> 00:24:02.680 structure as well. It's a new function that is constructor 366 00:24:02.720 --> 00:24:07.799 function for the structure and validate type function that is 367 00:24:07.839 --> 00:24:12.640 for validation of existing instance. So there are also a 368 00:24:12.720 --> 00:24:19.279 couple of other functions like typed fields and required fields 369 00:24:19.759 --> 00:24:23.000 that returns the list of the fields of your structure 370 00:24:23.160 --> 00:24:27.599 that has not new types. Let's say, so that's useful 371 00:24:27.640 --> 00:24:32.960 in actual change that. So the first two new and 372 00:24:33.319 --> 00:24:37.519 validate type functions they just facate for type insure module. 373 00:24:38.400 --> 00:24:42.960 So when you call car dot new and keywould leads 374 00:24:43.079 --> 00:24:47.359 to these fields and values for these fields, the new 375 00:24:47.440 --> 00:24:52.319 function bypasses that after some checks to type insure module 376 00:24:53.039 --> 00:24:57.279 type insure module, do pattern matches validate the all types 377 00:24:57.559 --> 00:25:01.599 of the values is as expected, then run pre condition 378 00:25:01.720 --> 00:25:06.000 functions associated with these types, checking okay the format of 379 00:25:06.079 --> 00:25:09.240 these values is good, all invariants have full field, and 380 00:25:09.319 --> 00:25:13.640 then returns back to the call site so and it 381 00:25:13.759 --> 00:25:20.359 returns the constructor the structure basically, So that's how you 382 00:25:20.400 --> 00:25:22.640 can be sure that at the time of the call, 383 00:25:22.839 --> 00:25:26.839 when you get this structure back, it's valid structure according 384 00:25:26.880 --> 00:25:30.599 to the type and pre conditions defined. Then if you 385 00:25:30.680 --> 00:25:35.559 modify the structure, for example, alter field of the car, 386 00:25:36.319 --> 00:25:40.559 then you can call again the validate type function with 387 00:25:40.720 --> 00:25:44.839 this modified instance, and the validate type function would do 388 00:25:44.920 --> 00:25:48.279 the same trip to the type insurance back, giving you 389 00:25:48.400 --> 00:25:52.519 the answer is it still okay structure matching the type 390 00:25:52.519 --> 00:25:56.119 and preconditions or no, you have this field incorrect because 391 00:25:56.160 --> 00:25:59.799 of this and that. So that's how it works basically. 392 00:26:00.119 --> 00:26:03.359 Okay, And what happened if I, like, have my car 393 00:26:03.920 --> 00:26:07.480 struck and I have said use domo and then instead 394 00:26:07.519 --> 00:26:10.319 of that, I just define a module which it's called 395 00:26:10.440 --> 00:26:13.839 type insure. What would happened then, like, because then I 396 00:26:14.000 --> 00:26:15.359 have a name class. 397 00:26:15.079 --> 00:26:19.079 Right, yeah, sure, the behavior would be the same if 398 00:26:19.759 --> 00:26:24.240 if you define type insure twice. So you can do 399 00:26:24.319 --> 00:26:28.640 this by hand and there are no any you know, 400 00:26:28.799 --> 00:26:32.079 hidden things behind that. It's just simply a generation of 401 00:26:32.119 --> 00:26:36.039