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.