1 00:00:00,500 --> 00:00:03,400 I think a good API and that's why nowadays. 2 00:00:03,800 --> 00:00:07,400 Finally, we all agree that API. First design is the way to go 3 00:00:07,400 --> 00:00:11,400 is, you don't want to expose your internal data models on 4 00:00:11,400 --> 00:00:15,800 your internal logic, too much on your apis, and the more new 5 00:00:15,800 --> 00:00:18,300 clients are not under your control, the less you want to do 6 00:00:18,300 --> 00:00:24,400 that. Hey everyone. 7 00:00:24,900 --> 00:00:26,700 My name is Henry Surya with Robin. 8 00:00:28,400 --> 00:00:31,300 And you're listening to the technology, you know, podcast 9 00:00:31,600 --> 00:00:34,000 the show where I'll be bringing you the greatest technical 10 00:00:34,000 --> 00:00:37,800 leaders practitioners and thought leaders in the industry 11 00:00:38,200 --> 00:00:42,600 to discuss about their Journey ideas and practices that we all 12 00:00:42,600 --> 00:00:46,200 can learn and apply to build a highly performing technical team 13 00:00:46,600 --> 00:00:49,000 and to make an impact in your personal work. 14 00:00:49,400 --> 00:00:57,900 So let's dive into our Journal. Hello, to all of you, my friends 15 00:00:57,900 --> 00:01:01,400 and My listeners, welcome again to the Tecla Journal, podcast, 16 00:01:01,400 --> 00:01:03,700 the show where you can learn about technical leadership and 17 00:01:03,700 --> 00:01:07,100 Excellence from my compositions with great thought, leaders in 18 00:01:07,100 --> 00:01:09,400 the tech industry. If this is your first time 19 00:01:09,400 --> 00:01:12,100 listening to technology, you know, subscribe and follow the 20 00:01:12,100 --> 00:01:16,000 show on your podcast app and on LinkedIn, Twitter and Instagram. 21 00:01:16,400 --> 00:01:19,500 And for those of you longtime listeners, if you find my 22 00:01:19,500 --> 00:01:22,900 podcast helpful and want to show your appreciation and support my 23 00:01:22,900 --> 00:01:25,600 work, you can subscribe as a patron at package. 24 00:01:25,600 --> 00:01:29,300 You know, that death / Patron or by Coffee at technology. 25 00:01:29,300 --> 00:01:31,100 Not deaf /. Tip. 26 00:01:32,000 --> 00:01:34,900 My guest for today's episode is Daniel ljubka. 27 00:01:35,400 --> 00:01:38,900 Daniel is a software, architect and the co-author of patterns 28 00:01:38,900 --> 00:01:43,600 for API design in this episode. Daniel and I discussed some API 29 00:01:43,600 --> 00:01:46,700 design patterns and best practices taken from his book. 30 00:01:47,200 --> 00:01:49,700 Daniel first, shared the importance of understanding the 31 00:01:49,700 --> 00:01:53,300 main requirements for building apis and several API, and 32 00:01:53,300 --> 00:01:56,000 message best practices such as API. 33 00:01:56,000 --> 00:01:59,600 First design, how to design Fine, Loosely coupled message 34 00:01:59,600 --> 00:02:02,300 exchanges. The trade-off between generic 35 00:02:02,300 --> 00:02:06,400 and specialized API operations and the risk of exposing too 36 00:02:06,400 --> 00:02:09,800 much internal data model in logic in our apis. 37 00:02:10,699 --> 00:02:13,700 Daniel also introduced the microservices domain-specific 38 00:02:13,700 --> 00:02:18,400 languages or M DSL as an alternative to open apis, for 39 00:02:18,400 --> 00:02:22,400 specifying apis, independent of the technology implementation 40 00:02:22,900 --> 00:02:25,900 towards the end. Daniel explained the importance 41 00:02:25,900 --> 00:02:29,700 of defining the API life cycle. How to support backward, 42 00:02:29,700 --> 00:02:33,300 compatibility and the different API, versioning strategies, we 43 00:02:33,300 --> 00:02:37,800 can use to evolve our apis. I enjoyed my conversation with 44 00:02:37,800 --> 00:02:41,500 Daniel learning about API design pattern and best practices 45 00:02:41,900 --> 00:02:45,100 specifically on some strategies, we can use to manage API 46 00:02:45,100 --> 00:02:48,900 lifecycle and evolution. If you also enjoy listening to 47 00:02:48,900 --> 00:02:51,300 this episode, please share it with others. 48 00:02:51,300 --> 00:02:54,000 Either your friends, or colleagues, who can also benefit 49 00:02:54,000 --> 00:02:57,200 from listening to this. Also leave this podcast of 5 50 00:02:57,200 --> 00:03:00,500 star rating and review on Apple podcast and Spotify. 51 00:03:00,800 --> 00:03:04,100 It will help me a lot to make this podcast discovered by other 52 00:03:04,100 --> 00:03:07,900 people on the platform before we continue to the conversation 53 00:03:07,900 --> 00:03:11,200 with Daniel, let's hear a few words from our sponsors. 54 00:03:11,800 --> 00:03:14,500 Are you looking for a new cool swag package? 55 00:03:14,500 --> 00:03:17,400 You know now offers you some swags that you can purchase 56 00:03:17,400 --> 00:03:21,900 online these wax are printed on demand based on your preference 57 00:03:22,100 --> 00:03:24,800 and will be delivered safely to you all over the world. 58 00:03:24,800 --> 00:03:28,000 We're shipping is available. Check out all the cool swag. 59 00:03:28,200 --> 00:03:30,000 Available by visiting technology. 60 00:03:30,000 --> 00:03:33,400 No dot f / shop, and don't forget to break yourself. 61 00:03:33,500 --> 00:03:35,600 Once you receive any of those tracks. 62 00:03:38,300 --> 00:03:40,200 Hello everyone. Welcome back to another new 63 00:03:40,200 --> 00:03:43,300 episode of the technology on our podcast today, I have with me a 64 00:03:43,300 --> 00:03:47,200 quarter of one of recently published book title patterns 65 00:03:47,200 --> 00:03:51,200 for API design simplifying integration with Loosely coupled 66 00:03:51,200 --> 00:03:53,500 message exchanges as pretty long. 67 00:03:53,900 --> 00:03:57,600 So, Daniel Luca is here. He's one of the co-authors and 68 00:03:57,600 --> 00:03:59,200 I'm really excited. Excited to talk about this 69 00:03:59,200 --> 00:04:01,500 because building API is something really important, 70 00:04:01,500 --> 00:04:04,400 especially these days and especially we will talk a lot 71 00:04:04,400 --> 00:04:07,100 about the message part of the API. 72 00:04:07,400 --> 00:04:11,900 So, Daniel, welcome to the show. Thanks Henry for having me on 73 00:04:11,900 --> 00:04:13,500 the show. I'm looking forward to 74 00:04:13,700 --> 00:04:16,300 discussing the book, The patterns messages. 75 00:04:17,500 --> 00:04:20,600 So, Daniel in the beginning, I always love to start by asking 76 00:04:20,600 --> 00:04:23,400 you about your career Journey. If you have any highlights or 77 00:04:23,400 --> 00:04:26,000 turning points that you think will be interesting for us to 78 00:04:26,000 --> 00:04:28,000 learn from you. Yeah, sure. 79 00:04:28,200 --> 00:04:31,800 So, I mean, I'm now 43 years old. 80 00:04:31,800 --> 00:04:33,900 So there have been some positions. 81 00:04:33,900 --> 00:04:36,200 I've taken has been actually long journey. 82 00:04:36,200 --> 00:04:39,600 So I started programming when I was in fifth grade. 83 00:04:39,900 --> 00:04:43,700 So rather, Lisa, I got my first computer when I was 12. 84 00:04:43,700 --> 00:04:46,900 I think back in the days, or compared to what we have now are 85 00:04:46,900 --> 00:04:50,300 very lousy Hardware. But nevertheless, start 86 00:04:50,300 --> 00:04:53,400 programming, very early, and even in school band, a team of 87 00:04:53,400 --> 00:04:57,600 five classmates, and we were developing a game which was 88 00:04:57,800 --> 00:05:01,200 released He successfully so you could buy it in the store on a 89 00:05:01,207 --> 00:05:05,300 CD-ROM back in the days and I think there was the first 90 00:05:05,300 --> 00:05:07,900 interesting point in my career because it was what a great 91 00:05:07,900 --> 00:05:11,300 success was still at school. And everyone said you couldn't 92 00:05:11,300 --> 00:05:15,500 do it, but it was then about Team Dynamics was the only 93 00:05:15,500 --> 00:05:18,900 release game because the team fell apart after that, a little 94 00:05:18,900 --> 00:05:22,300 bit because they were different interests and different 95 00:05:22,300 --> 00:05:25,600 recognition of how good everyone is. 96 00:05:26,000 --> 00:05:28,000 So that I think was the first Turning Point. 97 00:05:28,100 --> 00:05:31,200 When I studied in German is Convergence informati can be 98 00:05:31,200 --> 00:05:35,400 translated business informatics, which is a subject which is very 99 00:05:35,400 --> 00:05:38,200 German specific. So it comes close to Information 100 00:05:38,200 --> 00:05:42,300 Systems, I think, but it's more computer science plus economics. 101 00:05:43,000 --> 00:05:46,300 During that time. I also worked in very database 102 00:05:46,300 --> 00:05:51,300 having programming and the trainings and chanted, lots of 103 00:05:51,300 --> 00:05:55,400 computer science, lectures was a very great time actually. 104 00:05:55,700 --> 00:05:58,500 Although one thing I learned there was that, Even though the 105 00:05:58,500 --> 00:06:02,100 company I did the projects and trainings, have a profit margin 106 00:06:02,100 --> 00:06:07,300 of proximity 50%, if you have a bad CEO, can still go bankrupt 107 00:06:07,800 --> 00:06:10,900 you to take care of your cash flow, even on private life. 108 00:06:11,300 --> 00:06:15,500 There was quite a lesson to see I come from Germany, I studied 109 00:06:15,500 --> 00:06:19,200 in Germany, I did my Master's thesis and in Barcelona in 110 00:06:19,200 --> 00:06:21,800 Spain, which was very interesting and then I came back 111 00:06:21,800 --> 00:06:26,600 and did my PhD back in Hanover my hometown, you to science and 112 00:06:26,600 --> 00:06:28,900 the topic was so bizarre. Talking pictures. 113 00:06:28,900 --> 00:06:33,400 So really about, what we nowadays, call Api situation, 114 00:06:34,400 --> 00:06:38,000 choreographies back in the days of receiving some very different 115 00:06:38,000 --> 00:06:40,100 Tech stack. Again, I learned quite a lot 116 00:06:40,100 --> 00:06:43,600 there and then I moved to Switzerland because during my 117 00:06:43,600 --> 00:06:45,600 studies I didn't manage to go abroad. 118 00:06:45,600 --> 00:06:47,000 Okay? And was one semester in 119 00:06:47,000 --> 00:06:50,800 Barcelona or someone to at least but I really wanted to stay in a 120 00:06:50,808 --> 00:06:54,100 different country and originally I wanted to go to England but it 121 00:06:54,200 --> 00:06:57,800 came Switzerland was kind for two years and was eight years 122 00:06:57,800 --> 00:06:59,600 there. Are so obviously, it's been a 123 00:06:59,600 --> 00:07:02,500 great time. Still a great time since I met 124 00:07:02,500 --> 00:07:05,300 my wife. So there I was in large 125 00:07:05,400 --> 00:07:09,000 projects, very heavy on financial industry, obviously in 126 00:07:09,000 --> 00:07:13,100 Switzerland and too much complexity of In-House it 127 00:07:13,100 --> 00:07:17,300 Landscapes. So, the reality shock, which 128 00:07:17,300 --> 00:07:20,200 people get missed out and large organizations. 129 00:07:20,700 --> 00:07:23,500 And as a consultant, it's nice because move between different 130 00:07:23,500 --> 00:07:27,600 organizations, you learn many different ways of Designing 131 00:07:27,600 --> 00:07:29,800 systems. Different architectures. 132 00:07:29,800 --> 00:07:32,900 Different preferences by different teams so that was 133 00:07:32,900 --> 00:07:35,600 great and then I moved back to Germany. 134 00:07:36,000 --> 00:07:38,600 Now I'm the CEO of a small elephant comes. 135 00:07:38,600 --> 00:07:43,400 That accompany myself which also interesting because now you need 136 00:07:43,400 --> 00:07:46,800 to do more coordination of people doing work, you would 137 00:07:46,800 --> 00:07:49,800 like to do, but still I'm interested in the technology, 138 00:07:49,800 --> 00:07:53,000 I'm still working in Project, which is important. 139 00:07:53,000 --> 00:07:57,900 So I think you can only be good in technology and Technology. 140 00:07:58,000 --> 00:08:01,400 Insulting if you still have hands on experience now so that 141 00:08:01,400 --> 00:08:03,400 has been my life in three minutes or. 142 00:08:03,400 --> 00:08:07,300 So it's very interesting that you started to share your story 143 00:08:07,300 --> 00:08:10,800 about trading, computer games, I think it is almost like every 144 00:08:10,800 --> 00:08:14,400 childhood dream to come up with a game and you managed to 145 00:08:14,400 --> 00:08:17,700 publish and sell it in CD-ROMs. I still remember during back 146 00:08:17,700 --> 00:08:21,300 then I used this, get floppy disk but CD-ROM is like the Next 147 00:08:21,300 --> 00:08:23,900 Generation but I think it's still cool to be able to sell 148 00:08:23,900 --> 00:08:26,700 games when you are kid. So thanks for sharing that. 149 00:08:27,100 --> 00:08:28,900 So let's start. Your book. 150 00:08:29,000 --> 00:08:31,700 So you have had a lot of experience in the industry. 151 00:08:31,700 --> 00:08:35,200 You have written thesis work in large financial company. 152 00:08:35,500 --> 00:08:40,100 Why specifically writing an API design book because API has been 153 00:08:40,100 --> 00:08:42,500 around for many years especially when you said about. 154 00:08:42,500 --> 00:08:45,400 So all right SOA and there's so many books already published as 155 00:08:45,400 --> 00:08:47,500 well. So is there anything different 156 00:08:47,500 --> 00:08:51,300 that you try to convey or try to teach us from your book? 157 00:08:52,100 --> 00:08:54,300 Yeah. And definitely thanks so much 158 00:08:54,300 --> 00:08:56,200 story. Behind the book is a little bit 159 00:08:56,200 --> 00:08:57,900 longer. I can't go back some years. 160 00:08:58,000 --> 00:09:00,900 Ears all have to. My money is the first author and 161 00:09:01,100 --> 00:09:03,400 the team leader of the pattern approach. 162 00:09:03,600 --> 00:09:07,200 I knew him for quite some years. We met in Hanover, is 163 00:09:07,300 --> 00:09:10,100 interestingly, born in city near turnover. 164 00:09:10,700 --> 00:09:14,900 We hadn't seen as for a while, and then we met back in Zurich. 165 00:09:15,200 --> 00:09:17,100 He was in Switzerland. I moved to Switzerland. 166 00:09:17,600 --> 00:09:20,100 He became a professor there. And he was thinking about the 167 00:09:20,100 --> 00:09:22,000 case of what's, his line of research. 168 00:09:22,000 --> 00:09:26,600 And he was at IBM before. So also the mix of Consulting 169 00:09:26,600 --> 00:09:30,900 with also doing his Ph.D Why is it a can want to have this idea? 170 00:09:31,000 --> 00:09:34,100 We are building all these Services we have and then back 171 00:09:34,100 --> 00:09:38,300 in the day microservices really the hype a building, all these 172 00:09:38,300 --> 00:09:41,900 enough and need to teach this to and I have corporations who 173 00:09:41,900 --> 00:09:45,400 needs to build a pi. So I want to something to teach. 174 00:09:45,900 --> 00:09:50,300 I at the time was new at a very large scale project where they 175 00:09:50,300 --> 00:09:53,500 are connecting land. Registries Banks notaries and 176 00:09:53,500 --> 00:09:55,600 some other parties across whole Switzerland. 177 00:09:55,900 --> 00:09:58,300 So it's a system, we have like thousands Different 178 00:09:58,300 --> 00:10:02,400 organizations, connected and automating all these business 179 00:10:02,400 --> 00:10:04,800 processes. As you can imagine, there are 180 00:10:04,808 --> 00:10:09,000 many services meaning apis involved for doing vets Bank 181 00:10:09,000 --> 00:10:11,600 places. A request the platform, generate 182 00:10:11,600 --> 00:10:15,300 some documents sent them back to the bank so that they can do to 183 00:10:15,308 --> 00:10:18,700 the sign this. It goes from 1 to 2 and altering 184 00:10:18,700 --> 00:10:21,600 and then two advantages to add whatever you can do that. 185 00:10:22,000 --> 00:10:25,400 There were some people of every new to service design and we had 186 00:10:25,400 --> 00:10:29,700 many discussions about things. I would have thought a basic but 187 00:10:29,700 --> 00:10:33,000 obviously they weren't. So my motivation was more for my 188 00:10:33,000 --> 00:10:36,400 daily work life to just saying, here's a pointer, please read 189 00:10:36,400 --> 00:10:38,600 this there and then we can have this discussion again. 190 00:10:39,100 --> 00:10:40,700 Yeah. So that was essentially how it 191 00:10:40,700 --> 00:10:43,900 started and then other people join Mike mackool to down and 192 00:10:43,900 --> 00:10:47,800 who I can't recall. Now exactly in which order but 193 00:10:47,800 --> 00:10:51,600 quickly became this team of five people who Vince is, are both 194 00:10:51,600 --> 00:10:55,600 very experienced as patent. Office already will have an eye 195 00:10:55,600 --> 00:10:57,800 and mukul as well had some practical. 196 00:10:58,000 --> 00:11:00,400 More practical experience, although Olaf and was a 197 00:11:00,408 --> 00:11:03,000 professor and Merkel, actually, it's not as well. 198 00:11:03,800 --> 00:11:06,600 I'm still in Industry. I think that's the motivation. 199 00:11:06,600 --> 00:11:09,900 And then the question is, how do you teach these things? 200 00:11:10,000 --> 00:11:13,500 So I mean design architecture, always about decisions and 201 00:11:13,500 --> 00:11:17,000 decisions have these nasty aspects of that you get 202 00:11:17,000 --> 00:11:18,200 something, but you lose something. 203 00:11:18,500 --> 00:11:22,500 If you go through the right door, you can't go left or but 204 00:11:22,500 --> 00:11:25,600 sounds easy. But people always assume there's 205 00:11:25,600 --> 00:11:28,500 this perfect solution. You just do some And it's 206 00:11:28,500 --> 00:11:30,200 perfect. And you do this every time 207 00:11:30,200 --> 00:11:33,900 because works all the time, the silver balloting and we all 208 00:11:33,900 --> 00:11:37,200 know, it doesn't work. I think you can feel fresh from 209 00:11:37,200 --> 00:11:40,800 University at least after three years, it doesn't work that way. 210 00:11:41,200 --> 00:11:44,300 And patterns Make That explicit. I think that's so great because 211 00:11:44,300 --> 00:11:47,000 first, you have a name and I think we all talk about names as 212 00:11:47,000 --> 00:11:51,600 well, but you have this section about forces so what are the 213 00:11:51,600 --> 00:11:54,700 influences on your design? And some things are better if 214 00:11:54,700 --> 00:11:56,800 you use of certain pattern and some things are worse. 215 00:11:57,500 --> 00:12:01,200 So, You pay for your decision and patterns make this explicit. 216 00:12:01,200 --> 00:12:04,600 And that's why it's so great as both a teaching tool and also 217 00:12:04,600 --> 00:12:07,800 reference to them. So, even nowadays if I'm and 218 00:12:07,800 --> 00:12:11,900 projects, it's just nice to go through on the pattern list, and 219 00:12:11,900 --> 00:12:15,500 check whether there's something I should have considered, or 220 00:12:15,500 --> 00:12:18,900 not, because it's always busy. When you're doing things, it's 221 00:12:18,900 --> 00:12:22,400 nice to have checklist, I always loved reading pattern books 222 00:12:22,400 --> 00:12:24,700 because it is practical, that's the first thing, right? 223 00:12:24,800 --> 00:12:28,400 And also, it kind of like this down the decisions of the Off 224 00:12:28,400 --> 00:12:31,000 some people say on why you choose a certain pattern. 225 00:12:31,300 --> 00:12:35,000 So for example, if you opt for scalability, then maybe this 226 00:12:35,000 --> 00:12:37,900 pattern might be better, for example microservices, right. 227 00:12:38,000 --> 00:12:40,300 But obviously we know that microservices, not silver. 228 00:12:40,300 --> 00:12:43,400 Bullet in some cases, it might not work as well. 229 00:12:43,600 --> 00:12:45,900 So Fred Brooks have this right up last time. 230 00:12:45,900 --> 00:12:47,900 No Silver Bullet. So I guess it has been 231 00:12:47,900 --> 00:12:49,400 mentioned. Many times in any kind of 232 00:12:49,400 --> 00:12:52,400 architecture kind of discussion. I had in this technological 233 00:12:52,400 --> 00:12:54,600 episode, your subtitle of the book. 234 00:12:54,600 --> 00:12:57,800 Also mentioned specifically about Loosely coupled message. 235 00:12:57,900 --> 00:13:01,300 Exchanges. So tell us more why you choose 236 00:13:01,300 --> 00:13:04,200 specifically Loosely coupled message exchanges as your 237 00:13:04,200 --> 00:13:07,400 subtitle. Well actually the subtitle was 238 00:13:07,400 --> 00:13:12,400 one of the last things we decided and if we look at the 239 00:13:12,400 --> 00:13:15,900 book, what's special about this and closes the gap between high 240 00:13:15,900 --> 00:13:19,000 level books, like Enterprise Integration patterns which are 241 00:13:19,500 --> 00:13:22,200 not high level or very abstract, but they're certainly on a 242 00:13:22,208 --> 00:13:25,200 higher level of abstraction and then you have these books while 243 00:13:25,200 --> 00:13:27,800 technology. So how do I use the restaurant? 244 00:13:28,000 --> 00:13:32,400 Obviously graphql, whatever and what verbs to use and which 245 00:13:32,400 --> 00:13:34,900 circumstances, how do I build good? 246 00:13:34,900 --> 00:13:38,500 You are wise and all these things in between there is 247 00:13:38,500 --> 00:13:40,900 something. So you have a conceptual API 248 00:13:40,900 --> 00:13:42,500 design. Something they decide. 249 00:13:42,500 --> 00:13:46,600 Okay, I need these kinds of operations, I need these quality 250 00:13:46,600 --> 00:13:50,700 attributes, and because of this, I perhaps to pagination a chunk 251 00:13:50,700 --> 00:13:55,000 things and not transfer whole message and that's independent 252 00:13:55,100 --> 00:13:57,800 integration technology, protocols use. 253 00:13:57,900 --> 00:14:01,800 The bike and my first project was a banking system or banking 254 00:14:01,800 --> 00:14:06,900 platform and they use Kaaba on the way was all Kaaba already. 255 00:14:06,900 --> 00:14:10,300 There there were many patterns between still used today and 256 00:14:10,300 --> 00:14:15,600 more rest HTTP API is because it's a really long living and 257 00:14:15,600 --> 00:14:18,500 even now, whatever comes up next, you will have these 258 00:14:18,500 --> 00:14:21,000 problems. And people have these patterns, 259 00:14:21,000 --> 00:14:22,900 hopefully, addressing those problems. 260 00:14:22,900 --> 00:14:27,800 So it's not tied to any specific technology, first of all, so, 261 00:14:28,000 --> 00:14:31,400 You can make your API design on the conceptual level using this 262 00:14:31,400 --> 00:14:34,200 pageant and then shoot your technology. 263 00:14:34,600 --> 00:14:37,800 So that's one aspect. The patient's themselves are not 264 00:14:37,800 --> 00:14:41,300 coupled to any technology themselves, but obviously, it's 265 00:14:41,300 --> 00:14:45,300 probably more about the coupling between API clients and API 266 00:14:45,300 --> 00:14:48,400 providers. I think a good API and why, 267 00:14:48,400 --> 00:14:51,900 nowadays? Finally, we all agree that API. 268 00:14:51,900 --> 00:14:55,000 First design is the way to go is, you don't want to expose 269 00:14:55,000 --> 00:14:57,800 your internal data models on your end. 270 00:14:57,900 --> 00:15:02,300 Internal logic too much on your apis and the more your clients 271 00:15:02,300 --> 00:15:04,700 are not under your control, the less you want to do that. 272 00:15:05,300 --> 00:15:08,900 I think most patterns here will allow you to deal with this 273 00:15:08,900 --> 00:15:12,600 problem. So, how do I build apis, which? 274 00:15:12,900 --> 00:15:16,200 Well, if I do them by the pattern book, so to say, 275 00:15:16,200 --> 00:15:18,900 although it's not your goal shouldn't be to use as many 276 00:15:18,900 --> 00:15:23,300 pageants, but if you just follow these forces and things, then 277 00:15:23,300 --> 00:15:27,400 you will hopefully have a design which allows you to have these 278 00:15:27,400 --> 00:15:29,300 skills. Because Exchanges which are not 279 00:15:29,300 --> 00:15:31,300 dependent on the internal models. 280 00:15:32,200 --> 00:15:35,900 So you mentioned something API. First design, I think this is 281 00:15:35,900 --> 00:15:39,000 mentioned, many times in fact, I think I have one episode James 282 00:15:39,000 --> 00:15:41,400 higginbottom. Also talking about that and in 283 00:15:41,400 --> 00:15:44,700 the book you also mentioned a couple more good practices for 284 00:15:44,700 --> 00:15:47,400 API design. So I think these days almost all 285 00:15:47,400 --> 00:15:50,900 back end developers will create a pi especially rest API or 286 00:15:50,900 --> 00:15:55,200 maybe gr b, c or graphql. Are there any other things that 287 00:15:55,200 --> 00:15:57,800 you would advocate for all these engineers? 288 00:15:57,900 --> 00:15:59,900 What kind of good practices they should do? 289 00:15:59,900 --> 00:16:03,500 Or they should consider when building a pi or first of all 290 00:16:03,500 --> 00:16:05,900 you should think about how to express line. 291 00:16:06,200 --> 00:16:09,000 If you start with any software developments, just not only 292 00:16:09,000 --> 00:16:12,000 apis, but it's in general. You need to understand you two 293 00:16:12,000 --> 00:16:17,000 main thing, that's important. The problem with API is let's go 294 00:16:17,000 --> 00:16:20,800 back to this project. You have a team of people who, 295 00:16:21,000 --> 00:16:23,600 if you want to build a good solution or very good solution. 296 00:16:23,600 --> 00:16:26,100 Need to understand what the banks are doing with no to 297 00:16:26,100 --> 00:16:30,800 recent doing what land registry. Join the interesting part is the 298 00:16:30,800 --> 00:16:33,900 last couple of hundred years. I mean, this domain is very old 299 00:16:33,900 --> 00:16:36,500 houses and government management of houses. 300 00:16:36,500 --> 00:16:39,300 Have a long time to land registry is around like forever. 301 00:16:39,700 --> 00:16:44,900 And banks are very old concept and notaries I think as well and 302 00:16:44,900 --> 00:16:48,300 over these couple of hundred years, these three parties still 303 00:16:48,300 --> 00:16:50,000 haven't learned what they are doing. 304 00:16:50,500 --> 00:16:54,700 So that was very interesting, but bank doesn't know data model 305 00:16:54,700 --> 00:16:57,700 of Lent register, which is very interesting. 306 00:16:57,900 --> 00:17:01,400 It's surprising. So if you want to build apis for 307 00:17:01,400 --> 00:17:05,200 domain or for clients where you don't know exactly their 308 00:17:05,200 --> 00:17:08,700 requirements, it's the first thing we need to reach out to 309 00:17:08,700 --> 00:17:11,500 clarify this and that's easier said than done. 310 00:17:11,900 --> 00:17:13,500 There are a couple of approaches soon. 311 00:17:13,500 --> 00:17:16,099 First of all, you're doing workshops following first API 312 00:17:16,099 --> 00:17:20,200 version releases, try to evolve it but then you need to deal 313 00:17:20,200 --> 00:17:23,599 with life cycle issues. So one part of this Loosely 314 00:17:23,599 --> 00:17:26,800 coupled is also you need to decouple the life cycle of your 315 00:17:26,800 --> 00:17:30,400 client and your Because you won't deploy a new version, 316 00:17:30,400 --> 00:17:33,100 similar tenuously. So he will have points in time, 317 00:17:33,100 --> 00:17:35,600 many points in time where they're different versions. 318 00:17:35,600 --> 00:17:39,600 So kind normally supports an older version and the provider 319 00:17:39,600 --> 00:17:42,600 role to new API version, which should be Backward Compatible. 320 00:17:42,600 --> 00:17:46,100 So client, doesn't break. So let's kind of the ideal 321 00:17:46,100 --> 00:17:50,100 scenario while many people say okay, just built backwards, 322 00:17:50,100 --> 00:17:53,900 compatible apis. Yeah but it's not always 323 00:17:53,900 --> 00:17:56,300 possible. Sometimes you have breaking 324 00:17:56,300 --> 00:17:59,700 changes if You say okay, I don't know my clients. 325 00:17:59,700 --> 00:18:01,800 Well enough. I want to iterate and I want to 326 00:18:01,800 --> 00:18:05,100 improve things. It's more likely that you will 327 00:18:05,100 --> 00:18:09,300 have breaking changes. For instance, Banks usually had 328 00:18:09,400 --> 00:18:12,900 one to many relationships where the land registry internally 329 00:18:12,900 --> 00:18:16,000 managed has many to many relationship these kinds of 330 00:18:16,000 --> 00:18:18,000 things. If you know them later on. 331 00:18:18,000 --> 00:18:21,700 So you have your API Define with one too many and now you need to 332 00:18:21,700 --> 00:18:25,500 support many-to-many, likely going to be a breaking change. 333 00:18:25,900 --> 00:18:27,700 Also, in your environment, that might be breaking. 334 00:18:27,900 --> 00:18:29,200 Changes. So Europe. 335 00:18:29,200 --> 00:18:32,600 We have the Euro as its currency which before were multiple 336 00:18:32,600 --> 00:18:36,200 National currencies and if you had online banking back then to 337 00:18:36,200 --> 00:18:38,600 money transfer, there's no way of doing that. 338 00:18:38,600 --> 00:18:42,300 Now, I also was a breaking change that there's a Euro. 339 00:18:42,300 --> 00:18:45,700 I'm not on this local currencies, the same goes for 340 00:18:45,700 --> 00:18:49,500 count numbers, only have been local national account numbers 341 00:18:49,500 --> 00:18:52,800 and now we have the islands and international banking account 342 00:18:52,800 --> 00:18:55,200 number. So there will be changes new 343 00:18:55,200 --> 00:18:59,000 environment, which will break. Can't do anything and there will 344 00:18:59,000 --> 00:19:02,200 be changes where you learn your domain better and where you can 345 00:19:02,300 --> 00:19:05,200 say, okay, in theory I should have known this already but you 346 00:19:05,200 --> 00:19:09,000 didn't the more you train to get to requirements and more, you 347 00:19:09,000 --> 00:19:10,700 need to think about your life cycle. 348 00:19:11,300 --> 00:19:13,300 Some patterns, we have there is, for example, we have an 349 00:19:13,300 --> 00:19:16,800 experimental preview pattern. So you say, okay, let's say we 350 00:19:16,800 --> 00:19:20,100 roll this out and count, the I don't give you any guarantees, 351 00:19:20,300 --> 00:19:22,800 you can check this out, you can give us feedback, but it will 352 00:19:22,800 --> 00:19:26,900 break without us telling you. So that's not nice for the 353 00:19:26,900 --> 00:19:29,800 client. Declined also has some benefits 354 00:19:29,800 --> 00:19:33,800 because you get a preview. So better version where they can 355 00:19:33,800 --> 00:19:38,600 use the API preview, it use it, give feedback and perhaps 356 00:19:38,600 --> 00:19:42,000 hopefully getting a better IPI down the road due to this 357 00:19:42,000 --> 00:19:44,500 feedback, even if it has breaking changes. 358 00:19:45,100 --> 00:19:47,800 And obviously some organizations are some developers will say, 359 00:19:47,800 --> 00:19:51,300 okay, no under these circumstances having only an 360 00:19:51,300 --> 00:19:54,400 experiment to preview, I don't integrate, I don't use this API 361 00:19:54,400 --> 00:19:56,100 which is fair because it's known. 362 00:19:56,400 --> 00:19:58,100 What's unfair is. If you say Say okay. 363 00:19:58,100 --> 00:20:02,000 Here's an API and then you just say, I don't support it anymore, 364 00:20:02,000 --> 00:20:05,800 I break it in some way or another so being clear about 365 00:20:05,800 --> 00:20:09,000 your Evolution process, I think that's important so I have your 366 00:20:09,000 --> 00:20:12,900 own requirements, know how could you know them and then plan 367 00:20:12,900 --> 00:20:15,000 ahead because in the beginning you can. 368 00:20:15,400 --> 00:20:18,700 So if you just had a guarantee like we support this for three 369 00:20:18,700 --> 00:20:21,800 years and then you just try to alter this later on. 370 00:20:21,800 --> 00:20:24,000 People just come to your office and pick. 371 00:20:24,000 --> 00:20:27,300 You probably these are decisions, which you need to do, 372 00:20:27,400 --> 00:20:30,800 as a As possible. And then obviously, you need to 373 00:20:30,800 --> 00:20:34,000 flush out all the domain knowledge in your API payloads. 374 00:20:34,800 --> 00:20:37,100 So yeah, it's always wise to start with the domain 375 00:20:37,100 --> 00:20:40,500 understanding first and in fact, things like DDD or domain driven 376 00:20:40,500 --> 00:20:42,900 design, is also something that Advocates you to actually 377 00:20:42,900 --> 00:20:45,700 understand the problem. First, rather than coming up 378 00:20:45,700 --> 00:20:48,400 with just the technology of the solutions people. 379 00:20:48,400 --> 00:20:49,900 These days whenever they build API. 380 00:20:49,900 --> 00:20:52,400 The first question that they have in mind is definitely which 381 00:20:52,400 --> 00:20:57,300 technology that HTTP rest job, PC graphql and things like that. 382 00:20:57,500 --> 00:20:59,300 But Actually specifically in your book. 383 00:20:59,300 --> 00:21:01,500 You also cover the other important parts, which is the 384 00:21:01,500 --> 00:21:04,100 payload itself. You mentioned the messages may 385 00:21:04,100 --> 00:21:07,500 be for us Engineers here. Can you give an overview? 386 00:21:07,500 --> 00:21:10,700 What aspects that we should consider from the messages point 387 00:21:10,700 --> 00:21:12,600 of view? The payload point of view in 388 00:21:12,600 --> 00:21:15,100 order for us to design our API better? 389 00:21:16,000 --> 00:21:20,900 Well, I think the most important part is how many requests to you 390 00:21:20,900 --> 00:21:24,300 have and how large your message payload is. 391 00:21:24,700 --> 00:21:28,400 So, if we look at that, obviously, you could make An API 392 00:21:28,400 --> 00:21:30,900 operation, which might be an HTTP resource. 393 00:21:31,200 --> 00:21:35,200 When you say get me on, give me our customers and then you get 394 00:21:35,200 --> 00:21:37,400 back our customers and everyone's happy. 395 00:21:37,400 --> 00:21:40,600 You can do with the data whenever you like this approach. 396 00:21:40,600 --> 00:21:44,600 Obviously has some drawbacks so much load on the API provider 397 00:21:44,600 --> 00:21:47,300 because needs to fetch all these customer. 398 00:21:47,900 --> 00:21:51,100 If much load on the network gives you need to transmit all 399 00:21:51,100 --> 00:21:54,300 these customers. So we don't do this design. 400 00:21:54,500 --> 00:21:57,600 What we usually do is get a certain customer or search for 401 00:21:57,800 --> 00:22:00,900 customers - let everything we need to consider. 402 00:22:01,400 --> 00:22:03,800 No usually not. So if we look at the search even 403 00:22:03,800 --> 00:22:06,300 a search might return to many records. 404 00:22:06,500 --> 00:22:09,200 That depends a little bit on your domain on how many objects 405 00:22:09,200 --> 00:22:10,900 you have one domain objects. You have. 406 00:22:11,300 --> 00:22:13,400 So if we have a service which would return a list of 407 00:22:13,400 --> 00:22:15,400 currencies, we know how many they are harmed. 408 00:22:15,400 --> 00:22:18,900 It's quite manageable. If we are fetching customers 409 00:22:18,900 --> 00:22:23,300 from any large organization, Apple Microsoft on the whole 410 00:22:23,300 --> 00:22:26,600 Salesforce data base, whatever you like, let's too much. 411 00:22:26,700 --> 00:22:29,800 So we need to have some Isms if we are running into this 412 00:22:29,800 --> 00:22:33,500 problem, to limit our spawn sizes so you can either say okay 413 00:22:33,500 --> 00:22:35,800 I only returned the first 100 hits. 414 00:22:35,800 --> 00:22:40,200 I am might be a good strategy we could have pagination so I give 415 00:22:40,200 --> 00:22:42,800 you the first hundred and isn't sufficient. 416 00:22:42,800 --> 00:22:46,500 You can carry the next Sunday. We could also say, Okay, perhaps 417 00:22:46,500 --> 00:22:49,900 you need, not all customers, but very own sessions in the 418 00:22:49,900 --> 00:22:53,000 conference and that's a very huge conference. 419 00:22:53,200 --> 00:22:56,100 Like six hundred sessions to each session. 420 00:22:56,100 --> 00:22:58,500 You have some information like Like the title. 421 00:22:58,500 --> 00:23:01,700 Okay, just a string. Who's giving the presentation, 422 00:23:01,700 --> 00:23:04,900 like just a string, the image of the present. 423 00:23:05,000 --> 00:23:08,100 So, that's obviously some large payload part. 424 00:23:08,400 --> 00:23:12,200 When I put this in my message, it depends on the use case but 425 00:23:12,200 --> 00:23:15,100 most likely not. I would just put a link to this 426 00:23:15,100 --> 00:23:18,500 image and whenever the client probably pops into the detail 427 00:23:18,500 --> 00:23:21,500 view, then it can attach this data is required. 428 00:23:22,100 --> 00:23:25,700 So we have these decision on whether we need to include data 429 00:23:25,700 --> 00:23:29,000 or whatever your reference data. Pending on your use case, you'll 430 00:23:29,000 --> 00:23:32,200 often have things which you don't need coming back to the 431 00:23:32,200 --> 00:23:35,000 Spurs line. Registries yeah, hundreds of 432 00:23:35,000 --> 00:23:38,200 years of historical data. And for most use cases, you 433 00:23:38,200 --> 00:23:42,900 don't need historical data as so, it makes sense and one way 434 00:23:42,900 --> 00:23:46,100 or another, and there are multiple options address, what 435 00:23:46,100 --> 00:23:49,800 data the client needs and do many operations you could do 436 00:23:49,800 --> 00:23:53,200 some parameters, which there's a pattern called wish list. 437 00:23:53,200 --> 00:23:56,900 So I say, I want this in storage data or not, so such as a 438 00:23:56,900 --> 00:23:59,500 Boolean flag. And if you said it, you just get 439 00:23:59,500 --> 00:24:02,100 back, 20 times. The data like would have, if you 440 00:24:02,100 --> 00:24:05,800 have known historical data and if it gets more complex, then 441 00:24:05,800 --> 00:24:08,400 you might have not only wish list but it was template where 442 00:24:08,400 --> 00:24:12,300 you can Define in your whole data structure and all the 443 00:24:12,300 --> 00:24:15,300 nested things, what data you want to have or not which 444 00:24:15,300 --> 00:24:20,000 thanklessly or easily gets you to graphql all purposes. 445 00:24:20,000 --> 00:24:24,300 Just to specify a request with exactly the data you need and so 446 00:24:24,300 --> 00:24:27,600 then many things you can do to adjust or trade off. 447 00:24:27,900 --> 00:24:32,300 The number of requests and requests eyes on the response 448 00:24:32,300 --> 00:24:36,000 size especially and I think that's the point where we need 449 00:24:36,000 --> 00:24:39,300 to make more conscious decisions on average. 450 00:24:39,300 --> 00:24:43,000 I think most people just dumped on everything which they have 451 00:24:43,100 --> 00:24:46,400 and then it is certain point they just see, okay, well it 452 00:24:46,400 --> 00:24:50,300 doesn't scale, the database load gets too heavy and things are 453 00:24:50,300 --> 00:24:54,400 getting so slow, definitely creating an API and designing 454 00:24:54,400 --> 00:24:55,900 it. Well, the first point that you 455 00:24:55,900 --> 00:24:59,300 mentioned is about data size. The payload size, do you return 456 00:24:59,300 --> 00:25:01,300 everything? Or do you include the large 457 00:25:01,300 --> 00:25:03,200 payload? As part of their first response, 458 00:25:03,500 --> 00:25:06,400 I think that's always tricky. The other trade-offs that I 459 00:25:06,400 --> 00:25:10,200 normally see in day-to-day experiences that some people 460 00:25:10,200 --> 00:25:13,400 don't know whether they should create specialized API, you 461 00:25:13,400 --> 00:25:16,000 know, things that work for certain use cases only or for 462 00:25:16,000 --> 00:25:18,800 certain customers only, or they should create something more 463 00:25:18,800 --> 00:25:21,100 generic API. So, is there any kind of 464 00:25:21,100 --> 00:25:23,800 consideration that you would do to decide such thing? 465 00:25:25,500 --> 00:25:27,600 And when I do, it's has to interface segregation. 466 00:25:27,800 --> 00:25:31,600 Principal and it's hard. I mean if you look at graphql 467 00:25:32,200 --> 00:25:36,300 one extreme answer obviously. So just tells you I have a very 468 00:25:36,300 --> 00:25:40,900 generic API and u.s. client can specify what I returned and 469 00:25:40,900 --> 00:25:44,400 that's nice and sense because the client just fetches the data 470 00:25:44,400 --> 00:25:48,200 it needs can specify. But on the other hand it's kind 471 00:25:48,200 --> 00:25:52,200 of really key thing. Is you as a provider, you can't 472 00:25:52,200 --> 00:25:56,700 optimize for certain operations. So if you don't have an index on 473 00:25:56,700 --> 00:26:00,100 certain database, Columns graphical request might be 474 00:26:00,300 --> 00:26:04,400 painfully slow and you cannot anticipate it on the other side. 475 00:26:04,400 --> 00:26:08,600 If you have many specialized operations you can very well 476 00:26:08,600 --> 00:26:12,600 optimize your database access patterns for those or caching 477 00:26:12,600 --> 00:26:15,500 strategies and all things. So you can better optimize but 478 00:26:15,500 --> 00:26:17,900 obviously you have much more complexity different kind of 479 00:26:17,900 --> 00:26:21,400 complexity one is you need to implement a management different 480 00:26:21,400 --> 00:26:25,400 operations and on the other hand, you need to implement and 481 00:26:25,400 --> 00:26:28,500 deal with complexity of graphical and the Imitation 482 00:26:28,600 --> 00:26:31,900 behind this. So, again, this seems to be some 483 00:26:31,900 --> 00:26:35,000 Middle Ground. What I would recommend is to 484 00:26:35,000 --> 00:26:38,500 look at what use cases, you have in general, which anticipate. 485 00:26:39,300 --> 00:26:43,300 And then to check, whether there is a certain amount of like 23 486 00:26:43,300 --> 00:26:45,900 operations which would more or less cover these. 487 00:26:45,900 --> 00:26:50,800 Well, but you have to have like 20 different ones, then you 488 00:26:50,900 --> 00:26:53,800 probably should move on to graphql blowing something 489 00:26:53,800 --> 00:26:56,500 similar. And if you have just only one, 490 00:26:56,500 --> 00:26:59,200 then it's fine. As a rule of thumb, I would 491 00:26:59,200 --> 00:27:03,000 probably just after having three different specialized operation. 492 00:27:03,000 --> 00:27:06,700 I would rather check whether it's an approach, where it leads 493 00:27:06,700 --> 00:27:09,500 me down the rabbit hole of having 20 in specialized 494 00:27:09,500 --> 00:27:12,600 operations in the future, but it really depends on the system. 495 00:27:13,800 --> 00:27:16,100 All right, thanks for sharing that because, yeah, definitely. 496 00:27:16,100 --> 00:27:19,100 It is based on the context that we have, but it's one of the 497 00:27:19,100 --> 00:27:22,300 struggle that we have. Another one that is struggle is 498 00:27:22,300 --> 00:27:25,900 actually to expose how much from our internal you mentioned 499 00:27:25,900 --> 00:27:29,000 earlier in our conversation. That We should be conscious not 500 00:27:29,000 --> 00:27:32,200 to expose too much of the internal representation of our 501 00:27:32,200 --> 00:27:34,500 data model, for example, database schema. 502 00:27:35,000 --> 00:27:39,400 So how can we come up with a better exposure of our domain 503 00:27:39,400 --> 00:27:42,300 model as part of the API request and response. 504 00:27:42,500 --> 00:27:45,300 So maybe a little bit of advice here as well because I can see 505 00:27:45,300 --> 00:27:48,700 so many pitfalls people have gone into simply because they 506 00:27:48,700 --> 00:27:51,500 decide exposing data model unnecessarily. 507 00:27:51,500 --> 00:27:52,900 So maybe a little bit advice here. 508 00:27:52,900 --> 00:27:55,800 Daniel. Well, I think really it's what 509 00:27:55,800 --> 00:27:59,300 you would call a pi first nowadays or put it differently. 510 00:27:59,300 --> 00:28:03,700 Should have a separate API interface, whether it's open API 511 00:28:03,700 --> 00:28:05,900 or something else. Well, in the end doesn't matter, 512 00:28:06,200 --> 00:28:09,000 but you should do that. You should work on this 513 00:28:09,000 --> 00:28:12,200 interface without working in parallel on your count. 514 00:28:12,500 --> 00:28:14,700 I think it's one of the pragmatic things because if 515 00:28:14,700 --> 00:28:17,700 you're just working on your code and you have just pulled your 516 00:28:17,700 --> 00:28:20,900 database tables and you're building on your persistence 517 00:28:20,900 --> 00:28:24,900 land on these things, then your mind is Thinking in all these 518 00:28:24,900 --> 00:28:29,700 data structures well you need to be in very good developer to 519 00:28:29,900 --> 00:28:33,600 then switch over and say okay my API I want to have a more 520 00:28:33,600 --> 00:28:36,700 conceptual view so it's much easier if your brain is working 521 00:28:36,700 --> 00:28:39,900 in the conceptual mode, when you're doing your duty design, 522 00:28:40,300 --> 00:28:44,300 new more involve counseling requirements discussions and the 523 00:28:44,300 --> 00:28:48,300 state of mind, it's much easier to build an API, which doesn't 524 00:28:48,300 --> 00:28:52,000 leak your technical information. And I think that's very simple 525 00:28:52,000 --> 00:28:54,900 trick, but it works. And you my experience. 526 00:28:56,000 --> 00:28:57,800 Yeah, I feel. It's a very good advice because 527 00:28:57,800 --> 00:29:00,900 I can still remember those days when I used to code a lot. 528 00:29:01,100 --> 00:29:03,900 So every time as a developer, if we start from the code, 529 00:29:03,900 --> 00:29:07,700 definitely it's very hard to still think about good API 530 00:29:07,700 --> 00:29:10,300 design practices. Right because normally of course 531 00:29:10,300 --> 00:29:14,200 we always start with the data. We create a schema and easily or 532 00:29:14,200 --> 00:29:17,200 can just expose everything up to the API layers. 533 00:29:17,600 --> 00:29:19,600 So I think this is definitely not a good practice. 534 00:29:19,600 --> 00:29:22,600 So what you are saying API first definitely makes sense. 535 00:29:23,800 --> 00:29:27,000 Well it should. And that's also a thing State of 536 00:29:27,000 --> 00:29:29,700 Mind thing you should and it goes hand and hand. 537 00:29:29,700 --> 00:29:32,800 You should think from a client perspective and that's also 538 00:29:32,800 --> 00:29:35,400 something, which developers often do is you're building your 539 00:29:35,400 --> 00:29:37,300 back-end code. You're just putting an API on 540 00:29:37,300 --> 00:29:41,500 top and you're doing what's easy for you because you have the 541 00:29:41,500 --> 00:29:45,300 service class there or this repository is already there. 542 00:29:45,300 --> 00:29:47,900 And you don't think about whether those operations placed 543 00:29:47,900 --> 00:29:52,600 in a logical sensible place or whether the data structures with 544 00:29:52,600 --> 00:29:54,300 emoji. You need to have here or whether 545 00:29:54,300 --> 00:29:55,900 the interaction from the client side. 546 00:29:55,900 --> 00:29:59,300 Makes sense or client needs to know too much. 547 00:29:59,600 --> 00:30:03,000 I think if you look from more formal requirements or gt 548 00:30:03,000 --> 00:30:06,000 perspective, those three resembles looking from the 549 00:30:06,000 --> 00:30:09,400 client perspective and that's also state of mind. 550 00:30:09,500 --> 00:30:13,000 So again in your provider implementation, probably think 551 00:30:13,000 --> 00:30:15,800 about what you have there, what's easy for you but what you 552 00:30:15,800 --> 00:30:18,300 should really think about it. What's easy for the client 553 00:30:18,300 --> 00:30:21,000 because in the normal case you have like hundreds of your 554 00:30:21,000 --> 00:30:24,400 successful thousands of clients And only one providers. 555 00:30:24,400 --> 00:30:27,900 You should optimize the development of clients and lot 556 00:30:27,900 --> 00:30:30,800 of yourself. I think that's really good 557 00:30:30,800 --> 00:30:33,200 advice. So always think from that API 558 00:30:33,200 --> 00:30:35,600 clients point of view not as a provider, right? 559 00:30:35,800 --> 00:30:39,100 So thanks for reminding that I also notice in your book that 560 00:30:39,100 --> 00:30:41,800 you came up with this thing called, microservice 561 00:30:41,800 --> 00:30:45,000 domain-specific language. Maybe you can elaborate a little 562 00:30:45,000 --> 00:30:47,800 bit more. What is this DSL, specifically 563 00:30:48,000 --> 00:30:50,600 and why do you create it? What kind of problems that it 564 00:30:50,600 --> 00:30:54,400 tries to solve? Well essentially, you should do 565 00:30:54,400 --> 00:30:57,500 a podcast with Olaf about that because it's his baby. 566 00:30:58,300 --> 00:31:01,100 Probably I might be wrong. So, that's my trick knee in some 567 00:31:01,100 --> 00:31:04,500 blog posts or so, but I think there were two motivations for 568 00:31:04,500 --> 00:31:07,400 him. The first one is to have or to 569 00:31:07,400 --> 00:31:10,500 make patterns explicit in your API contract. 570 00:31:11,000 --> 00:31:14,200 So a pattern language, if we go back to this gang of four book 571 00:31:14,200 --> 00:31:17,400 that's probably one of the most successful books and 572 00:31:17,400 --> 00:31:20,400 programming. Not because people nowadays by 573 00:31:20,400 --> 00:31:22,900 these books because they do Don't anymore, I think. 574 00:31:23,200 --> 00:31:27,200 But because the language is now deeply embedded into all of our 575 00:31:27,200 --> 00:31:30,500 programming, languages and Frameworks and things. 576 00:31:30,900 --> 00:31:34,800 And so that's why they're successful as a language and 577 00:31:34,900 --> 00:31:39,000 these names convey while whole Design Concepts in single name. 578 00:31:39,500 --> 00:31:41,700 So if we have Observer or listener, we know. 579 00:31:41,700 --> 00:31:44,000 Okay. Let's that and probably if we 580 00:31:44,000 --> 00:31:46,700 now talk about Pitch Nation, people know, okay. 581 00:31:47,000 --> 00:31:49,300 I have an idea of what this means. 582 00:31:49,400 --> 00:31:51,600 And so one motivation was to entertain. 583 00:31:51,900 --> 00:31:56,300 Apis in the contract with okay. Yeah, I use pagination and 584 00:31:56,300 --> 00:31:59,800 that's a public API and we require an API key just as 585 00:31:59,800 --> 00:32:04,200 keyword of this interface language, the other motivation 586 00:32:04,300 --> 00:32:08,500 was to specify an API more independently of the technology. 587 00:32:08,700 --> 00:32:12,700 So from MDS Elna generators which will generate open API and 588 00:32:12,700 --> 00:32:15,200 they're also bindings for soap services and things. 589 00:32:15,200 --> 00:32:17,300 So it's independent of the technology. 590 00:32:17,900 --> 00:32:20,000 I think. Probably all of my dick and 591 00:32:20,000 --> 00:32:21,600 correct me. It's much more concise. 592 00:32:21,700 --> 00:32:25,100 Less than let's say open API. Because if you look at open API 593 00:32:25,100 --> 00:32:28,600 is really, there are many, many lines you need to express things 594 00:32:28,600 --> 00:32:31,000 because every attribute goes into a new line. 595 00:32:31,700 --> 00:32:34,900 So, you have your data time, has a name, you know, it has some 596 00:32:34,900 --> 00:32:37,800 occurrences new line and test type new line. 597 00:32:37,900 --> 00:32:39,900 So, these cars are getting their long. 598 00:32:40,600 --> 00:32:43,700 Interestingly, XML, schema was much more concise in terms of 599 00:32:43,700 --> 00:32:45,900 line numbers. I mean, both formats are 600 00:32:45,900 --> 00:32:49,300 probably shouldn't change in a text editor but you something we 601 00:32:49,500 --> 00:32:51,600 can deal with these formats but line one. 602 00:32:51,800 --> 00:32:55,400 XML schema was much more Compact and yes, L it has the least 603 00:32:55,400 --> 00:32:58,500 compactness, it's not XML, it's not Jason, it's more or less 604 00:32:58,500 --> 00:33:01,200 human readable language which is very compact. 605 00:33:01,200 --> 00:33:04,100 Very can also insert all these pageants and they can then 606 00:33:04,100 --> 00:33:07,500 generate code and your API interfaces. 607 00:33:07,900 --> 00:33:11,500 And for the book it was nice because if we print it open API 608 00:33:12,100 --> 00:33:14,300 just have probably 500 pages more. 609 00:33:15,000 --> 00:33:18,500 Thanks for giving a summary of that, I'm sure if we get 610 00:33:18,500 --> 00:33:21,500 confused with the MDS L, I will have a special episode. 611 00:33:21,700 --> 00:33:24,700 To discuss about this. So that didn't I want to go 612 00:33:24,700 --> 00:33:27,200 through to the last section of API design patterns? 613 00:33:27,200 --> 00:33:29,000 Do you have any favorites that you want to cover? 614 00:33:30,000 --> 00:33:32,500 Firstly, I will still very involved in the evolution 615 00:33:32,500 --> 00:33:36,300 section as we can assume please General remarks there because I 616 00:33:36,308 --> 00:33:39,100 think it's a section which is a little bit special and because 617 00:33:39,100 --> 00:33:41,800 all other patterns are very involved in the message, 618 00:33:41,800 --> 00:33:46,100 contents itself and evolution is a bit more out of the message. 619 00:33:46,700 --> 00:33:50,600 And I also have seen this many times at some companies, back in 620 00:33:50,600 --> 00:33:53,800 the day, they said, Account was done, our service oriented 621 00:33:53,800 --> 00:33:56,800 architecture and the only thing missing is all versioning 622 00:33:56,800 --> 00:34:00,000 scheme. First of all, versioning isn't 623 00:34:00,000 --> 00:34:01,800 the important part in that sense? 624 00:34:02,500 --> 00:34:06,100 So let's just buy product, what you haven't considered as your 625 00:34:06,100 --> 00:34:09,000 life cycle strategy? And that's probably one of the 626 00:34:09,000 --> 00:34:10,500 most important parts you have thought. 627 00:34:10,500 --> 00:34:14,300 Of first, people are always good at bringing new apis and 628 00:34:14,300 --> 00:34:18,400 services into the landscape, but they are very bad on getting 629 00:34:18,400 --> 00:34:21,500 them out of the landscape. So, decommissioning apis. 630 00:34:21,699 --> 00:34:25,000 Or changing apis and managing the clients and the impact to 631 00:34:25,000 --> 00:34:27,300 the clients. So there was quite interesting 632 00:34:27,300 --> 00:34:29,000 that a large insurance companies that are. 633 00:34:29,000 --> 00:34:31,500 And while we are more or less done with that, we haven't 634 00:34:31,500 --> 00:34:34,600 thought about the life cycle. Yeah, well, go back to square 635 00:34:34,600 --> 00:34:36,199 one. And that's why I'm thinking 636 00:34:36,199 --> 00:34:38,300 Belushi is important. And there are not that many 637 00:34:38,300 --> 00:34:41,500 things, you can consider, essentially, I have a question 638 00:34:41,500 --> 00:34:46,300 of how Backward Compatible, do you want to stay, which involves 639 00:34:46,500 --> 00:34:50,400 certain costs from you as a provider, which might make the 640 00:34:50,400 --> 00:34:52,300 API dirty? The time. 641 00:34:52,699 --> 00:34:55,500 So, we refactor our source code on the time to make the 642 00:34:55,500 --> 00:34:57,400 structure better to make names better. 643 00:34:57,800 --> 00:35:01,200 Stay in backwards compatible means that I can't reflector 644 00:35:01,200 --> 00:35:03,800 many aspects of my API, because it would break. 645 00:35:04,500 --> 00:35:08,400 So many people just price in there for instance, or some 646 00:35:08,400 --> 00:35:11,700 attribute names without the unit that works. 647 00:35:11,700 --> 00:35:14,600 If you don't have a single unit, like what's your length, 648 00:35:14,800 --> 00:35:18,400 somewhere in the comment you see it's lengthen meters meters or 649 00:35:18,400 --> 00:35:21,500 feet price usually means the price and the car. 650 00:35:21,600 --> 00:35:25,200 And see the main currency of your organization and that 651 00:35:25,200 --> 00:35:27,700 works. Well unless you have the 652 00:35:27,700 --> 00:35:31,400 software going internationally. So then you need to change that 653 00:35:31,800 --> 00:35:34,300 and then you cannot simply add a currency field. 654 00:35:34,300 --> 00:35:38,000 Is that would change the semantics of price, so there 655 00:35:38,000 --> 00:35:40,600 will be a breaking change because some let's say 656 00:35:40,900 --> 00:35:43,300 implicitly was priced in u.s. dollars. 657 00:35:43,800 --> 00:35:47,400 Now you have currency feel and all client reading price and 658 00:35:47,400 --> 00:35:51,300 doesn't know currency, then it will interpret this field. 659 00:35:51,700 --> 00:35:57,400 Tell us which might not at all. So if you want to do this you 660 00:35:57,400 --> 00:36:02,700 need to keep price and then you define property price with 661 00:36:02,700 --> 00:36:06,100 currency. And you need to support both of 662 00:36:06,100 --> 00:36:09,000 these elements which makes you provide a code. 663 00:36:09,000 --> 00:36:13,100 Much harder more difficult to maintain over time because you 664 00:36:13,107 --> 00:36:15,700 have all these different things. When you have multiple ways of 665 00:36:15,700 --> 00:36:19,100 expressing the same logic, are transferring the same thing? 666 00:36:19,500 --> 00:36:21,500 Most real life cases, you just don't. 667 00:36:21,600 --> 00:36:24,500 To guarantee and less backwards compatibility. 668 00:36:24,700 --> 00:36:27,700 And then the question is, how do you manage to your deprecated 669 00:36:27,700 --> 00:36:31,100 things and occasionally to? This would be one strategy for 670 00:36:31,100 --> 00:36:34,100 announced applications and also 42mm production things? 671 00:36:34,100 --> 00:36:37,600 You know, the strength to API versions active and you can then 672 00:36:37,600 --> 00:36:41,700 migrate over and then the older one will be gone in and outs 673 00:36:41,700 --> 00:36:44,200 timeframe or you just say from the beginning. 674 00:36:44,200 --> 00:36:46,900 Okay, maybe I guarantee you that for next two years. 675 00:36:47,000 --> 00:36:52,100 But stable real time based guarantee and then Obviously, 676 00:36:52,100 --> 00:36:54,900 you can just pretend to be backwards compatible forever, 677 00:36:54,900 --> 00:36:57,600 which will lead to probably down the way to the deprecation 678 00:36:57,600 --> 00:37:00,100 approach anyway because at some point you will realize, okay, I 679 00:37:00,107 --> 00:37:04,200 need to do something breaking and then I just announced how 680 00:37:04,200 --> 00:37:06,000 this works. So basically these are the 681 00:37:06,000 --> 00:37:07,600 strategies and you can combine them. 682 00:37:07,600 --> 00:37:10,500 Obviously plus the remainder previously talked about me say 683 00:37:10,500 --> 00:37:13,500 again I'm not really in production, just don't give you 684 00:37:13,500 --> 00:37:17,300 any guarantees and then you have covered everything and then you 685 00:37:17,300 --> 00:37:21,000 need to choose and pick one or a combination of these but you 686 00:37:21,000 --> 00:37:23,000 should do. This because it's not a question 687 00:37:23,000 --> 00:37:25,400 of versioning. It's a question of life cycle. 688 00:37:25,400 --> 00:37:28,200 You want to force the clients into certain life cycle? 689 00:37:29,400 --> 00:37:32,000 I think it's pretty insightful because for those Engineers who 690 00:37:32,000 --> 00:37:33,900 have developed their API for long. 691 00:37:34,100 --> 00:37:37,200 There will be multiple versions, multiple iterations of your apis 692 00:37:37,400 --> 00:37:38,800 and this is where it gets tricky, right? 693 00:37:38,800 --> 00:37:42,000 How do you support backward, compatibility how far do you 694 00:37:42,000 --> 00:37:44,300 want to support it. So you mentioned a couple of 695 00:37:44,300 --> 00:37:47,700 patterns here things like for example 2 in production limited 696 00:37:47,700 --> 00:37:50,600 lifetime guarantee just like, how long do you want to support 697 00:37:50,600 --> 00:37:52,400 the API? And you also mentioned 698 00:37:52,400 --> 00:37:55,600 experimental, preview earlier, and one more is about aggressive 699 00:37:55,600 --> 00:37:57,500 obsolescence. So tell us more about this 700 00:37:57,500 --> 00:38:00,500 aggressive obsolescence. Is it something that you force 701 00:38:00,600 --> 00:38:02,600 the client to actually just break? 702 00:38:03,800 --> 00:38:06,000 Actually, let's the deprecation approach. 703 00:38:06,400 --> 00:38:09,300 As long as it works. I stay backwards compatible and 704 00:38:09,300 --> 00:38:12,600 make it work for you. But I also have this mechanism 705 00:38:12,600 --> 00:38:15,000 of telling you, okay, we deprecate something. 706 00:38:15,500 --> 00:38:18,500 And from on provider perspective, we will try to do 707 00:38:18,500 --> 00:38:21,700 this in an aggressive way because we want to reduce our 708 00:38:21,700 --> 00:38:25,700 technical debt at some point, we would say, okay this operation, 709 00:38:25,700 --> 00:38:30,500 or this data element is deprecated and And you have more 710 00:38:30,500 --> 00:38:34,600 like, say two months or a year, depends on office, your clients 711 00:38:34,600 --> 00:38:37,800 and power clients have over you or you have over your clients. 712 00:38:38,200 --> 00:38:41,200 We give a certain time span until they have to migrate, and 713 00:38:41,200 --> 00:38:45,500 if they don't migrate well, they will break, you will discontinue 714 00:38:45,500 --> 00:38:48,200 this feature. So, let's put this aggressive as 715 00:38:48,200 --> 00:38:50,100 a bone. Obviously, we have other 716 00:38:50,100 --> 00:38:53,300 deprecation approaches if you look at the Java class library 717 00:38:53,300 --> 00:38:56,800 is things in there which are deprecated, like 20 years, or 718 00:38:56,808 --> 00:38:59,000 so, I don't know. So they obviously see. 719 00:38:59,200 --> 00:39:03,200 Okay, you shouldn't use that but we place a high emphasis on 720 00:39:03,200 --> 00:39:07,700 backwards compatibility which cost them for API, provide a 721 00:39:07,700 --> 00:39:11,200 perspective you want or you sometimes must be talk about the 722 00:39:11,200 --> 00:39:14,800 currency and count numbers and so there you must make breaking 723 00:39:14,800 --> 00:39:16,900 changes. Sometimes you want to do 724 00:39:16,900 --> 00:39:19,400 breaking changes because you want to refactor things. 725 00:39:19,500 --> 00:39:22,400 That's what's placed on the aggressive, you know, want to 726 00:39:22,400 --> 00:39:25,800 give a sensible timeframe but you have a certain time frame 727 00:39:25,800 --> 00:39:29,300 when you will definitely face out some feature a little it of 728 00:39:29,300 --> 00:39:31,500 question about maintaining all these versions. 729 00:39:31,600 --> 00:39:34,700 First of all, obviously there's this Paradigm, how should we 730 00:39:34,700 --> 00:39:36,700 version it? Is it like version one version 731 00:39:36,700 --> 00:39:39,600 to version 3? Or is there any other strategy 732 00:39:39,600 --> 00:39:43,200 things like semantic versioning and how do you actually test? 733 00:39:43,200 --> 00:39:45,900 If you have multiple versions that you have as an API 734 00:39:45,900 --> 00:39:48,000 provided? Is there anything special that 735 00:39:48,000 --> 00:39:50,500 you have learned throughout your journey to test all these 736 00:39:50,500 --> 00:39:52,700 different permutations of apis that you have? 737 00:39:55,500 --> 00:39:58,000 And, you know, we'll have a flame war on the comment 738 00:39:58,000 --> 00:39:59,900 section. So, you know, that just by 739 00:39:59,900 --> 00:40:03,400 placing this topic, well, let's say there are two schools, one, 740 00:40:03,400 --> 00:40:06,600 laughs versioning, or having some kind of version. 741 00:40:06,600 --> 00:40:09,900 Identifier visible. In either your endpoints, are 742 00:40:09,900 --> 00:40:13,400 your URLs or in the messages being transferred. 743 00:40:13,800 --> 00:40:16,300 Perhaps, also the content type HTTP. 744 00:40:16,900 --> 00:40:19,800 And some people say, it's just the most evil thing you can do 745 00:40:20,300 --> 00:40:22,300 for my experience. I like to have some version 746 00:40:22,300 --> 00:40:25,500 indication. However, Yeah, that you 747 00:40:25,500 --> 00:40:28,900 shouldn't place any logic so any business logic so if it's 748 00:40:28,900 --> 00:40:32,300 version to this field, prize means this and it's version. 749 00:40:32,300 --> 00:40:35,200 One of the sphere price is definitely and dollars or so let 750 00:40:35,200 --> 00:40:38,100 you shouldn't do. But you should be able to Signal 751 00:40:38,200 --> 00:40:41,400 some kind of compatibility. So let's say you have a mobile 752 00:40:41,400 --> 00:40:46,000 app and the user has an upgraded it or has an old operating 753 00:40:46,000 --> 00:40:49,500 system on its mobile and can't use your news app version. 754 00:40:49,900 --> 00:40:52,600 You want to make an ism? You can say, probably this 755 00:40:52,600 --> 00:40:57,300 doesn't work and And just saying okay no you can't use this API 756 00:40:57,300 --> 00:41:00,700 if you know that semantic versioning has the advantage of 757 00:41:00,900 --> 00:41:04,400 indicating, what kind of changes you make, social these three 758 00:41:04,400 --> 00:41:08,200 versions major minor patch or fix pending on, who tells you 759 00:41:08,200 --> 00:41:11,500 what this last digit is name. But it's very clear if you have 760 00:41:11,500 --> 00:41:15,500 a major changes breaking and it's clear that if you have a 761 00:41:15,500 --> 00:41:19,300 fixed version changes, just a minor cosmetic thing which 762 00:41:19,400 --> 00:41:21,700 shouldn't break anything on the client side. 763 00:41:22,300 --> 00:41:26,300 I think that's worthwhile to see So you have some possibility and 764 00:41:26,300 --> 00:41:28,500 estimating the impact of these changes. 765 00:41:29,100 --> 00:41:32,500 Now I think that's more or less answers your question. 766 00:41:32,500 --> 00:41:36,700 So you have these two parties in the API Community, favoring or 767 00:41:36,707 --> 00:41:41,600 disfavoring explicit versioning and if you version, many people 768 00:41:41,600 --> 00:41:44,800 use semantic versioning to indicate at least some kind of 769 00:41:44,800 --> 00:41:48,000 compatibility. And how about testing those 770 00:41:48,000 --> 00:41:51,200 different versions that you have the you especially need to 771 00:41:51,200 --> 00:41:55,200 provide test cases for all Yeah, you should have test cases for 772 00:41:55,200 --> 00:41:57,600 all. What we did just referring back 773 00:41:57,600 --> 00:42:01,000 to this project is named very open and transparent and can 774 00:42:01,000 --> 00:42:03,000 very openly talk about what we've done there. 775 00:42:03,000 --> 00:42:07,200 So that policy was yeah, maximum up to three versions. 776 00:42:07,500 --> 00:42:11,600 So when a new version is released might be 3 and the 777 00:42:11,600 --> 00:42:14,600 oldest one will then be taken down two years later. 778 00:42:14,800 --> 00:42:17,800 You see, it's a very not a jowl environment. 779 00:42:17,900 --> 00:42:21,900 Very highly times. So it means you have possibly 780 00:42:22,100 --> 00:42:25,500 three banking. API, version 3 land registry API 781 00:42:25,500 --> 00:42:29,200 versions and three notary API versions and the same process 782 00:42:29,200 --> 00:42:32,300 might be under the nine different API version 783 00:42:32,300 --> 00:42:34,700 combinations. So, that's pretty bad. 784 00:42:35,300 --> 00:42:38,600 Actually, what we did, there was, we generated test cases. 785 00:42:38,600 --> 00:42:43,900 So, we went way of specifying the data, so on more business 786 00:42:43,900 --> 00:42:48,500 level, more specification level. And then we are generators on 787 00:42:48,500 --> 00:42:51,600 for creating messages, conforming to this different API 788 00:42:51,600 --> 00:42:54,800 versions. And See that's one extreme side 789 00:42:54,800 --> 00:42:59,500 of things not in all projects you benefit from the generation 790 00:42:59,500 --> 00:43:02,600 because generation itself. Also cause something we have a 791 00:43:02,607 --> 00:43:05,800 different cost structures and you have more upfront effort and 792 00:43:05,800 --> 00:43:09,200 then things get easier if you just have two apis at saying 793 00:43:09,400 --> 00:43:13,800 version 1 and 2 when you release be you always have your test 794 00:43:13,800 --> 00:43:18,500 cases for a already there when you get them to cover version B, 795 00:43:18,500 --> 00:43:22,100 and if you find some point in time take down version a by 796 00:43:22,100 --> 00:43:24,500 whatever means for the Occasionally because you have to 797 00:43:24,500 --> 00:43:27,700 in production or reach the lifetime guarantee, then you 798 00:43:27,700 --> 00:43:31,200 will also do the test cases and that also works for if you're 799 00:43:31,200 --> 00:43:34,500 saying we're keeping backwards compatibility and so going back 800 00:43:34,500 --> 00:43:37,400 to this currency example, and you have a test case for version 801 00:43:37,400 --> 00:43:40,300 a which checks. The price is working. 802 00:43:40,600 --> 00:43:43,700 If I don't send the currency with the price correctly as US 803 00:43:43,700 --> 00:43:47,200 Dollars and a test case which sends a different currency which 804 00:43:47,200 --> 00:43:50,200 could present the vision being so doesn't mean that I need to 805 00:43:50,207 --> 00:43:53,000 explicitly version things, but I should also have test cases. 806 00:43:53,200 --> 00:43:57,700 It's just evolved my Pi without person identifies, so for people 807 00:43:57,700 --> 00:44:01,000 who are not producing API as like they sell the apis. 808 00:44:01,000 --> 00:44:02,600 Right. Sometimes Engineers tend to 809 00:44:02,600 --> 00:44:06,000 forget about this testing part, they always keep evolving for 810 00:44:06,000 --> 00:44:09,400 the new one, new versions but they don't realize that actually 811 00:44:09,400 --> 00:44:12,200 their old API or the older version of the IDE guide. 812 00:44:12,400 --> 00:44:15,100 There are still some people using it and whenever we make 813 00:44:15,100 --> 00:44:18,200 these new changes it will break. So I think what you mentioned 814 00:44:18,200 --> 00:44:21,700 definitely makes sense rights for people to always have test 815 00:44:21,700 --> 00:44:24,200 cases for all the aps. Is that you still support? 816 00:44:24,200 --> 00:44:27,000 That is still life as part of your API provider. 817 00:44:27,600 --> 00:44:29,600 So, Daniel is been a pleasant conversation. 818 00:44:29,600 --> 00:44:31,900 There are so many things wrap up in the book. 819 00:44:32,000 --> 00:44:34,000 That thing is pretty thick, the way that I see it. 820 00:44:34,000 --> 00:44:37,300 So many patterns starting from the basic one, the fundamentals, 821 00:44:37,400 --> 00:44:39,700 what is API? What is the structure protocol? 822 00:44:39,700 --> 00:44:41,700 And things like that up to the patterns? 823 00:44:41,900 --> 00:44:44,800 I think for people who want to build a better, if you guys, I 824 00:44:44,800 --> 00:44:48,000 would definitely recommend reading Daniels book but 825 00:44:48,000 --> 00:44:50,300 unfortunately we need to wrap up this episode. 826 00:44:50,400 --> 00:44:53,300 But before I let you go, I have one last question that I Many 827 00:44:53,300 --> 00:44:56,300 ask for all my guests which is for you to share what I call 828 00:44:56,300 --> 00:44:59,200 three technical leadership wisdom, you can think of it like 829 00:44:59,200 --> 00:45:01,700 an advice that you want to import for the listeners here to 830 00:45:01,700 --> 00:45:04,700 learn from your experience or Journey now. 831 00:45:04,800 --> 00:45:07,600 So I think first is lead by competence. 832 00:45:08,200 --> 00:45:11,700 So if you take these by definition you're leading a team 833 00:45:11,700 --> 00:45:15,200 of Junior and perhaps in your people and you have people who 834 00:45:15,200 --> 00:45:18,000 are trying to say okay I'm higher in the hierarchy. 835 00:45:18,000 --> 00:45:23,100 So therefore my argument went that's not true in multiple They 836 00:45:23,100 --> 00:45:27,400 suspect behaviors one is, you're not really respected the team, 837 00:45:27,600 --> 00:45:30,500 so you're respected. Usually the development 838 00:45:30,500 --> 00:45:33,000 Community because you're good at something. 839 00:45:33,300 --> 00:45:36,100 So let's one thing. So if you can persuade by 840 00:45:36,100 --> 00:45:39,500 bringing good designs and good suggestions and you're able to 841 00:45:39,500 --> 00:45:44,300 say why they are good well I've done this for 20 years, it's bad 842 00:45:44,300 --> 00:45:46,600 explanation. What if you can say okay we 843 00:45:46,600 --> 00:45:49,900 should do this here because otherwise I'll database a little 844 00:45:50,200 --> 00:45:52,100 too high. For example it's much better so 845 00:45:52,100 --> 00:45:55,900 lead by The other side of the coin is you also learn. 846 00:45:56,200 --> 00:45:59,600 There's so many new things going on there and two new developers 847 00:45:59,600 --> 00:46:03,800 are very often much better and knowing the new stream versions 848 00:46:04,300 --> 00:46:07,100 deep in the technical detail. They're not as good and 849 00:46:07,100 --> 00:46:10,400 conceptual thinking hopefully but you can still learn things 850 00:46:10,400 --> 00:46:13,300 should be open to that as well. And if you just say, well, I'm 851 00:46:13,300 --> 00:46:15,100 the boss here and then you won't learn. 852 00:46:15,800 --> 00:46:20,900 Number two is keep on thinking. Well, people often just to not 853 00:46:20,900 --> 00:46:24,100 think enough about their decisions and And why they make 854 00:46:24,100 --> 00:46:27,100 this decision? So we have like architectural 855 00:46:27,100 --> 00:46:30,000 decision records, or we can document, why we do something 856 00:46:30,500 --> 00:46:34,400 you can say, Okay pageants, make explicit what we want to 857 00:46:34,400 --> 00:46:36,300 achieve. And what we lose, it's really 858 00:46:36,300 --> 00:46:39,900 making conscious decisions about things and not just going along. 859 00:46:40,400 --> 00:46:44,000 And all the third is also hard for me to translate it seems 860 00:46:44,100 --> 00:46:47,300 probably will laugh. But anyway, so make the world a 861 00:46:47,308 --> 00:46:50,400 better place. So within your project within 862 00:46:50,400 --> 00:46:53,500 your team, within your company and probably will Product. 863 00:46:53,500 --> 00:46:55,400 You were nice. It's so incredible. 864 00:46:55,400 --> 00:46:59,900 What you can do with software, what we can really achieve in 865 00:46:59,900 --> 00:47:03,800 this world, like I said, like in our team up to when things are 866 00:47:03,800 --> 00:47:06,700 released. So imagine you an engineer Tesla 867 00:47:06,700 --> 00:47:10,400 and at some point in time, you're the greatest auto pilot 868 00:47:10,600 --> 00:47:13,900 cars are moving by themselves. So how great is that? 869 00:47:14,400 --> 00:47:18,100 Obviously they are more boring projects but still even Whispers 870 00:47:18,100 --> 00:47:20,600 language, history thing is now moved back to Germany. 871 00:47:20,600 --> 00:47:24,500 We bought a house last year and it was It's all on paper because 872 00:47:24,500 --> 00:47:27,100 my software there is no paperwork and here. 873 00:47:27,100 --> 00:47:31,500 Now I got tired of paper and then I realized it was not just 874 00:47:31,500 --> 00:47:34,800 boring administrative product, it really made people's lives 875 00:47:34,800 --> 00:47:37,000 better. And that's very satisfying as 876 00:47:38,100 --> 00:47:40,100 well. That's a very beautiful message. 877 00:47:40,300 --> 00:47:42,000 So make the world a better place. 878 00:47:42,200 --> 00:47:44,100 So yeah, a lot of Engineers when they do work. 879 00:47:44,100 --> 00:47:46,700 Sometimes they don't think about what impact, or what values, 880 00:47:46,700 --> 00:47:49,800 they bring to the larger society, not just for the 881 00:47:49,800 --> 00:47:52,800 company or to the human, the people, the customers. 882 00:47:53,000 --> 00:47:55,200 Use the product. So I think that's a pretty good 883 00:47:55,200 --> 00:47:57,700 reminder for us to actually know and align. 884 00:47:58,000 --> 00:48:00,400 What, exactly the value, we bring to the users and the 885 00:48:00,408 --> 00:48:03,400 customers out there and best if we could bring it to the world, 886 00:48:03,400 --> 00:48:05,200 right? I think that's pretty impactful. 887 00:48:05,700 --> 00:48:09,300 So, Daniel if people want to connect with you or learn more 888 00:48:09,300 --> 00:48:11,800 from you, is there a place where they can find you online 889 00:48:12,900 --> 00:48:17,800 insurance own Linton? Then you can so I know it's very 890 00:48:18,000 --> 00:48:21,700 International first name and painful moan Jim's because last 891 00:48:21,700 --> 00:48:24,500 time. So if you search within Huey, 892 00:48:24,500 --> 00:48:26,600 you'll find me on LinkedIn and on Twitter. 893 00:48:26,600 --> 00:48:30,700 Just t, look, if you want to read my blog gets on digital 894 00:48:30,700 --> 00:48:33,300 dash solution, Dash, architecture.com. 895 00:48:33,800 --> 00:48:35,800 I'll put those in the show notes, so thank you so much for 896 00:48:35,800 --> 00:48:38,300 your time today. I really learned a lot about API 897 00:48:38,300 --> 00:48:40,700 design pattern and hopefully all the listeners here. 898 00:48:40,700 --> 00:48:43,900 Also learn a lot from you. So, thanks again for that. 899 00:48:44,700 --> 00:48:47,100 And thank you for having me was a pleasant discussion. 900 00:48:50,100 --> 00:48:53,400 Thank you for listening to this episode and for staying, right 901 00:48:53,400 --> 00:48:56,900 until the end, if you're highly enjoyed it, I would appreciate 902 00:48:56,900 --> 00:48:59,400 if you share it with your friends and colleagues who you 903 00:48:59,400 --> 00:49:02,300 think would also benefit from listening to this episode. 904 00:49:02,500 --> 00:49:05,300 And if you're new to the podcast, make sure to subscribe 905 00:49:05,300 --> 00:49:07,800 and leave me your valuable review and feedback. 906 00:49:08,000 --> 00:49:10,500 It helps me a lot. In order to grow this podcast 907 00:49:10,500 --> 00:49:12,700 better. You can also find the full show 908 00:49:12,700 --> 00:49:16,100 notes of this conversation on the episode page, at Tech Legion 909 00:49:16,100 --> 00:49:19,800 o.f website, including the full transcript interesting. 910 00:49:20,000 --> 00:49:23,600 It's and links to the resources mention from the conversation. 911 00:49:24,000 --> 00:49:27,000 And lastly, make sure to subscribe to the show's mailing 912 00:49:27,000 --> 00:49:30,400 list on technology. Not deaf to get notified for any 913 00:49:30,400 --> 00:49:33,100 future episodes. Stay tuned for the next 914 00:49:33,100 --> 00:49:36,400 technology, no episode. And until then goodbye.