Analytics for your API, with Steve McDougall from Treblle

Analytics for your API with Steve McDougall from Treblle

[00:00:00] Track 1: Take it away, Phil.

[00:00:02] Phil S: Oh me,

[00:00:02] Track 1: Oh yeah.

[00:00:04] Phil S: How do you even do an intro? I haven't done it in so long. Uh, Hey everyone. Welcome to APIs you won't hate. I dunno what episode number this is or what day it is. But thank you for coming along.

[00:00:13] Track 1: That's what we like to hear. It's perfect.

[00:00:15] Phil S: Yeah. Do you wanna do the intro

[00:00:18] Track 1: Oh, you better believe I'm gonna use that.

[00:00:20] Phil S: I haven't done it in age years. Matt was doing it forever. And then you did it and yeah, I'm just, I'm just along for the ride. Half the time.

[00:00:26] Track 1: Yeah, I, it's just your velvety narrator voice, Phil, that the people come for. Whoa. Why don't we do it this way? Uh, Welcome to APIs you won't hate for the second time. My name is Mike bco. I am one of the, co runners of APIs you won't hate. I'm hanging out here today with Phil Sturgeon, and our good pale Steve McDougal from Treble. Phil, how are you doing

today?

[00:00:45] Phil S: I'm pretty good. I've spent the whole morning out and about in the Woodlands up to my knees in mud, which is my happy place. And now I get to talk about APIs, which is my other happy place. So I'm excited that we got Steve

along

today.

Thanks for coming, Steve.

[00:00:56] Steve McDougall: Thanks. Thanks for having me. So yeah, I'm really excited to be here. [00:01:00] Obviously I've been a longtime listener, new in the kind of public facing API world right now. So I'm excited to, to have a chat about APIs.

[00:01:10] Track 1: Yeah. Well, uh, to have you here. Why don't we start this way? Uh, tell us little bit about yourself. Um, live? Where do you work? What have you been working on? How'd you get here?

[00:01:18] Steve McDougall: So I live in South Wales and I believe my house is probably gonna get turned into trees by fill at some point soon. But yeah, I've been in the API space for maybe six, seven years heavily on the PHP side using Lara Valve Slim. Recently you've been using framework X, which is really fast, asynchronous framework.

Yeah, I do a lot of, a lot of talks around APIs. I do a lot of talks around integrating with APIs with a focus on kind of quality and scaling out the complexity. And my day-to-day has basically been building lots of tooling around APIs, so I'm in that API head.[00:02:00]

[00:02:00] Phil S: So you've just started uh, working at Treble? Right. And I, I've come across Treble a bunch of times. I was on one of their Twitter circles a while ago and I think I chatted to them like right when they were starting out, but, Ages ago, and they do a bunch of stuff.

So in a similar way to a lot of the tooling vendors, there's, there's so many different parts of the API lifecycle. Most tooling vendors don't want to just do one bit. They want to try and do a few. And so you guys have got an interesting different set, mostly with some overlap of stoplights. So I kind of bounced around treble a little bit then, but we've gotta mention that uh, Trevor in the past have sponsored the.

But I don't listen to the podcast, so I don't know what they said about it. So, , so can you explain to me what's, what's going on with?

[00:02:46] Steve McDougall: Yeah, so we are currently scaling, we're hiring more engineers to help us build out better and higher quality tools, building out more tooling. And we're we're basically what you're. Google Analytics, but for your [00:03:00] api, that is the best way to explain what Trevor is to most people. You could go into the observability, into the monitoring and explain all of that aspect of it, but I've always found the easiest way to explain it is just, it's like Google Analytics for your api.

[00:03:15] Phil S: Okay. Nice. And looking at it just bouncing around the homepage, I mean the, the API monitoring and observability stuff looks to me a little bit like New Relic, but kind of API focused.

[00:03:26] Steve McDougall: Yeah, similar.

[00:03:27] Phil S: Okay.

[00:03:28] Steve McDougall: very similar. One of our one of the clients I'm working with at the moment kind of described as, as a log rocket, but for their api, they use Log Rocket on the front end, and. Now currently trying out us on their APIs. So

[00:03:43] Phil S: Interesting. Okay. And then, so you've got the monitoring, but then it kind of moves into auto-generated API docs. How, how does that work?

[00:03:51] Steve McDougall: So basically every request that you make We log, we do ETL script on it to make sure that we're pulling out data, standardizing data formats, [00:04:00] and adding it into our database. And while we're doing that, we're triggering lots of events to start building up paths and endpoints and query parameters, emerging query parameters, and we are just kind of merging and mangling data in the background to build out an open API spec.

Basical.

[00:04:16] Phil S: Nice. That's pretty cool. There's, there's. People doing that now. Like I, the last post I just did the other day on, on APIs, you won hate blog was about using Optic to do that, which is a slightly different approach. You, you run a CLI script and then basically man in the middle, whatever, a API you feel like, man in the Midling.

I was doing it for the master mastered on a api, which is pretty cool. But this, this will be kind of implemented by the API developer team or the CIS ops team or something. You just kind of shove that. No, it, it's not done at the server level. It's not like a proxy. It's done as like an sdk. How does it, how does it get that?

[00:04:52] Steve McDougall: our, well, we we're a, we've got an s STK as well, and basically it's just a, a piece of middleware that [00:05:00] will capture the request of response. and then on the kind of termination of the script, we gather the data and send that off to our API to then be processed. So it's, yeah, it's a middleware basically.

So one of the benefits that I found is that you can choose what endpoints you want to add it to. You can add it to all of them, add it to some of them, and you can slowly roll it out to make sure that you know you're getting the data you need. And because we are en we're enabling field masking that gentler rollout is sometimes recommended because sending over passwords, credit card numbers, email addresses, all of those sorts of things in a monitoring solution you don't want.

So with our field masking every request and response, Goes through this masking process where we turn the value into stars of the same length, roughly. So that you're still getting the understanding of that data, but [00:06:00] you're not passing that data, which keeps things a lot cleaner for you. There's no kind of data privacy worries about are they going to know my passwords?

And it, it does that with the headers as well. , you, you kind of, we are masking all the different orth headers that you might have and custom orth headers as well. So

[00:06:20] Phil S: Okay, that's pretty smart to find it. I guess it's looking for like X hyphen a P i key and X hyphen authentication token, as well as

[00:06:27] Steve McDougall: yeah, we, we basically got a big list of different ones, uppercase, lowercase, spelt wrong, not spelt wrong, , just to try gather all of them basically.

[00:06:37] Phil S: Access tok.

Um, fantastic. Okay, that sounds really handy. I, I like, I like the idea of it being a, a middleware and I like that there's different people doing different approaches cuz I know I wrote about aquita turning your HTP traffic into open API as well and there's a few more steps of indirection involved there cuz Again, Aquita is like a whole platform that does a bunch of different parts of the puzzle.

And then you kind of export [00:07:00] the open API out and they just added like a engine X module so you can really wedge it in at, at

[00:07:07] Steve McDougall: Oh, nice. Yeah,

[00:07:09] Phil S: that, that seems complicated and something that a lot of people can't necessarily do in certain hosting environments anyway, so.

[00:07:15] Steve McDougall: yeah. We are looking at different options at the moment as well. Like I was talking to one of our other devs the other day about could we create our own custom ingress for Kubernetes? So that we can just capture specific parts and then it's not handled within the web request. It's handled within the, the, the Kubernetes engine itself.

We'll then send that data to us. But you know that that's probably something down the road once we've hired a few more people, I think.

[00:07:42] Phil S: Absolutely. Well, there was another approach that I think a previous job I was talking about trying to build this, I think Stoplight was trying to do it and WeWork was trying to hack it. But we were talking about trying to, cause we've got um, the Prism proxy, right? And that in previous versions, prism Proxy was doing some learning.

It's not doing learning [00:08:00] anymore. It does do a bit of like content validation to go like, oh, that's bad. You did an error, whatever. I'm telling. And, and all of that stuff. We only ever really got it as far as working in development and staging because we didn't really have the confidence in the production performance to say like, Hey, go wedge this into the critical path and I'm sure it'll be fine. And so we were kind of recommending a few bigger customers you can do like Traffic cloning or like traffic shadowing, I can't remember what it's called. So you basically in, in Kubernetes somewhere, say like, look for all these requests coming through. Take one in a hundred of them and just like fire 'em over this way as well.

And then you just make sure the database doesn't do anything and you have to build like a separate environment that's just like a, a castrated version of the royal production.

[00:08:43] Steve McDougall: It. It sounds like a lot of juggling just to get that simple kind of logging effort, right?

[00:08:48] Phil S: Exactly. Yeah. But then on the other hand, like with, with your sdk, it's super simple cause it's just in the code there, but then that's still kind of slowing things down.

Although if it's after the person got there, Jason, maybe [00:09:00] that doesn't matter. So there's, there's like a bunch of different ways of like pros and cons of, of how to get that stuff. And

[00:09:07] Steve McDougall: definitely. And that's one of the struggles that I'm working on this week actually. I was working with the people from React, P h p, working on asynchronous middleware. So what I can do is I can send a H E T P request asynchronously in P H P, and while that's running, I can return that response and then deal with any failures within that asynchronous process.

[00:09:32] Phil S: Yeah, that's brilliant. That's what you want. I mean, yeah, obviously I have no idea how the SDK works, but that , that sounds like a good approach.

[00:09:38] Steve McDougall: currently not like that, but , I'm this refactoring effort at the minute where I'm looking at our p the PHP ecosystem for our SDKs to make sure we support a wide bunch of frameworks as, as well as, you know, psr 15 middleware as well for those kind of build your own. So yeah, I'm, I'm trying to assess all.

To try and figure out what the [00:10:00] best approach is so that I'm not forcing dependencies on any one framework. So it, it's been a juggle definitely.

[00:10:08] Phil S: guessing, I'm guessing that a lot of the different SDKs in different languages will work differently as well. So I'm, you know, we are probably by default talking about PHP without really mentioning it there, cuz that's our backgrounds. But I'm sure, I'm sure like the node one is asynchronous by default or whatever.

So, Just gotta try and find different ways to make it work. I thematically, or whatever the correct word is, I just, I just do tree stuff now. I forget words.

[00:10:30] Steve McDougall: I forget words. I just know. Birch

[00:10:33] Phil S: concepts. Yep.

[00:10:36] Track 1: so Steve, I'm a little bit curious about, um, end user benefits of, uh, adding trouble to your system. So, made the comparison before between treble and uh, right? Sort of the log rocket for your APIs. Um, used Log Rocket before and am a big fan of it for the applications that I build for the web and whatnot.

Um, assuming I had never been exposed to Log Rocket before, what the heck does that mean? What do I get?

[00:10:59] Steve McDougall: so [00:11:00] what you get is you can have multiple projects, obviously. Um, Maybe you've got internal APIs, external APIs, and you want to kind of keep all of them, you know, separate. We capture the requests, the response, response time, request time, the total low time so that you can start to see. Perhaps you're getting issues in that API lifecycle, in that request response lifecycle.

We capture bugs, we capture that full kind of stack trace from the exception and handlers so that you can see bugs that are introduced. And this is like over time, for example. So let's say you do a big feature deployment and it breaks a couple of endpoints. You can kind of pinpoint that back down through. Tracing through the requests, seeing where those errors were back on. Were, were starting to be introduced and we're, we are looking at building out a, a, you know, a fully fledged alerting system as well, and enabling you to ignore certain errors within your [00:12:00] api. For example, with with Laravel, for example, if I return a 4 22 from Laravel, it means that my validation's failed in Laravel.

That's currently being reported as a problem. However, it's technically not an API problem, it's a user problem. So we're looking at extending rsdk to say that you can ignore specific exceptions

[00:12:23] Track 1: Yeah.

[00:12:24] Steve McDougall: that they aren't reported as an actual problem cuz it's a user problem or an implementation problem, not a API problem.

As.

[00:12:32] Track 1: right? Yeah. And I guess when you're trying to assess how your, um, system is running, uh, are working as they should, you don't wanna

report that as a problem? Yes, sir.

[00:12:40] Steve McDougall: You don't wanna report that someone's trying to register again, using the same email address as a API problem. Right. Because it's not, it's, it's a human problem at that point.

[00:12:50] Track 1: I think it's interesting too that, um, getting a bunch of information in addition to just whether things are working or failing or crashing, whether you're getting errors and things like that. Especially in a [00:13:00] world where people are starting to talk way more about, uh, between.

typical lambda serverless functions and edge functions and all that. Uh, sort of like technical debt creep that can happen where your, um, can become slow and slow, can be the problem not failing, right? You're things can start to feel like they're kind of creeping along and having some sort of intelligence behind the scenes to be able to track like, hey, which calls are getting slow, help your engineering teams to, to

trace that all down.

Um,

[00:13:27] Steve McDougall: massively. I'm, I'm currently working with our engineering team at the minute to implement, a re-architected approach to how we're logging things so that we're gonna have much more intelligence on the reports that we can generate. So, you know, you can pinpoint the exact request when it was, why it was what happened, and a lot more.

And we're also jumping on that bandwagon of G P T and saying, okay, so what can we actually.

What, what could we, what information could we get from AI on this? What, you know, we, we've obviously got a lot of generating going on [00:14:00] for building out an open API spec. Is there any way that we could improve upon that?

[00:14:05] Track 1: of course. And behind the scenes, those G p t uh, are really good at noticing patterns that are probably not, uh, apparent to you and me.

[00:14:13] Steve McDougall: yeah, exactly.

[00:14:14] Track 1: superpower in itself. imagine when adding trouble to your service. Actually, one of the things I saw on your site earlier, I was kind of browsing around, is that I think you get something like 50 data points for every API call, as part of the kind of analytics end of this.

Um, that feels like a lot, right? Like that can be imposing at first. If you're, if you're working with a team that's just adopting trouble, like what are some of the first things you tell them to look for or look at or optimize for when they're working?

[00:14:38] Steve McDougall: To be honest, I've not worked with many people onboarding who have asked questions. I've only been here three weeks, the only thing I've dealt with so far is uh, talking about. You know, how much of a bottleneck is it gonna cause with it being middleware and sending a request? Had to explain that.

It's terminating middleware. So it's at the end of that PHP CGI process or you know, [00:15:00] FPM process. It triggers a terminate command, and then that middleware triggers talked about data leakage and using the masked fields to be honest. The hardest thing is getting people to understand what it gives you.

When it's just like, well, I know I'm sending a request. I know I'm getting a response. I, you know, I could probably generate an open API spec using an open source tool. But what that isn't telling you is what's being used, how much it's being used, which is the most popular endpoints, which is the slowest endpoint.

Where is where your request body is starting to get a little bit too excessive? Should you. introducing Jason API specification so that you can tweak that payload coming back a little bit more because your response size is getting a little bit too big and taking a little bit too long. So yeah, there's, there's lots of things we have to do when we are onboarding people to explain what you can do and how to get the most out of it. And [00:16:00] part of my job is to record and create content around that as well. So, I'm gonna be creating videos around, I'm gonna be able a really bad API for fun and stick it through treble and see how much I can improve it based on just using those insights instead of me using my brain and thinking, oh, I know this is gonna be a problem, I'm gonna take that.

I might even get someone else to join me on it and get them to do it . Cause I know that habits can die. And just see how much improvements we can get on an API based off of just that insight.

[00:16:33] Phil S: As a consultant in APIs and as a, like someone who's worked on dev tools, I have this really interesting kind of thing where I'm, we're building these dev tools to try and solve problems and then the people don't necessarily know that they need them cuz they've just got shit breaking.

If, if some shit's breaking and some stuff's going slow, then they're like looking at some exceptions and saying, oh, you should probably fix that. And it is very much like a how do we fix the problem that happened? But then. They [00:17:00] don't really. I've worked with so many teams that don't really recognize there's so much more than just the code exceptions.

Like you get some exceptions or you get some slowness, or you might not even know it's going slow. Like, how do you know that something was slow or someone complained about it? Well, how many customers did you lose before they complained?

[00:17:15] Steve McDougall: yeah, exactly.

[00:17:16] Phil S: they do complain, you're just like, well, I don't know.

It seems all right to me. And you get some really weird scenario where

[00:17:21] Steve McDougall: Works on my machine

[00:17:22] Phil S: month or something. Yeah. And so, or there's this, like, we've had this crazy thing where, you know uh, One CR job would run like, you know, once a month and then requests would be really slow then.

So someone would complain about the a p i being slow and then you check it out tomorrow, you're like, nah, that's fine. You're mad. So being able to look back in time and see that kind of the performance, just graphs and stuff are super handy. But then people don't know that they need that. Cuz if you are, like I said, if you're getting complaints, you, you, you wanna try and treat the the symptom or the why, no.

You wanna try and treat the specific problem at the time and

[00:17:54] Steve McDougall: Yeah, you wanna, you wanna treat the cause, not the symptoms. Right?

[00:17:57] Phil S: Yeah. Yeah,

[00:17:59] Steve McDougall: [00:18:00] So, you know, before I started down this journey of API monitoring on observability stuff you know, the typical approach would be, oh, I don't know. I'll install Century and I'll get all my logs and I'll enable performance monitoring, and if anything notifies me, I'll deal with it. But that's, you know, you've gotta, sometimes you've gotta take that proactive approach when you're trying to build a good product, right? You got proactively search for ways to improve what you've got. If, if you're not building new features, you're improving what you've got. So it's just a tool to enable you to do that at the end of the day, isn't it?

[00:18:35] Phil S: Yeah, exactly. I mean, I, I basically lived in New Relic and went at previous jobs and it, it seems like this would be more useful than that cuz it. Targeted APIs, I had to kind of

convince it to, to, to tell me what I wanted a lot of the time. And I'm sure they've changed in the years since I've used it.

But yeah, like that was my, my job as kind of API governance before API governance existed was just to snoop around New Relic, see what was happening and, and [00:19:00] the development teams maintaining those APIs Would, if there was an, an error or, you know, something bad in the logs, they would, they would usually get told about it and they would usually fix it.

But it was, it was trying to find all the things that. Weren't problems yet. Things that were on their way to being problems

[00:19:15] Steve McDougall: Yeah. And the problem with things like that is that you're not spotting trends, are you? You're just seeing. Oh, it took 52 milliseconds to do that. It took this long to do that. It was doing this, his a SQL query that was ran and you know, you're not seeing, okay, this response payload's huge or this response load time is increasing.

You're not seeing that information when you're just kind of scrolling through performance metrics from Century or New Relic or anything.

[00:19:45] Phil S: Right? And so is that what the treble API score is all about? Is, is trying to remove some of that, like trying to guess at what's good or bad and just basically saying,

[00:19:54] Steve McDougall: Yeah, basically.

[00:19:56] Phil S: that's kind of cool.

[00:19:57] Steve McDougall: And I, I'm currently building out monthly [00:20:00] reports at the moment as well, so that you can see, you know, for, cause I used to be an engineering manager. One thing that was important to me was, you know, what is our performance like over the last month? Has it gone up or down? It's a low time going up or down.

Is this an issue? Memory consumption being increased to see, you know, sometimes a PR slips through that causes a bug that you don't know about. Maybe use with more memory. Maybe it locks a database for X amount of seconds. You, we, yeah. You don't see that unless you can kind of get that holistic overview on, you know, the last 30 days. Response times gun up by X percent. Your low times gun up by this.

[00:20:43] Phil S: really interesting cuz I think, again, in when I've worked on this sort of thing, people like. Look at the graph, look at the response time. I mean the, the classic New Relic graph of like median time, so it's not even, it's not even showing you the percentiles, it's just like, on average it looks fine.

And, and even then you're kind of [00:21:00] looking at a graph and depends on how thick your glasses are and whether you can spot the fact that it's gone up by 2% over the

[00:21:06] Steve McDougall: Especially as they don't, yeah, they don't, they don't allow you to zoom on the graph, so it's like you are looking at 30 days and you can't really tell that much.

[00:21:14] Phil S: Exactly. So like if, if your application is getting slower by 2% every month or whatever, there's gonna be some serious trouble in a couple of months and,

[00:21:21] Steve McDougall: Yeah, exactly.

[00:21:22] Phil S: just by looking to graph.

So if you can kind of let people know that sort of trend, that's really helpful.

[00:21:28] Steve McDougall: Yeah. It's again, it's taking the metrics and spinning it into something that's a little bit more proactive for someone that they, they can act upon and not just have to search to try and find, cuz they may not think of it.

[00:21:41] Phil S: Yeah, that's cool. On the topic of API scores, it's something that we, we always talked about doing with spectral, and I don't know what they're up to these days. I don't work there now, but the the idea of an API score we were going for

we were working on like looking at open API and then judging your API on that and . Saying like um, oh [00:22:00] this is inconsistent. This breaks these rules. It's kind of the opposite of Lin. Instead of saying, here are problems, it just kind of says you don't have any problems or you're an a plus plus a api.

And it, it really makes me want to get back to it. Cause if you can have a design score and then like a performance score, that would be super cool.

[00:22:19] Steve McDougall: I'm actually, I was working on that not last week, the week before. I spent literally the whole week going through every page of the open API specification, converting that to data objects so that I can pass an open API spec, pass it in, and start to do calculations. you know, data that I actually know and understand.

My eyes were, you know, very kind of bleeding by the end of the week once I'd finished building all of it. But yeah, it was um, it's coming. We, we are currently doing, we've got a big list of metrics, which we're gonna check against once we've got that open API spec. And what we're gonna be doing is [00:23:00] we're actually gonna release that part as a free. So it'll be under, like, once it's built, it'll be like insights treble.com and you can either pass the URL to your open API spec, paste it in, or upload the file. And what we'll do is we'll build, pass and give you a score and give you, kind of hear other problems. Here is where you're doing well, things like, are you using restful patterns?

Yes. Authentication percentage and all those sorts of things.

[00:23:30] Phil S: That's

[00:23:31] Steve McDougall: that will be a, a free tool for people to just use

[00:23:34] Phil S: Do you guys have any sort of do you folks have any sort of like green tech ideas in your, in your roadmap? Because I would love to talk to some of you folks about that, if not.

[00:23:46] Steve McDougall: it. It's something that's on my mind. I'm very much aware that a platform like ours, which deals with analytics, can quite easily increase carbon usage by. You know, a new client [00:24:00] coming on board who's got a very busy api, suddenly our carbon footprint goes from X to X plus seven. And definitely looking at what the options are for that, and we are currently having discussions internally about how our application works, how it performs, and what we can do to kind of shrink that a little.

[00:24:18] Phil S: that's really interesting. That's, that's less, less what I meant, but really interesting or the same. What I mean is Knowing and doing something about the carbon footprint of your organization and your application wherever you may work, is a good thing. That's kind of making tech green. But kind of helping other people make their tech green is something that, that treble or any analytics software could really help with.

Like, I've toyed around with the idea for ages of coming up with some sort of tool, some sort of proxy that would just look at all the traffic coming through and being like, you could have put a cash header on that. It's been exactly the.

99% of the time, what are you doing? And there's a bunch of other like tweaks and suggestions you could make to people.

Like if, if someone's making [00:25:00] the same request over and over again, you could even just say like, you know, that could be a head request or, or, there's a lot of different stuff. And I think that that could be really powerful for an analytics company

[00:25:10] Steve McDougall: I mean, we have those sorts of that information already, so, so as it'll be something, you know, I, I'd speak to the designer and say, okay, can you design something cool so that on a project or on an endpoint, I can add a badge and say, you know, you've got a green bonus, which boosts your API score.

[00:25:30] Phil S: Yeah,

[00:25:31] Steve McDougall: That, that sort of thing to say, you know, you are actually using caching, you're limiting your response size.

You, you know, you, you're following a practice, which is perhaps more green than I'll just make another API request.

[00:25:46] Phil S: Exactly. Yeah. That's something that I think we're gonna talk about a lot more as a few guests that I'm lining up to, to talk

about more green tech stuff in depth. I know that you've kind of looked into it a bit and, and you suffer the fire hose. That is my Twitter profile, so you see me banging

[00:25:59] Steve McDougall: [00:26:00] Yep.

[00:26:00] Phil S: there. But , God knows what's coming up on there next, but yeah I think the, the green tech angle is something obviously I'm super passionate about, and I think there's. There's a lot more people starting to notice that we can, we can really do something about this cuz I, I forgot all the numbers, but like the internet is the 2%, 4% of global emissions.

Like it's, it is growing. It's the same as flying and getting worse. And of that like 85% is API traffic. And so if we can like put a little dent in that, just by helping people realize they should, they could have cashed something where they weren't thinking about it before. That seems pretty helpful, especially if you can show a graph going down.

You can even have people selling carbon credits off the back of it or something. Or at least kind of that, at least their company can pat themselves on the back for doing it. But yeah,

[00:26:42] Steve McDougall: Yeah, exactly.

[00:26:43] Phil S: emissions go down is a good thing. Cool.

[00:26:46] Steve McDougall: I've found is that a lot of developers only understand certain levels of caching. So a lot of the questions I get asked all the time, cuz I do lots of tutorials and live streams and that sort of stuff, is, how can I properly cash? You know, [00:27:00] how can I enable cashing on my API or on my application?

It's like, well, it depends on what you, what your application does. You know, you need to build out a cash strategy to understand that and understand. Kind of some of the business logic to know what you can cash and for how long, but it seems that there's a big lack of, well, a big gap of knowledge just missing in, in some areas where people don't understand how to cash,

[00:27:26] Phil S: Yeah.

[00:27:26] Steve McDougall: which again, would really help on that green front, right.

[00:27:30] Phil S: Absolutely. I feel guilty cause I've not really talked about it enough. Myself on the blog, we've done a, a blog post about how clients can implement caching with, with client middlewares on their end. But like, we've not really talked about how to do it particularly well for the backend and oth other people have.

But Yeah, I feel like I should be doing more there. Ah, I was gonna say something and I totally forgot. God damn it. I'm just looking out the window and I'm seeing an invasive cherry laurel that I want to cut down, but it's not on my property and it's distracting me.

.

[00:27:56] Phil S: Something, something green tech.

Yeah, that was it. It's the [00:28:00] green. Making your APIs like greener is a really interesting topic. I mean, when it comes to the front end, if you see all of the Green Software Foundation and all the Green Tech people, they're for the front end. They're basically giving you all the same advice they would give you to make your website faster.

There's nothing particularly different in there, like for the front end. It's literally. You know lazy load images when you're scrolling and try and like, make your requests smaller and more cashable and blah, blah, blah. And it's, you know, not squish 'em all into one request because that just means that ev if you change anything, you have to blow the whole lot away and different pages have more information than they need, blah, blah, blah.

But it's all the same advice as making it faster, making it greener, kind of the same thing. And then when it comes to API design, Development. It always seems like making the A API faster just means spinning up more instances all around the world and then like doing, doing things over and over and over and over and over and over and over again.

But from like nearer and and so yeah, like [00:29:00] anyone who can help people realize that that's not the case is gonna get a big thumbs up from me.

[00:29:04] Steve McDougall: Yeah, we're currently investigating what we can do with CloudFlare work is that in a minute. So you know, part of the, part of the process with Treble is that you send that payload to us. Now, if we can move that us closer to you, that means it's gonna be a quicker response time. It's gonna be less network traffic.

Less carbon footprint by sending it closer instead of, you know, where our servers are located, somewhere in America or somewhere else. You know, if I'm doing that from AUR Wales where I am, then you know, it's just quite, quite a distance. I've gotta send that payload, which, yeah, I could reduce that traffic by using Edge locations a little bit more.

So we are looking into all of those different ways that we can really reduce. The, the latency and that payload and that what we can do with it.

[00:29:58] Phil S: Brilliant. I look forward to finding [00:30:00] out more about that. I was gonna ask, cuz we've, we've asked you a whole bunch of stuff about treble, but I know that you've done lots of other a p I stuff. So you were working on you invited me to a livestream that I think I didn't make it to, but you've also done like a video series on building APIs with Laravel.

Can you tell us, tell us more about that.

[00:30:17] Steve McDougall: Yeah, so I'm actually working on another video series at the moment called API Masterclass and Lara Valve. So going from, I've never built not, I've never built an API before, but I've built an api. But let's be honest, I can't really call it an api. I can call it adjacent interface to my database.

I'm gonna go from where that would be to building something that is, Better going, you know, going through API design, what's important, actually understanding the process behind why you have an api, what the API's for cashing, you know, building up effective queries around it and that sort of stuff. [00:31:00] That is underway. I'm tempted to lead that into a book

because, but you know, we, we've spoken a few times, Phil. Me, me releasing an API book as an updated APIs you won't hate specifically for Laal to stop the questions for you.

[00:31:17] Phil S: Not allowed. There can only be one book about APIs. No one else can do any API books.

[00:31:22] Steve McDougall: Well, my, my book's gonna be called APIs Phil won't hate, so it's okay.

[00:31:27] Phil S: Nice. I was joking the other day that the Build APIs you won't hate was the dumbest name for a book, cuz it's not about whether you like it or not, it's about whether your clients do

[00:31:35] Steve McDougall: Yeah.

[00:31:36] Phil S: So I'm like, there's a mistake in my book name. Yeah, that's brilliant. I mean, the, the book that I did was like how to build Rest ish APIs with Laravel

[00:31:44] Steve McDougall: pretty short. Yeah, I've got it here, I think. Yeah.

[00:31:48] Phil S: you had a whole box of him at one point.

[00:31:50] Steve McDougall: Yeah. No, I, I've finally managed to give all of those out.

[00:31:52] Phil S: Fantastic. You just giving 'em away on the street corner. You can put mugs on it. It's

[00:31:57] Steve McDougall: Yep.

[00:31:57] Phil S: it as a door stop. Awesome. But yeah, [00:32:00] no, I like the idea of there being a specific for Laravee up-to-date book because yeah, it, it's really hard to like any. Writing about APIs should be polyglot. It should be completely agnostic to the, to the code in question.

But people don't just want ethereal concepts wafted in their face for 300 pages. So you need to

[00:32:20] Steve McDougall: cons. Yeah. They want code examples and things they can relate to.

[00:32:24] Phil S: Exactly. And not just, not just shoving it into a a page like, cuz if I'm, I, I remember like when I was like 11 years old, just like trying to type code that was in a book and, and that is dumb.

People don't want that anymore. They want the code in GitHub. And so you have to make it a real thing. And then, you know, Laravel has had four or five, probably more. Are they on La LaVale? 10.

[00:32:46] Steve McDougall: Yeah. LaVale 10 currently.

[00:32:47] Phil S: Cool. My book was done with like 4.2, so,

um, Yeah,

Taylor's been a, Taylor's been a busy, busy boy, but yeah, trying to keep that up to date is hard work.

And so, yeah, I think more people should make kind of specific, this is how you do it in this, [00:33:00] this sort of language. That sounds good. So the, the video series, the masterclass, you are gonna like build a real API that does actual stuff, or is it, is it a Twitter clone? , what you doing?

[00:33:12] Steve McDougall: No, I'm, I'm gonna I'm gonna build an actual api. And it's gonna be, I'm gonna have, each chapter will be a new branch. So here's where you start. Go to that next branch, follow along, go to the next branch, follow along so you can really understand the journey that you're going on. And you know, by doing it that way, people following along can choose when they want to get off.

Like, okay, I'm happy with how far I've gone. I'm gonna stick with this for. , I know I've got four more branches to go, or four more chapters to go. But for now I'm happy. I've learnt a few lessons and then they can come back and revisit it to kind of go those further steps. Cause there's a bit of a joke in Bel community about me being opinionated with my code.

And it's not really, it's, it's not a [00:34:00] joke. It's true. I'm probably one of the most opinionated developers you'll find, but it's for a. You know, I, I, I like things a certain way. Probably part of my OCDs just rubbing off on my coding standards, so,

you

[00:34:16] Phil S: the idea of somebody in the Laravel community saying that somebody else is opinionated,

they're like opinionated by default. So anybody, anybody that's sticking out above that has to be really up there. Fantastic though. Opinions do help make things quicker, as long as you can get along with those opinions.

Like a lot of the frameworks that try to do, anyone could do anything in any way that they want. Then everyone just goes, how the hell do I do anything? So

[00:34:43] Steve McDougall: yeah, exactly.

[00:34:45] Phil S: frameworks, Julie, grease the wheels on getting things done sometimes, but

[00:34:48] Steve McDougall: Yeah. It's helped us learn a few, learn a few lessons over the past in the industry, you know, by someone formulating an opinion and people adopting that opinion. It means that that's become the new standard. [00:35:00] And so that's a little bit how PSRs came about. in the PHP world.

[00:35:04] Phil S: For sure. I mean, I've been using Laravel for the Protect Earth api and that's, that's been a really nice experience. We've got a bunch of live wire, well, no, we've got Nova, but we might be switching to Live wire or something. But the API is really slick and there's an an amazing community of people as well.

We've got like five, six volunteers who just throw code at us and, and enable us to do really useful stuff. And I was saying we've launched the we've launched the weather track. Stuff, which is like finding out what the temperature, humidity, and rainfall was getting that from an api and then we're talking to another API and finding out what the soil type is in a certain area.

And then we can find out like when, when we do beat up surveys to find out which ones died, we can, we can kind of go, well, we probably shouldn't plant in a, in a place like that. Or if we are going to, we should at least make sure it's more watered or whatever. And so, yeah, like right now, Laravel is literally saving the world by improving forest.

So

[00:35:58] Steve McDougall: Yep.

[00:35:59] Phil S: So it's, it's [00:36:00] been really been really fun to be back in that, in that kind of in the community, but mostly just using it and, and just it working and me not feeling like I have to get involved with the framework or like bickering cuz it just works really well and I can just get on with it. That's quite nice.

[00:36:16] Steve McDougall: It's definitely, I mean, yeah, I've lost my hair, but you know, that's not Lara's fault. That's, that's me having the amount of children I do. But yeah, if your children went here, I'd definitely have long, luscious looks like you, Phil.

[00:36:28] Phil S: Need to get a cut.

[00:36:31] Steve McDougall: Lara's definitely made development easier, especially in the API space.

[00:36:34] Track 1: Yeah, I'm gonna start blaming Laravel for my, uh, l l lack of coverage here too. I think even though I've been a JavaScript developer for longer than I can think about

at

this point.

[00:36:43] Phil S: That is

[00:36:44] Steve McDougall: that's just the weight of the NPN modules. Pulling your hair out of your

[00:36:47] Track 1: That's it. Totally. Yeah. Dragging it away from me. One, one thread at a time here.

So Steve, what are the things that you're working on now that are coming next? Right? Like, I, I know you have maybe some work things. You have, uh, [00:37:00] personal projects that may be coming.

Um, what are you thinking about right?

[00:37:03] Steve McDougall: Right now. Ooh, that's a very good question. At the minute I'm, I'm building out SDK tools. I released a new open source package a few days ago called sda SD K tools. I'm trying to, my second attempt at enabling people to build better SDKs in, in P h P. Um, I'm trying to adopt more. PSRs, lots more auto discovery, but still enabling them to keep uh, kinda that friendly API and developer experience I might be used to in something like LaVale, for example.

That's my current project, if going well so far. I released it, didn't publish it really, I, I tweeted about it as it's been starred a few times. I've used it twice already. and it, it's, it's definitely helped. It's, you know, that's my current project [00:38:00] cuz I like integrating with APIs as well as building APIs.

So it's always a bit of a where do I want to focus?

[00:38:07] Track 1: Of course, yeah. It's probably a good sign that you're your own user as well. Uh, you feel some of the pains that

you're trying to solve there.

[00:38:14] Steve McDougall: Yeah. I mean that's one of the things that I say to anybody, building an API is, You know, as you're building your api, make sure you're integrating with it so you can feel those pain points that your user will do, because that's gonna point to where you can improve upon.

[00:38:29] Track 1: Yeah,

[00:38:30] Steve McDougall: And it was actually what part of my talk that I gave at Lara EU around I think it was called building APIs or something like that.

They wouldn't let me change the name to building APIs. Phil would like so

[00:38:41] Phil S: Good. I'm

glad. It's not just

me.

It's not just me. Freezing.

[00:38:44] Track 1: I've, supported every, uh, every proposal I put in from now on is gonna have Phil's name tossed in there somewhere.

Yeah.

[00:38:49] Steve McDougall: Approved by Phil

[00:38:50] Track 1: so Steve, um, appreciate you coming and joining us today. Uh, can you tell us where folks can find you online?

[00:38:56] Steve McDougall: just Steve King, everywhere.

[00:38:59] Track 1: it. [00:39:00] Cool. Yeah, and I'll, I'll throw, we have lots of links to you everywhere, uh, which I'll drop in the show notes here. Um, about trouble? Where's the best place to

go

to get started there?

[00:39:07] Steve McDougall: trevor.com. T R E B L L e.com.

[00:39:10] Track 1: Perfect. Well,

[00:39:12] Steve McDougall: spelling, but we're, yeah, we are. There we're uh, Trevor API on Twitter. We're always tweeting, always

[00:39:20] Phil S: Awesome. Well, thank you so much for telling us about all of those cool things that travel are working on and you are working on. I want to keep an eye on them. And on the subject of s D K stuff, I've, I'm writing the latest book, surviving Other People's APIs. I know I've mentioned it in the past.

I am li I am honestly working on it very, very quickly now. I've done I've finished three chapters in three days, and so people should check that out because it's not just if you are a front end developer, but it's any API that talks to other APIs. So anyone that talks to APIs, which should be most of.

This, this book should be right up your alley and it talks about SDK's a fair bit because half of the [00:40:00] stuff that you have to know in order to successfully interact with an API can be done by the sdk. So you don't have to, otherwise you just have to build an SDK for every API that you ever talk to every time, and that's probably going to be bad.

So yeah. Brilliant. I look forward to your, your stuff about SDKs and I'll, I'll shove it in the book if it's out in time.

[00:40:22] Steve McDougall: Yeah. Sounds good.

[00:40:24] Phil S: Sweet. Alright, thank you very much. I'm gonna go and get back out into the woods. I've got invasive species to hit with an

[00:40:30] Steve McDougall: Enjoy the

trees.

[00:40:32] Track 1: Right

on.

Thanks for joining,

[00:40:33] Steve McDougall: Thanks very much for having me. Take care.

[00:40:36] Track 1: Take care.