Sledgehammers on the job site

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.

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.

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

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.

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.

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.

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.

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.

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.

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.

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

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

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.

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

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.

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

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.

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

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.

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

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.

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.