APIs You Won't Hate

Phil and Mike catch up about APIs for planting trees, the value of planning, and API gotchas in serverless functions

Show Notes

Links from today's show

Phil's reforestation charity
Posts on APIs You Won't Hate
API Tooling

Serverless functions in JAMstack frameworks

Thank you so much to our sponsors:

Creators & Guests

Host
Mike Bifulco
Cofounder and host of APIs You Won't Hate. Blogs at https://mikebifulco.com Into 🚴‍♀️, espresso ☕, looking after 🌍. ex @Stripe @Google @Microsoft

What is APIs You Won't Hate?

A no-nonsense (well, some-nonsense) podcast about API design & development, new features in the world of HTTP, service-orientated architecture, microservices, and probably bikes.

Phil Sturgeon: and

Mike Bifulco: we'll come back to APIs.

You won't hate it's me, Mike, with Phil here, Phil.

How's it going?

Phil Sturgeon: Hey, pretty good.

I've been out in a failed plan entries in the rhino day.

So just, you know,

Mike Bifulco: normal pretty standard stuff.

Yeah.

Where in the world are you?

Uh, catching up with me from today?

Phil Sturgeon: Southwest of England.

Again, she's is my usual corner of the world.

These.

Mike Bifulco: Yeah.

It's an odd feeling that you have a usual place to me.

I don't think I'll ever quite get used to that because it sort of feels like
you're, you're hopping about and jumping from forest to forest, like a, an idea.

I can't quite get a grasp on.

Phil Sturgeon: That's been all over the place.

I mean, it's been a bit weird.

I'm in the peak district.

Near Manchester one day and then like north Wales around
the corner, the next looking at a bit of land and then

rushing off to, to do a planning project in London.

And then I've been putting some real miles on my like electric
rental thing, but, uh, hopefully I can ditch the car soon and

get back to being, uh, the wandering woodsmen on, on two wheels.

Cause, uh, I'm recovered from my, from my injury surgery.

Recovery has gone nicely.

I'm I'm back and I can like lift stuff
without crying and um, Back to back to health.

So, uh, yeah, there'll be plenty of moving around,
but it will be, it'll be bike powered instead.

Mike Bifulco: Yeah.

Well, that's great to hear.

I'm glad to hear your recovery is going well.

Did, did you end up having two surgeries?

No, just

Phil Sturgeon: the one in the end.

The, um, there was some like other side effects.

Basically.

I had like a surgery and then I was still in loads
of pain and I said, what the hell is going on?

And basically it's just cause.

I had gone from being incredibly active to sitting on the couch for four months.

Um, there weren't like loads of other problems going on,
like crazy stomach acid, just like causing pain everywhere.

So it seemed like there was something much bigger going on, but
it was like, oh no, you've just been really lazy for a while.

And your body's upset about it.

Yeah.

So.

Mike Bifulco: Yeah.

Yeah.

Cool.

Well, I'm glad to hear it.

I'm glad you're back in one piece.

And I guess just probably as the weather starts to get
a little nicer there, you can get back on two wheels and

kind of start to do all the things that you'd like to do.

Phil Sturgeon: Yeah.

We're currently being battered by storm Ursula, which is a
ridiculous name for quite a vicious storm, but, uh, yeah,

the weather should start getting nicer in a couple of days.

Mike Bifulco: Yeah.

Well, I'm glad to hear it.

I want to get an update from you on, uh, your, uh, work with protect.

I want to hear a little bit about what's been going on with APS.

You won't hate.

And some of the work we've put out there, but first, before
we do that, let's hear a little bit from our sponsors.

This episode of APS you won't hate is brought to you by
triple treble is an API management platform that helps

developers and companies understand their APIs better.

And then the process saves a lot of time and money.

What started out as a solution for their own problems has grown into
a platform that's processing more than 9 million API requests a month.

Treble features real-time API monitoring, automatically
generated documentation, logging and error tracking, API

analytics, and one click API testing to learn more about trouble.

Go to treble.com/api, as you love.

That's trebled, T R E B L L e.com/api, as you.

Thank you so much to trouble for sponsoring API rotate.

This episode of APS you won't hate is brought to you by lob.

Lob is a group of passionate people working towards their vision
of increasing connectivity between the offline and online worlds.

They helped developers.

Card's letters and checks is easily.

It's email through restful APIs, lobbyists looking for engineers at
all levels, interested in joining a successful growth stage startup.

They offer collaborative culture, supporting teamwork and mentorship.

Their founders have a strong vision of building a product
led organization, and it's an opportunity to have a

big impact on LOBs business and engineering culture.

Lob is built using open API specifications for contract
testing, generating documentation, and soon SDK.

Their API is written in the mix of JavaScript go
Lang and elixir and their customer facing deck.

Built with Vue JS.

If you're interested in joining lob, check them out online at lob.com/careers.

Thank you so much to LA for sponsoring APS, you will need.

And we're back.

So Phil tell me you've been outside.

You've been doing things.

Uh what's.

What's the latest with the

Phil Sturgeon: charity.

Yeah.

I've barely been looking at my laptop, which is ridiculous.

Cause there's a lot more planning work to be
done, but it is the height of planting season.

I'm pretty much planting trees every day.

Sometimes it's a volunteer project where there's 60 of
us trying to get through 5,000 trees in three days and

sometimes there's eight of us and we've got, I've got some.

Tough paid planters.

You know, we had a few projects where there
was maybe eight of us doing 1,500 trees a day.

So the, the number of trees we can get done
in a day really varies project to project.

But yeah, there's loads of projects going on.

It's pretty much every day, like back to back, um, Thursday,
I'll be in the Cotswolds Friday, I'll be in London or weekend.

There'll be up in Manchester.

It's like, as soon as it gets dark planting, I jump in
the car and you're just scream off to the next project.

But yeah, the.

The charities and a funny place, because we've, we've
basically paid for paid for loads and loads and loads

of trees and been planting loads and loads of trees.

And now I've got to do the job of documenting all the.

So that they start showing up on people's ecology
profiles and everywhere else where we get our money from.

And we've had a few new funding partners on board.

So I've had to do some work on our API, um, and the iPhone app
to, because we use an iPhone out to take photographs of all the

trees that gets them up in our API and then funding partners
can pull those, those photographs of trees in for whatever.

And yeah, that's a layer of our PHP app that Matt originally
put together and it's using a whole bunch of open API as well.

So it feels pretty cool.

Quit working in tech and quit working on API APIs, but still be
doing modes of API work and open API work, and then writing about it.

VPAs you and hate.

So I haven't gone too far.

Mike Bifulco: Yeah.

It's rarely to get, to actually be able to meaningfully
use the stuff you we want to build and, and, uh, be

your own user is kind of an interesting place to be in.

So give me a sense of scale here.

I know it's been a long winter for you.

Do you have some estimate for how many trees you've
planted with your volunteers in the past few?

Phil Sturgeon: We planted 3000 trees, roughly, I think in the last winter.

And then this winter we've done, uh, we've done about 15,000 under
projects that we kind of directly control, but I know that there's another

double that there's another like 17,000 floating around that we have.

Paid for, but I haven't gone out to the projects to see them yet.

So we're looking at about whatever, 35,000 trees
this season, and there are still more to come.

We've probably got another, I've got like another
10,000 left to do before the middle of March.

It's all a bit bonkers.

Um, so we've really, really grown that up and we're
starting to get our hands on huge chunks of land as well.

So we've, um, we've just had.

It's only seven more sleeps until we get our hands on
the Cornish bit of land, the ancient replanted, Woodland.

Heck.

Yeah.

And that has been an emotional rollercoaster since October.

Cause there's been so many times where it seemed like we might not get it.

There was a few issues around like VAT and, and
like negotiations with a philanthropic donor.

And there's been a lot of different things going on, but like I
think, yeah, contracts are being exchanged in, in seven, seven days.

Oh, that's amazing.

And we've started working with people who were basically the original
plan was that we kind of raised a bunch of money from donors and

then Bilan directly, and then we're still doing that, but we've also.

That's really interesting person who was just got millions of pounds, apparently
burning a hole in his pocket and he wants to kind of buy land and hold onto it.

And then he needs someone to reforest it.

So it's kind of more like a partnership, um, where we'll lease
the land from, I dunno, a pound a year or something, and we'll,

we'll, we'll manage the land back to back to being a forest.

And so we've just found 27 acres for him and the offer was accepted and.

That's only using like 1% of the money.

So there's going to be a lot of land for us to plan, which
is why it's all about scaling things up, making things

more efficient, making the project planning more efficient.

I was talking about that last time and, and making sure that the
API is solid and does everything that our funding partners need.

So they can pull out all the data and, and, and run their business off
of it and not have any bugs and mistakes, because whenever I have to try

it, Figure out what's going wrong with the API or awkward mismatches.

It's like, I'm in a field and I'm trying to send you samples of
code and code requests on my phone and this is not going well.

So I have to make sure that thing is like slick and reliable
and not taking me away from the actual work at hand.

Mike Bifulco: Yeah.

So really that's incredible.

It sounds like you, you have been figuring out how to scale
beyond just the fill, which is one of the core problems.

I'm sure that you have there.

Unbelievable for me to imagine that there's, I don't know,
sounds like 15, 20, 30,000 trees being planted this year.

And each one of them will also have a glamorous.

Pretty wild, man.

That's very cool.

Phil Sturgeon: Yeah.

Luckily we have a lot of different types of projects
where some of them, we handle the entire thing.

And sometimes the project has already been planned
by a big group, like say the Woodland trust.

And they're just looking for someone to do the actual planting.

And so with those sorts of projects, luckily we can just shove them in and take
like a few establishing Schultz, but we don't have to take a photograph of.

But yeah, there, there are some of those projects where like we're
planting 4,000 trees near, uh, soon my neck of the woods and yep.

I'm gonna have to, I'm gonna have to go out and photograph
4,000 trees and put that one's a bird cherry that one's a Rowan.

That one's a, ah, you're about to get like three pound for everyone.

Mike Bifulco: Yeah.

Yeah.

That's really cool.

You're also about to have the least interesting
Instagram feed I've ever seen, but you know, I'm into it.

That's great.

Phil Sturgeon: Yeah, I should hook it up.

So every single one just goes straight out and
people are like, we don't care about this at all.

They all look the same.

They're all two years old.

It's not interesting.

Mike Bifulco: It's all right.

That's all right.

Yeah, really cool, man.

So th the work that you've been doing to support that kind of the
infrastructure behind this stuff has resulted in some learnings and

some articles that we've published recently on the site for API, as you
won't hate, you want to tell a little, tell us a little bit about that.

Phil Sturgeon: So Matt did a great job of
putting the APA together in a bit of a rush.

We were kind of given, we were given an API hosted by
another planting partner of, at one of our funding partners.

There's a company called future forest company.

They do amazing things.

They do.

Slightly differently, but a good group of people.

And we basically had to kind of copy their API so that they could
be integrated into one of our funding partners really easily.

So we didn't really bother designing the API as such.

We just kind of went, make it look like.

And that seemed like a reasonable reason to not design it.

It's one of those things, like the mechanics car is always
broken or like the shoemaker's son never has shoes or whatever.

There's a million of those phrases around, like, I know chefs that
just microwave all of their dinners when they get home from work.

It's always that thing of like, you think you're
an expert in it, so you just kind of don't bother.

And I thought I know all about APA design first.

I know enough.

To to know when I should use it.

And when I shouldn't and I totally messed up,
they're not having open API from the start.

It just meant that we didn't have any API documentation.

When we had a second funding partner, they want it to get on board
and I'm like, oh, let me send you some awkward curl examples.

And if you have questions, just figure it out, I guess.

And that led to a bunch of integration issues
and we had no way to do contract testing.

There were just no tests at all.

So we made a bunch of changes to improve before.

Because it was built to handle like hundreds of
trees and then we've got tens of thousands of trees.

So yeah, things kind of blow up in our face in a bunch of different
ways from just having their docs, having no contract testing

and not being able to do design first for new functionality.

So if he wants to add a new end point,
we've kind of got, I have this like weird.

You know, we started a new open API from scratch and
it just had the one end point in it with nothing else.

So it was kind of useless.

Couldn't use it for mocking or anything else.

So, um, I really wish I stuck to my own advice.

I've been talking about how important EPA designed
first for months, and then I just don't do it.

It's immediately justified everything I've been saying for years.

Yeah.

Mike Bifulco: I think we can chalk it up to a good reminder
that, uh, it's helpful to put yourself in the right

shoes from time to time to reinvigorate that context.

I, I tend to live more on the visual design
side of things in, in sort of past lives.

And that's something that a lot of designers will say, like,
you really need to go in and do sketches and put together wire

frames and all these other things before you start building.

And every single designer I know with the website.

Splash some CSS on to their code editor and
started making a mess of that way first.

So, uh, I'm also definitely guilty of that.

It's tempting to go in and do it the wrong way first.

Um, and the quote that I always bandy about from a
friend and a mentor is from, I think it's our Franklin.

That's essentially like a, as an architect, your most valuable tools are
the pencil at the drawing board and a sledgehammer on the construction site.

And it's sorta like, guess which one of those is cheaper?

You know, it's definitely usually a better idea to spend some
time with a piece of paper or, you know, your design system,

writing things down, uh, ahead of time or you can go and build it.

And then when your, your project goes from a hundred trees to a thousand
trees, to 10,000, you're going to be sledgehammering your app into

shape and, uh, starting from scratch and wasting a bunch of time.

Yeah.

Phil Sturgeon: I mean, there were, there was, there was so many things that
like, you know, not all Matt's fault, uh, it really, really hard to spot,

but they were little things where the, we were copying was a numeric string
and, uh, instead of, uh, integer or whatever, and PHP had opinions and just

did it one way or the other, and they're, they're really small, hard to
spot things, but I can cause you know, a bunch of errors on the other side.

So yeah, I think I'm.

I'm just never making that mistake again.

I'm always going to, if I ever need someone to
make an API for me, I'm always going to say right.

Here's the open API spec.

When you build it, implement contract testing
with the spec and like make sure it passes.

Past this open API.

Like it, it doesn't work the way I want it to, so you
don't get paid until you fix it, like make that pass.

And then the contract is done.

The job is done.

Mike Bifulco: We'll say I've definitely been on the
other side of fill requests for software in the past.

And usually it starts with a cheeky, like, Hey, I've got a quick
idea for something that's going to be really easy to go and build it.

And really like, you're just polishing the tip of the iceberg and introducing
it to me in a way that sounds like it'll be a quick coffee break project.

Uh, and they, they get big pretty fast.

So we've all been victim to this.

I think, you know, Matt and I are no strangers to these sizes of problems.

And sometimes you just do what you can with the time you've got, for sure.

Phil Sturgeon: Yeah.

The, um, uh, I need to change.

How I do business completely from everything is messed up because it's always,
it's always like the quickest laziest, crappiest version of everything.

Like I'm usually zipping about doing a million things and then
like an idea pops into my head and it's maybe it's like three pints

in, but I'm just like, oh yeah, we totally need to do this thing.

Hey Mike, can you do this thing?

And I just fire over a DM and you're like, I
guess, and then you do what seems sensible.

And it wasn't exactly what I imagined based on 10 words.

And then.

You messed it up, maybe to spend again, that's like the benefit of the,
kind of the open API thing, or just generally writing down a bloody project.

Brief both.

If it's an API, like the more time you can spend planning
the thing, the less time you spend on doing the thing.

Cause if I just say 10 words at you and you take a
swing at it, it's not going to be exactly what I meant.

Is it for

Mike Bifulco: sure?

Yeah.

Yeah.

Uh, a thoughtful proposal is, is the hard part of the job on some
level when you're doing planning and sort of the leadership side of.

And by the way, I should say that wasn't meant to be
a personal critique or attack or anything like that.

We've all done it.

Phil Sturgeon: Um, well, uh, I'm well aware.

It's just kind of why I had to quit the last job.

Right.

It was like I'm doing a full-time job and the charity and trying to like for
a while, like get Dutch residency and start this software consulting business.

And, and, and then like, people were like,
Hey, come and do this, uh, PHB meet up.

And then there's a podcast.

And then, ah, Oh, fuck it.

But, um, yeah, thankfully, hopefully as I get more time,
I can, I can put more effort into doing things properly.

Or I'll just keep taking on more tree planting
projects and keep rushing around doing them all badly.

We'll see.

Yeah.

Mike Bifulco: Well, Hey, part of the reason we have the, the site and
the podcast is to scale your wisdom and the experiences that we all have.

And the thing I haven't really said in public is that part of the
reason we're also recording your voice over and over, is that just

so that we can take all the words you've written and throw them
through machine learning and deep, fake Phil wisdom from here forward.

So you can go play in the trees and we'll just set up a
fill, but to yell at people on the internet when we need it.

Phil Sturgeon: Sounds good.

Well, speaking of getting machines to do our bidding,
one of the things, one of the two articles we put up

recently was about using, um, Akita, a really helpful tool.

Uh, it's this, the tool I use to get me out of the hole where like, okay,
we have API, we need open API so that we can do a bunch of useful things.

Docs, mocks, contract testing.

But I am not going to sit down there and go to every end point and go, oh,
there's a property called, you know, Fu and it looks like a string and oh, you

know, format equals date and just click a thousand buttons or type a thousand.

Mine's a Yammer.

That just sounds like death.

And no one got time for that.

So, uh, yeah, we did not call called creating open API from HTTP traffic.

And it would like show you how it works, but super handy.

I knew there were tools out there that.

And I'd kind of like played with them a little bit a year ago and they
were all still, you know, kind of, kind of getting really good now.

And there's another one called optic, which people recommend.

I played around with some Beyers that were a little tricky.

But, uh, I've heard, that's made a lot of progress too, so
Akita or optic can help you out, but it's amazing to just

say, Hey, look, maybe was over there, poke a few end points
with your HTP client of choice, co postmen, whatever insomnia.

And then it just goes right.

You've got these endpoints, these properties, these mindsets.

Does your rep an API.

Yeah.

And you're done.

Yeah.

That's

Mike Bifulco: pretty amazing.

It's definitely hacker friendly.

And I mean, hacker and maybe the friend, well, the, the nicer sense of
the word, not like I'm going to go steal your bank account necessarily,

but like, if you want to figure out how something is built or get some
introspection until the way that someone else has designed an API.

Like, it can be a useful exercise to go
in and dive in and use that kind of thing.

Even if you're not going, and re-engineering an API or putting
design docs and testing together around something that you're

already using, like kind of interesting to see the way that
things are organized, uh, from, you know, soup to nuts.

It's, it's one of those things that's really easy to do with some of the
other things we work with, but like, yeah, these, these tools are really.

Coming into shape lately and definitely hitting a stage where it's like, oh,
you can go and do some really meaningful, interesting Packery with this stuff

and put together a useful prototype based on an API that you know, exists.

Phil Sturgeon: Yeah.

Yeah, for sure.

And I just, I can think about how it would have helped me in a lot of things.

Projects in the past, like when I was at, um, giant coworking
company that I need to stop naming when I'm complaining about

them, I was constantly trying to get people to write open API.

You know, we had a few people that were like, yeah, I'm going to make open API.

I want dogs and mocks and SDK generations and all that.

Good.

And I brought people with pizza that helped, but
it was still quite a lot of reach-out effort.

And then it was like trying to get people to slight that work into that
sprints when they have completely unmanageable deadlines already and, and

constant rewrites, because they never wrote any docs in the first place.

So they don't know how it works.

So they're too busy doing three, right.

To write the docs, which means they'd probably
have to do another rewrite in the future.

Ah, so I was trying to get people out of that cycle and I could just imagine.

Dropping Akita or something similar optic, some sort of traffic sniffing proxy.

I can just imagine dropping that into the end to end test suite
where we've got, you know, multiple APIs or talking to each

other, and then all of that traffic is being recorded and you
can then convert that into open API and awesomely for the.

Comfort for the API is and teams that did have open API.

We were dropping that into the end to end test suite with a validation proxy.

So if you suddenly made a change that broke
your open API, it would say error error.

So you could kind of use the end-to-end test
suite to create the open API if you don't have it.

And then once you do that, You can use it for validation testing
and you wouldn't have to say, please, please, please, can you sit

down and type out every single property in every single thing?

Cause again, humans will get that wrong.

So yeah, it's a really useful tool and I'm glad that I got to play with it.

Cause I think a lot more people can use that to catch up because
so, so many people I know don't I've done the poll a few times.

Yeah.

Are you code first design first, uh, switching from
code first to design first, or like awkward combination.

And most people are awkward combination, um, or switching.

So yeah, using those tools, you can kind of play,
catch up, get your open API and move on from there.

Design first, all the things.

Yeah, I think

Mike Bifulco: the reality is there's very few companies that any
of us get to work with on any level that are like starting from

scratch and getting to play with things from the ideal scenario.

And especially if you've got something that's, I don't know, 10, 15 years old,
like you're working your way back towards compliance, uh, is a, is a mega chore.

And some of those tasks that are sitting down and staring at Yamhill, or, you
know, HTTP responses, sound torturous for experienced people and our problems.

A little too important to give to someone who's like in an
internship or data entry role or whatever, for a variety of reasons.

And, and putting tooling in the middle, I guess, is sort
of the obvious engineer's response there is to figure

out some way to automate it in a way that's rolling.

Phil Sturgeon: I've definitely seen some engineers kind
of saying, well, we don't need to ever make an open API

because we can always just produce them automatically.

And that's taking the point too far a little bit.

Like, I, I think some optic definitely seems to kind of be
portraying that as like, you don't need to spend time designing

it because you could just, you know, make it automatically.

And I.

No, if that's still their messaging or, or maybe it never was.

But I, I worry about that sort of concept because what I did with Akita was use
it to get a starting point that's pretty accurate and then tweak it from there.

And there were things missing and there was like, the human touch was missing.

It was just what you can sniff and control.

And there were, I think there are a few examples in there, but I want
to put some more targeted examples and I had to remove a few sensitive

UIDs cause you know, with, with certain new ideas, the way it's currently
built, if you have the UID of a funding partner, you can just see your.

Orders and save all of their trees and not have to pay for them.

So I don't want to put that ID in the docks.

And so I think anything that you get from one of these tools
that kind of looks at what's going on and takes the best

educated, guess it can, it's never going to be perfect.

It's never going to be a publishable document that you would be proud to
make, you know, your API reference documentation of choice for end users.

Uh, it's just like a useful artifact of this getting pretty close.

It's like a quick.

More than anything else, you know?

And, uh, yeah, I've seen some engineers go well, great.

I don't have to do the time-consuming thing
cause I'll just do the auto automated bad thing.

And that just lazy.

It's easy to

Mike Bifulco: maybe, um, interpret in bad faith, I suppose, or like in, in a
way that makes life easier, but not necessarily in the long run beneficial.

So.

I wanted to mention one of the things I've been thinking about lately.

So I think you, well, I'd imagine you're probably much more disconnected
from the internet and Twitter and things than I am these days, as a

result of you mostly literally getting your hands dirty, but, uh, you
and I tend to run in slightly different, like developer circles online.

And one of the things I've.

Noticing a lot lately is a lot of, sort of like call it
indie web sort of developers and people building their own

products and whatnot who are building on top of frameworks.

Like, uh, she's I don't know, Jekyll and, um, view and remix is one of
the newer ones and next JS and all these other things that have really

interesting integrations for sort of natively supporting automatically
generated or serverless functions within a sort of web application context.

You could basically use a command line app
to generate the framework for a web app.

And then by creating a file in a specific place, it
gets deployed to, uh, an Amazon serverless app or, you

know, whatever other hosting providers who do magic.

I love it pretty cool.

And it's all done.

Like it hooks into CII really nicely and does lots of good things with that.

In addition to giving sort of the.

In most cases, JavaScript, granted hooks into the API lifecycle or
the HTTP verbs and things like that, that you would want for an API.

There is a lot of cool stuff you can do with that.

And you can kind of imagine that being in the middle layer for a lot of things.

In fact, actually the, the, our new API is you won't hate site uses
some of this stuff for like our contact form, where we sort of use

that as air to fire things off to places to automate our lives.

On the other end, when we.

But what's interesting to me there is that there's almost no discussion around
how to keep track of those things and how to make sure that you are, you know,

not using, uh, your, uh, delete verb for a post and those kinds of things.

And in those communities in particular, there
is precious little education to begin with.

You know, why you would make these kinds of choices and, and why
it's important to consider like the shape of things coming into

your API or where they're coming from and validating and doing
things like recaptures and honeypots and all those sorts of things.

I bring all this up mostly to say that, like, I think that's an interesting
avenue for maybe me to head down over the coming months in terms of

considering types of things that we can help those sorts of developers.

Because I think it's largely unknown to this, to lots of folks in
this audience, one, the structure of, of these sorts of APIs, even

if it's a very basic crud thing for one use case, like a lot of it
seems to be just like smash this code into place and it'll work.

Trust me.

Like I know because of the axles.

Yeah.

And the other side of it is too, like the, the debug tooling to be able to go
and build these things like using postman, insomnia, all those things to go

and actually fire off the HTTP requests to test just the serverless function.

I never see those talked about when people are
building these serverless things on these frames.

So I think there's very likely a, um, a hole in documentation, a
hole in content produced there a whole and just discussion around

like, here's, what's actually going on behind the scenes here.

Here's how you can think about it.

And here's how you can build and debug it as a developer, building
these things out, whether you're creating a contact form or completing

a purchase, or I don't know, you name it, creating an account for
your, you know, visitors to your app or whatever the case may be.

It's an interesting thing where we have a full stack to our way into
what could be a potentially like security averse kind of mindset.

Yeah.

I I'm I'm, I'm not, uh, I won't say I'm preoccupied about it,
but I'm definitely fascinated by the way, all that stuff is.

Phil Sturgeon: Yeah, that, that sounds really interesting.

I, I keep seeing fantastic things coming along and, and generally
I'm only introduced to new web front end kind of frameworks when you

switch the website to them and you're like this cool new tool came out.

It does this, this and this.

And I'm like, all right.

And you know, you, you like put, uh, moved us from wherever it was.

Uh, yeah.

Yeah.

That was.

Uh, there was middleman for awhile and then Gatsby.

And then, um, we were on, uh, I don't even know, but we switched
to Netlify and then I was like, oh, damn, this is really good.

And then versa last, even better that makes Netlify look like rubbish.

Like there are all these kinds of new changes come
along and make things faster and easier and better.

And so I have been really impressed with a lot of that end.

But like the specific troubles you're
describing, it's just kind of makes me laugh.

I feel like we went from a period where, you
know, service lead pages were very static.

It's like, I'm going to figure out what HTML to spit out and then
you'll do a form and I'll think about it and spouse and HTML.

And that was very static and that.

Kind of web one, right.

Or maybe when you got to forums, it was like kind of getting into web two.

And we're not just talking about three today that can get in the bent.

There was this kind of period in, in kind of web
to where it was like more rich and interactive.

And, and we started to do a lot more Ajax functions.

So you had a site that felt generally quite static being loaded by the server.

And then you had these little random Ajax functions, these
little random end points that would be you just called whatever.

And maybe have like an Ajax controller and group them under that
like set like slash Ajax slash whatever random logic you wanted.

And they were all just like floaty, totally disparate.

No one was really meant to use them, although they totally could.

And it was just kind of a, a kind of a
floating function useful for the front end.

Um, and then we went through this period of.

Glorifying the API for many good reasons, but all of
a sudden it became about like I'm making an API for my

website and this API will be called like API dot, whatever.

And, and it should all be consistent and lovely and, and follow all these rules.

I don't know what rules, what, what, what can we do to make it good Russ dish?

Sure.

Those are the rules that we will follow.

And everyone kind of focused on that.

And the idea of these floaty disparate age
actually functions has just kind of fell away.

Um, but it sounds like we're moving back towards that very quickly without
taking any of the lessons learned from either of those two iterations, because

there are reasons why you do things like use the correct, um, HTP method, right.

Gave a talk ages ago, like the original API
pain points talk I used to do back in the day.

It sounds like a lot of that stuff might be good content for them because
there's things like, um, you know, Uh, some company, I think it was Rackspace.

They had an API that you would delete action was on a get method.

And so Google found the XML, um, the crawler, the XML, uh,
collection, and started calling all these endpoints and just deleting

people's servers, just bang, bang, bang, bang, just deleting them.

Google was just sitting there going right.

It's like Google sitting there going, I wonder what's on this link.

Oh, nothing.

That's weird.

I wonder why.

Oh, nothing.

That's all right.

Right.

So these things matter, the conventions matter.

You don't know why they matter.

So you think they don't matter, but they bloody well do.

And so if we're kind of getting a bunch of people who are
generally not that used to all of the horror stories that I've

been trying to tell for years and other people have been going on.

And they just think, oh, it's just some ivory tower
nonsense and preferences and opinions and whatever.

They're going to build a bunch of shit and repeat all the same mistakes.

Yeah.

Everything

Mike Bifulco: old is indeed new again in this case.

Uh, and it's funny because it's, a lot of these things
are pitched as like, this is just a really fast way.

Like it's fast and you'll get it done and
it's deployed on the edge of the network.

So it's performance and it's like, yeah.

Yeah, cool.

Like that.

That's great.

And all, but if I'm giving you the, uh, the nuclear.

Uh, faster and on the edge of the network.

It's not a good thing for me.

You know, I, I need some degree of certainty
that the things are being built here.

We've done responsibly, or, you know, in ways that, that
won't open up holes in the functionality of the software.

And I think there's very likely.

Quite a few exploits to do with these things.

As people like go and copy paste, uh, unwittingly, some code from a very
popular tutorial that doesn't happen to consider these things or like is

just reusable and all kinds of places, all the things we've seen before.

And definitely like not, not meaning to point to anyone's anything
in particular and say, this is bad, but it's more the, the

rough concept of the thing that, uh, that's the starting point.

Phil Sturgeon: It does just seem like a walk down memory
lane a lot, like copying and pasting random insecure

PHP code you found on a tutorial was how I started.

That's the only way I've ever 20 plus years ago.

That's the first thing I was doing.

Yeah.

And it's not great.

Yeah, right.

And like you copy and paste a class off of, uh, off of a blog and
you'd have to change all of the, um, like all of the quotation

marks accidentally being converted to like, you know, uh, tactics or
smart quotes or Kelly, Kelly quotes, Sage that find them replacing.

And now you type like composer install when you get that package,
check them to make sure it's not being completely screwed.

But yeah, like let's not, let's not do all that again.

It's not go backwards.

Mike Bifulco: Yeah.

Maybe I'll have to sit down and actually put some things
into writing here and we can, we can educate the world.

Phil Sturgeon: The good news is my old content
is now going to stay relevant for longer.

So thank you for that,

Mike Bifulco: for sure.

Yeah.

Right.

All you've got to do is slap a new title on
your old talk and you're back in business, man.

That's great.

Maybe not even a new

Phil Sturgeon: functions, you won't hate exactly.

Exactly.

It's just exactly the same thing.

Mike Bifulco: AWS, you all and hate has a weird
ring to it, but I'm kind of into that too.

All right, man.

We'll look, it's been nice catching up.

We are, I should say I'm getting into the cadence of
doing this thing on a roughly monthly schedule, although

as the stars aligned for the three of us to get on it.

It's monthly ish, but, um, yeah, we'll we'll um, gosh,
I guess I'll catch up with you in a few weeks and we'll,

we'll see where you're, uh, where you're at at that point.

Phil Sturgeon: Yeah.

In a few weeks, I should be nearly done with planting seasons.

Thank God.

So I will be I'm coming at, you live from a beach or something.

I don't know.

I need a break.

Mike Bifulco: There we go.

It sounds lovely.

Well, take care of yourself and

Phil Sturgeon: good to see you.