Princess Beef Heavy Industries, Vacuum, Wiretap: API linting & Compliance with Quobix

[00:00:00] Phil Sturgeon: Get my sexy radio voice on. Ah, no, I'm

[00:00:03] Quobix: Radio dj.

[00:00:05] Phil Sturgeon: that was a bad joke and everyone's upset. Hello everybody. Welcome to another episode of APIs. You won't hate the podcast version. And yeah, I'm excited once again. I'm running the show. No, Mike to help me out, so bear with us. I think it's recording. I guess you'll find out. I, today I am joined by David Shanley who you may have heard all over the place.

[00:00:30] He's popping up. I, I was talking to him at API days. In Paris recently and he's made a whole bunch of really cool tools. So David, do you wanna tell everyone a bit about yourself?

[00:00:42] Quobix: Thank you for having me, Phil. Yeah, so my name is Dave Shanley. I go by the name of Quos. You know, but, you know that's just, you know, a stupid internet thing. But anyway Dave, Dave Shanley. I,

[00:00:52] Phil Sturgeon: I, I called you David. Sorry. I, I, I go, I, I'm, I'm posh Now I go too formal. That's upsetting. Just Dave,

[00:00:59] Quobix: [00:01:00] No problem, no problem at all. So I'm the founder of Princess Beef Heavy Industries or PB three, three F. You know, it's, it's, it's, it's shorter to write, but it's just longer to say in all, in all of all forms.

[00:01:12] Phil Sturgeon: What is that? name about? Tell us some more about that before you get back to the intro.

[00:01:16] Quobix: Yeah, so actually I was, I was thinking of, you know, what do I call, what do I call, what would I call myself or would I call my company? And it was actually my 2-year-old daughter, which she was two at the time. And she came up, she used to watch this show. It was blaze in the Monster Machines, which is a show about monster trucks.

[00:01:31] And she said, I wanna watch Princess Beef. I'm like. What Princess? Princess Beef, there's no mentions of princesses or beef or anything like that in the show. She just called it Princess Beef. So then, you know, actually it was a little while longer, she said she was playing the drums, like toy drums and she called them the honey drums and I put the two together and thought Princess Beef and the honey drums.

[00:01:52] Isn't that a great name for a band? If I was younger? You

[00:01:55] know, I thought, I thought, yeah, may maybe, maybe. But then I thought, you know, it's bit too much for [00:02:00] company name, but Princess beef and then. I looked it up and there's already a company called Princess Beef. They're a ranch in Colorado, I think.

[00:02:08] And they, they, they raise cattle.

[00:02:10] So I thought, well, okay, well how do I differentiate it? And I was thinking back to, you know, my, my, my nineties roots and there was a wonderful company called Loft Heavy Industries, or. 10 PHT depends on how you, you would say the acronym. It was a hacker think group hack, hacker tank think tank type thing.

[00:02:27] And I just love that heavy industries element. And there was like a bunch of skater companies that had heavy industries on there, you know, postpay it to the name. I thought, why not? Let's, let's go right back to the nineties and re, you know, relive all of this, this joy. Anyway, so that's the, that's the reason why it's called that.

[00:02:42] No, nothing else other than I just, I love

[00:02:45] Phil Sturgeon: software. I like the approach. I'm, I'm, I'm apparently trying to do like the punk version of the Woodland Trust, so I like the, the punk version of software. Let's, let's do it. Keep it interesting. Alright, brilliant. So I interrupted you, but you were telling us about a bit more about what yourself and what you get up to.[00:03:00]

[00:03:00] Quobix: Yes. So I'm the f founder of Princess Beef. I'm also, you know, that's, that's what I do by, by night. But I also have a full-time job as a distinguished engineer at a company called Splunk. If you haven't heard of it, it's it's like we do. Big data. We collect all the logs, all the information, put it into our big index and allows you to make sense of it.

[00:03:19] And we build premium applications on top of that platform. So yeah, that's what I do during the day

[00:03:23] and

[00:03:24] Phil Sturgeon: have heard of them. The, that's, it's like a pretty big deal, right? It's like a pretty big company or how many? A few are

[00:03:31] Quobix: Yeah, it's, but there's, there's, there's about 8,000 people in the company, maybe 9,000 now. It's pretty large. It's actually just been bought, acquired, well, it hasn't closed yet, but Cisco has just purchased it for 27 billion, which

[00:03:43] Phil Sturgeon: Good lord.

[00:03:44] Quobix: largest. Yeah, it's a larger, large amount of money. So yeah, we'll see what hap what happens with that.

[00:03:48] But

[00:03:48] Phil Sturgeon: much of that do you get?

[00:03:51] Quobix: 0.0001%

[00:03:54] Phil Sturgeon: But yeah, there, there was a number at the end of all those zeroes though. So there is something, there is

[00:03:59] Quobix: [00:04:00] There is some, there is definitely something. But yeah, definitely not what the CEO is gonna be walking away with for sure.

[00:04:05] Phil Sturgeon: now. Fair. Alright, well that's, that's, that's news. It's not, it's not bad news, it's news. Fantastic. And so on the side you are working on a bunch of really cool stuff and so. I, we, we spoke a bit. You've been helping out with open API tools, the website that lists, guess what? A bunch of open API I tools. I dunno why I expanded on that.

[00:04:26] It's in the name. It does what it says on the tin. But we'd been a little bit snowed under and you were helping with some pull requests and I appreciated that. And then, yeah, I got to see you give a talk at API days in Paris. I went over there, was running about. Who needs some work? Do you need some work?

[00:04:41] Can I write for you? Oh God. Work. You know, work, work work is hard when you don't have a regular, regular job. I just have to go and

[00:04:48] Quobix: It is, yeah. You know, trying and lots of talking to people

[00:04:51] Phil Sturgeon: Yeah, it was the first time I've actually had to do networking, right? Like, normally I just turn up at a conference and I'm like, the company I'm working for paid me to be here.

[00:04:58] Here's my talk. I'll be at the [00:05:00] pub from here on out. But this time it was very much like I actually need to go to every booth and shake every hand and talk to everyone and see if anyone has any paid work for me anyway. Seeing your talk was, was a, a nice refreshing break from a lot of, like, AI will save the world and, if you don't need to build an API, you don't need to build an API Ever 'cause you can just get AI to do it. Although you have to write a specific API for the AI to work. Just a lot of very silly talk. Brilliant talk. We won't, we won't get onto that tangent. Good talk from you. You were, it, it was, I really enjoyed the talk considering you spent the a good half of the talk, making fun of spectral a tool that I helped to build.

[00:05:36] So I did what any rational human being would do and we all, we went to the pub and shot the shit and it was great. You built, you built vacuum, which is kind of like a go equivalent of, of spectral. And to save me butcher in the introduction, like, tell me, tell, tell our listeners a little bit more about vacuum.

[00:05:52] Quobix: Yeah, so, so it's, it's it's inspired by spectral it's, it's it's based on the same concept, so it's compatible with [00:06:00] spectral rules and core functions and things like that. So you. In theory, you should be able to take a spectral rule set, plug it into vacuum, and it'll give you the same results.

[00:06:09] There's, there's, there's different logic and it, it's, it's built differently. Completely different. It's different architecture, but the reason why it exists and now understand I was making fun of some of the speed was, was, was because of the, was because of the speed. So I'll take, I take you back to the, the kind of origins of it.

[00:06:25] It was around like 2019 when I was working at a company called VMware. It doesn't exist anymore. It's been bought by Broadcom. But yeah, but the, the, the, the big thing there was, you know, there was a huge, there's thousands and thousands of open API specs, and there was, some were generated, some were handwritten, some were rubbish, some were just, didn't even work.

[00:06:45] But these were all being just. Pushed out as documentation to customers, and they were just rubbish. They were just terrible. They didn't work in co generators. They, the, the documentation was awful. It, it just didn't load. It was, there was no SEO, you couldn't discover it. All, all kinds of [00:07:00] problems anyway.

[00:07:01] So I got tasked with this problems like, can you start figuring this out? Can you start figuring this mess out? And the first thing I did was, okay, let's go and grab some tools from the internet. So I started grabbing documentation tools and linting grab spectral started running it, and it was doing fine for the smaller specs, you know, the smaller SaaS services.

[00:07:20] But when I fed in, there's a product of VMware called vSphere. This thing was built in 2006, and it has. 10,000. 20,000 a Ps, an ungodly amount of APIs, and all these models were object oriented, fed some of those specs in, and they were like 70, 80 megabytes a piece. spect, which did give us a response back.

[00:07:43] It just, it just never came back. It went off, never came back. It was like, okay, what do we do about that? So started, we actually tried to build a tool internally to replicate spectral, and failed absolutely miserably. We failed. Couldn't do it just because spectral was, it's so complicated. Did such a good

[00:07:58] job and it was, [00:08:00] you know,

[00:08:00] Phil Sturgeon: does a lot of different things as well. Like the way, so one thing that people always kind of forget about with linter is like when you've got a code-based linter, you can usually look at that file to find out if that syntax is correct, or you can, you can kind of use reflection APIs in PP to use the PHP term.

[00:08:15] You can look at the reflection. API. To load it up and be like, does the name of this function look right to you? But it, but you, you know what line that that file is on or that function is on and you, and it's, it's a lot easier to, to work with individual files, which is therefore quicker than it, than with open API because you have to.

[00:08:32] Build all of the structure into memory, like you have to follow every single ref of which there might be thousands. And then build kind of like a, an actual map, a fully referenced map of that, which gets quite chunky. And then you have to like find out if something is a problem in every single location.

[00:08:47] What it is used like the. The issue might not be in the file you are looking at, it's when that file is, is reved into a place and now it's a problem. And then, and then a lot of tools have done that. Like Specky, the thing that kind of inspired Spectral did [00:09:00] that, but then it couldn't tell you which file the problem was in.

[00:09:03] So you have to kind of go up and down into these different formats and like map everything to a different place and it's bloody confusing to do so. I can only imagine, like I've, I've played with the Spectral Source code quite a lot. I didn't write it, but I was like the product manager there for a while.

[00:09:16] And yeah, every time I look in there, I just go, Hmm, someone else can work on that. I'm not gonna, I'm not, not gonna even try.

[00:09:24] Quobix: It, you know, the, so and I discovered that when, after, long story short we were trying to run spectral with some of this tooling, couldn't get it to run at the speed that we needed it to. So I said, look, let's, let's rebuild it. And VMware said no. And as I got all these other tools that we built, said, let's open source them.

[00:09:40] And they're like, no, we're not gonna do any of that. So I was like, okay, I want to, I want to give back to the community. I want to work on this stuff. I want to build this link. You won't, you don't wanna do it. I don't have a future here if you don't wanna work on it. So I'm out. So when I, and I basically quit VMware and started building it from scratch, so.

[00:09:56] Th going through that process of day zero, blank [00:10:00] slate. Okay, I'm gonna build my own version. I'm gonna take spectral as a template or as a, as a, as an inspiration. Look at the source code and then reimagine that and go. And I spent two months rewriting that. Reference, look up, trying to figure that out.

[00:10:16] Recursive logic, months, months of scratch scratching my head and I failed multiple times. I couldn't get it to work and I couldn't get it to work fast. So trying to make that work, you know, the work that was done on Spectra was, was phenomenal. It to be months and months just to wrap my head around how to get the logic together.

[00:10:33] Eventually I pulled it, pulled it, pulled it together, but I was having like. Recursive dreams. Like I was waking up, you know, in the same like loop in my head, like trying to program my way through a dream, you know, in this recursive stepping in way. Anyway, it was driving me nuts, but yeah, got there in the end and, and the whole purpose was to, I want to be able to generate a spectral report or a report but I want it to run.

[00:10:56] Fast and I need a, a language that's more suited [00:11:00] to do this type of stuff. You know, ideally it would've been in Rust or done it in c plus plus or something, but you know, I was familiar with Go Loved Go, been using it for years and it's almost as fast, you know, you know,

[00:11:10] it's not as, not as fast, but yeah, almost as fast.

[00:11:14] So it would, it would do the job. Plus there's a, there's a pretty large community for Go, so yeah, it's spent like four months, five months building it, you know, just every day. Chop away. Chop away. Chop away. Threw it away. Start again. Start again. Eventually I got a design that actually worked and worked well and was something I could then add onto to and scale up and open.

[00:11:35] Sourced it and said, you know, what do you think?

[00:11:39] No. First few months there was zero. It was like, no, it was cricket, but yeah. Started to take off.

[00:11:44] Phil Sturgeon: that's wild. I mean, yeah. The, the entire API linting when was vacuum released a year or two ago,

[00:11:51] Quobix: Yeah, it was 2022, like April or May,

[00:11:54] Phil Sturgeon: Yeah, I gotcha. So that's, that's like linting is a thing now by 2022, right? Like that, [00:12:00] that's it still kind of early days, but in it is been the last year or two where it's really taken off all of the tooling vendors.

[00:12:06] Are working on it. They've either, you know, they've either baked, spectral in under the hood like Postman did, or e even SmartBear have kind of replaced their, their own kind of mostly red checks or whatever based linting with spectral under the hood. Now they've acquired stoplight or they're working on their own kind of thing.

[00:12:23] Or like everyone's, everyone's into it now. It's a thing, like it didn't exist as a, as a. It didn't exist more than conceptually in bullshit hacks until, until about then. So yeah. Now, now we're onto the, the good uptake the good part of the hype cycle where it's not just early adopters, it's loads more people and people are looking for different tools and they might not want something that's JavaScript.

[00:12:42] They might not want something that's slow and that, and they might want something, you know, some people want things that are CLI based or like other different types of interface. We've got the rate my open API app. That's turned up that you've been helping out with. So that's by Zulo, but you know, they, they're running on, on vacuum.

[00:12:58] And then there's I did a review of these two [00:13:00] API insights as a

[00:13:01] Quobix: by treble though, right?

[00:13:02] Phil Sturgeon: Trouble. Yeah. And so them on the podcast recently, and I've done a review on APIs, you went hate blog about those two tools, but they're both more visuals instead of CLI based. So we, we've gone from a world where like these tools didn't exist to now where like these tools are aimed at different types of user and different types of use case, which is a brilliant place to be.

[00:13:20] 'cause now we're all sharing ideas and. Powering each other and improving things. And there is a bit of a, in, in my head, coming from like a, a background with standards bodies. I'm like, why are there five different formats? You know, there's like, you thankfully have gone with a spectral compatible thing and maybe that will change in the future.

[00:13:36] But then there's kind of the redoc le into, which is its own more simple DSL. Simpler, but somewhat less powerful. And then potentially, and then there's the open, there's the optic CLI lint GPT, which is like, you can just send it a string of human words. And if you, you know, ask the wizard nicely, it will, it will give you the thing you want.

[00:13:56] And review of that on the blog recently as well. So we're in this amazing [00:14:00] place where there's loads of linting going on and, and. I'm into it. I think vacuum, from what I've seen is, is blooming brilliant and I think your choice of langu in go is, is probably isn't gonna be a limiting factor to the speed.

[00:14:13] Right. I think a, a big benefit that you've got there is the way that it was architected. I think spectral is kind of tipping it hand as being in initially. A utility of stoplight studio where you are editing a bunch of files and whether they're local or on the cloud, it has all the files kind of local.

[00:14:31] Even the, even the cloud version would clone the entire repo into your browser and have all of those files like there. Yeah, clone it somewhere. It'll clone it into local storage. And then you could kind of access it from there. And basically the idea was, you'd kind of you'd run it and it would get an idea of all of your open API and then you'd, you'd edit one model and it would go, alright, let's just update that one model in, in the storage and it would run it from there.

[00:14:54] So it's more meant to lint while you edit, which is quite fast. 'cause it [00:15:00] does the initial upfront load and then it's just like, oh, you change your speech, change your speech, change this bit. But yeah, like when you've got, you know what's the, you, you were using GitHub. The GitHub example, which is Monstrous and Stripe as well.

[00:15:11] They're both huge. And yeah, when you just say, go and figure that whole thing out, it just kind of weeps and just can't handle it. So yeah, it's great to see these different use cases being covered by by different approaches and I can only imagine how hard that was to, to build from scratch. Yeah.

[00:15:26] Quobix: was, it was an adventure. It was, it was, you know, it was definitely putting my imposter syndrome on full tilt, you know, standing and think, why can't I figure this out? You know, why can't I get this algorithm to work? Why is it getting stuck? Why is it spinning out? Why are these threads pauses? Why is this lock?

[00:15:43] I mean, it was just every, every time I tried to do it. So, you know, hats off to the engineers working on spectral because solving that problem, you know, and doing it in a way that works consistently. Very, very, very hard. Very, very hard.

[00:15:57] Phil Sturgeon: Do you have you mentioned there wasn't that much adoption [00:16:00] at first, is have things been picking up? That's where I started to go with my like hype cycle, ramble.

[00:16:05] Quobix: Yeah, there's, so it, it kind of, it, it's, it, it goes through little waves, depends on whether there's a holiday or not. Like a, the traffic to the docks, it's weekends, ghost Town, Monday morning, straight again spikes up. So it's very much following that kind of business you know, peaks and troughs. So, over Christmas it kind of dipped a bit, but then it was, you know, it's up to about, between 11, 12,000 downloads a month via MPM, it's had nearly half a million downloads, so it's.

[00:16:31] Phil Sturgeon: Wow. Yeah, yeah, yeah.

[00:16:33] Quobix: it's moving. It's not where I'd want it to be, obviously, but it's definitely moving, you know,

[00:16:37] Phil Sturgeon: Oh yeah, and I saw that. So it can be installed by NPM as well.

[00:16:40] Quobix: Yes.

[00:16:41] Phil Sturgeon: That, that's, that's pretty interesting. Yeah. 'cause things I, I've never, I've never tried running go in like GitHub actions or whatever. I'm sure it's fine. But whenever you ask people, like most open API tooling is. In JavaScript.

[00:16:53] It seems to be like a really node heavy community and not entirely sure why that is, but it is. And it's, so, it's, it is always good to see [00:17:00] other languages kind of getting involved. But then because so many people are used to NPM, it's good to have that covered as well. 'cause if you are, if you, if you're currently running spectral, you could just run vacuum and, and see if it works

[00:17:10] Quobix: I mean, that's where the majority of the downloads come from is from MPM use. Whenever I speak to people on the forums or they come on the Discord, you know, they're. They're running it or installing it via MPM or Docker, those two, the, the most popular, which is really surprising for me. You know, I, I thought, you know, most people would want to be installing it, you know, as a CLI tool and have it as a binary, just, you know, using Home Brew or via Shell or something.

[00:17:32] But no, it's Docker. Yeah, Docker and MPM most

[00:17:34] popular. It was, yeah, very surprising.

[00:17:38] Phil Sturgeon: Nice. Well yeah, great to give people a bunch of different installation options and where. Where's it at and where's it going? What's the plan for vacuum?

[00:17:46] Quobix: Yes. That's a great question. So the, the, the kind of the purpose of, of what I've been working recently, or up until this point, was to be able to get it to a state where it's consistently operated. The, the bugs that I can fix, I can solve are mostly, mostly [00:18:00] cleared. And to be honest, the majority of them live outside of vacuum is actually in lib open API, which we can talk about a bit.

[00:18:06] And that getting that, that's, that's kind of the beating heart of everything and getting that to a point where. It's working for all the use cases of all the variations from the very, very complicated to the very, very simple. Basically, I wanted it to stop blowing up because I actually run it as a demo in the pipeline and when I first put it up, you know, every day.

[00:18:26] It just panic, panic, panic. And it would reset itself. You know, it's like a tiny little container, but I was just watching this just blow up over and over and over again, and I'd fix those bugs and then I'd wait, wait for it to spin outta control. And that stopped happening now. So now it's, it's not blowing up anymore.

[00:18:42] It's not spinning outta control. It's consistent. The error reports I'm seeing are very, very limited or things I already know about. So that's been the goal is to harden it, get it to the point where it's. I'm happy to say it's gonna run, you know, consistently now, wherever it is, the next piece is to start making it [00:19:00] more usable.

[00:19:00] So for example. Like you, like you were talking about with rule sets and rules and the syntax of the DSL and doing J path queries and figuring out functions and function options, it can get a bit hairy particularly with, you know, you know, some really complicated rules and then you ha adding in custom JavaScript functions, all of that kind of, is it working?

[00:19:20] Can I test it? How do I know it's working? You need some kind of, you know. Tool to be able to test your rule sets, test your rules, test your path, test your functions, test your logic. That doesn't exist right now. So that's the next step is to, to allow you to see your spec, see the linting, so, and label it to work with a language server so we can plug it straight into.

[00:19:42] Vs code and, you know, make a VS code extension and then bring that even further. So you can have a rule set editor and a rule editor and a, you know, try out your JavaScript function, see if it works. You know, does it, what does it pick up? What does this pick up? What happens? What's the outcome? So it's like a, you know, like a sound bit or a sandbox for rules and rule [00:20:00] sets.

[00:20:00] That's where I'm gonna go next with it and improve the, the rendering. Right now there's an H TM L report, which I think is pretty good, but I could do better, do much

[00:20:08] better.

[00:20:09] Phil Sturgeon: Well, it's exciting to hear that 'cause I think the, the dev experience, like anyone. Anyone who's tried writing a bunch of spectral rule sets will know that it can be very hard. I'm currently updating the spectral ow wasp security rule set for security. What the top 10, 20, 23? 'cause the previous report was 2019.

[00:20:26] And yeah, like I'm, I'm doing zany stuff and I, it's hard work and I think. It was always discussed at, sort like a long time ago that the plan was to build some sort of dev experience to help people do that. But it, it didn't get around to materializing 'cause the the effort was put into like making hosted rule sets where you could, instead of editing a YAML file on your computer, you've got a nice gooey for working on them.

[00:20:49] But that gooey was replacing the YAML file. It wasn't replacing the, the, the. The guts or the experience of working out what rules to put in. And so e even like a RegX power.com equivalent of like, [00:21:00] here I am typing in a rule here you can see it's selecting the right bit of open API Now what would you like to do with it?

[00:21:06] Anything along those lines would really help. It's why I build them as NPM test suites because I could just type like NPM test, NPM test, NP test, and PM test and just like. Randomly bullshit my way towards getting to the correct solution. But that, that's the key thing because this is why we've seen people making wizard based approaches or like nicer DSL based approaches because the J path thing is so complicated and, and custom functions can be so difficult.

[00:21:29] But I don't feel like you can just avoid that problem with the DSL. Like with it, there's, there needs to be something in the middle or just a DSL. You can only do what the DSL does. But leaning forward into like, I'm gonna combine JSON path plus RegX based with RegX in it and like have no way of knowing if that's working well or not, apart from like trying it and seeing what happens.

[00:21:52] Neither of those are particularly good experiences.

[00:21:56] Quobix: Yes, exactly, exactly that. It's like you just, you just keep hitting it with a [00:22:00] hammer over and over and over again until you see something. Having some kind of guide, some like feedback. It's, you're doing it wrong, you're doing it wrong. I've tried to capture that with some of the linting rules that.

[00:22:12] One thing you don't get with, I haven't seen anyway, with spectral is like, here's how to fix this problem. It's like, here's your problem, but here's what you go and do to go and remedy it. And here's some docs of a good example and a bad example. So doing that same type of thing, but with, you know, the dev experience, you know your rules wrong.

[00:22:28] This is not finding anything. This is what it's picking up. This is, this is what you think you are getting, this is what you're actually getting, type thing.

[00:22:33] Phil Sturgeon: Yeah, I gotcha. Alright. We could talk about Linton stuff for ages, and that's why I wanted to get this one done first. But you've built loads of other tools as well, and so wiretap is really cool. A a, a mocking server aiming to do some of what Prism was meant to do, but Prism kind of got left behind in prioritization a little bit and hasn't really done many of the things that it wanted to do.

[00:22:55] When it, when it started off? Unfortunately. So tell me a little bit about wire itap [00:23:00] and

[00:23:00] Quobix: Yeah. Great. Thank you. So wiretap, it actually started this, there's this, there's something that's a, like a real u real life use case that I have at Splunk. There's two things. First the way that our, that we build our premium applications as Splunk we were using Webpac dev server for all of our front end stuff.

[00:23:16] So, you know, we, we load up our front end and it'll make all these API calls at the back end. Problem is, is that, you know, when we do. Running this thing for know, a few hours, it would start to choke, right? The, the whole thing would just start, you know, API calls are failing, weird errors are coming back. It was caching some weird stuff.

[00:23:34] It was just, just didn't work. You know? It didn't work at scale. Great for smaller stuff, and when you start using it, let scale didn't work. So we had that problem there. The next problem is. We have all these front ends and backends, and some of them have a open API spec. Some of them don't, and we don't actually know if any of them are compliant with each other.

[00:23:52] We don't have the backends been implemented properly. We don't have the front ends been implemented properly. And we don't, well, obviously the API open API spec is in in [00:24:00] one condition as well. So problem A is we're struggling with how to build our UIs in the front end Problem B is. We we can't tell if our API traffic is compliant, frontend or backend.

[00:24:12] And there's the third problem, which is mocking and frontend. Mocking. Obviously you've been in software development, you know, the front end moves at different speed from the backend. So we get a bunch of requirements from PMs and the backend teams start moving at this, you know, a glacial speed. And the front end team, we're all like mocked up and ready to go with the ux, but there's no backend.

[00:24:30] What do we do? How do we move forward? So with API first, with an API first methodology, working on the contract first, we can then take something like wiretap and, and mock it out so we can have a front end working with the contract whilst the backend does, you know, their implementation. So it solves those, those three problems that we, that we have.

[00:24:48] And, you know, so. The, the way that we use it today is it powers our, our call local dev suite. So all the UI developers, they, when they run NPM start, it actually [00:25:00] spins up wiretap, it's not spinning up webpac. And we can run a, we run web pack as a watcher, so it's recompiling all the JS and the CSS in the background.

[00:25:07] So it spins that up and then we start capturing all the, all the API traffic. So the other thing that it does was its primary goal. The, the, that's what I wanted to build it for. But I also saw these other use cases as well. Primary goals was mocking and API open API validation. So whilst it's serving all the static content, any APIs, it can, you read them in and you can configure them with, you know allow lists and denial lists and things like that.

[00:25:31] You can do path rewriting. A lot of the stuff that you get from like, like Webpac dev server, it's actually a drop in replacement for a lot of those features like, you know, variables and authentication tokens and all that kind of stuff. Anyway, it act as a proxy, a, a, a complete transparent proxy for all of your APIs and remap 'em if they need to, but it captures all the API traffic and allows you to, you know, validate the, the requests and responses and sch.

[00:25:57] Effectively looks at the whole open API contract in [00:26:00] detail, and then shows you which of your requests are invalid. You know, how, how compliant are you? And then you can see where those, those, those violations are. And it gives you numbers to straight to the spec. That's something that's missing from a number of tools, is the ability to get to.

[00:26:16] Here's your problem. Here's why it's wrong here it is in the spec. Here's where it is in those line numbers and in go that functionality was missing from, from, you know, another of other libraries that are out there. So

[00:26:28] Phil Sturgeon: gotcha. That's pretty handy. 'cause the, that, that's always been, that's been the goal of so many tools that. Kind of the contract validation stuff I think is really important. So when we talk about validation, there's two types. And so vacuum tools like that, the linters, they are schema validators, like is my schema correct?

[00:26:45] To whatever roles I may have defined to the spec and to my preferences. But then there's the, I call it data validator which I've never said out loud and is annoying. I need a different term now. But data validation doesn't sound so bad. But yeah, the goal of that is like, and is the [00:27:00] data, is this, is this instance of Jason or whatever valid to what the schema said it should be.

[00:27:06] And, and that's pretty bloody key when people are. If you're doing the a PA design first, then you can, your, whatever, your teams in general will agree on a contract, and then everyone has to build to that contract. And, and your front end teams wanna build to it, and your backend teams wanna build to it.

[00:27:21] And if the, if the clients are sending things that don't conform to the rules. Someone should tell them. And if the backend team is also like emitting stuff that isn't right, someone should tell them too. And I think we kind of aim to do that with Prism. With you, you, you can build a mock server, so if the backend doesn't exist, you've got the mock server and you can just talk to the mock and it all let you know if you're doing it wrong.

[00:27:42] And then once you've actually got the once you've actually got the API, you switch that mock to a proxy and it will still put the same traffic through pretty invisible. Just there's a bit more business logic happening. Tax rules might actually be applied instead of just static examples coming back.

[00:27:54] That was kinda the plan for Prism. Sounds like y'all do the same thing too, but what I really liked about it was you, you've got a [00:28:00] built in, like a Go terminal, like a ui thing. So you can actually see the requests that have gone through, see which one's passed, see which one, which one's failed. And if you wanted that with, with Prism, you didn't really get it like.

[00:28:10] You could sniff on some headers. I think we had like a Xen something or other responses validation errors kind of Jason that you then have to like unfurl somehow. But yeah, having it in that terminal built in, otherwise you've gotta go and have another proxy installed. Like go and set up Charles proxy or go and

[00:28:26] Quobix: Right, right. Yeah.

[00:28:28] Phil Sturgeon: Some sort of sniffing thing, which is a bit of a pain in the backside. So yeah, having that all in one place is, is pretty handy. And especially if that's one command that your front end people can write. Maybe the front end people are, aren't, aren't the ones that wanna set up Charles' proxy. So yeah, that's, that's really handy.

[00:28:44] Quobix: Yeah, so it, it was, it was that, it's the same thing with vacuum. Like there's a console, CLI, there's a sort, the terminal CLI, there's A-H-T-M-L report. So with Wire it's got the same thing that, you know, you can run it, run it as a service. It runs, it actually powers some other stuff as well. But it runs as service or it runs as [00:29:00] a, you know, as a, as a, a local, local ui, local GUI to be able to, to, to view it.

[00:29:06] And

[00:29:07] part of the, you know, the, the,

[00:29:09] Phil Sturgeon: Sorry. I was just gonna say it, it, it can be a fia when I, I've said in the past some teams, some front end teams, like I, I don't, front end teams are perfectly smart and the front end stack is a lot more complicated than the backend in so many ways. But yes, when you give 'em a new tool, if I've tried to say like, oh yeah, just install like Prism and point it at this open API file and then like pass these options or whatever, and they're like, I don't really want to do that.

[00:29:32] 'cause then they've got, you know, trying to get the. The proxy information out's a bit of a faf, but when I, if you can host it, then you can just like change an environment variable and say like, just point your front end at this instead of pointing it at that, or it's completely seamless to them. Like just point it at the API and you don't even need to know that it's running the proxy right now.

[00:29:49] We've just squished that into place. That, that makes it a lot more useful for those teams that don't wanna figure out a new tool right now.

[00:29:55] Quobix: That's, it was exactly that use case is how, how, how do I make this completely [00:30:00] transparently replace the thing that's giving us our dev experience right now and serving all the content and making all the API calls and proxying them to our staging servers. How do I replace that with, you know, so it's completely transparent so that even the MPM commands are the same in the script, is just, it's, you know, they don't have to think about it.

[00:30:18] That's what obviously makes the adoption so much easier because, you know, it's just. Just all of a, all of a sudden one day, it's just, it's not breaking anymore.

[00:30:26] Phil Sturgeon: Yeah. Brilliant. Alright again, loads of other stuff I could talk to you about this, about. This is mostly just a chance for. For me to nerd out with someone who's working on the exact same problems that I spent years working on. So hopefully, hopefully some other listeners like this, but it's fun for me at least.

[00:30:41] Anyway, the next one, otherwise a massive waste of time. Hello. Is this thing on the, another thing you've been working on, which I always wanted to get involved with, but never had the chance is kind of changes and change detection. So this is a new, a new area that's kind of popping up for people is we've now, we've now [00:31:00] spent enough time with the API design, first lifecycle, or whatever is going on.

[00:31:04] Enough people are making open API and describing their APIs well. They've learned how to, you know, describe it well with, with good standards. And they've learned how to make sure it's true by using contract testing in their test suite or prison contract testing style proxies. That stuff's done great.

[00:31:23] Now it's in production and people are making changes and shit's breaking 'cause people love making breaking changes and. There's an increasing number of tools that are coming out to, I, I haven't looked at how open API changes actually works, but I, there's optic Diff and Bump have got like breaking change detection on their, on their documentation deployment, which I'm, I've been doing some writing for them recently and it's quite a cool, and where you just kind like deploy your docs, keep on deploying your docs, put it in the.

[00:31:51] Put it in the pull request and just keep on deploying your docs when they go to master. And then on your pull requests it can go, whoa, there, there's a break and change in here. Is that something that you wanted to do? [00:32:00] Or like, this has been removed, that's been added. And it's really nice to see more people getting into that.

[00:32:04] 'cause that's one of the hardest problems in APIs is if y'all break, if you, if you change stuff, things are gonna break for your consumers. So how have you gone about stepping into the world of, of API changes and what problems are you trying to solve? I.

[00:32:17] Quobix: Yeah, it's a great question. So the, it's, it's exactly that is how do we know, and this is another thing, there's another problem that, again, it's with my day job. I've always wanted to build this, I've actually built it before with VMware, but this is a very real problem, is devs aren't, because there's no testing, there's no compliance validation, there's no quality assurance on, on his open API contracts, they're making changes or they changed automatically through code changes if it's code first and it gets deployed.

[00:32:42] There's no testing and a customer gets broken. It's like, well, well we, we read the contract and it's not working, and we're breaking each other, like we're breaking product A to product B. The integration points between them, because the teams just aren't. They don't know, they, they're not following the, the dots aren't connected.[00:33:00]

[00:33:00] So first, you know, you, the, the change detection only works if you are using the open a PA contract as that source of truth. And when you are, you know, you want to know exactly what has changed. So there's, there's a, there's other tools out there, like like it's great tools like OASD that does, you know, same thing, you put rules in there.

[00:33:16] The, the thing that I noticed though with a lot of these diff tools is. I, I, I'm, I'm getting like a, like you would get with vacuum, you get a straight. A hot list of all of the violations that have occurred. And it's, it's when there's, there's a lot of them, it's a okay, where in the model has that changed?

[00:33:33] Because that property, that name ID, is used 10,000 times and I dunno, which, I dunno where it is. And if I can't see it, I don't have a visual representation of it. I'm struggling to get the gestalt of what's actually changed. So that was the approach that I took with Open API changes is it's actually more of a visual rendering.

[00:33:51] So it does. Two things. It the way, the way it works, it, it reads in the model. From both A and B, then it does actually [00:34:00] every single object as a hash check against this. So it takes the object, hashes it in to says, has it changed? And if it has changed, it looks at every single property, what was added, what was removed, and decide if it was, you know, is there a braking change if you added like a, a non-optional parameter, things like that.

[00:34:14] And then what it will do is render out those changes as part of the. The model of the open API document. So you can see the past, you can see the parameters were added. You can see where in the structure it was changed and then you can flip it. Instead of just looking at a tree, you can look at a graph like it actually renders out a visual graph.

[00:34:33] I was really inspired by a tool called jason crack.com and it's allows you to feed in adjacent file and it will visualize it. It broken apart and you can see it. I was like, that's very, very good. That's very useful. I would like to see that, but with something that's not just adjacent file, you know, a, a, a data structure.

[00:34:52] So I took that same idea. I used all the same light. In fact, I built this all in React just so I could make it work with the tool that they, because I loved it. And yeah, [00:35:00] we recreated that same experience, but now instead of rendering out just the J file, it's rendering out the change tree. So you can see the open API document as a visual graph and explore it that way, and you can rotate it, you know, and we'll get all different layouts and stuff like that.

[00:35:14] But, so it's a visual way to explore and also it then it gives you the ability to go back in time. So you can not only see, you know, the change from where you are today, but you can see where it was previous before that. And then it gives you some graphs and charts of how it has changed over time. So it's, it's like a local tool right now that will give you that, whether, whether you've got a local Git repository, it will look through all of your revisions.

[00:35:37] It will just do a left or a right, or it can pull straight from GitHub and pull down all the, the revisions for that. You just literally pointed at the, the open file and pull down all the, all the, the commits that you've had, and then do diffs for every single one up to a limit. You can, you can limit it to five or 10 or whatever, but it was a different experience that I was missing.

[00:35:58] I want to see what's changed [00:36:00] over time and I want to visualize it. I don't just want a, a straight list of violations here in like, like a. You know, like vacuum or spectral, when is something more visual? So that's, that's the difference of how it works. It's gets custom built. It doesn't use any other existing libraries other than the open API.

[00:36:18] And it walks the model as a hierarchy. So it gives you a hierarchical rendering com complete with, you know, line numbers and columns, which is also missing from a number of other tools that don't give you the line numbers and columns. They just tell you the path to where it changed.

[00:36:30] Phil Sturgeon: Absolutely. Well, yeah, that's, that's back to what I said about some of the pres spectral stuff in it where yeah, people are like, I, I read all of your files into this massive array. Now go figure out where in this massive array array it went wrong. You're like, that's not helpful. I need to fix this. So yeah, I think some of those tools were kind of designed by either.

[00:36:51] Very small teams that didn't have a chance to like really get into it, or were kind of designed by people that aren't as in the trenches doing open API stuff all the [00:37:00] time. So therefore, didn't really realize the importance. Like, Hey, our product manager's happy, but the people that actually need this to solve actual problems aren't, aren't so impressed.

[00:37:08] So that's, that's pretty handy. I do wonder with some of this stuff, with like the breaking changes in open API, like, I feel there's, there's a little part of my brain that's like, did we create a problem for ourselves? Where originally a lot of the tools that I didn't like so much would keep open API completely separate from the source code.

[00:37:27] And, you know, maybe some, if you're doing code first and then you just render it, render out some open API and it somewhere that's, whatever, that's a bit different. But as, as well, a lot of people will export the open API from their code and then it goes into the repo. And if you're designed first, it lives in the repo and then you actually use it as the source of truth, maybe for testing, maybe to power some of the code.

[00:37:46] So either way you go more often, open API lives in the repo so that you know when you make a pull request, any changes that happen will happen to your open API and therefore your docs and your hosted marks and everything else all at [00:38:00] once, all along with the code. So it's a bit more atomic. A way that things worked before that was, yeah, you, you've got your code over here and you've got your contract testing suite over there and that meant that if you made a breaking change, then it would probably notice, like the completely separate contract test suite would, would kind of notice 'cause you hadn't updated that.

[00:38:18] And it was always really annoying if you, if you make an intentional change. Then it breaks your contract test suite and you have to go and change that. So that always kind of annoyed me, but it, it does at least kind of then give you some protection against that happening. But as soon as we've moved it all into the repo, you can easily just like delete something and it breaks for everyone.

[00:38:38] And it goes, yes, I've contract tested with myself, and I've agreed that I'm correct. So even though I'm not what the clients want and that, and that's where tools like Pact come in, right? 'cause then the, the, the consumer has to set up their own contract testing, which isn't, you know, the, the producer is, hi, my API does what I think it should.

[00:38:55] And then consumer testing is like, does your API do what I think it should. And I, [00:39:00] you know, the consumers can test for the bits they're interested in. But if, if you have change detection running then you can, I dunno if open a PA changes does this, some of the diff tools do where your consumers can actually subscribe to changes and get like an email when changes come out.

[00:39:16] And I don't

[00:39:16] Quobix: that's a good idea. I'll run that one down.

[00:39:18] Phil Sturgeon: automate something that, something the bump does. And I really like that 'cause it, it, it solves both. I've not needed to make this really annoying. Blocker where, you know, your contract testing is totally separate from your code and you constantly have to go and change it in two different places, but you haven't also forced all of the work onto your consumers to find out whether you've broken shit recently or not.

[00:39:38] They can find out what's changed. They can find out if they care about it. And, and that's a, a powerful thing for change detection, I think. But yeah, that

[00:39:45] Quobix: Yeah, it is. it it it it very powerful and it's a, it is a big problem, right? Big problem is like, how do, how do, how, how do we, you know, find the balance there. I like that idea of, you know, like a Slack or a message email or something. It don't do any of that stuff because it's, [00:40:00] it's just like a local tool.

[00:40:01] It has no kind of network connect. I mean, it, it, it does some stuff, but yeah, there's no like put your emails, no subscriptions yet.

[00:40:08] Phil Sturgeon: No, that's cool. Well, we've got more to talk about here 'cause you've got, you've been busy, you've been really busy. We have been talking about three open source tools that you've worked on, and they are powered by lib open API Now do you just enjoy writing code or why, why does that exist?

[00:40:23] Quobix: So, yeah, so it, again, it started with this, all the tools that I've seen out there, they're missing some of these key pieces that I need to be able to build the tools that I want to build. So I'm still trying to build the tool that I want to build and all the bits that I need to build it haven't, they didn't exist or they didn't exist in the way that I needed them to.

[00:40:40] And I started with vacuum and lib open API was born inside vacuum. And it was, how do I, how do I pass this open API filing go. So there's already a great library out there, like kin open API. And that was my, just, so why would I reinvent this? Why would I redo this work? And I went to the plug it in.

[00:40:59] But there's, [00:41:00] there's, there's a problem. There's two problems actually. The first problem is it's a fundamental design problem. The way that it, when it passes in the model, it loses all the context of line numbers and columns, which is critical in my opinion, for being able to do change detection and show you where things have changed.

[00:41:18] And then with the, you know, being able to build, same thing for linting. I need to know where it is to be able to say, here's the problem. And it doesn't have that, and it won't be able to have that because of the, the way the architects put together. So the only way to do it was to literally rebuild it from scratch as a, like a compiler passing the abac.

[00:41:34] Abstract syntax tree, which is, you know, the raw YAML effectively, or the raw Jason, and then put that into a model that captures all of that low level information. And there's things like anchors and aliases and comments in YAML that all get lost. And you need to know about all of the sources of that and where it was come from, particularly doing like references.

[00:41:55] Anyway that's why it exists because. F first of all, there was no lineups and columns. The [00:42:00] second thing is that KIN doesn't support 3.1 yet, and

[00:42:03] that

[00:42:04] Phil Sturgeon: Does it spot 3.0 even?

[00:42:06] Quobix: it does, yeah, it does support 3.0. But simply because of it's got its own Jason Schema model. The problem is, is we have exclusive minimum, exclusive maximum, you know, went from Boolean to and things like that.

[00:42:17] Phil Sturgeon: All the nut

[00:42:18] Quobix: Unless you've got like, like ability to do dynamic objects, which is what we have in lib open API, you're kind of stuck and you've gotta rebuild the whole thing again. And that's kind of where the project is. It's you've gotta rebuild the model to be able to make this work, which is just, it's just too much for some maintainers.

[00:42:35] So that's why I, I built it 'cause what I needed didn't exist and we, I wasn't gonna be able to get to 3.1 support. And, you know, it's a useful tool by itself. So live it just inside vacuum. When people don't wanna do linting, they just wanna be able to pass the model or do d diff checking programmatically.

[00:42:52] So that's, that's why I built it and that's why I exist. And yes, to answer your first question, I love coding. Love coding

[00:42:57] Phil Sturgeon: Just like you really enjoy writing the really [00:43:00] just like difficult under the hood, low level, just like writing some code that in, in like inspects YAML anchors, like most people don't even like working with YAML anchors, but you're like, let me write some code that muck about with this, or

[00:43:14] Quobix: yeah, yeah. yeah. Part, you know, part of the challenge is can, can I even do this? Do I, am I good enough to do that? And you know, the, then there's the, there's something, there's something really rewarding about, you know, when you're working in these high level experiences and you are, know, rendering, you know, graphs and charts to be able to trace.

[00:43:33] All the way down to the, the code that literally read those bites in from the spec and know that tree is something very rewarding about that to me. You know, have

[00:43:41] that, that over at that full, that full view. But anyway, yeah, that's that's a lib open. API. It's the heart of all the tools. It's, you know, it's the ultimate in dog food, if you will.

[00:43:51] Every single piece relies on this. So when all these things break in these higher levels, it always usually traces back to a problem in live open a [00:44:00] p.

[00:44:00] Phil Sturgeon: Yeah,

[00:44:02] Quobix: It's pretty robust. There's no real open bug reports. Clinger, there's a few, but maybe it depends on who you look at

[00:44:08] Phil Sturgeon: there's, there's, there's always some things.

[00:44:10] Quobix: there's always some stuff in, there's, there's, there's a few things in there, but it's, it's actually the point where, you know, if I wanted to, it would be able to cut a 1.0 release, which is kind of very rare, but Yeah. it's,

[00:44:22] Phil Sturgeon: Well, that's, that's brilliant. And so you, you're doing this, you're doing this all as a side project and one of the questions someone was asking APIs was like, how sustainable is this? Like, is this just a hobby that you'll get bored of? And so that brings us to the next topic, which is.

[00:44:37] You're building like a SaaS and a suite to tie this all together. How? How does that work?

[00:44:42] Quobix: So like that. So all of the individual tools, you know, they're useful in their own purposes, but they're all designed as, they're, they're tools that you download them, you own them, you run them, you modify them. They're, they're yours forever. But then there's the idea of, well, well, all these individual pieces are valuable, but what if it was all.

[00:44:58] Put together, you know, the, the idea of [00:45:00] a suite, that that's, they're all in. They're actually designed to work together. They're all put, built in a way that they'll click together. So it's being able to do quality analysis and have the ability to edit rule sets and, you know, and then be able to visualize your contracts and see your schemas visually.

[00:45:15] It's another thing that we've kind of lacking on. You know, there's, there's tools out there that will visualize. To a certain degree. But for example, if I'm designing a whole bunch of schemas in an open API, how can I take a look at the, the class hierarchy? Hierarchy, sorry. In, you know, in some form of UML, you know, maybe not ml, I dunno.

[00:45:33] But you get to the point is how do I visualize it? How do I do change detection? How do I do mocking and testing? How do I do compliance? How do I do validation? Having that as part of. One tool that, you know, works as a desktop app, but also is available as a SaaS platform. So know, so it's got its own full API and then it means it can be introduced into things like GitHub actions and all of those functionalities that you use as the individual tools [00:46:00] now become available as a service or as a suite that you can, you can download and then moving that forward and offering, you know, really what I wanna focus on is.

[00:46:09] The upstream elements of all of open APIs focusing on the contracts, not necessarily the artifacts that are generated from the contracts like SDKs and, you know, docs to some degree, but it's really about maintaining, you know giving you visibility into the contract. A lot of it is inspired by a lot of the work that's stoplight has done, you know

[00:46:29] Phil Sturgeon: Cool. I mean, yeah, there's, there's a lot of different verticals, right? So there, we talk to a lot of all vendors on this podcast and I'm usually asking 'em which bits they're going for, 'cause. Jason Harmon from Stoplight did a brilliant piece about how you can't do every vertical well, and anyone who tries is delusional or lying.

[00:46:45] And not, not those exact words, but something along those lines. And it, it definitely, it definitely checks out. Like there's a lot of companies that kind of do a certain vertical as a checkbox activity and, and it's just sad for everyone. But yeah, it seems like, so focusing on. Kind of linting [00:47:00] and mocking and, and validation and that, that's, that's already quite and change detection.

[00:47:06] That's already quite, quite a blooming lot, but it's, it's all areas that aren't massively well served currently. I mean yeah, there's a lot of tools that kind of go for it, but they've all got primary focuses elsewhere. So e even if you kind of do put in some, some docs, I mean, you know. Not, that's not the hardest one.

[00:47:25] Once you've got some open API, you can render it with a pretty interface. So like everyone does docs and something else. But yeah, that's, it's an interesting series of verticals to go for and it's good that there's a plan to get some money involved to help you work on that. 'cause it's not, I.

[00:47:38] Something you can do Well if it's purely evenings and weekends, not, not

[00:47:42] Quobix: Yeah.

[00:47:43] Phil Sturgeon: not in that sweet sense. Like you can make the tools and give them out to people, but glue in it all together. I, I compare it to like, you know, I want, I want to set a cutlery and and, and I've just got a knife and I'm like, all right, well let me just whittle for the next two days and I'll have that.

[00:47:57] But like, not everyone wants to do that. They don't want to go, all right, let [00:48:00] me plug this into this part of the ci and then that can do these other 12 steps, you know, glue it together for me please.

[00:48:06] Quobix: Yes, yes. It's the glue. Yeah. Gl I'll, I'll, here's a service that sticks it all together for you and gives you, you know, a lovely set of interfaces, easy APIs to integrate with. So you're right. Yeah. It, it, it can't be something that just stays as evenings and weekends. That's my long term goal is to turn it into, you know, a business that I can work on, you know, full time. That's, that's where, that's where I want to be. And, you know, it depends on the, the reason why I'm doing this right now is validation. Is it, would people even pay, would they be interested in, you know, there's users of open API, there's all these companies that are using it, but are they gonna.

[00:48:41] Four Cal. And I know that model exists because, you know, the, through the success of companies like Bump or optic or Speakeasy or you know stop Lying, being acquired, definitely a, a market for it. I just wanted to see, first of all, would people be interested in using my tools first? That seems to be, you know, [00:49:00] validated to a degree.

[00:49:01] Now it's, let's, let's make it better.

[00:49:04] Phil Sturgeon: it's

[00:49:04] Quobix: the gas.

[00:49:05] Phil Sturgeon: exactly, I mean that's, I think, I think something you mentioned when I saw you talk was like. If people, if people start paying and you can afford to bring somebody on, then that's, that's something that you know, you'd like to do and start to expand it. And that, that I think is really interesting.

[00:49:18] Like my, my background when I'm not messing with startups it is mostly bootstrapped, right? Like I, yeah, I, I work for WeWork, definitely not a startup. They like to pretend they are and they have the ping pong tables, but obviously a massive corporation. But before that, loads of loads of bootstrap companies and, and small startups and stuff.

[00:49:33] And yeah, it's. It's really cool to see you go in the bootstrapped approach and, and look into grow, but also starting off still with so much open source. Because the balance for most of these tooling companies is if you make everything so that people have to pay you a thousand pounds a month just to start using it, you have a really hard time getting people to start using it.

[00:49:55] 'cause it's, it's 100% like enterprise sales, team driven and you've [00:50:00] gotta get those big enterprise contracts and you've gotta have a lot of functionality. So it's a massive chicken and egg. But then if you have open source, you get a lot of developers using it and some of them might start paying for it.

[00:50:09] So stoplight's approach was, we've got, you know I can't really put numbers on it, I I, but it felt like kind of 20, 25% of our effort would be like entirely open source. Like, you know, issues that only really affect the open source projects or are primarily asked for by open source. And so you're kinda like making that stuff out there in the open that people can use, but then it's also powering your paid products.

[00:50:30] And not only does that mean that. You know, some people might be contributing bugs that then improve the experience for your paid users, which is cool. But you are also like getting people hooked on the free stuff and then not, you know, then you glue it together for them and that that brings them in.

[00:50:46] So it is really interesting to see a one man army kind of just go, well, I'll just start off with open source and bloody everything and figure it out later. Like, I really kind of just like the, it's, it's bold. It's a bold choice. But it seems to be working.

[00:50:59] Quobix: [00:51:00] I appreciate that. Yeah, it's, yeah, it's, it's, it's, it's going in the right direction. That, that's for sure. For now, you know, anything, can anything come along and derail anything But it, the, the hunger's there, the, the audience is there. The interest in Open API is growing. It seems there's a friend of mine who, he mentioned, he calls it like an evergreen, it's an evergreen

[00:51:19] field. You know, in 2016, I remember, you know, there was, we were coming off the Ramel versus swagger wars. And you know, the conversation was like, what, we need to invest in this, this is important. We should care about this. So even then, you know, the same conversations are happening.

[00:51:36] We really haven't made huge amounts of progress towards actually getting this sold, you know, at at, at the company level. There's lots of individual companies doing this really well, but large enterprises are still mostly absolutely terrible at this. So it's, there's this field where there is evergreen.

[00:51:51] There's always a need to improve here, and my opinion is the open API is like it. It is the key to rest, [00:52:00] like is if, just, just to say that we, if we're gonna do rest, there's open API Sure there's other DSLs out there in other languages, but it's, it's the one that everyone, every company has settled on.

[00:52:09] I, I don't see anyone talking about any of the

[00:52:11] Phil Sturgeon: exactly. Doesn't need to like. We don't necessarily need to think it's the best. It's the one that stuck

[00:52:17] Quobix: Yeah. It's VHS, right? It

[00:52:18] Phil Sturgeon: Yeah.

[00:52:19] Quobix: tape. It's, it just, we,

[00:52:20] Phil Sturgeon: Laser discs were cool. You could use them as giant dangerous Frisbees as well. Yeah, I mean the last the last I think two podcasts we've done, we, we had Daryl Miller and Vincent whose surname I forgot.

[00:52:32] I'm sorry. I, I, I got really cocky that I knew everyone's names and then, and then went for it. But but Lorna Mitchell as well. And we were talking about moonwalk a little bit, like yeah, there's, there's a V four open, API coming. And I do want to dig in more to see how that is looking. 'cause I'm, you know, that's gonna be a big change for a lot of tooling developers and it's, it's rough to see like this massive.

[00:52:52] Massive improvement in tools happening recently. Like I set up open APA duct tools because everything, everything was kind of [00:53:00] shy, like a lot of the open source space was. We, we were all like, they were all really small tools and everything was like you know, little, little dodgy projects with like three stars.

[00:53:09] And it was all, we'd all, we were all really just a young ecosystem and everything was coming off of like swagger two and getting ditched and starting over and in open API three 'cause it was so different. And, and it just felt like at that time, so much of the cool flashy works really well, looks really nice, has good marketing, is really battle tested.

[00:53:28] So much of the good stuff. All of that effort was just going into different communities. It was all going into GraphQL and they were making cool stuff and they were like, screw, screw, rest. The shiny stuff's over here. I was like, you could make, you could do all of that over here. You've just chosen to do it over there.

[00:53:41] And now we're kind of stuck with nothing. But over the last couple of years, like the, the tooling has, has grown up so much that I like. I have absolutely no envy for those folks over there. And people are starting to come back and, you know, the hype cycle on GraphQL is calming down. And, and, and the ma the tooling here is maturing to a really good spot.

[00:53:57] So I love to see the competition in, [00:54:00] in the different spaces and verticals happening to push everyone forwards. And the focus on, on just like good looking websites and good looking tools and good looking simple things that plug and play together. So, yeah, I'm really excited to, to see where it goes.

[00:54:12] And I just, I hope that the open a PV four isn't a, a big drop kick between the legs of the progress that we've, we've all been making on that front. So remains, remains to be seen.

[00:54:24] Quobix: It's quite as, it's quite as significant. W So the moonwalks, from what I've seen from the early earliest specifications, it's, it is gonna, it will be a nuclear bomb being dropped on, on the deaf community, particularly with the existing tools. It's, there's lots of Jason Schema support, which is great. Yeah.

[00:54:41] But yeah. It will take some time. I don't, I don't even know how close we are to, you know, full adoption of 3.1, yet there's still, you know, a huge amount of 3.0 spec still being created today. But anyway, yeah, it's fun to see where it goes and I'm glad that it's moving. You know, it's, it's the fact that we've got the workflow [00:55:00] specification that's almost there, that's, that's really big overlays as well is an interesting thing that's

[00:55:05] not quite there yet.

[00:55:07] But like companies like speakeasy, they've already gone ahead and, you know. Adopted some of the, like lib open API, they've already built their own kind of extensions for it to support overlay. I think so anyway, I, I'm guessing they support overlays and they use lib open api, so I'm guessing they've done that, but

[00:55:20] Phil Sturgeon: Perfect. Yes. No. I was playing around with the speakeasy. Implementation is pretty, it's pretty good. Yeah, so there's loads of cool stuff coming in open API four and the kind of open API connected ecosystem with these working groups, and we've talked about that in previous episodes. I'll have to talk about that more in future ones 'cause.

[00:55:36] This is getting close to being. Well, this is, we did it. It's a podcast. Thank you so much for coming and talking about all this stuff. We, we could have gone for like two hours, but we'll, we'll, we'll make life easier for the editor and, and, and get outta here, but

[00:55:49] Quobix: Thank you so much.

[00:55:51] Phil Sturgeon: pleasure having you. Cheers.

[00:55:53] Quobix: it. Cheers to the chat. Bye.