Track 1: Take it away, Phil.
Phil S: Oh me,
Track 1: Oh yeah.
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.
Track 1: That's what we like to hear.
It's perfect.
Phil S: Yeah.
Do you wanna do the intro
Track 1: Oh, you better believe I'm gonna use that.
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.
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?
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.
Steve McDougall: Thanks.
Thanks for having me.
So yeah, I'm really excited to be here.
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.
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?
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.
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?
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 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.
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.
Steve McDougall: Yeah, similar.
Phil S: Okay.
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
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?
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, 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.
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?
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 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
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
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
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.
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 the open API out and they just added
like a engine X module so you can really wedge it in at, at
Steve McDougall: Oh, nice.
Yeah,
Phil S: that, that seems complicated and something that a lot of people
can't necessarily do in certain hosting environments anyway, so.
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.
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 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.
Steve McDougall: It.
It sounds like a lot of juggling just to get that simple kind
of logging effort, right?
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 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
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.
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.
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 best approach is so that I'm not forcing
dependencies on any one framework.
So it, it's been a juggle definitely.
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.
Steve McDougall: I forget words.
I just know.
Birch
Phil S: concepts.
Yep.
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?
Steve McDougall: so 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 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
Track 1: Yeah.
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.
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.
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.
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 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,
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
for building out an open API spec.
Is there any way that we could improve upon that?
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.
Steve McDougall: yeah, exactly.
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?
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, 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 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.
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 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?
Steve McDougall: yeah, exactly.
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
Steve McDougall: Works on my machine
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
Steve McDougall: Yeah, you wanna, you wanna treat the cause, not the symptoms.
Right?
Phil S: Yeah.
Yeah,
Steve McDougall: 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?
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
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
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.
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,
Steve McDougall: Yeah, basically.
Phil S: that's kind of cool.
Steve McDougall: And I, I'm currently building out monthly 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.
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 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
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.
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,
Steve McDougall: Yeah, exactly.
Phil S: just by looking to graph.
So if you can kind of let people know that sort of trend, that's really helpful.
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.
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 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.
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 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.
Phil S: That's
Steve McDougall: that will be a, a free tool for people to just use
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.
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 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.
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 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
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.
Phil S: Yeah,
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.
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
Steve McDougall: Yep.
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,
Steve McDougall: Yeah, exactly.
Phil S: emissions go down is a good thing.
Cool.
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, 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,
Phil S: Yeah.
Steve McDougall: which again, would really help on that green front, right.
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.
. Something, something green tech.
Yeah, that was it.
It's the 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 anyone who can help people
realize that that's not the case is gonna get a big thumbs up from me.
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.
Phil S: Brilliant.
I look forward to finding 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.
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.
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.
Phil S: Not allowed.
There can only be one book about APIs.
No one else can do any API books.
Steve McDougall: Well, my, my book's gonna be called APIs
Phil won't hate, so it's okay.
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
Steve McDougall: Yeah.
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
Steve McDougall: pretty short.
Yeah, I've got it here, I think.
Yeah.
Phil S: you had a whole box of him at one point.
Steve McDougall: Yeah.
No, I, I've finally managed to give all of those out.
Phil S: Fantastic.
You just giving 'em away on the street corner.
You can put mugs on it.
It's
Steve McDougall: Yep.
Phil S: it as a door stop.
Awesome.
But yeah, 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
Steve McDougall: cons.
Yeah.
They want code examples and things they can relate to.
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.
Steve McDougall: Yeah.
LaVale 10 currently.
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, 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?
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 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
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
Steve McDougall: yeah, exactly.
Phil S: frameworks, Julie, grease the wheels on getting
things done sometimes, but
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.
And so that's a little bit how PSRs came about.
in the PHP world.
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
Steve McDougall: Yep.
Phil S: So it's, it's 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.
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.
Phil S: Need to get a cut.
Steve McDougall: Lara's definitely made development easier,
especially in the API space.
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.
Phil S: That is
Steve McDougall: that's just the weight of the NPN modules.
Pulling your hair out of your
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, personal projects that may be coming.
Um, what are you thinking about right?
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 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?
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.
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.
Track 1: Yeah,
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
Phil S: Good.
I'm
glad.
It's not just
me.
It's not just me.
Freezing.
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.
Steve McDougall: Approved by Phil
Track 1: so Steve, um, appreciate you coming and joining us today.
Uh, can you tell us where folks can find you online?
Steve McDougall: just Steve King, everywhere.
Track 1: it.
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?
Steve McDougall: trevor.com.
T R E B L L e.com.
Track 1: Perfect.
Well,
Steve McDougall: spelling, but we're, yeah, we are.
There we're uh, Trevor API on Twitter.
We're always tweeting, always
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 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.
Steve McDougall: Yeah.
Sounds good.
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
Steve McDougall: Enjoy the
trees.
Track 1: Right
on.
Thanks for joining,
Steve McDougall: Thanks very much for having me.
Take care.
Track 1: Take care.