Subscribe
Share
Share
Embed
- Quobix - Dave Shanley's site. Code is art
- daveshanley/vacuum on GitHub - the world's fastest OpenAPI 3, OpenAPI 2 / Swagger linter
- wework/speccy on GitHub - Well Spectually 🤓 Enforce quality rules on your OpenAPI 3.0.x specifications.
- Wire⚡️Tap - is the world’s coolest OpenAPI compliance and testing tool, from Quobix
- Battle of the API Ratings from APIs You Won't Hate - Dive into a detailed comparison of Trebble's API Insights and Zuplo's Rate my API, exploring their unique approaches to evaluating API design, performance, and security
- Openapi.tools - an Open Source and community-driven list of high-quality, modern tools for OpenAPI from APIs You Won't Hate.
Creators and Guests
What is APIs You Won't Hate?
A no-nonsense (well, some-nonsense) podcast about API design & development, new features in the world of HTTP, service-orientated architecture, microservices, and probably bikes.
Track 1: Get my sexy radio voice on.
Ah, no, I'm
Quobix: Radio dj.
Track 1: 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.
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?
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,
Track 1: 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,
Quobix: 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.
Track 1: What is that?
name about?
Tell us some more about that
before you get back to the intro.
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.
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.
Isn't that a great name for a band?
If I was younger?
You
know, I thought, I thought,
yeah, may maybe, maybe.
But then I thought, you know,
it's bit too much for 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.
And they, they, they raise cattle.
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.
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.
No, nothing else other than I just, I love
Track 1: 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.
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.
And we build premium applications
on top of that platform.
So yeah, that's what I do during the day
and
Track 1: 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
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
Track 1: Good lord.
Quobix: largest.
Yeah, it's a larger,
large amount of money.
So yeah, we'll see what
hap what happens with that.
But
Track 1: much of that do you get?
Quobix: 0.0001%
Track 1: But yeah, there,
there was a number at the end
of all those zeroes though.
So there is something, there is
Quobix: There is some, there
is definitely something.
But yeah, definitely not what the CEO
is gonna be walking away with for sure.
Track 1: 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.
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?
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
Quobix: It is, yeah.
You know, trying and
lots of talking to people
Track 1: 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.
Here's my talk.
I'll be at the 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.
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.
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 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.
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.
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.
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 problems anyway.
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.
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.
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
job and it was, you know,
Track 1: 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.
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.
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.
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 that,
but then it couldn't tell you
which file the problem was in.
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.
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.
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.
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.
Th going through that process
of day zero, blank 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.
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.
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.
Fast and I need a, a language that's
more suited 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,
it's not as, not as fast,
but yeah, almost as fast.
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.
Sourced it and said, you
know, what do you think?
No.
First few months there was zero.
It was like, no, it was cricket, but yeah.
Started to take off.
Track 1: that's wild.
I mean, yeah.
The, the entire API linting when was
vacuum released a year or two ago,
Quobix: Yeah, it was
2022, like April or May,
Track 1: Yeah, I gotcha.
So that's, that's like linting
is a thing now by 2022, right?
Like that, 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.
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.
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.
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.
And then there's I did a review
of these two API insights as a
Quobix: by treble though, right?
Track 1: 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.
'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.
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.
And review of that on the
blog recently as well.
So we're in this amazing
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.
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.
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.
So it's more meant to lint while
you edit, which is quite fast.
'cause it 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.
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.
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?
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.
Track 1: Do you have you mentioned
there wasn't that much adoption at
first, is have things been picking up?
That's where I started to go
with my like hype cycle, ramble.
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.
Track 1: Wow.
Yeah, yeah, yeah.
Quobix: it's moving.
It's not where I'd want it
to be, obviously, but it's
definitely moving, you know,
Track 1: Oh yeah, and I saw that.
So it can be installed by NPM as well.
Quobix: Yes.
Track 1: 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.
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 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
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.
But no, it's Docker.
Yeah, Docker and MPM most
popular.
It was, yeah, very surprising.
Track 1: 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?
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 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.
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.
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.
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 more usable.
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?
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.
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 sets.
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
better.
Track 1: 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.
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.
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, 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?
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.
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.
Neither of those are
particularly good experiences.
Quobix: Yes, exactly, exactly that.
It's like you just, you just keep
hitting it with a 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.
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.
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.
Track 1: 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.
When it, when it started off?
Unfortunately.
So tell me a little
bit about wire itap and
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.
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.
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.
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 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.
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.
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.
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 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.
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.
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.
Effectively looks at the whole open
API contract in 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.
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
Track 1: 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?
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 data, is this, is this
instance of Jason or whatever valid
to what the schema said it should be.
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.
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.
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.
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 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.
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
Quobix: Right, right.
Yeah.
Track 1: 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.
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 a,
you know, as a, as a, a local, local ui,
local GUI to be able to, to, to view it.
And
part of the, you know, the, the,
Track 1: 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.
'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.
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.
Quobix: That's, it was exactly that
use case is how, how, how do I make
this completely 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.
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.
Track 1: 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.
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 spent enough
time with the API design, first
lifecycle, or whatever is going on.
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.
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.
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?
Or like, this has been
removed, that's been added.
And it's really nice to see
more people getting into that.
'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.
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.
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.
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.
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?
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.
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 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.
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.
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.
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, 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.
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.
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.
I want to see what's changed 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.
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.
Track 1: 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.
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 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.
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.
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.
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 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.
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.
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.
And then consumer testing is like, does
your API do what I think it should.
And I, 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.
And I don't
Quobix: that's a good idea.
I'll run that one down.
Track 1: 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.
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
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, it's just like a local tool.
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.
Track 1: 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?
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.
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.
But there's, 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.
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.
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.
Anyway that's why it exists because.
F first of all, there was
no lineups and columns.
The second thing is that KIN
doesn't support 3.1 yet, and
that
Track 1: Does it spot 3.0 even?
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.
Track 1: All the nut
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.
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.
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
Track 1: Just like you really enjoy
writing the really 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
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.
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
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.
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 p.
Track 1: Yeah,
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
Track 1: there's, there's,
there's always some things.
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,
Track 1: 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.
You're building like a SaaS and
a suite to tie this all together.
How?
How does that work?
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.
Put together, you know, the, the idea
of 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.
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.
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 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.
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
Track 1: 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.
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 and mocking and, and
validation and that, that's, that's
already quite and change detection.
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.
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.
Something you can do Well if it's
purely evenings and weekends, not, not
Quobix: Yeah.
Track 1: 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.
But like, not everyone wants to do that.
They don't want to go, all right, let 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.
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.
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,
validated to a degree.
Now it's, let's, let's make it better.
Track 1: it's
Quobix: the gas.
Track 1: 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.
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.
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.
'cause it's, it's 100% like enterprise
sales, team driven and you've 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.
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.
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.
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.
Quobix: 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
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.
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.
There's always a need to improve here,
and my opinion is the open API is like it.
It is the key to rest, 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.
I, I don't see anyone
talking about any of the
Track 1: exactly.
Doesn't need to like.
We don't necessarily need
to think it's the best.
It's the one that stuck
Quobix: Yeah.
It's VHS, right?
It
Track 1: Yeah.
Quobix: tape.
It's, it just, we,
Track 1: 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.
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.
Massive improvement in
tools happening recently.
Like I set up open APA duct tools because
everything, everything was kind of 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.
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.
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.
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.
So I love to see the competition in,
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.
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.
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.
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 specification
that's almost there, that's,
that's really big overlays as well
is an interesting thing that's
not quite there yet.
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
Track 1: 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.
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
Quobix: Thank you so much.
Track 1: pleasure having you.
Cheers.
Quobix: it.
Cheers to the chat.
Bye.