1 00:00:00,040 --> 00:00:02,920 Hey, a quick message for those of you who are listening to this 2 00:00:02,920 --> 00:00:06,280 episode on Spotify. I have a small favor to ask. 3 00:00:06,640 --> 00:00:10,040 Spotify now allows mobile users to rate podcasts. 4 00:00:10,360 --> 00:00:13,680 I would really appreciate it if you can take a quick pause to go 5 00:00:13,680 --> 00:00:16,120 to the Technically Journal podcast page and leave your 6 00:00:16,120 --> 00:00:18,600 favorite show your best rating on Spotify. 7 00:00:19,160 --> 00:00:21,720 It will help me a lot to get this podcast to reach more 8 00:00:21,720 --> 00:00:24,120 people on the platform. Thanks a lot. 9 00:00:26,720 --> 00:00:28,400 So let's start. To your book. 10 00:00:28,680 --> 00:00:31,400 So you have had a lot of experience in the industry. 11 00:00:31,400 --> 00:00:34,920 You have written thesis work in large financial company. 12 00:00:35,160 --> 00:00:38,440 Why specifically? Writing an API design book 13 00:00:38,560 --> 00:00:41,760 because API has been around for many years, especially when you 14 00:00:41,760 --> 00:00:44,320 said about SOA, right SOA. And there are so many books 15 00:00:44,320 --> 00:00:47,200 already published as well. So is there anything different 16 00:00:47,200 --> 00:00:50,840 that you try to convey or try to teach us from your book? 17 00:00:51,760 --> 00:00:53,240 Yeah, definitely. Thanks. 18 00:00:53,600 --> 00:00:56,200 So the story behind the book is a little bit longer. 19 00:00:56,360 --> 00:00:59,400 I need to go back some years. All I have to my money was the 20 00:00:59,400 --> 00:01:02,920 first author and the team lead of this pattern approach. 21 00:01:03,200 --> 00:01:06,920 I knew him for quite some years. I said OK I want to have this 22 00:01:06,920 --> 00:01:08,560 idea. We are building all these 23 00:01:08,560 --> 00:01:12,360 services we have and then back in the day microservices were 24 00:01:12,360 --> 00:01:16,320 really the hype rebuilding all these and FI need to teach those 25 00:01:16,320 --> 00:01:18,200 two. And I have corporations. 26 00:01:18,200 --> 00:01:21,840 We only need to build API. So I want something to teach. 27 00:01:22,560 --> 00:01:26,840 I at the time was new at a very large scale project where they 28 00:01:26,840 --> 00:01:30,520 are connecting land, registries, banks, notaries and some other 29 00:01:30,520 --> 00:01:32,120 parties across whole Switzerland. 30 00:01:32,520 --> 00:01:34,880 So it's a system where you have like 1000 different 31 00:01:34,880 --> 00:01:38,960 organizations connected and automating all these business 32 00:01:38,960 --> 00:01:41,440 processes. As you can imagine there are 33 00:01:41,440 --> 00:01:44,800 many services, many APIs involved for doing that. 34 00:01:44,800 --> 00:01:48,400 A bank places a request, the platform generates some 35 00:01:48,400 --> 00:01:52,040 documents, send them back to the bank so that they can digitally 36 00:01:52,040 --> 00:01:55,320 sign this. It goes forward to the notary 37 00:01:55,320 --> 00:01:58,160 and then to the lender Just ran whatever you can do there. 38 00:01:58,600 --> 00:02:02,000 There were some people very new to service design and we had 39 00:02:02,000 --> 00:02:05,280 many discussions about things which I would have thought are 40 00:02:05,280 --> 00:02:07,400 basic, but obviously they weren't. 41 00:02:07,840 --> 00:02:11,200 So my motivation was more for my daily work life to just say, 42 00:02:11,200 --> 00:02:14,200 here's a pointer, please read this there and then we can have 43 00:02:14,200 --> 00:02:15,880 this discussion again. Yeah. 44 00:02:15,880 --> 00:02:17,760 So that was essentially how it started. 45 00:02:17,760 --> 00:02:20,880 And then other people joined like Merkel and Sizar and Uber, 46 00:02:21,400 --> 00:02:25,280 I can't recall now exactly in which order, but quickly became 47 00:02:25,280 --> 00:02:28,560 this team of five people. Uber and Sizar both were very 48 00:02:28,560 --> 00:02:33,000 experienced as patent authors. Already Olaf and I and Mirko as 49 00:02:33,000 --> 00:02:35,960 well had some practical, more practical experience, although 50 00:02:35,960 --> 00:02:39,520 Olaf and was a professor and Merkel actually now as well. 51 00:02:39,720 --> 00:02:43,160 I'm still in industry. I think that's the motivation. 52 00:02:43,160 --> 00:02:46,600 And then the question is, how do you teach these things? 53 00:02:46,600 --> 00:02:50,120 So I mean, design, architecture, always about decisions and 54 00:02:50,120 --> 00:02:53,200 decisions have these nasty aspects of that. 55 00:02:53,200 --> 00:02:54,760 You get something, but you lose something. 56 00:02:55,080 --> 00:02:57,720 And if you go through the right door, you can't go through the 57 00:02:57,720 --> 00:03:00,320 left door. That sounds easy, but people 58 00:03:00,320 --> 00:03:03,320 always assume that there's this perfect solution. 59 00:03:03,320 --> 00:03:05,600 You just do something and then it's perfect. 60 00:03:05,600 --> 00:03:08,160 And you do this every time because it works all the time. 61 00:03:08,720 --> 00:03:11,600 The silver bullet thing. And we all know it doesn't work. 62 00:03:12,200 --> 00:03:15,440 I think even if you're fresh from university, at least after 63 00:03:15,440 --> 00:03:17,280 three years, it doesn't work that way. 64 00:03:17,720 --> 00:03:20,840 And patterns make that explicit. I think that's so great because 65 00:03:20,920 --> 00:03:23,600 firstly you have a name and I think we'll talk about names as 66 00:03:23,600 --> 00:03:25,880 well. But you have the section bound 67 00:03:25,880 --> 00:03:28,920 forces. So what are the influences on 68 00:03:28,920 --> 00:03:31,240 your design? And some things are better if 69 00:03:31,280 --> 00:03:34,560 you use a certain pattern and some things are worse, so you 70 00:03:34,560 --> 00:03:37,800 pay for your decision. And patterns make this explicit, 71 00:03:37,800 --> 00:03:41,120 and that's why it's so great as both a teaching tool and also 72 00:03:41,120 --> 00:03:44,400 reference tool. So even nowadays if I'm in 73 00:03:44,400 --> 00:03:48,480 projects, it's just nice to go through the pattern list and 74 00:03:48,480 --> 00:03:52,440 check whether there's something I should have considered or not. 75 00:03:52,760 --> 00:03:55,680 Because it's always busy when you're doing things, it's nice 76 00:03:55,680 --> 00:03:58,640 to have checklist. I always love reading pattern 77 00:03:58,640 --> 00:04:01,160 books because it is practical. That's the first thing, right? 78 00:04:01,360 --> 00:04:04,280 And also it kind of like lists down the decisions or the 79 00:04:04,280 --> 00:04:07,160 trade-offs some people say on why you choose a certain 80 00:04:07,160 --> 00:04:09,800 pattern. So for example if you opt for 81 00:04:09,800 --> 00:04:12,960 scalability, then maybe this pattern might be better for 82 00:04:12,960 --> 00:04:15,640 example microservices, right? But obviously we know that 83 00:04:15,640 --> 00:04:17,279 microservices is not silver bullet. 84 00:04:17,600 --> 00:04:19,959 In some cases it might not work as well. 85 00:04:20,160 --> 00:04:23,320 So Fred Brooks have this write up last time, no silver bullet. 86 00:04:23,480 --> 00:04:26,000 So I guess it has been mentioned many times in any kind of 87 00:04:26,040 --> 00:04:28,920 architecture kind of discussion I had in this Technician 88 00:04:28,920 --> 00:04:31,480 episode. Your subtitle of the book also 89 00:04:31,480 --> 00:04:33,760 mentions specifically about Loosely coupled. 90 00:04:33,880 --> 00:04:37,640 Message Exchanges. So tell us more why you? 91 00:04:37,680 --> 00:04:40,680 Choose specifically loosely. Coupled message exchanges as 92 00:04:40,680 --> 00:04:43,960 your subtitle. Well, actually the subtitle was 93 00:04:43,960 --> 00:04:45,800 one of the last things we decided. 94 00:04:47,400 --> 00:04:50,720 And if we look at the book, what's special about this? 95 00:04:50,800 --> 00:04:54,160 It closes the gap between high level books like Enterprise 96 00:04:54,160 --> 00:04:57,720 Integration Patterns, which are not high level or very abstract, 97 00:04:57,720 --> 00:05:00,200 but they're certainly on a high level of abstraction. 98 00:05:00,200 --> 00:05:02,560 And then you have these books about technology. 99 00:05:02,560 --> 00:05:07,760 So how do I use REST or GRPC or graph, QR or whatever, and what 100 00:05:07,760 --> 00:05:10,600 verbs to I use and which circumstances, how do I build 101 00:05:11,160 --> 00:05:15,040 good UIS and all these things. And in between there is 102 00:05:15,040 --> 00:05:17,480 something. So you have a conceptual API 103 00:05:17,480 --> 00:05:20,320 design, something where you decide, OK, I need these kinds 104 00:05:20,320 --> 00:05:24,120 of operations, I need to have these quality attributes and 105 00:05:24,240 --> 00:05:26,720 because of this I perhaps to pagination. 106 00:05:26,720 --> 00:05:30,280 I chunk things and not transfer a whole message and that's 107 00:05:30,320 --> 00:05:34,120 independent of the integration technology of the protocols you 108 00:05:34,120 --> 00:05:36,840 use. Back in my first project was a 109 00:05:36,840 --> 00:05:40,360 banking system or a banking platform and they used CORBA all 110 00:05:40,360 --> 00:05:44,000 the way. It was all CORBA already there. 111 00:05:44,000 --> 00:05:47,440 There were many patterns which we still use today and more REST 112 00:05:47,440 --> 00:05:52,960 http://apis because these are really long living and even now 113 00:05:52,960 --> 00:05:56,400 whatever comes up next, you will have these problems and you will 114 00:05:56,480 --> 00:05:59,480 have these patterns hopefully addressing those problems. 115 00:05:59,480 --> 00:06:03,120 So it's not tied to any specific technology. 116 00:06:03,600 --> 00:06:07,200 First of all, so you can make your API design on a conceptual 117 00:06:07,200 --> 00:06:10,760 level using these patterns and then shoots your technology. 118 00:06:11,200 --> 00:06:14,320 So that's one aspect. The patterns themselves are not 119 00:06:14,320 --> 00:06:17,880 coupled to any technology themselves, but obviously it's 120 00:06:17,920 --> 00:06:21,840 probably more about the coupling between API clients and API 121 00:06:21,840 --> 00:06:24,760 providers. I think a good API and that's 122 00:06:24,760 --> 00:06:29,400 why nowadays finally we all agree that API first design is 123 00:06:29,400 --> 00:06:33,240 the way to go is you don't want to expose your internal data 124 00:06:33,240 --> 00:06:36,960 models or your internal logic too much on your APIs. 125 00:06:37,320 --> 00:06:40,360 And the more your clients are not under your control, the less 126 00:06:40,360 --> 00:06:43,680 you want to do that. I think most patents here will 127 00:06:44,080 --> 00:06:46,040 allow you to deal with this problem. 128 00:06:46,520 --> 00:06:51,360 So how do I build APIs which well if I do them by the pattern 129 00:06:51,360 --> 00:06:54,800 book so to say, although it's not your goal shouldn't be to 130 00:06:54,800 --> 00:06:59,040 use as many patterns, but if you just follow these forces and 131 00:06:59,040 --> 00:07:03,400 things then you will hopefully have a design which allows you 132 00:07:03,400 --> 00:07:05,920 to have these loosely coupled exchanges which are not 133 00:07:05,920 --> 00:07:07,880 dependent on your internal models. 134 00:07:08,720 --> 00:07:11,400 So you mentioned something. API first design. 135 00:07:11,720 --> 00:07:13,400 I think this is mentioned many times. 136 00:07:13,400 --> 00:07:16,480 In fact, I think I have one episode James Higginbottom also 137 00:07:16,480 --> 00:07:18,960 talking about that and in the book you also. 138 00:07:18,960 --> 00:07:22,080 Mentioned a couple more. Good practices for API design. 139 00:07:22,440 --> 00:07:25,560 So I think these days almost all back end developers will create 140 00:07:25,560 --> 00:07:29,920 API especially REST API or maybe GRPC or Graph QL. 141 00:07:30,240 --> 00:07:33,800 Are there any other things that you would advocate for all these 142 00:07:33,800 --> 00:07:36,000 engineers? What kind of good practices they 143 00:07:36,000 --> 00:07:38,640 should do or they should consider when building API? 144 00:07:39,640 --> 00:07:42,480 Well, first of all you should think about how to express that 145 00:07:42,760 --> 00:07:45,560 if you start with any software development, it's just not only 146 00:07:45,560 --> 00:07:48,400 APIs, but it's in general. You need to understand your 147 00:07:48,400 --> 00:07:53,440 domain thing, that's important. The problem with APIs is let's 148 00:07:53,440 --> 00:07:57,760 go back to this project. You have a team of people who if 149 00:07:57,760 --> 00:07:59,720 you want to build a good solution or a very good 150 00:07:59,720 --> 00:08:02,360 solution, you need to understand what banks are doing, what 151 00:08:02,360 --> 00:08:04,880 notaries are doing, what land registries are doing. 152 00:08:05,520 --> 00:08:08,920 And the interesting part is in the last couple of 100 years, I 153 00:08:08,920 --> 00:08:12,440 mean this domain is very old. Houses and government management 154 00:08:12,440 --> 00:08:15,120 of houses have a long time. So land registries are around 155 00:08:15,120 --> 00:08:20,240 like forever and banks are very old concept and no trees I think 156 00:08:20,240 --> 00:08:22,680 as well. And over these couple of 100 157 00:08:22,680 --> 00:08:26,080 years, these three parties still haven't learned what they are 158 00:08:26,080 --> 00:08:28,400 doing. So that was very interesting. 159 00:08:28,920 --> 00:08:32,919 A bank doesn't know data and model of land register, which is 160 00:08:32,919 --> 00:08:37,880 very interesting and surprising. So if you want to build APIs for 161 00:08:38,000 --> 00:08:41,760 domain or for clients where you don't know exactly their 162 00:08:41,760 --> 00:08:44,920 requirements, it's the first thing where you need to reach 163 00:08:44,920 --> 00:08:47,400 out. To clarify this and it's easier 164 00:08:47,400 --> 00:08:49,160 said than done. There are a couple of 165 00:08:49,160 --> 00:08:50,960 approaches. So most of all you're doing 166 00:08:50,960 --> 00:08:54,520 workshops, building your first API version, release it, try to 167 00:08:54,520 --> 00:08:58,040 evolve it, but then you need to deal with life cycle issues. 168 00:08:58,440 --> 00:09:01,960 So one part of this loosely coupled is also you need to 169 00:09:01,960 --> 00:09:04,760 decouple the life cycle of your client and your provider, 170 00:09:05,200 --> 00:09:08,280 because you won't deploy new versions simultaneously, so you 171 00:09:08,280 --> 00:09:11,080 will have points in time, many points in time where they're 172 00:09:11,080 --> 00:09:14,000 different versions. So client normally supports an 173 00:09:14,000 --> 00:09:17,560 older version and the provider rolls out a new API version 174 00:09:17,560 --> 00:09:20,480 which should be backward compatible so client doesn't 175 00:09:20,480 --> 00:09:22,720 break. So that's kind of the ideal 176 00:09:22,720 --> 00:09:25,800 scenario. Well, many people say OK, just 177 00:09:25,800 --> 00:09:30,440 build backwards compatible APIs, yeah, but it's not always 178 00:09:30,440 --> 00:09:32,880 possible. Sometimes you have breaking 179 00:09:32,880 --> 00:09:35,880 changes. If you say OK, I don't know my 180 00:09:35,880 --> 00:09:38,840 clients well enough, I want to iterate and I want to improve 181 00:09:38,840 --> 00:09:41,720 things. It's more likely that you will 182 00:09:41,760 --> 00:09:45,800 have breaking changes. For instance, banks usually had 183 00:09:45,880 --> 00:09:49,480 one to many relationships where the Land Registry internally 184 00:09:49,480 --> 00:09:51,360 manages many to many relationships. 185 00:09:52,000 --> 00:09:54,640 These kinds of things if you know them later on. 186 00:09:54,640 --> 00:09:57,920 So you have your API defined with one to many and now you 187 00:09:57,920 --> 00:10:01,120 need to support many to many. It's likely going to be a 188 00:10:01,120 --> 00:10:03,720 breaking change. Also in your environment there 189 00:10:03,720 --> 00:10:06,760 might be breaking changes. So in Europe we have the Euro as 190 00:10:06,760 --> 00:10:10,880 a currency, which before were multiple national currencies and 191 00:10:10,880 --> 00:10:14,360 if you had online banking bank then to money transfer, there's 192 00:10:14,360 --> 00:10:18,000 no way of doing that now as it was a breaking change that 193 00:10:18,000 --> 00:10:20,880 there's a euro and not all these local currencies. 194 00:10:21,400 --> 00:10:24,960 The same goes for account numbers only have been local 195 00:10:24,960 --> 00:10:28,360 national account numbers and now we have the Ibens International 196 00:10:28,360 --> 00:10:31,880 Banking account number. So there will be changes in your 197 00:10:31,880 --> 00:10:35,080 environment which will break where you can't do anything. 198 00:10:35,080 --> 00:10:38,120 And there will be changes where you learn your domain better and 199 00:10:38,120 --> 00:10:40,760 where you can say, OK, in theory I should have known this 200 00:10:40,760 --> 00:10:44,200 already, but you didn't. The more you iterate to get to 201 00:10:44,200 --> 00:10:46,920 your requirements, the more you need to think about your life 202 00:10:46,920 --> 00:10:49,120 cycle. Some patterns we have there is, 203 00:10:49,120 --> 00:10:51,240 for example we have an experimental preview pattern. 204 00:10:51,560 --> 00:10:55,040 So you say, OK, let's say we roll this out and currently I 205 00:10:55,040 --> 00:10:58,040 don't give you any guarantees, you can check this out, you can 206 00:10:58,040 --> 00:11:02,080 give us feedback, but it will break without us telling you so 207 00:11:02,080 --> 00:11:05,840 That's not nice for the client, but the client also has some 208 00:11:05,840 --> 00:11:09,280 benefits because he gets a preview, so a better version 209 00:11:09,760 --> 00:11:13,560 where they can use the API, preview it, use it, give 210 00:11:13,560 --> 00:11:17,560 feedback, and perhaps hopefully getting a better API down the 211 00:11:17,560 --> 00:11:21,120 road due to this feedback, even if it has breaking changes. 212 00:11:21,760 --> 00:11:24,720 And obviously some organizations or some developers will say, OK, 213 00:11:24,720 --> 00:11:28,480 no, under these circumstances, having only an experimental 214 00:11:28,480 --> 00:11:31,400 preview, I don't integrate, I don't use this API, which is 215 00:11:31,400 --> 00:11:34,600 fair because it's known. What's unfair is if you say, OK, 216 00:11:34,600 --> 00:11:38,640 here's an API and then you just say don't support it anymore, I 217 00:11:38,640 --> 00:11:42,520 break it in some way or another. So being clear about your 218 00:11:42,520 --> 00:11:44,600 evolution process, I think that's important. 219 00:11:45,000 --> 00:11:49,000 So have your requirements, know how good you know them and then 220 00:11:49,000 --> 00:11:51,560 plan ahead because in the beginning you can. 221 00:11:52,000 --> 00:11:55,320 So if you just had guarantee like we support this for three 222 00:11:55,320 --> 00:11:59,320 years and then you just try to alter this later on, people just 223 00:11:59,440 --> 00:12:02,760 come to your office and hit you. Probably These are decisions 224 00:12:02,760 --> 00:12:06,920 which you need to do as early as possible, and then obviously you 225 00:12:06,920 --> 00:12:10,560 need to flesh out all the domain knowledge in your API payloads. 226 00:12:11,360 --> 00:12:13,680 So yeah, it's always wise to start with the domain 227 00:12:13,680 --> 00:12:17,040 understanding first, and in fact things like DDD or Domain Driven 228 00:12:17,040 --> 00:12:19,560 Design is also something that advocates you to actually 229 00:12:19,560 --> 00:12:22,720 understand the problem. 1st. Rather than coming up with just 230 00:12:22,720 --> 00:12:25,800 the technology or the solutions, people these days whenever they 231 00:12:25,800 --> 00:12:28,280 build API, the first question that they have in mind is 232 00:12:28,280 --> 00:12:33,040 definitely which technology like HTTP, Ras, GRPC, Graph, QL and 233 00:12:33,040 --> 00:12:34,720 things like. That, but actually. 234 00:12:34,720 --> 00:12:37,320 Specifically in your book you also covered the other important 235 00:12:37,320 --> 00:12:38,840 parts, which is the payload itself. 236 00:12:38,840 --> 00:12:43,040 You mentioned the messages. Maybe for us engineers here, can 237 00:12:43,040 --> 00:12:46,080 you give an overview what aspects that we should consider 238 00:12:46,080 --> 00:12:49,160 from the messages point of view, the payload point of view, in 239 00:12:49,160 --> 00:12:51,640 order for us to design our API better? 240 00:12:52,480 --> 00:12:56,640 Well yeah, I think the most important part is how many 241 00:12:56,640 --> 00:13:00,920 requests do you have and how large your message payload is. 242 00:13:01,280 --> 00:13:05,520 So if we look at that, obviously you could make an API operation 243 00:13:05,520 --> 00:13:09,800 which might be an HTTP resource where you say get me all 244 00:13:09,800 --> 00:13:13,680 customers and then you get back all customers and everyone's 245 00:13:13,680 --> 00:13:15,400 happy. You can deal with the data 246 00:13:15,400 --> 00:13:17,960 whenever you like. This approach obviously has some 247 00:13:17,960 --> 00:13:22,440 drawbacks, So much load on the API provider because it needs to 248 00:13:22,440 --> 00:13:25,480 fetch all these customers. You have much load on the 249 00:13:25,480 --> 00:13:28,400 network because you need to transmit all these customers. 250 00:13:28,960 --> 00:13:32,560 So we don't do this design. What we usually do is get a 251 00:13:32,560 --> 00:13:36,000 certain customer or search for customers, but it's that 252 00:13:36,000 --> 00:13:38,920 everything we need to consider, No, usually not. 253 00:13:38,920 --> 00:13:41,920 So if we look at the search, even a search might return too 254 00:13:41,920 --> 00:13:44,040 many records. That depends a little bit on 255 00:13:44,040 --> 00:13:47,080 your domain and how many objects you have, what domain objects 256 00:13:47,080 --> 00:13:49,080 you have. So if we have a service which 257 00:13:49,080 --> 00:13:51,960 would return list of currencies, we know how many there are and 258 00:13:51,960 --> 00:13:55,520 it's quite manageable. If we are fetching customers 259 00:13:55,520 --> 00:13:59,840 from any large organization at the Microsoft on the whole 260 00:13:59,840 --> 00:14:03,080 Salesforce database, whatever you like, that's too much. 261 00:14:03,280 --> 00:14:05,960 So we need to have some mechanisms if we are running 262 00:14:05,960 --> 00:14:08,320 into this problem to limit our response sizes. 263 00:14:08,880 --> 00:14:12,760 So you can either say OK I only returned the 1st 200 hits I have 264 00:14:12,840 --> 00:14:15,920 might be a good strategy. We could have pagination. 265 00:14:15,920 --> 00:14:19,400 So I give you the first hundred and if it isn't sufficient you 266 00:14:19,400 --> 00:14:23,040 can query the next hundred. We could also say, OK, perhaps 267 00:14:23,040 --> 00:14:26,480 you need not all customers, but query all sessions in the 268 00:14:26,480 --> 00:14:28,840 conference. And that's a very huge 269 00:14:28,840 --> 00:14:33,120 conference, like 600 sessions. To each session you have some 270 00:14:33,120 --> 00:14:37,320 information like the title. OK, just a string who's giving 271 00:14:37,320 --> 00:14:40,360 the presentation? That's just a string, the image 272 00:14:40,400 --> 00:14:43,600 of the presenter. So that's obviously some large 273 00:14:43,600 --> 00:14:46,680 payload part. When I put this in my message, 274 00:14:47,160 --> 00:14:49,920 it depends on the use case, but most likely not. 275 00:14:49,920 --> 00:14:53,480 I would just put a link to this image and whenever the client 276 00:14:53,520 --> 00:14:57,240 probably pops into the detail view then it can fetch this data 277 00:14:57,240 --> 00:15:00,280 as required. So we have this decision on 278 00:15:00,280 --> 00:15:04,040 whether we need to include data or whether we reference data. 279 00:15:04,240 --> 00:15:06,920 Depending on your use case, you often have things which you 280 00:15:06,920 --> 00:15:09,200 don't need. Coming back to the Swiss land 281 00:15:09,200 --> 00:15:13,720 registries, you have hundreds of years of historical data and for 282 00:15:13,720 --> 00:15:16,280 most use cases you don't need historical data. 283 00:15:17,080 --> 00:15:19,920 So it makes sense in one way or another. 284 00:15:19,920 --> 00:15:23,480 And there are multiple options. Address what data the client 285 00:15:23,480 --> 00:15:25,480 needs and you could do many operations. 286 00:15:25,760 --> 00:15:29,040 You could do some parameters which there's a pattern called 287 00:15:29,040 --> 00:15:31,800 wish list. So I say I want this historic 288 00:15:31,800 --> 00:15:34,480 data or not. So it's just a boolean flag and 289 00:15:34,840 --> 00:15:38,600 if you set it you just get back 20 times the data what have If 290 00:15:38,600 --> 00:15:42,480 you have no historical data and if it gets more complex then you 291 00:15:42,480 --> 00:15:45,120 might have not only wish list but a wish template where you 292 00:15:45,120 --> 00:15:49,320 can define in your whole data structure and all the nested 293 00:15:49,320 --> 00:15:51,440 things what data you want to have or not. 294 00:15:51,440 --> 00:15:55,280 Which then closely or easily gets you to graph QL. 295 00:15:55,680 --> 00:15:59,160 And all-purpose is just to specify a request with exactly 296 00:15:59,160 --> 00:16:02,080 the data you need. And so there are many things you 297 00:16:02,080 --> 00:16:06,440 can do to adjust or trade off the number of requests and 298 00:16:06,840 --> 00:16:09,800 request size on the response size especially. 299 00:16:10,320 --> 00:16:13,600 And I think that's the point where we need to make more 300 00:16:13,600 --> 00:16:16,760 conscious decisions. On average, I think most people 301 00:16:16,760 --> 00:16:20,720 just dump out everything which they have and then at a certain 302 00:16:20,720 --> 00:16:25,040 point they just see OK, well it doesn't scale, the database load 303 00:16:25,160 --> 00:16:27,680 gets to have me and things are getting so slow. 304 00:16:30,080 --> 00:16:32,680 I hope you enjoyed this short clip from Tech Lead Journal 305 00:16:32,680 --> 00:16:35,520 Favorite Playlist. If you find this episode useful, 306 00:16:35,800 --> 00:16:38,480 please help share it with your friends and colleagues who you 307 00:16:38,480 --> 00:16:41,240 think would also benefit from listening to this episode. 308 00:16:41,680 --> 00:16:45,000 And if you want to listen more from this conversation, please 309 00:16:45,000 --> 00:16:48,040 go back and listen to the original full conversation with 310 00:16:48,040 --> 00:16:50,400 my guest. Stay tuned for the next Tech 311 00:16:50,400 --> 00:16:53,200 Lead Journal episode, and until then, goodbye.