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.
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.