WEBVTT NOTE This file was generated by Descript 00:00:00.581 --> 00:00:01.591 Track 1: Take it away, Phil. 00:00:02.025 --> 00:00:02.575 Phil S: Oh me, 00:00:02.825 --> 00:00:03.375 Track 1: Oh yeah. 00:00:04.336 --> 00:00:05.676 Phil S: How do you even do an intro? 00:00:05.676 --> 00:00:06.796 I haven't done it in so long. 00:00:07.086 --> 00:00:08.516 Uh, Hey everyone. 00:00:08.516 --> 00:00:09.996 Welcome to APIs you won't hate. 00:00:09.996 --> 00:00:12.276 I dunno what episode number this is or what day it is. 00:00:12.276 --> 00:00:13.356 But thank you for coming along. 00:00:13.516 --> 00:00:14.806 Track 1: That's what we like to hear. 00:00:14.806 --> 00:00:15.206 It's perfect. 00:00:15.803 --> 00:00:16.293 Phil S: Yeah. 00:00:16.293 --> 00:00:17.293 Do you wanna do the intro 00:00:18.668 --> 00:00:20.458 Track 1: Oh, you better believe I'm gonna use that. 00:00:20.731 --> 00:00:21.781 Phil S: I haven't done it in age years. 00:00:21.781 --> 00:00:22.621 Matt was doing it forever. 00:00:22.621 --> 00:00:25.581 And then you did it and yeah, I'm just, I'm just along for the ride. 00:00:25.581 --> 00:00:26.061 Half the time. 00:00:26.276 --> 00:00:28.566 Track 1: Yeah, I, it's just your velvety narrator voice, 00:00:28.566 --> 00:00:29.726 Phil, that the people come for. 00:00:30.110 --> 00:00:30.430 Whoa. 00:00:30.450 --> 00:00:31.550 Why don't we do it this way? 00:00:31.550 --> 00:00:34.250 Uh, Welcome to APIs you won't hate for the second time. 00:00:34.356 --> 00:00:35.476 My name is Mike bco. 00:00:35.476 --> 00:00:38.396 I am one of the, co runners of APIs you won't hate. 00:00:38.416 --> 00:00:41.526 I'm hanging out here today with Phil Sturgeon, and our good 00:00:41.526 --> 00:00:43.006 pale Steve McDougal from Treble. 00:00:43.166 --> 00:00:44.206 Phil, how are you doing 00:00:44.206 --> 00:00:44.486 today? 00:00:45.071 --> 00:00:45.811 Phil S: I'm pretty good. 00:00:45.811 --> 00:00:48.931 I've spent the whole morning out and about in the Woodlands up to my knees 00:00:48.931 --> 00:00:50.491 in mud, which is my happy place. 00:00:50.651 --> 00:00:53.131 And now I get to talk about APIs, which is my other happy place. 00:00:53.181 --> 00:00:54.811 So I'm excited that we got Steve 00:00:54.811 --> 00:00:55.091 along 00:00:55.091 --> 00:00:55.371 today. 00:00:55.371 --> 00:00:56.531 Thanks for coming, Steve. 00:00:56.711 --> 00:00:57.321 Steve McDougall: Thanks. 00:00:57.321 --> 00:00:58.121 Thanks for having me. 00:00:58.121 --> 00:00:59.641 So yeah, I'm really excited to be here. 00:00:59.641 --> 00:01:04.031 Obviously I've been a longtime listener, new in the kind of 00:01:04.031 --> 00:01:06.471 public facing API world right now. 00:01:06.481 --> 00:01:10.011 So I'm excited to, to have a chat about APIs. 00:01:10.596 --> 00:01:11.086 Track 1: Yeah. 00:01:11.086 --> 00:01:12.566 Well, uh, to have you here. 00:01:12.566 --> 00:01:13.526 Why don't we start this way? 00:01:13.526 --> 00:01:14.901 Uh, tell us little bit about yourself. 00:01:14.991 --> 00:01:15.442 Um, live? 00:01:15.442 --> 00:01:16.002 Where do you work? 00:01:16.002 --> 00:01:17.082 What have you been working on? 00:01:17.082 --> 00:01:17.802 How'd you get here? 00:01:18.680 --> 00:01:22.830 Steve McDougall: So I live in South Wales and I believe my house 00:01:22.830 --> 00:01:25.910 is probably gonna get turned into trees by fill at some point soon. 00:01:26.520 --> 00:01:31.500 But yeah, I've been in the API space for maybe six, seven years heavily on 00:01:31.500 --> 00:01:33.500 the PHP side using Lara Valve Slim. 00:01:34.385 --> 00:01:37.545 Recently you've been using framework X, which is really 00:01:37.545 --> 00:01:39.185 fast, asynchronous framework. 00:01:39.595 --> 00:01:42.645 Yeah, I do a lot of, a lot of talks around APIs. 00:01:42.835 --> 00:01:47.165 I do a lot of talks around integrating with APIs with a focus on kind of 00:01:47.165 --> 00:01:49.885 quality and scaling out the complexity. 00:01:50.515 --> 00:01:56.615 And my day-to-day has basically been building lots of tooling around 00:01:56.725 --> 00:01:59.735 APIs, so I'm in that API head. 00:02:00.145 --> 00:02:02.195 Phil S: So you've just started uh, working at Treble? 00:02:02.195 --> 00:02:02.475 Right. 00:02:02.575 --> 00:02:05.195 And I, I've come across Treble a bunch of times. 00:02:05.305 --> 00:02:10.912 I was on one of their Twitter circles a while ago and I think 00:02:10.912 --> 00:02:14.562 I chatted to them like right when they were starting out, but, Ages 00:02:14.562 --> 00:02:16.642 ago, and they do a bunch of stuff. 00:02:16.732 --> 00:02:20.082 So in a similar way to a lot of the tooling vendors, there's, there's so many 00:02:20.082 --> 00:02:21.442 different parts of the API lifecycle. 00:02:21.712 --> 00:02:24.562 Most tooling vendors don't want to just do one bit. 00:02:24.562 --> 00:02:25.802 They want to try and do a few. 00:02:25.902 --> 00:02:30.002 And so you guys have got an interesting different set, mostly 00:02:30.002 --> 00:02:31.442 with some overlap of stoplights. 00:02:31.442 --> 00:02:35.442 So I kind of bounced around treble a little bit then, but we've 00:02:35.442 --> 00:02:38.082 gotta mention that uh, Trevor in the past have sponsored the. 00:02:38.592 --> 00:02:41.452 But I don't listen to the podcast, so I don't know what they said about it. 00:02:41.582 --> 00:02:44.932 So, , so can you explain to me what's, what's going on with? 00:02:46.062 --> 00:02:49.952 Steve McDougall: Yeah, so we are currently scaling, we're hiring more engineers 00:02:49.952 --> 00:02:54.392 to help us build out better and higher quality tools, building out more tooling. 00:02:54.972 --> 00:02:57.312 And we're we're basically what you're. 00:02:58.182 --> 00:03:02.152 Google Analytics, but for your api, that is the best way to explain 00:03:02.152 --> 00:03:03.352 what Trevor is to most people. 00:03:03.595 --> 00:03:07.855 You could go into the observability, into the monitoring and explain all of 00:03:07.855 --> 00:03:12.255 that aspect of it, but I've always found the easiest way to explain it is just, 00:03:13.035 --> 00:03:14.965 it's like Google Analytics for your api. 00:03:15.432 --> 00:03:15.922 Phil S: Okay. 00:03:15.952 --> 00:03:16.442 Nice. 00:03:16.462 --> 00:03:20.762 And looking at it just bouncing around the homepage, I mean the, 00:03:20.762 --> 00:03:24.722 the API monitoring and observability stuff looks to me a little bit like 00:03:24.722 --> 00:03:26.682 New Relic, but kind of API focused. 00:03:26.788 --> 00:03:27.678 Steve McDougall: Yeah, similar. 00:03:27.775 --> 00:03:28.265 Phil S: Okay. 00:03:28.605 --> 00:03:29.085 Steve McDougall: very similar. 00:03:29.245 --> 00:03:33.885 One of our one of the clients I'm working with at the moment kind of described as, 00:03:33.885 --> 00:03:39.085 as a log rocket, but for their api, they use Log Rocket on the front end, and. 00:03:39.825 --> 00:03:43.325 Now currently trying out us on their APIs. 00:03:43.455 --> 00:03:43.805 So 00:03:44.322 --> 00:03:44.682 Phil S: Interesting. 00:03:44.682 --> 00:03:45.162 Okay. 00:03:45.342 --> 00:03:47.402 And then, so you've got the monitoring, but then it kind of 00:03:47.402 --> 00:03:50.002 moves into auto-generated API docs. 00:03:50.002 --> 00:03:51.082 How, how does that work? 00:03:51.476 --> 00:03:55.602 Steve McDougall: So basically every request that you make We log, we do ETL 00:03:55.602 --> 00:03:58.922 script on it to make sure that we're pulling out data, standardizing data 00:03:58.922 --> 00:04:01.282 formats, and adding it into our database. 00:04:01.502 --> 00:04:04.682 And while we're doing that, we're triggering lots of events to start 00:04:04.882 --> 00:04:08.522 building up paths and endpoints and query parameters, emerging query 00:04:08.522 --> 00:04:13.029 parameters, and we are just kind of merging and mangling data in the 00:04:13.029 --> 00:04:15.229 background to build out an open API spec. 00:04:15.229 --> 00:04:15.469 Basical. 00:04:16.474 --> 00:04:16.964 Phil S: Nice. 00:04:16.964 --> 00:04:17.804 That's pretty cool. 00:04:17.804 --> 00:04:18.524 There's, there's. 00:04:18.744 --> 00:04:19.944 People doing that now. 00:04:19.944 --> 00:04:23.424 Like I, the last post I just did the other day on, on APIs, you won hate 00:04:23.424 --> 00:04:27.521 blog was about using Optic to do that, which is a slightly different approach. 00:04:27.541 --> 00:04:32.081 You, you run a CLI script and then basically man in the middle, whatever, 00:04:32.271 --> 00:04:33.961 a API you feel like, man in the Midling. 00:04:34.121 --> 00:04:36.761 I was doing it for the master mastered on a api, which is pretty cool. 00:04:37.041 --> 00:04:42.641 But this, this will be kind of implemented by the API developer team 00:04:42.641 --> 00:04:44.521 or the CIS ops team or something. 00:04:44.521 --> 00:04:45.561 You just kind of shove that. 00:04:46.901 --> 00:04:49.171 No, it, it's not done at the server level. 00:04:49.171 --> 00:04:49.851 It's not like a proxy. 00:04:49.851 --> 00:04:51.211 It's done as like an sdk. 00:04:51.211 --> 00:04:52.571 How does it, how does it get that? 00:04:52.746 --> 00:04:56.486 Steve McDougall: our, well, we we're a, we've got an s STK as well, and basically 00:04:56.486 --> 00:05:02.216 it's just a, a piece of middleware that will capture the request of response. 00:05:03.256 --> 00:05:09.496 and then on the kind of termination of the script, we gather the data and send 00:05:09.496 --> 00:05:11.936 that off to our API to then be processed. 00:05:12.386 --> 00:05:14.696 So it's, yeah, it's a middleware basically. 00:05:14.706 --> 00:05:19.976 So one of the benefits that I found is that you can choose what 00:05:20.136 --> 00:05:21.096 endpoints you want to add it to. 00:05:22.351 --> 00:05:25.691 You can add it to all of them, add it to some of them, and you can slowly 00:05:25.691 --> 00:05:29.851 roll it out to make sure that you know you're getting the data you need. 00:05:30.031 --> 00:05:35.551 And because we are en we're enabling field masking that gentler rollout is 00:05:35.551 --> 00:05:40.551 sometimes recommended because sending over passwords, credit card numbers, email 00:05:40.551 --> 00:05:44.471 addresses, all of those sorts of things in a monitoring solution you don't want. 00:05:44.721 --> 00:05:49.716 So with our field masking every request and response, Goes through this masking 00:05:49.716 --> 00:05:55.876 process where we turn the value into stars of the same length, roughly. 00:05:56.006 --> 00:05:59.836 So that you're still getting the understanding of that data, but 00:05:59.836 --> 00:06:03.636 you're not passing that data, which keeps things a lot cleaner for you. 00:06:03.766 --> 00:06:10.696 There's no kind of data privacy worries about are they going to know my passwords? 00:06:11.016 --> 00:06:12.996 And it, it does that with the headers as well. 00:06:13.891 --> 00:06:17.291 , you, you kind of, we are masking all the different orth headers that you might 00:06:17.291 --> 00:06:19.531 have and custom orth headers as well. 00:06:19.581 --> 00:06:19.931 So 00:06:20.069 --> 00:06:21.879 Phil S: Okay, that's pretty smart to find it. 00:06:21.879 --> 00:06:26.239 I guess it's looking for like X hyphen a P i key and X hyphen 00:06:26.239 --> 00:06:27.759 authentication token, as well as 00:06:27.814 --> 00:06:30.704 Steve McDougall: yeah, we, we basically got a big list of different 00:06:30.704 --> 00:06:34.624 ones, uppercase, lowercase, spelt wrong, not spelt wrong, , just to 00:06:34.624 --> 00:06:36.624 try gather all of them basically. 00:06:37.284 --> 00:06:38.414 Phil S: Access tok. 00:06:39.144 --> 00:06:40.694 Um, fantastic. 00:06:40.804 --> 00:06:41.974 Okay, that sounds really handy. 00:06:42.004 --> 00:06:45.854 I, I like, I like the idea of it being a, a middleware and I like that there's 00:06:45.854 --> 00:06:49.454 different people doing different approaches cuz I know I wrote about aquita 00:06:49.454 --> 00:06:53.814 turning your HTP traffic into open API as well and there's a few more steps of 00:06:53.814 --> 00:06:57.344 indirection involved there cuz Again, Aquita is like a whole platform that does 00:06:57.344 --> 00:06:58.544 a bunch of different parts of the puzzle. 00:06:58.824 --> 00:07:02.624 And then you kind of export the open API out and they just added 00:07:02.624 --> 00:07:07.104 like a engine X module so you can really wedge it in at, at 00:07:07.269 --> 00:07:07.859 Steve McDougall: Oh, nice. 00:07:08.289 --> 00:07:08.779 Yeah, 00:07:09.024 --> 00:07:11.504 Phil S: that, that seems complicated and something that a lot of people 00:07:11.504 --> 00:07:14.824 can't necessarily do in certain hosting environments anyway, so. 00:07:15.349 --> 00:07:15.839 Steve McDougall: yeah. 00:07:15.839 --> 00:07:18.599 We are looking at different options at the moment as well. 00:07:18.599 --> 00:07:23.759 Like I was talking to one of our other devs the other day about could we create 00:07:23.759 --> 00:07:26.199 our own custom ingress for Kubernetes? 00:07:26.989 --> 00:07:31.099 So that we can just capture specific parts and then it's not 00:07:31.099 --> 00:07:32.419 handled within the web request. 00:07:32.419 --> 00:07:35.819 It's handled within the, the, the Kubernetes engine itself. 00:07:35.819 --> 00:07:37.779 We'll then send that data to us. 00:07:38.599 --> 00:07:41.019 But you know that that's probably something down the road once we've 00:07:41.019 --> 00:07:41.939 hired a few more people, I think. 00:07:42.744 --> 00:07:43.594 Phil S: Absolutely. 00:07:43.594 --> 00:07:47.464 Well, there was another approach that I think a previous job I was 00:07:47.464 --> 00:07:49.824 talking about trying to build this, I think Stoplight was trying to do 00:07:49.824 --> 00:07:50.984 it and WeWork was trying to hack it. 00:07:51.294 --> 00:07:55.867 But we were talking about trying to, cause we've got um, the Prism proxy, right? 00:07:55.867 --> 00:07:58.787 And that in previous versions, prism Proxy was doing some learning. 00:07:58.787 --> 00:08:00.027 It's not doing learning anymore. 00:08:00.347 --> 00:08:04.107 It does do a bit of like content validation to go like, oh, that's bad. 00:08:04.107 --> 00:08:05.547 You did an error, whatever. 00:08:05.947 --> 00:08:06.427 I'm telling. 00:08:07.112 --> 00:08:08.252 And, and all of that stuff. 00:08:08.252 --> 00:08:11.732 We only ever really got it as far as working in development and staging 00:08:11.732 --> 00:08:16.452 because we didn't really have the confidence in the production performance 00:08:16.452 --> 00:08:20.012 to say like, Hey, go wedge this into the critical path and I'm sure it'll be fine. 00:08:20.839 --> 00:08:24.539 And so we were kind of recommending a few bigger customers you can do like 00:08:24.589 --> 00:08:28.189 Traffic cloning or like traffic shadowing, I can't remember what it's called. 00:08:28.189 --> 00:08:31.069 So you basically in, in Kubernetes somewhere, say like, look for all 00:08:31.069 --> 00:08:32.109 these requests coming through. 00:08:32.219 --> 00:08:36.109 Take one in a hundred of them and just like fire 'em over this way as well. 00:08:36.169 --> 00:08:39.069 And then you just make sure the database doesn't do anything and you have to 00:08:39.069 --> 00:08:41.869 build like a separate environment that's just like a, a castrated 00:08:41.869 --> 00:08:43.069 version of the royal production. 00:08:43.309 --> 00:08:43.659 Steve McDougall: It. 00:08:43.659 --> 00:08:47.659 It sounds like a lot of juggling just to get that simple kind 00:08:47.659 --> 00:08:48.739 of logging effort, right? 00:08:48.934 --> 00:08:49.534 Phil S: Exactly. 00:08:49.534 --> 00:08:49.854 Yeah. 00:08:49.854 --> 00:08:53.054 But then on the other hand, like with, with your sdk, it's super simple cause 00:08:53.054 --> 00:08:57.214 it's just in the code there, but then that's still kind of slowing things down. 00:08:57.414 --> 00:09:00.534 Although if it's after the person got there, Jason, maybe that doesn't matter. 00:09:00.544 --> 00:09:03.934 So there's, there's like a bunch of different ways of like pros and 00:09:03.934 --> 00:09:06.014 cons of, of how to get that stuff. 00:09:06.394 --> 00:09:06.814 And 00:09:07.029 --> 00:09:07.669 Steve McDougall: definitely. 00:09:08.244 --> 00:09:11.344 And that's one of the struggles that I'm working on this week actually. 00:09:11.634 --> 00:09:15.204 I was working with the people from React, P h p, working 00:09:15.204 --> 00:09:16.574 on asynchronous middleware. 00:09:17.024 --> 00:09:24.094 So what I can do is I can send a H E T P request asynchronously in P H P, 00:09:24.094 --> 00:09:29.047 and while that's running, I can return that response and then deal with any 00:09:29.047 --> 00:09:31.647 failures within that asynchronous process. 00:09:32.667 --> 00:09:33.627 Phil S: Yeah, that's brilliant. 00:09:33.627 --> 00:09:34.227 That's what you want. 00:09:34.227 --> 00:09:36.747 I mean, yeah, obviously I have no idea how the SDK works, but that 00:09:37.107 --> 00:09:38.547 , that sounds like a good approach. 00:09:38.872 --> 00:09:42.912 Steve McDougall: currently not like that, but , I'm this refactoring effort at the 00:09:42.912 --> 00:09:47.632 minute where I'm looking at our p the PHP ecosystem for our SDKs to make sure we 00:09:47.632 --> 00:09:53.032 support a wide bunch of frameworks as, as well as, you know, psr 15 middleware 00:09:53.032 --> 00:09:55.312 as well for those kind of build your own. 00:09:55.802 --> 00:09:57.832 So yeah, I'm, I'm trying to assess all. 00:09:58.702 --> 00:10:02.412 To try and figure out what the best approach is so that I'm not forcing 00:10:02.412 --> 00:10:04.452 dependencies on any one framework. 00:10:05.302 --> 00:10:08.162 So it, it's been a juggle definitely. 00:10:08.177 --> 00:10:10.897 Phil S: guessing, I'm guessing that a lot of the different SDKs in different 00:10:11.017 --> 00:10:12.137 languages will work differently as well. 00:10:12.137 --> 00:10:15.137 So I'm, you know, we are probably by default talking about PHP 00:10:15.137 --> 00:10:17.297 without really mentioning it there, cuz that's our backgrounds. 00:10:17.577 --> 00:10:21.057 But I'm sure, I'm sure like the node one is asynchronous by default or whatever. 00:10:21.057 --> 00:10:24.182 So, Just gotta try and find different ways to make it work. 00:10:24.692 --> 00:10:28.702 I thematically, or whatever the correct word is, I just, I just do tree stuff now. 00:10:28.702 --> 00:10:29.342 I forget words. 00:10:30.842 --> 00:10:31.772 Steve McDougall: I forget words. 00:10:31.772 --> 00:10:32.412 I just know. 00:10:32.612 --> 00:10:33.172 Birch 00:10:33.682 --> 00:10:34.372 Phil S: concepts. 00:10:35.592 --> 00:10:36.012 Yep. 00:10:36.677 --> 00:10:39.854 Track 1: so Steve, I'm a little bit curious about, um, end user benefits 00:10:39.904 --> 00:10:41.821 of, uh, adding trouble to your system. 00:10:41.871 --> 00:10:46.401 So, made the comparison before between treble and uh, right? 00:10:46.401 --> 00:10:48.241 Sort of the log rocket for your APIs. 00:10:48.451 --> 00:10:52.181 Um, used Log Rocket before and am a big fan of it for the applications 00:10:52.181 --> 00:10:53.541 that I build for the web and whatnot. 00:10:53.951 --> 00:10:56.901 Um, assuming I had never been exposed to Log Rocket before, 00:10:56.901 --> 00:10:57.981 what the heck does that mean? 00:10:57.981 --> 00:10:58.581 What do I get? 00:10:59.432 --> 00:11:03.242 Steve McDougall: so what you get is you can have multiple projects, obviously. 00:11:03.452 --> 00:11:07.332 Um, Maybe you've got internal APIs, external APIs, and you want to kind of 00:11:07.332 --> 00:11:09.572 keep all of them, you know, separate. 00:11:10.222 --> 00:11:15.212 We capture the requests, the response, response time, request time, the total 00:11:15.212 --> 00:11:17.332 low time so that you can start to see. 00:11:18.572 --> 00:11:22.622 Perhaps you're getting issues in that API lifecycle, in that 00:11:22.622 --> 00:11:23.862 request response lifecycle. 00:11:24.312 --> 00:11:29.582 We capture bugs, we capture that full kind of stack trace from the 00:11:29.582 --> 00:11:35.262 exception and handlers so that you can see bugs that are introduced. 00:11:35.562 --> 00:11:37.742 And this is like over time, for example. 00:11:37.742 --> 00:11:40.462 So let's say you do a big feature deployment and it 00:11:40.462 --> 00:11:41.622 breaks a couple of endpoints. 00:11:41.802 --> 00:11:44.142 You can kind of pinpoint that back down through. 00:11:44.981 --> 00:11:48.381 Tracing through the requests, seeing where those errors were back on. 00:11:48.621 --> 00:11:52.901 Were, were starting to be introduced and we're, we are looking at building out 00:11:52.901 --> 00:11:57.651 a, a, you know, a fully fledged alerting system as well, and enabling you to 00:11:57.651 --> 00:12:00.251 ignore certain errors within your api. 00:12:00.311 --> 00:12:05.601 For example, with with Laravel, for example, if I return a 4 22 00:12:05.871 --> 00:12:09.161 from Laravel, it means that my validation's failed in Laravel. 00:12:09.906 --> 00:12:12.236 That's currently being reported as a problem. 00:12:12.526 --> 00:12:16.596 However, it's technically not an API problem, it's a user problem. 00:12:16.966 --> 00:12:22.716 So we're looking at extending rsdk to say that you can ignore specific exceptions 00:12:23.576 --> 00:12:24.066 Track 1: Yeah. 00:12:24.286 --> 00:12:27.326 Steve McDougall: that they aren't reported as an actual problem cuz it's 00:12:27.436 --> 00:12:31.936 a user problem or an implementation problem, not a API problem. 00:12:31.936 --> 00:12:32.256 As. 00:12:32.261 --> 00:12:32.821 Track 1: right? 00:12:32.821 --> 00:12:33.101 Yeah. 00:12:33.101 --> 00:12:36.924 And I guess when you're trying to assess how your, um, system is running, uh, are 00:12:36.924 --> 00:12:38.404 working as they should, you don't wanna 00:12:38.404 --> 00:12:39.244 report that as a problem? 00:12:39.824 --> 00:12:40.524 Yes, sir. 00:12:40.639 --> 00:12:42.959 Steve McDougall: You don't wanna report that someone's trying to 00:12:43.199 --> 00:12:47.159 register again, using the same email address as a API problem. 00:12:47.159 --> 00:12:47.479 Right. 00:12:47.479 --> 00:12:50.119 Because it's not, it's, it's a human problem at that point. 00:12:50.269 --> 00:12:53.016 Track 1: I think it's interesting too that, um, getting a bunch of 00:12:53.016 --> 00:12:56.416 information in addition to just whether things are working or 00:12:56.416 --> 00:12:58.896 failing or crashing, whether you're getting errors and things like that. 00:12:58.896 --> 00:13:01.416 Especially in a world where people are starting to talk 00:13:01.416 --> 00:13:02.976 way more about, uh, between. 00:13:03.716 --> 00:13:07.156 typical lambda serverless functions and edge functions and all that. 00:13:07.606 --> 00:13:11.436 Uh, sort of like technical debt creep that can happen where your, 00:13:11.686 --> 00:13:15.596 um, can become slow and slow, can be the problem not failing, right? 00:13:15.596 --> 00:13:18.716 You're things can start to feel like they're kind of creeping along and 00:13:18.716 --> 00:13:21.356 having some sort of intelligence behind the scenes to be able to track like, 00:13:21.356 --> 00:13:24.989 hey, which calls are getting slow, help your engineering teams to, to 00:13:24.989 --> 00:13:25.829 trace that all down. 00:13:26.319 --> 00:13:26.669 Um, 00:13:27.154 --> 00:13:27.834 Steve McDougall: massively. 00:13:27.834 --> 00:13:30.744 I'm, I'm currently working with our engineering team at the minute to 00:13:30.744 --> 00:13:36.384 implement, a re-architected approach to how we're logging things so that 00:13:36.384 --> 00:13:39.584 we're gonna have much more intelligence on the reports that we can generate. 00:13:39.714 --> 00:13:44.064 So, you know, you can pinpoint the exact request when it was, why it 00:13:44.064 --> 00:13:45.824 was what happened, and a lot more. 00:13:45.924 --> 00:13:49.784 And we're also jumping on that bandwagon of G P T and saying, 00:13:49.784 --> 00:13:51.224 okay, so what can we actually. 00:13:51.744 --> 00:13:55.514 What, what could we, what information could we get from AI on this? 00:13:55.514 --> 00:13:59.997 What, you know, we, we've obviously got a lot of generating going on 00:13:59.997 --> 00:14:02.597 for building out an open API spec. 00:14:02.887 --> 00:14:05.837 Is there any way that we could improve upon that? 00:14:06.119 --> 00:14:06.479 Track 1: of course. 00:14:06.479 --> 00:14:11.239 And behind the scenes, those G p t uh, are really good at noticing patterns that are 00:14:11.479 --> 00:14:13.219 probably not, uh, apparent to you and me. 00:14:13.954 --> 00:14:14.884 Steve McDougall: yeah, exactly. 00:14:14.899 --> 00:14:15.859 Track 1: superpower in itself. 00:14:16.579 --> 00:14:18.819 imagine when adding trouble to your service. 00:14:19.139 --> 00:14:21.499 Actually, one of the things I saw on your site earlier, I was kind of browsing 00:14:21.499 --> 00:14:25.929 around, is that I think you get something like 50 data points for every API call, as 00:14:25.929 --> 00:14:27.729 part of the kind of analytics end of this. 00:14:28.019 --> 00:14:29.469 Um, that feels like a lot, right? 00:14:29.469 --> 00:14:30.909 Like that can be imposing at first. 00:14:30.909 --> 00:14:33.509 If you're, if you're working with a team that's just adopting trouble, 00:14:33.509 --> 00:14:36.589 like what are some of the first things you tell them to look for or look at 00:14:36.589 --> 00:14:38.229 or optimize for when they're working? 00:14:39.021 --> 00:14:40.891 Steve McDougall: To be honest, I've not worked with many people 00:14:41.041 --> 00:14:42.771 onboarding who have asked questions. 00:14:42.771 --> 00:14:46.114 I've only been here three weeks, the only thing I've dealt with 00:14:46.114 --> 00:14:47.834 so far is uh, talking about. 00:14:48.129 --> 00:14:51.549 You know, how much of a bottleneck is it gonna cause with it being 00:14:51.549 --> 00:14:53.309 middleware and sending a request? 00:14:53.569 --> 00:14:54.549 Had to explain that. 00:14:54.549 --> 00:14:55.709 It's terminating middleware. 00:14:55.709 --> 00:15:00.812 So it's at the end of that PHP CGI process or you know, FPM process. 00:15:01.182 --> 00:15:04.172 It triggers a terminate command, and then that middleware triggers 00:15:04.509 --> 00:15:09.532 talked about data leakage and using the masked fields to be honest. 00:15:10.089 --> 00:15:13.249 The hardest thing is getting people to understand what it gives you. 00:15:13.559 --> 00:15:15.889 When it's just like, well, I know I'm sending a request. 00:15:15.889 --> 00:15:17.169 I know I'm getting a response. 00:15:17.799 --> 00:15:24.129 I, you know, I could probably generate an open API spec using an open source tool. 00:15:24.399 --> 00:15:28.059 But what that isn't telling you is what's being used, how much it's 00:15:28.059 --> 00:15:32.219 being used, which is the most popular endpoints, which is the slowest endpoint. 00:15:32.219 --> 00:15:35.019 Where is where your request body is starting to get a 00:15:35.019 --> 00:15:36.019 little bit too excessive? 00:15:36.209 --> 00:15:37.019 Should you. 00:15:38.049 --> 00:15:44.616 introducing Jason API specification so that you can tweak that payload coming 00:15:44.616 --> 00:15:47.536 back a little bit more because your response size is getting a little bit 00:15:47.536 --> 00:15:49.376 too big and taking a little bit too long. 00:15:49.726 --> 00:15:54.599 So yeah, there's, there's lots of things we have to do when we are onboarding 00:15:54.599 --> 00:15:58.999 people to explain what you can do and how to get the most out of it. 00:15:59.532 --> 00:16:03.432 And part of my job is to record and create content around that as well. 00:16:03.482 --> 00:16:09.044 So, I'm gonna be creating videos around, I'm gonna be able a really bad API for 00:16:09.044 --> 00:16:15.084 fun and stick it through treble and see how much I can improve it based on just 00:16:15.084 --> 00:16:19.804 using those insights instead of me using my brain and thinking, oh, I know this is 00:16:19.804 --> 00:16:21.684 gonna be a problem, I'm gonna take that. 00:16:21.794 --> 00:16:24.804 I might even get someone else to join me on it and get them to do 00:16:24.804 --> 00:16:27.284 it . Cause I know that habits can die. 00:16:27.974 --> 00:16:31.614 And just see how much improvements we can get on an API based 00:16:31.614 --> 00:16:33.414 off of just that insight. 00:16:33.716 --> 00:16:37.506 Phil S: As a consultant in APIs and as a, like someone who's worked on dev 00:16:37.506 --> 00:16:41.266 tools, I have this really interesting kind of thing where I'm, we're building 00:16:41.266 --> 00:16:45.306 these dev tools to try and solve problems and then the people don't 00:16:45.306 --> 00:16:47.986 necessarily know that they need them cuz they've just got shit breaking. 00:16:47.986 --> 00:16:51.106 If, if some shit's breaking and some stuff's going slow, then they're like 00:16:51.386 --> 00:16:54.786 looking at some exceptions and saying, oh, you should probably fix that. 00:16:54.786 --> 00:16:57.346 And it is very much like a how do we fix the problem that happened? 00:16:57.826 --> 00:16:58.426 But then. 00:16:59.336 --> 00:17:00.096 They don't really. 00:17:00.551 --> 00:17:03.201 I've worked with so many teams that don't really recognize there's so much 00:17:03.201 --> 00:17:05.121 more than just the code exceptions. 00:17:05.121 --> 00:17:07.881 Like you get some exceptions or you get some slowness, or you might 00:17:07.881 --> 00:17:09.001 not even know it's going slow. 00:17:09.001 --> 00:17:12.201 Like, how do you know that something was slow or someone complained about it? 00:17:12.201 --> 00:17:14.801 Well, how many customers did you lose before they complained? 00:17:15.336 --> 00:17:16.146 Steve McDougall: yeah, exactly. 00:17:16.281 --> 00:17:17.961 Phil S: they do complain, you're just like, well, I don't know. 00:17:17.961 --> 00:17:18.881 It seems all right to me. 00:17:18.881 --> 00:17:21.001 And you get some really weird scenario where 00:17:21.006 --> 00:17:22.326 Steve McDougall: Works on my machine 00:17:22.441 --> 00:17:23.121 Phil S: month or something. 00:17:23.121 --> 00:17:23.401 Yeah. 00:17:23.747 --> 00:17:26.607 And so, or there's this, like, we've had this crazy thing where, you 00:17:26.607 --> 00:17:30.439 know uh, One CR job would run like, you know, once a month and then 00:17:30.439 --> 00:17:31.839 requests would be really slow then. 00:17:31.839 --> 00:17:36.319 So someone would complain about the a p i being slow and then you check it out 00:17:36.519 --> 00:17:37.439 tomorrow, you're like, nah, that's fine. 00:17:37.439 --> 00:17:37.839 You're mad. 00:17:38.129 --> 00:17:41.679 So being able to look back in time and see that kind of the performance, 00:17:42.229 --> 00:17:44.209 just graphs and stuff are super handy. 00:17:44.429 --> 00:17:46.729 But then people don't know that they need that. 00:17:46.729 --> 00:17:48.929 Cuz if you are, like I said, if you're getting complaints, you, 00:17:48.929 --> 00:17:52.249 you, you wanna try and treat the the symptom or the why, no. 00:17:52.249 --> 00:17:54.609 You wanna try and treat the specific problem at the time and 00:17:54.674 --> 00:17:57.484 Steve McDougall: Yeah, you wanna, you wanna treat the cause, not the symptoms. 00:17:57.484 --> 00:17:57.724 Right? 00:17:57.899 --> 00:17:58.389 Phil S: Yeah. 00:17:59.159 --> 00:17:59.649 Yeah, 00:17:59.794 --> 00:18:04.224 Steve McDougall: So, you know, before I started down this journey 00:18:04.354 --> 00:18:08.234 of API monitoring on observability stuff you know, the typical 00:18:08.514 --> 00:18:09.474 approach would be, oh, I don't know. 00:18:10.634 --> 00:18:14.874 I'll install Century and I'll get all my logs and I'll enable 00:18:14.874 --> 00:18:18.954 performance monitoring, and if anything notifies me, I'll deal with it. 00:18:19.214 --> 00:18:22.227 But that's, you know, you've gotta, sometimes you've gotta take that 00:18:22.227 --> 00:18:24.707 proactive approach when you're trying to build a good product, right? 00:18:25.007 --> 00:18:28.267 You got proactively search for ways to improve what you've got. 00:18:28.267 --> 00:18:31.747 If, if you're not building new features, you're improving what you've got. 00:18:31.837 --> 00:18:35.067 So it's just a tool to enable you to do that at the end of the day, isn't it? 00:18:35.922 --> 00:18:36.642 Phil S: Yeah, exactly. 00:18:36.672 --> 00:18:40.602 I mean, I, I basically lived in New Relic and went at previous jobs 00:18:40.602 --> 00:18:43.882 and it, it seems like this would be more useful than that cuz it. 00:18:44.102 --> 00:18:45.902 Targeted APIs, I had to kind of 00:18:46.462 --> 00:18:48.902 convince it to, to, to tell me what I wanted a lot of the time. 00:18:48.902 --> 00:18:50.822 And I'm sure they've changed in the years since I've used it. 00:18:50.822 --> 00:18:55.602 But yeah, like that was my, my job as kind of API governance before API governance 00:18:55.602 --> 00:18:59.762 existed was just to snoop around New Relic, see what was happening and, and 00:19:00.182 --> 00:19:04.322 the development teams maintaining those APIs Would, if there was an, an error 00:19:04.412 --> 00:19:08.002 or, you know, something bad in the logs, they would, they would usually get told 00:19:08.002 --> 00:19:09.482 about it and they would usually fix it. 00:19:09.542 --> 00:19:11.562 But it was, it was trying to find all the things that. 00:19:12.322 --> 00:19:13.602 Weren't problems yet. 00:19:13.842 --> 00:19:15.642 Things that were on their way to being problems 00:19:15.756 --> 00:19:16.246 Steve McDougall: Yeah. 00:19:16.246 --> 00:19:19.326 And the problem with things like that is that you're not spotting trends, are you? 00:19:19.326 --> 00:19:19.966 You're just seeing. 00:19:20.741 --> 00:19:23.851 Oh, it took 52 milliseconds to do that. 00:19:23.851 --> 00:19:25.091 It took this long to do that. 00:19:25.091 --> 00:19:30.451 It was doing this, his a SQL query that was ran and you know, you're not seeing, 00:19:30.961 --> 00:19:37.131 okay, this response payload's huge or this response load time is increasing. 00:19:37.281 --> 00:19:41.171 You're not seeing that information when you're just kind of scrolling 00:19:41.171 --> 00:19:44.971 through performance metrics from Century or New Relic or anything. 00:19:45.731 --> 00:19:45.931 Phil S: Right? 00:19:45.931 --> 00:19:48.891 And so is that what the treble API score is all about? 00:19:48.891 --> 00:19:52.931 Is, is trying to remove some of that, like trying to guess at what's good 00:19:52.931 --> 00:19:54.411 or bad and just basically saying, 00:19:54.511 --> 00:19:55.641 Steve McDougall: Yeah, basically. 00:19:56.001 --> 00:19:57.011 Phil S: that's kind of cool. 00:19:57.231 --> 00:20:00.651 Steve McDougall: And I, I'm currently building out monthly reports at 00:20:00.651 --> 00:20:03.771 the moment as well, so that you can see, you know, for, cause I 00:20:03.771 --> 00:20:04.811 used to be an engineering manager. 00:20:04.811 --> 00:20:08.131 One thing that was important to me was, you know, what is our 00:20:08.131 --> 00:20:09.331 performance like over the last month? 00:20:09.331 --> 00:20:10.251 Has it gone up or down? 00:20:11.016 --> 00:20:12.786 It's a low time going up or down. 00:20:12.836 --> 00:20:13.826 Is this an issue? 00:20:13.896 --> 00:20:19.106 Memory consumption being increased to see, you know, sometimes a 00:20:19.106 --> 00:20:22.626 PR slips through that causes a bug that you don't know about. 00:20:22.626 --> 00:20:24.506 Maybe use with more memory. 00:20:24.626 --> 00:20:27.786 Maybe it locks a database for X amount of seconds. 00:20:28.182 --> 00:20:29.082 You, we, yeah. 00:20:29.082 --> 00:20:32.882 You don't see that unless you can kind of get that holistic overview 00:20:33.172 --> 00:20:35.552 on, you know, the last 30 days. 00:20:36.822 --> 00:20:39.102 Response times gun up by X percent. 00:20:39.349 --> 00:20:41.719 Your low times gun up by this. 00:20:43.109 --> 00:20:46.469 Phil S: really interesting cuz I think, again, in when I've worked 00:20:46.469 --> 00:20:48.069 on this sort of thing, people like. 00:20:48.684 --> 00:20:51.774 Look at the graph, look at the response time. 00:20:51.774 --> 00:20:55.134 I mean the, the classic New Relic graph of like median time, so it's not even, 00:20:55.134 --> 00:20:58.134 it's not even showing you the percentiles, it's just like, on average it looks fine. 00:20:58.454 --> 00:21:03.394 And, and even then you're kind of looking at a graph and depends on how thick your 00:21:03.394 --> 00:21:06.794 glasses are and whether you can spot the fact that it's gone up by 2% over the 00:21:06.889 --> 00:21:09.139 Steve McDougall: Especially as they don't, yeah, they don't, they don't 00:21:09.139 --> 00:21:12.499 allow you to zoom on the graph, so it's like you are looking at 30 days 00:21:12.499 --> 00:21:14.179 and you can't really tell that much. 00:21:14.389 --> 00:21:14.949 Phil S: Exactly. 00:21:14.949 --> 00:21:18.869 So like if, if your application is getting slower by 2% every month or 00:21:19.029 --> 00:21:21.549 whatever, there's gonna be some serious trouble in a couple of months and, 00:21:21.649 --> 00:21:22.619 Steve McDougall: Yeah, exactly. 00:21:22.669 --> 00:21:23.589 Phil S: just by looking to graph. 00:21:23.589 --> 00:21:26.829 So if you can kind of let people know that sort of trend, that's really helpful. 00:21:28.039 --> 00:21:28.279 Steve McDougall: Yeah. 00:21:28.279 --> 00:21:33.449 It's again, it's taking the metrics and spinning it into something that's 00:21:33.449 --> 00:21:37.009 a little bit more proactive for someone that they, they can act upon 00:21:37.009 --> 00:21:40.169 and not just have to search to try and find, cuz they may not think of it. 00:21:41.399 --> 00:21:42.439 Phil S: Yeah, that's cool. 00:21:43.339 --> 00:21:47.049 On the topic of API scores, it's something that we, we always talked 00:21:47.049 --> 00:21:49.889 about doing with spectral, and I don't know what they're up to these days. 00:21:49.889 --> 00:21:53.409 I don't work there now, but the the idea of an API score we were going for 00:21:53.409 --> 00:21:57.569 we were working on like looking at open API and then judging your API on that and 00:21:57.569 --> 00:22:01.592 . Saying like um, oh this is inconsistent. 00:22:01.592 --> 00:22:02.632 This breaks these rules. 00:22:02.632 --> 00:22:03.832 It's kind of the opposite of Lin. 00:22:03.832 --> 00:22:07.912 Instead of saying, here are problems, it just kind of says you don't have any 00:22:07.912 --> 00:22:10.032 problems or you're an a plus plus a api. 00:22:10.252 --> 00:22:12.632 And it, it really makes me want to get back to it. 00:22:12.632 --> 00:22:16.472 Cause if you can have a design score and then like a performance 00:22:16.472 --> 00:22:17.912 score, that would be super cool. 00:22:19.097 --> 00:22:21.837 Steve McDougall: I'm actually, I was working on that not 00:22:21.837 --> 00:22:22.877 last week, the week before. 00:22:23.227 --> 00:22:26.957 I spent literally the whole week going through every page of the 00:22:26.957 --> 00:22:33.797 open API specification, converting that to data objects so that I 00:22:33.797 --> 00:22:37.677 can pass an open API spec, pass it in, and start to do calculations. 00:22:38.436 --> 00:22:40.896 you know, data that I actually know and understand. 00:22:41.346 --> 00:22:45.136 My eyes were, you know, very kind of bleeding by the end of the week 00:22:45.136 --> 00:22:46.576 once I'd finished building all of it. 00:22:46.916 --> 00:22:50.089 But yeah, it was um, it's coming. 00:22:50.699 --> 00:22:54.529 We, we are currently doing, we've got a big list of metrics, which 00:22:54.529 --> 00:22:57.929 we're gonna check against once we've got that open API spec. 00:22:58.469 --> 00:23:00.489 And what we're gonna be doing is we're actually gonna 00:23:00.489 --> 00:23:02.969 release that part as a free. 00:23:04.164 --> 00:23:08.954 So it'll be under, like, once it's built, it'll be like insights treble.com and you 00:23:08.954 --> 00:23:14.834 can either pass the URL to your open API spec, paste it in, or upload the file. 00:23:15.054 --> 00:23:19.434 And what we'll do is we'll build, pass and give you a score and give 00:23:19.434 --> 00:23:21.714 you, kind of hear other problems. 00:23:22.144 --> 00:23:26.394 Here is where you're doing well, things like, are you using restful patterns? 00:23:26.394 --> 00:23:26.754 Yes. 00:23:27.774 --> 00:23:30.154 Authentication percentage and all those sorts of things. 00:23:30.446 --> 00:23:31.056 Phil S: That's 00:23:31.091 --> 00:23:33.611 Steve McDougall: that will be a, a free tool for people to just use 00:23:34.576 --> 00:23:39.856 Phil S: Do you guys have any sort of do you folks have any sort of like green 00:23:39.856 --> 00:23:42.266 tech ideas in your, in your roadmap? 00:23:42.266 --> 00:23:44.866 Because I would love to talk to some of you folks about that, if not. 00:23:46.141 --> 00:23:46.491 Steve McDougall: it. 00:23:46.491 --> 00:23:47.771 It's something that's on my mind. 00:23:48.181 --> 00:23:52.801 I'm very much aware that a platform like ours, which deals with analytics, can 00:23:52.801 --> 00:23:57.111 quite easily increase carbon usage by. 00:23:58.136 --> 00:24:01.996 You know, a new client coming on board who's got a very busy api, 00:24:01.996 --> 00:24:05.156 suddenly our carbon footprint goes from X to X plus seven. 00:24:05.926 --> 00:24:09.426 And definitely looking at what the options are for that, and we are 00:24:09.426 --> 00:24:13.266 currently having discussions internally about how our application works, 00:24:13.266 --> 00:24:18.066 how it performs, and what we can do to kind of shrink that a little. 00:24:18.406 --> 00:24:19.696 Phil S: that's really interesting. 00:24:19.696 --> 00:24:23.176 That's, that's less, less what I meant, but really interesting or the same. 00:24:23.526 --> 00:24:27.426 What I mean is Knowing and doing something about the carbon footprint of 00:24:27.426 --> 00:24:31.406 your organization and your application wherever you may work, is a good thing. 00:24:31.406 --> 00:24:33.286 That's kind of making tech green. 00:24:33.656 --> 00:24:37.076 But kind of helping other people make their tech green is something 00:24:37.076 --> 00:24:40.316 that, that treble or any analytics software could really help with. 00:24:40.316 --> 00:24:44.116 Like, I've toyed around with the idea for ages of coming up with some 00:24:44.116 --> 00:24:47.516 sort of tool, some sort of proxy that would just look at all the traffic 00:24:47.516 --> 00:24:50.396 coming through and being like, you could have put a cash header on that. 00:24:50.396 --> 00:24:51.436 It's been exactly the. 00:24:51.876 --> 00:24:54.236 99% of the time, what are you doing? 00:24:54.646 --> 00:24:58.306 And there's a bunch of other like tweaks and suggestions you could make to people. 00:24:58.306 --> 00:25:01.386 Like if, if someone's making the same request over and over again, you 00:25:01.386 --> 00:25:04.386 could even just say like, you know, that could be a head request or, or, 00:25:04.386 --> 00:25:05.466 there's a lot of different stuff. 00:25:05.996 --> 00:25:10.016 And I think that that could be really powerful for an analytics company 00:25:10.141 --> 00:25:13.991 Steve McDougall: I mean, we have those sorts of that information already, so, 00:25:14.241 --> 00:25:18.391 so as it'll be something, you know, I, I'd speak to the designer and say, okay, 00:25:18.391 --> 00:25:25.151 can you design something cool so that on a project or on an endpoint, I can add 00:25:25.151 --> 00:25:28.951 a badge and say, you know, you've got a green bonus, which boosts your API score. 00:25:30.381 --> 00:25:30.871 Phil S: Yeah, 00:25:31.171 --> 00:25:34.181 Steve McDougall: That, that sort of thing to say, you know, you 00:25:34.181 --> 00:25:37.421 are actually using caching, you're limiting your response size. 00:25:38.041 --> 00:25:43.011 You, you know, you, you're following a practice, which is perhaps more green 00:25:43.011 --> 00:25:45.411 than I'll just make another API request. 00:25:46.281 --> 00:25:46.951 Phil S: Exactly. 00:25:47.141 --> 00:25:47.631 Yeah. 00:25:47.631 --> 00:25:50.431 That's something that I think we're gonna talk about a lot more as a few 00:25:50.431 --> 00:25:52.431 guests that I'm lining up to, to talk 00:25:52.431 --> 00:25:54.191 about more green tech stuff in depth. 00:25:54.191 --> 00:25:57.711 I know that you've kind of looked into it a bit and, and you suffer the fire hose. 00:25:57.711 --> 00:25:59.711 That is my Twitter profile, so you see me banging 00:25:59.791 --> 00:26:00.211 Steve McDougall: Yep. 00:26:00.271 --> 00:26:00.391 Phil S: there. 00:26:00.791 --> 00:26:04.551 But , God knows what's coming up on there next, but yeah I think the, the green tech 00:26:04.551 --> 00:26:07.111 angle is something obviously I'm super passionate about, and I think there's. 00:26:07.581 --> 00:26:10.501 There's a lot more people starting to notice that we can, we can really do 00:26:10.501 --> 00:26:13.621 something about this cuz I, I forgot all the numbers, but like the internet 00:26:13.621 --> 00:26:16.171 is the 2%, 4% of global emissions. 00:26:16.171 --> 00:26:17.251 Like it's, it is growing. 00:26:17.251 --> 00:26:19.251 It's the same as flying and getting worse. 00:26:19.611 --> 00:26:23.411 And of that like 85% is API traffic. 00:26:23.551 --> 00:26:27.731 And so if we can like put a little dent in that, just by helping people 00:26:27.731 --> 00:26:29.891 realize they should, they could have cashed something where they 00:26:29.891 --> 00:26:30.891 weren't thinking about it before. 00:26:31.416 --> 00:26:34.346 That seems pretty helpful, especially if you can show a graph going down. 00:26:34.366 --> 00:26:38.066 You can even have people selling carbon credits off the back of it or something. 00:26:38.066 --> 00:26:40.986 Or at least kind of that, at least their company can pat themselves 00:26:40.986 --> 00:26:41.946 on the back for doing it. 00:26:41.946 --> 00:26:42.626 But yeah, 00:26:42.756 --> 00:26:43.566 Steve McDougall: Yeah, exactly. 00:26:43.786 --> 00:26:44.786 Phil S: emissions go down is a good thing. 00:26:45.216 --> 00:26:45.706 Cool. 00:26:46.106 --> 00:26:48.186 Steve McDougall: I've found is that a lot of developers only 00:26:48.186 --> 00:26:50.066 understand certain levels of caching. 00:26:50.956 --> 00:26:55.286 So a lot of the questions I get asked all the time, cuz I do lots of tutorials 00:26:55.286 --> 00:26:58.846 and live streams and that sort of stuff, is, how can I properly cash? 00:26:59.146 --> 00:27:02.646 You know, how can I enable cashing on my API or on my application? 00:27:02.646 --> 00:27:07.426 It's like, well, it depends on what you, what your application does. 00:27:07.566 --> 00:27:09.986 You know, you need to build out a cash strategy to 00:27:09.986 --> 00:27:11.426 understand that and understand. 00:27:11.946 --> 00:27:15.226 Kind of some of the business logic to know what you can cash and for how 00:27:15.226 --> 00:27:21.216 long, but it seems that there's a big lack of, well, a big gap of knowledge 00:27:21.216 --> 00:27:25.376 just missing in, in some areas where people don't understand how to cash, 00:27:26.221 --> 00:27:26.711 Phil S: Yeah. 00:27:26.926 --> 00:27:29.526 Steve McDougall: which again, would really help on that green front, right. 00:27:30.411 --> 00:27:31.261 Phil S: Absolutely. 00:27:31.261 --> 00:27:33.301 I feel guilty cause I've not really talked about it enough. 00:27:33.541 --> 00:27:36.461 Myself on the blog, we've done a, a blog post about how clients 00:27:36.461 --> 00:27:39.581 can implement caching with, with client middlewares on their end. 00:27:39.581 --> 00:27:42.901 But like, we've not really talked about how to do it particularly well for 00:27:42.901 --> 00:27:44.261 the backend and oth other people have. 00:27:44.261 --> 00:27:46.431 But Yeah, I feel like I should be doing more there. 00:27:47.041 --> 00:27:48.991 Ah, I was gonna say something and I totally forgot. 00:27:48.991 --> 00:27:49.671 God damn it. 00:27:49.671 --> 00:27:52.431 I'm just looking out the window and I'm seeing an invasive cherry laurel 00:27:52.431 --> 00:27:55.591 that I want to cut down, but it's not on my property and it's distracting me. 00:27:56.161 --> 00:27:57.721 . Something, something green tech. 00:27:57.721 --> 00:27:58.521 Yeah, that was it. 00:27:58.521 --> 00:28:00.401 It's the green. 00:28:00.751 --> 00:28:06.401 Making your APIs like greener is a really interesting topic. 00:28:06.942 --> 00:28:10.792 I mean, when it comes to the front end, if you see all of the Green Software 00:28:10.792 --> 00:28:13.272 Foundation and all the Green Tech people, they're for the front end. 00:28:13.272 --> 00:28:15.792 They're basically giving you all the same advice they would give 00:28:15.792 --> 00:28:17.032 you to make your website faster. 00:28:17.162 --> 00:28:20.352 There's nothing particularly different in there, like for the front end. 00:28:20.352 --> 00:28:21.192 It's literally. 00:28:21.702 --> 00:28:24.722 You know lazy load images when you're scrolling and try and like, 00:28:24.722 --> 00:28:27.642 make your requests smaller and more cashable and blah, blah, blah. 00:28:27.642 --> 00:28:31.002 And it's, you know, not squish 'em all into one request because that just 00:28:31.002 --> 00:28:33.802 means that ev if you change anything, you have to blow the whole lot away and 00:28:33.802 --> 00:28:36.162 different pages have more information than they need, blah, blah, blah. 00:28:36.222 --> 00:28:39.362 But it's all the same advice as making it faster, making it 00:28:39.362 --> 00:28:40.762 greener, kind of the same thing. 00:28:41.182 --> 00:28:45.037 And then when it comes to API design, Development. 00:28:45.037 --> 00:28:49.797 It always seems like making the A API faster just means spinning up 00:28:49.797 --> 00:28:53.357 more instances all around the world and then like doing, doing things 00:28:53.357 --> 00:28:55.357 over and over and over and over and over and over and over again. 00:28:55.357 --> 00:29:00.837 But from like nearer and and so yeah, like anyone who can help people 00:29:00.837 --> 00:29:03.797 realize that that's not the case is gonna get a big thumbs up from me. 00:29:04.977 --> 00:29:08.587 Steve McDougall: Yeah, we're currently investigating what we can do with 00:29:08.587 --> 00:29:09.987 CloudFlare work is that in a minute. 00:29:10.557 --> 00:29:14.814 So you know, part of the, part of the process with Treble is 00:29:14.814 --> 00:29:17.734 that you send that payload to us. 00:29:18.114 --> 00:29:22.844 Now, if we can move that us closer to you, that means it's 00:29:22.844 --> 00:29:24.124 gonna be a quicker response time. 00:29:24.354 --> 00:29:26.084 It's gonna be less network traffic. 00:29:26.984 --> 00:29:31.634 Less carbon footprint by sending it closer instead of, you know, where 00:29:31.634 --> 00:29:34.754 our servers are located, somewhere in America or somewhere else. 00:29:34.754 --> 00:29:39.874 You know, if I'm doing that from AUR Wales where I am, then you know, 00:29:39.874 --> 00:29:41.474 it's just quite, quite a distance. 00:29:41.474 --> 00:29:45.624 I've gotta send that payload, which, yeah, I could reduce that traffic by 00:29:46.144 --> 00:29:48.344 using Edge locations a little bit more. 00:29:48.344 --> 00:29:52.834 So we are looking into all of those different ways that we can really reduce. 00:29:53.617 --> 00:29:57.717 The, the latency and that payload and that what we can do with it. 00:29:58.017 --> 00:29:58.817 Phil S: Brilliant. 00:29:58.887 --> 00:30:00.577 I look forward to finding out more about that. 00:30:01.107 --> 00:30:03.477 I was gonna ask, cuz we've, we've asked you a whole bunch of stuff 00:30:03.477 --> 00:30:06.697 about treble, but I know that you've done lots of other a p I stuff. 00:30:06.977 --> 00:30:10.377 So you were working on you invited me to a livestream that I think I didn't make 00:30:10.377 --> 00:30:15.337 it to, but you've also done like a video series on building APIs with Laravel. 00:30:15.337 --> 00:30:16.697 Can you tell us, tell us more about that. 00:30:17.812 --> 00:30:20.142 Steve McDougall: Yeah, so I'm actually working on another 00:30:20.192 --> 00:30:24.192 video series at the moment called API Masterclass and Lara Valve. 00:30:24.602 --> 00:30:28.622 So going from, I've never built not, I've never built an API 00:30:28.622 --> 00:30:30.622 before, but I've built an api. 00:30:30.762 --> 00:30:33.542 But let's be honest, I can't really call it an api. 00:30:33.612 --> 00:30:37.462 I can call it adjacent interface to my database. 00:30:38.072 --> 00:30:44.502 I'm gonna go from where that would be to building something that is, Better 00:30:44.582 --> 00:30:48.662 going, you know, going through API design, what's important, actually 00:30:48.662 --> 00:30:53.902 understanding the process behind why you have an api, what the API's for 00:30:54.352 --> 00:30:59.262 cashing, you know, building up effective queries around it and that sort of stuff. 00:30:59.592 --> 00:31:00.682 That is underway. 00:31:02.272 --> 00:31:04.612 I'm tempted to lead that into a book 00:31:05.132 --> 00:31:08.162 because, but you know, we, we've spoken a few times, Phil. 00:31:08.937 --> 00:31:15.247 Me, me releasing an API book as an updated APIs you won't hate specifically 00:31:15.247 --> 00:31:17.167 for Laal to stop the questions for you. 00:31:17.511 --> 00:31:18.211 Phil S: Not allowed. 00:31:18.211 --> 00:31:20.131 There can only be one book about APIs. 00:31:20.131 --> 00:31:22.251 No one else can do any API books. 00:31:22.751 --> 00:31:25.201 Steve McDougall: Well, my, my book's gonna be called APIs 00:31:25.201 --> 00:31:26.481 Phil won't hate, so it's okay. 00:31:27.241 --> 00:31:27.731 Phil S: Nice. 00:31:27.841 --> 00:31:31.211 I was joking the other day that the Build APIs you won't hate was the 00:31:31.211 --> 00:31:33.571 dumbest name for a book, cuz it's not about whether you like it or not, 00:31:33.571 --> 00:31:34.811 it's about whether your clients do 00:31:35.216 --> 00:31:35.706 Steve McDougall: Yeah. 00:31:36.091 --> 00:31:38.331 Phil S: So I'm like, there's a mistake in my book name. 00:31:38.591 --> 00:31:39.601 Yeah, that's brilliant. 00:31:39.631 --> 00:31:44.241 I mean, the, the book that I did was like how to build Rest ish APIs with Laravel 00:31:44.446 --> 00:31:45.296 Steve McDougall: pretty short. 00:31:45.296 --> 00:31:47.016 Yeah, I've got it here, I think. 00:31:47.686 --> 00:31:48.176 Yeah. 00:31:48.191 --> 00:31:49.771 Phil S: you had a whole box of him at one point. 00:31:50.136 --> 00:31:50.626 Steve McDougall: Yeah. 00:31:50.626 --> 00:31:52.706 No, I, I've finally managed to give all of those out. 00:31:52.836 --> 00:31:53.596 Phil S: Fantastic. 00:31:53.896 --> 00:31:55.516 You just giving 'em away on the street corner. 00:31:55.516 --> 00:31:56.556 You can put mugs on it. 00:31:56.556 --> 00:31:56.956 It's 00:31:57.066 --> 00:31:57.486 Steve McDougall: Yep. 00:31:57.636 --> 00:31:58.396 Phil S: it as a door stop. 00:31:59.076 --> 00:31:59.746 Awesome. 00:31:59.746 --> 00:32:02.946 But yeah, no, I like the idea of there being a specific for Laravee 00:32:03.096 --> 00:32:07.546 up-to-date book because yeah, it, it's really hard to like any. 00:32:07.952 --> 00:32:10.792 Writing about APIs should be polyglot. 00:32:10.792 --> 00:32:14.032 It should be completely agnostic to the, to the code in question. 00:32:14.172 --> 00:32:17.752 But people don't just want ethereal concepts wafted in 00:32:17.752 --> 00:32:19.392 their face for 300 pages. 00:32:19.442 --> 00:32:20.432 So you need to 00:32:20.572 --> 00:32:21.062 Steve McDougall: cons. 00:32:21.062 --> 00:32:21.382 Yeah. 00:32:21.382 --> 00:32:24.582 They want code examples and things they can relate to. 00:32:24.682 --> 00:32:25.242 Phil S: Exactly. 00:32:25.242 --> 00:32:29.402 And not just, not just shoving it into a a page like, cuz if I'm, I, I 00:32:29.562 --> 00:32:33.242 remember like when I was like 11 years old, just like trying to type code that 00:32:33.242 --> 00:32:35.002 was in a book and, and that is dumb. 00:32:35.082 --> 00:32:35.922 People don't want that anymore. 00:32:35.922 --> 00:32:37.322 They want the code in GitHub. 00:32:37.522 --> 00:32:39.762 And so you have to make it a real thing. 00:32:39.762 --> 00:32:44.512 And then, you know, Laravel has had four or five, probably more. 00:32:44.512 --> 00:32:45.592 Are they on La LaVale? 00:32:45.592 --> 00:32:45.792 10. 00:32:46.372 --> 00:32:46.852 Steve McDougall: Yeah. 00:32:46.852 --> 00:32:47.892 LaVale 10 currently. 00:32:47.967 --> 00:32:48.457 Phil S: Cool. 00:32:48.457 --> 00:32:50.577 My book was done with like 4.2, so, 00:32:50.577 --> 00:32:51.097 um, Yeah, 00:32:51.097 --> 00:32:54.177 Taylor's been a, Taylor's been a busy, busy boy, but yeah, trying to 00:32:54.177 --> 00:32:55.337 keep that up to date is hard work. 00:32:55.337 --> 00:32:59.457 And so, yeah, I think more people should make kind of specific, this is how you 00:32:59.457 --> 00:33:00.897 do it in this, this sort of language. 00:33:01.397 --> 00:33:02.367 That sounds good. 00:33:03.177 --> 00:33:06.687 So the, the video series, the masterclass, you are gonna like build 00:33:06.687 --> 00:33:10.687 a real API that does actual stuff, or is it, is it a Twitter clone? 00:33:11.127 --> 00:33:11.807 , what you doing? 00:33:12.022 --> 00:33:15.372 Steve McDougall: No, I'm, I'm gonna I'm gonna build an actual api. 00:33:16.672 --> 00:33:20.852 And it's gonna be, I'm gonna have, each chapter will be a new branch. 00:33:21.142 --> 00:33:23.372 So here's where you start. 00:33:23.542 --> 00:33:26.532 Go to that next branch, follow along, go to the next branch, follow 00:33:26.532 --> 00:33:30.892 along so you can really understand the journey that you're going on. 00:33:30.892 --> 00:33:35.292 And you know, by doing it that way, people following along can 00:33:35.292 --> 00:33:37.012 choose when they want to get off. 00:33:37.562 --> 00:33:40.052 Like, okay, I'm happy with how far I've gone. 00:33:40.232 --> 00:33:41.452 I'm gonna stick with this for. 00:33:42.167 --> 00:33:45.367 , I know I've got four more branches to go, or four more chapters to go. 00:33:45.427 --> 00:33:47.767 But for now I'm happy. 00:33:47.767 --> 00:33:51.287 I've learnt a few lessons and then they can come back and revisit it 00:33:51.287 --> 00:33:52.847 to kind of go those further steps. 00:33:52.847 --> 00:33:56.207 Cause there's a bit of a joke in Bel community about me 00:33:56.207 --> 00:33:57.647 being opinionated with my code. 00:33:58.177 --> 00:34:00.357 And it's not really, it's, it's not a joke. 00:34:00.357 --> 00:34:00.797 It's true. 00:34:00.967 --> 00:34:06.627 I'm probably one of the most opinionated developers you'll find, but it's for a. 00:34:07.477 --> 00:34:10.657 You know, I, I, I like things a certain way. 00:34:11.377 --> 00:34:15.337 Probably part of my OCDs just rubbing off on my coding standards, so, 00:34:15.987 --> 00:34:16.407 you 00:34:16.462 --> 00:34:19.382 Phil S: the idea of somebody in the Laravel community saying that 00:34:19.582 --> 00:34:20.542 somebody else is opinionated, 00:34:22.112 --> 00:34:24.022 they're like opinionated by default. 00:34:24.192 --> 00:34:28.672 So anybody, anybody that's sticking out above that has to be really up there. 00:34:29.072 --> 00:34:30.232 Fantastic though. 00:34:30.232 --> 00:34:33.472 Opinions do help make things quicker, as long as you can 00:34:33.572 --> 00:34:35.072 get along with those opinions. 00:34:36.002 --> 00:34:39.522 Like a lot of the frameworks that try to do, anyone could do 00:34:39.722 --> 00:34:40.882 anything in any way that they want. 00:34:40.882 --> 00:34:42.882 Then everyone just goes, how the hell do I do anything? 00:34:43.012 --> 00:34:43.362 So 00:34:43.732 --> 00:34:44.742 Steve McDougall: yeah, exactly. 00:34:45.002 --> 00:34:47.162 Phil S: frameworks, Julie, grease the wheels on getting 00:34:47.162 --> 00:34:48.522 things done sometimes, but 00:34:48.722 --> 00:34:49.212 Steve McDougall: Yeah. 00:34:49.212 --> 00:34:53.612 It's helped us learn a few, learn a few lessons over the past in the industry, 00:34:53.612 --> 00:34:57.612 you know, by someone formulating an opinion and people adopting that opinion. 00:34:57.702 --> 00:34:59.972 It means that that's become the new standard. 00:34:59.972 --> 00:35:02.572 And so that's a little bit how PSRs came about. 00:35:03.367 --> 00:35:04.327 in the PHP world. 00:35:04.812 --> 00:35:05.372 Phil S: For sure. 00:35:05.372 --> 00:35:08.922 I mean, I've been using Laravel for the Protect Earth api and that's, 00:35:08.922 --> 00:35:10.362 that's been a really nice experience. 00:35:10.412 --> 00:35:14.342 We've got a bunch of live wire, well, no, we've got Nova, but we might be 00:35:14.342 --> 00:35:15.782 switching to Live wire or something. 00:35:16.062 --> 00:35:20.422 But the API is really slick and there's an an amazing community of people as well. 00:35:20.422 --> 00:35:25.062 We've got like five, six volunteers who just throw code at us and, and 00:35:25.062 --> 00:35:26.662 enable us to do really useful stuff. 00:35:26.662 --> 00:35:30.272 And I was saying we've launched the we've launched the weather track. 00:35:31.022 --> 00:35:36.142 Stuff, which is like finding out what the temperature, humidity, and rainfall was 00:35:36.302 --> 00:35:39.782 getting that from an api and then we're talking to another API and finding out 00:35:39.782 --> 00:35:41.382 what the soil type is in a certain area. 00:35:41.622 --> 00:35:44.942 And then we can find out like when, when we do beat up surveys to find out 00:35:44.942 --> 00:35:47.502 which ones died, we can, we can kind of go, well, we probably shouldn't 00:35:47.502 --> 00:35:49.222 plant in a, in a place like that. 00:35:49.222 --> 00:35:52.062 Or if we are going to, we should at least make sure it's more watered or whatever. 00:35:52.502 --> 00:35:55.342 And so, yeah, like right now, Laravel is literally saving 00:35:55.342 --> 00:35:56.862 the world by improving forest. 00:35:57.752 --> 00:35:58.102 So 00:35:58.477 --> 00:35:58.897 Steve McDougall: Yep. 00:35:59.112 --> 00:36:02.782 Phil S: So it's, it's been really been really fun to be back in that, in that 00:36:02.782 --> 00:36:07.472 kind of in the community, but mostly just using it and, and just it working 00:36:07.472 --> 00:36:11.112 and me not feeling like I have to get involved with the framework or like 00:36:11.112 --> 00:36:13.952 bickering cuz it just works really well and I can just get on with it. 00:36:13.952 --> 00:36:14.632 That's quite nice. 00:36:16.677 --> 00:36:19.247 Steve McDougall: It's definitely, I mean, yeah, I've lost my hair, but 00:36:19.247 --> 00:36:20.647 you know, that's not Lara's fault. 00:36:20.757 --> 00:36:23.607 That's, that's me having the amount of children I do. 00:36:23.977 --> 00:36:26.797 But yeah, if your children went here, I'd definitely have long, 00:36:26.797 --> 00:36:28.237 luscious looks like you, Phil. 00:36:28.527 --> 00:36:29.577 Phil S: Need to get a cut. 00:36:31.047 --> 00:36:33.057 Steve McDougall: Lara's definitely made development easier, 00:36:33.057 --> 00:36:34.337 especially in the API space. 00:36:34.482 --> 00:36:36.972 Track 1: Yeah, I'm gonna start blaming Laravel for my, uh, l 00:36:36.972 --> 00:36:38.519 l lack of coverage here too. 00:36:38.519 --> 00:36:41.176 I think even though I've been a JavaScript developer for 00:36:41.176 --> 00:36:42.136 longer than I can think about 00:36:42.136 --> 00:36:42.296 at 00:36:42.296 --> 00:36:42.576 this point. 00:36:43.601 --> 00:36:44.331 Phil S: That is 00:36:44.416 --> 00:36:46.576 Steve McDougall: that's just the weight of the NPN modules. 00:36:46.576 --> 00:36:47.656 Pulling your hair out of your 00:36:47.671 --> 00:36:48.311 Track 1: That's it. 00:36:48.311 --> 00:36:48.911 Totally. 00:36:48.911 --> 00:36:49.351 Yeah. 00:36:49.351 --> 00:36:50.591 Dragging it away from me. 00:36:50.591 --> 00:36:52.031 One, one thread at a time here. 00:36:53.631 --> 00:36:56.677 So Steve, what are the things that you're working on now that are coming next? 00:36:56.677 --> 00:36:56.997 Right? 00:36:56.997 --> 00:36:58.637 Like, I, I know you have maybe some work things. 00:36:58.637 --> 00:37:01.397 You have, uh, personal projects that may be coming. 00:37:01.567 --> 00:37:02.997 Um, what are you thinking about right? 00:37:04.106 --> 00:37:04.906 Steve McDougall: Right now. 00:37:05.436 --> 00:37:06.936 Ooh, that's a very good question. 00:37:07.584 --> 00:37:10.694 At the minute I'm, I'm building out SDK tools. 00:37:10.934 --> 00:37:15.824 I released a new open source package a few days ago called sda SD K tools. 00:37:16.324 --> 00:37:21.194 I'm trying to, my second attempt at enabling people to 00:37:21.194 --> 00:37:24.354 build better SDKs in, in P h P. 00:37:25.144 --> 00:37:28.134 Um, I'm trying to adopt more. 00:37:29.044 --> 00:37:34.617 PSRs, lots more auto discovery, but still enabling them to keep uh, 00:37:34.617 --> 00:37:39.527 kinda that friendly API and developer experience I might be used to in 00:37:39.527 --> 00:37:40.887 something like LaVale, for example. 00:37:41.477 --> 00:37:45.167 That's my current project, if going well so far. 00:37:45.947 --> 00:37:50.337 I released it, didn't publish it really, I, I tweeted about it as 00:37:50.337 --> 00:37:51.657 it's been starred a few times. 00:37:52.087 --> 00:37:54.121 I've used it twice already. 00:37:55.206 --> 00:37:57.166 and it, it's, it's definitely helped. 00:37:57.166 --> 00:38:01.806 It's, you know, that's my current project cuz I like integrating 00:38:01.806 --> 00:38:03.766 with APIs as well as building APIs. 00:38:03.766 --> 00:38:06.806 So it's always a bit of a where do I want to focus? 00:38:07.946 --> 00:38:08.736 Track 1: Of course, yeah. 00:38:08.736 --> 00:38:11.176 It's probably a good sign that you're your own user as well. 00:38:11.176 --> 00:38:12.416 Uh, you feel some of the pains that 00:38:12.416 --> 00:38:13.296 you're trying to solve there. 00:38:14.166 --> 00:38:14.656 Steve McDougall: Yeah. 00:38:14.656 --> 00:38:17.776 I mean that's one of the things that I say to anybody, building an API is, 00:38:18.776 --> 00:38:22.636 You know, as you're building your api, make sure you're integrating with it 00:38:22.636 --> 00:38:26.876 so you can feel those pain points that your user will do, because that's gonna 00:38:26.876 --> 00:38:29.196 point to where you can improve upon. 00:38:29.556 --> 00:38:30.046 Track 1: Yeah, 00:38:30.366 --> 00:38:32.866 Steve McDougall: And it was actually what part of my talk that I gave at 00:38:32.866 --> 00:38:37.026 Lara EU around I think it was called building APIs or something like that. 00:38:37.056 --> 00:38:39.826 They wouldn't let me change the name to building APIs. 00:38:39.826 --> 00:38:40.826 Phil would like so 00:38:41.086 --> 00:38:41.576 Phil S: Good. 00:38:41.576 --> 00:38:41.776 I'm 00:38:41.776 --> 00:38:41.896 glad. 00:38:41.896 --> 00:38:42.376 It's not just 00:38:42.376 --> 00:38:42.576 me. 00:38:42.576 --> 00:38:43.296 It's not just me. 00:38:43.456 --> 00:38:43.576 Freezing. 00:38:44.256 --> 00:38:46.536 Track 1: I've, supported every, uh, every proposal I put in 00:38:46.536 --> 00:38:48.816 from now on is gonna have Phil's name tossed in there somewhere. 00:38:49.246 --> 00:38:49.736 Yeah. 00:38:50.226 --> 00:38:50.826 Steve McDougall: Approved by Phil 00:38:50.946 --> 00:38:53.749 Track 1: so Steve, um, appreciate you coming and joining us today. 00:38:53.799 --> 00:38:56.349 Uh, can you tell us where folks can find you online? 00:38:56.619 --> 00:38:58.829 Steve McDougall: just Steve King, everywhere. 00:38:59.184 --> 00:38:59.344 Track 1: it. 00:38:59.734 --> 00:39:00.224 Cool. 00:39:00.224 --> 00:39:03.144 Yeah, and I'll, I'll throw, we have lots of links to you everywhere, uh, 00:39:03.144 --> 00:39:04.344 which I'll drop in the show notes here. 00:39:04.434 --> 00:39:05.154 Um, about trouble? 00:39:05.154 --> 00:39:05.994 Where's the best place to 00:39:05.994 --> 00:39:06.114 go 00:39:06.114 --> 00:39:06.754 to get started there? 00:39:07.074 --> 00:39:08.164 Steve McDougall: trevor.com. 00:39:08.644 --> 00:39:10.964 T R E B L L e.com. 00:39:10.964 --> 00:39:11.634 Track 1: Perfect. 00:39:11.664 --> 00:39:12.154 Well, 00:39:12.564 --> 00:39:14.764 Steve McDougall: spelling, but we're, yeah, we are. 00:39:14.764 --> 00:39:16.844 There we're uh, Trevor API on Twitter. 00:39:17.544 --> 00:39:19.784 We're always tweeting, always 00:39:20.084 --> 00:39:20.754 Phil S: Awesome. 00:39:20.754 --> 00:39:24.594 Well, thank you so much for telling us about all of those cool things that travel 00:39:24.594 --> 00:39:26.114 are working on and you are working on. 00:39:26.114 --> 00:39:27.274 I want to keep an eye on them. 00:39:27.944 --> 00:39:33.414 And on the subject of s D K stuff, I've, I'm writing the latest book, 00:39:33.414 --> 00:39:35.254 surviving Other People's APIs. 00:39:35.254 --> 00:39:36.574 I know I've mentioned it in the past. 00:39:36.604 --> 00:39:40.014 I am li I am honestly working on it very, very quickly now. 00:39:40.124 --> 00:39:44.454 I've done I've finished three chapters in three days, and so people should 00:39:44.454 --> 00:39:48.614 check that out because it's not just if you are a front end developer, but 00:39:48.614 --> 00:39:51.054 it's any API that talks to other APIs. 00:39:51.304 --> 00:39:54.214 So anyone that talks to APIs, which should be most of. 00:39:54.754 --> 00:39:58.154 This, this book should be right up your alley and it talks about SDK's a fair bit 00:39:58.154 --> 00:40:03.404 because half of the stuff that you have to know in order to successfully interact 00:40:03.404 --> 00:40:06.164 with an API can be done by the sdk. 00:40:06.164 --> 00:40:10.484 So you don't have to, otherwise you just have to build an SDK for every 00:40:10.484 --> 00:40:14.924 API that you ever talk to every time, and that's probably going to be bad. 00:40:15.374 --> 00:40:16.424 So yeah. 00:40:16.424 --> 00:40:16.784 Brilliant. 00:40:16.784 --> 00:40:20.064 I look forward to your, your stuff about SDKs and I'll, I'll shove it 00:40:20.064 --> 00:40:21.104 in the book if it's out in time. 00:40:22.304 --> 00:40:22.794 Steve McDougall: Yeah. 00:40:22.794 --> 00:40:23.314 Sounds good. 00:40:24.219 --> 00:40:24.699 Phil S: Sweet. 00:40:24.789 --> 00:40:26.339 Alright, thank you very much. 00:40:26.359 --> 00:40:28.219 I'm gonna go and get back out into the woods. 00:40:28.449 --> 00:40:30.339 I've got invasive species to hit with an 00:40:30.494 --> 00:40:31.214 Steve McDougall: Enjoy the 00:40:31.214 --> 00:40:31.454 trees. 00:40:32.469 --> 00:40:33.029 Track 1: Right 00:40:33.029 --> 00:40:33.189 on. 00:40:33.189 --> 00:40:33.669 Thanks for joining, 00:40:33.714 --> 00:40:35.124 Steve McDougall: Thanks very much for having me. 00:40:35.124 --> 00:40:35.644 Take care. 00:40:36.010 --> 00:40:36.509 Track 1: Take care.