Subscribe
Share
Share
Embed
Our guest this episode is Josh Twist, CEO and Co-founder of Zuplo. We chat about Zuplo's history, their developer products and audience, and the complexities of maintaining APIs in small and large companies.
We also discuss Zuplo's support for APIs You Won't Hate through their recent sponsorship of https://openapi.tools. Thanks so much to Zuplo for supporting our community!
We also discuss Zuplo's support for APIs You Won't Hate through their recent sponsorship of https://openapi.tools. Thanks so much to Zuplo for supporting our community!
Creators & Guests
Host
Host
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.
mike_bifulco: Hello, and
welcome back to APIs.
You won't hate the podcast.
My name is Mike Filko.
I'm one of your co-hosts, and
today I'm joined by, uh, two
friends of mine, including the,
uh, ever wandering Phil Sturgeon.
Phil, how are you today?
Track 1: Hey, how you doing?
Um, uh, I'm good.
I actually dunno where I currently am.
Um, but uh, I have internet and that
seems like the most important thing.
mike_bifulco: that's good.
Yeah, you seem to be in good health
too, which is, uh, usually a relief.
yeah, and we're here today
also speaking with our friend
Josh Twist from Zulo, Josh.
Uh, thanks for joining us today.
josh_twist: Yeah, no, great to be here.
Great to sort of meet you guys
in person and uh, yeah, thanks
for having me on the show.
mike_bifulco: of course.
Interestingly enough, uh, you guys
have come on board as a sponsor for
one of our sites, that, uh, APIs
Walnut Hate has developed along
the way called Open api.tools.
Open api.tools is just
what it sounds like.
It is a, open source list of
tooling for working with open api.
So if you're listening to the
show, you can head to the url.
It's one of those funny top level
domains that sounds like it might
not be real, but it is actually real.
And there's a list of dozens
dozens of, open API tooling that
has been, cobbled together from.
The APIs, you all hate community,
including, uh, myself and Phil and
Matt Trask and a bunch of other people
uh, You're welcome to submit
things you might want to add.
And, you'll notice, Zulo is our, uh,
prime sponsor for the site at the moment.
Why don't we start there?
Why don't you give the 32nd pitch for,
uh, what you're working on at Zulu,
what, uh, what the story is and why
our API devs might be interested in it.
josh_twist: 30 seconds is
quite a tight time slot.
Um,
Track 1: We have, we have
more questions, Kevin,
about it as well.
So don't worry.
That's, that's not the whole thing,
josh_twist: so yeah, I've
worked , let's sit podcast over.
Uh, no, I've worked on, uh, I've
worked on in on APIs for a long time.
I actually founded the Azure
API management product at
Microsoft through an acquisition.
And I've sort of sat watching
that whole industry for, I dunno,
nearly 10 years, seven years,
somewhere between those two numbers.
And I just felt that none of
the products were fun to use.
Uh, there's like a, it's a red ocean.
There's lots and lots of API
gateways and API management tools,
but I think they have low N ps.
They're really not designed for engineers.
Um, and I just felt there was
time for a fresh take on it.
And so we created Zulo in, uh, July
of 21 was when we founded the company.
And we're, we're trying to bring a
really sort of fresh perspective to.
API management and democratize the
technology is kind of our goal.
So we wanna make it something that
every business would consider using.
You know, API management today is
typically used by larger companies.
Um, and I think it's
something startups should use.
Like, don't spend time on this.
We can do it faster, better, more
secure, uh, and cheaper than if
you build this stuff yourself.
And yeah, we're gonna do that by making it
easy, making it affordable, making it fun.
Track 1: fun.
Nice.
You said a bunch of stuff in there and I
dunno what NPSs is and a bunch of those
other things, but first we have to ask
the question, what is an APA gateway?
josh_twist: Oh, is that to me,
Track 1: to me?
Yeah.
josh_twist: oh God.
Wow.
I feel like I'm being tested now.
Well, it's a gateway.
And what's the difference
between API management is like
a constant sort of, uh, debate.
So, um, you know, a gateway at, to simple
level in my mind is, is, is sort of a
layer, an architectural layer you put in
front of your, your APIs that typically
take care of some sort of common, um, uh,
common concerns that, that, that you need
when you're, when you're shipping APIs.
So authentication, um, security,
uh, protection, like rate limiting,
um, Uh, et cetera, et cetera.
And so, you know, there's lots of
gateways in the market actually,
that that market is really enormous.
Uh, uh, you considered engine X and
um, uh, all of the platforms that
are forked Engine X, um, that exist.
Um, and then you've got API management,
which I think is, is, is API gateway
plus plus that takes, that looks
after additional concerns and
really tries to give you a holistic
way of managing a lot of APIs.
In our case, we also try and make
it easier for people to ship APIs.
So, so one of the things we say,
actually, both Mike and I worked at
Stripe for a while, is that we helped
startups ship, uh, Stripe Quality api.
Very quickly.
And to do that, we take care of
your developer documentation.
We call it the, the three pillars
actually of, of sort of shipping an api.
You need protection, you
need authentication, and
you need documentation.
Like that's the bare minimum that
you want when shipping an api.
So protection means things
like rate limiting and funny,
like this happens all the time.
And I talk to customers, they're like, I,
some half of people say I don't need rate
limiting cuz I'm not gonna get attacked
by, uh, anonymous or this hacker gang.
And.
It's not the hackers that are gonna get
you, it's your customer that's gonna
write a bad fall loop and take you down.
And then the other half of customers are
like, yeah, this happened to me yesterday.
useEffect in react is probably the
ultimate culprit for taking APIs down
that don't have rate limiting in place.
Um, so protection is, is things
like rate limiting and quotas.
Uh, documentations fairly
self-explanatory I think.
And then authentication is, you
know, what's your approach to orth?
Are you gonna use Jot?
Are you gonna say API keys?
I have strong opinions on that as well.
And we make those, you know, just
drag in a policy or drop at your
ship you'd done and you can get on
focusing on your business logic.
Um, so yeah, A quick take on
API management, API gateway,
Track 1: Nice.
We don't like strong
opinions on, on this podcast.
Uh, we like to be fair and
balanced at all the things.
Um, that's not true.
That's pretty cool.
And so what, what sort of,
um, users are you going for?
Right, because there's, there's a
whole bunch of a API I Gateways and
a p a management tools out there.
There's, there's all like the
Enterprisey A and all of that.
Um, there's, uh, every one of the
cloud solutions, like a Azure has one.
Um, AWS has two for reasons.
Um, there's, there's,
there's loads of 'em.
Um, there's uh, tyke, there's Kong,
there's little JavaScript based ones.
Like what, what separates
yours from all of them?
Is it different personas?
It different functionality?
josh_twist: No, I don't.
Interestingly, we've, we, we've
approached this a little bit
unusually in terms of persona.
I th I think there's definitely
differentiators that I could go into.
Um, but actually one of the things when
we, you know, we're a newish company
about year, year and a half coming,
uh, coming approaching two years,
one of the things I was keen to do, I
mentioned democratizing API gateways.
Um, I really wanted to build a
product that would span the needs of
a large organization and a small one.
And so one of the hypotheses we set
out to prove or disprove, uh, initially
is, can you, does such a product exist?
Can you do that?
And, um, my belief was you
can, because actually the, the
concerns are roughly the same.
It's just the experience that
matters more to that low end.
So we, you know, I feel
like we've done that.
I've got, uh, a good number of
tiny customers that have like two
employees and they just wanna ship
an API quickly and they're delighted
that they have this great, um, uh,
they have this great experience that
they didn't have to work so hard on.
And I have, um, uh, customers with 5,000
employees, um, large contracts that we're
considering, I won't name any names, but
you've already said them, um, in an rfp.
And we went through a formal RFP process.
And so what's really exciting to me
is we've kind of, I feel like we've
proven that hypothesis recently
that a product can do both of those.
You can build a product that's easy
to use and that's why these big
companies are choosing us is because.
They don't need to be sent on a training
course for a week to use sulo, but it
can do pretty much everything the, the
bigger, more mature products can do.
And it just fits into their,
their life cycle better fits into
their, uh, developer workflow.
That's a, been a massive focus for us.
mike_bifulco: Yeah, it's interesting.
It sounds like it fits sort of the
classification of products that like
enables a lot of superpowers without,
uh, having to spin up an entire team
of, of wizards or experts or whatever to
go and, uh, figure out how to, uh, you
know, go around all the edge cases of
rate limiting and all of the things that,
uh, your team is no doubt an expert on.
Um, I, I tend to think that it's a
pretty good hallmark too of a product
that's worth looking at when it works
for both the small and large teams.
Uh, especially because that means
that someone at a larger company
can grow their, you know, their
little, uh, niche, uh, api, um,
from, from nothing with a couple of
people to something pretty massive.
josh_twist: The a hundred percent.
And the, the other thing
actually just from.
Like a business perspective in my mind.
You know, I think, I think one
of the businesses that's done
this very well is OTH zero.
Um, and they built a product that works
great for large companies, they have
massive customers, but pretty much
every startup I talk to uses them.
And that was actually part of their
go-to-market strategy is, you know,
people used Orth Zero on their side
project and their hobby project
or, but they also worked at Big Co.
And so when the time came that,
hey, we need this identity solution.
Um, you know, and very much I hope that's
what what I hope happens with Zulo.
We have lots of hobbyists building things.
We did, we did some stuff with
Superb Base recently as a backend.
And if you want to go API first with
a super base backend, you know, Zulo
is a pretty easy way of doing that.
Um, very low lift, which is
great for that audience cuz
they don't have a ton of time.
And you know, the hope is that
they'll fall in love with the product
and go and sell it at their big
company they work at during the week.
mike_bifulco: Sure.
Yeah.
I was, uh, diving in and
looking at your docs.
Uh, I guess as I was preparing for the
show here, and one of the things that
stood out to me as interesting is, um, I
think there's a section in documentation
that's something like, um, get started
or quickstart or something like that.
Uh, and that there were a couple of
key use cases that fell into that
quickstar category that really made
it feel like, um, if you're looking
for these things, the solution is, you
know, dead simple right in front of you.
Um, and the, the two that I recall off
the top of my head are documentation
and rate limiting as, as, or, uh,
you know, just general gateway
features as a, as a quick start.
Uh, and like that's.
, that's a, a really simple way
to evaluate the product and, uh,
whether or not it fits your use case.
Um, and that meshes well, uh, with the
pricing tiers that you have as well.
So if this is me putting on my, you know,
uh, startup founder hat, I guess too,
but that's a really interesting way to
like, just let someone get in and use
the thing and then go sell it to their
organization as opposed to having to
deal with the sales team on your side.
Are you finding that that's a,
that's a way that people, um, really
do sort of join and get started.
Like you've left the right
breadcrumbs for people to try out Zu.
josh_twist: Yeah, the smaller folks
for sure, um, they tend to come in, try
the free product, and then, you know,
uh, we see them in the Discord chat
and end up becoming paying customers.
Um, the larger customers, we've,
there's actually a bit of a, uh, I
don't know how relevant this is to
you, to the podcast, but I'll share
it anyway, but there's a bit of a,
the, it's called product led growth.
This idea what, what, um, if you're
familiar with it, what, what ZE did
a great job of, and it's actually
become, there's a bit of a backlash
against it in the startup world today,
that it's not the be all and end all.
And I think we see it as like,
you actually need both streams.
Like our larger customers at the
moment, they haven't come in that route.
They don't really sign up themselves.
We get sent a formal, they hear
about us, they're excited about
it, they see the demo, and that's
usually when they suddenly get
very interested and are willing.
You know, to be clear for a large
company to take a bet on zulo, it takes
someone risking some personal capital.
It's like, you know, they're saying
you don't get fired for choosing b m.
It's like, just pick Apogee or Congo, one
of the big names, you know, it's easier.
But once they see what they can enable
their teams to do, and their teams
will actually like using it, they're,
they're willing to fight for Zulo.
But that's a more formal, sort of
sales led process, um, for those folks.
I hope it switches.
You know, I love it when people come
in and stick a credit card in and
they're just away, uh, at the races.
But we definitely see both channels
being important, um, uh, important for
us, but we're very passionate about,
I, I think about building a product
like this, like building a video game.
And I think, um, someone did a
great article on this actually.
I'll, I'll add it to your show notes.
Um, when I dig it out, um, actually
I got it from, Uh, uh, a memo
in Side Stripe from Patrick.
Um, and, uh, and it talks about like
the best products are like video games
in terms of, they start very easy, you
know, when you, when you start Mario
level one, you know, you just gotta jump
around a bit and you're gonna finish.
But there's a way and a ramp to
like use all the power of a product.
And it's like your face of bows
are on the, the last level,
on the, the, the bad guy.
But, so, uh, products in this market,
I find it feels like you're just
facing Bowser from the get-go, right?
That's your, like , you're
literally on the last level.
It's really hard to get started.
And so we, we spend a lot of time and
attention is how do we make the, a really
nice sort of glide slope to the product.
You come in, you've got API key
management set up, it's tied to a
project, but then as things get more
complex and you're, you're starting to
wanna do some wild stuff, then we, we
give you all the tools that you can,
you can do whatever you need to do.
So that's a thing we think about a lot.
mike_bifulco: Yeah.
Uh, that's, um, one of those things that
I think, um, people using your products
too won't realize it's happening, right?
But they'll, they'll have become
experts and kind of grown this
understanding and attachment, uh,
to the tools that they're using.
Um, and in particular, if that
feels familiar, like that journey is
something that feels like they've felt
with products that they already love.
You know, like, oh, this is just
like when I started with super base,
for example, or whatever, right?
You feel like you're, uh, hopping
from lilypad to lilypad in a way that,
um, is familiar and generally good.
You, you get the network effect
of those associations too.
josh_twist: Yep.
Track 1: Yeah, I mean that's something
that I quite liked about the way that
things ended up going at stoplight.
Um, that was, Whether you see it as like
a skeezy marketing tactic or whether
you see it as um, kinda like that
product led stuff you're talking about.
Like we released a bunch of open
source tools, um, and, and loads
of people were used to working just
purely with those open source tools.
Like people love spectral and they'll
just use spectral all the time and
it's little c l i thing, and then maybe
they'll use it in the VS code thing.
But you get used to using this
stuff from stoplight and then.
, you're like, actually I'm, I'm fed up with
editing open API via Yammel, so I'm gonna
go use their studio, but I'll download
the desktop one and it's totally free.
So these hobbyists and these
individuals, and maybe you're working
at a company using that stoplight
stuff without the company signing off
on anything cuz you didn't need to.
It's just an app on my computer and then
all of a sudden someone's like, ah man,
we need a editor that everyone can use.
And there's like five people at that
company going stoplight, I already use it.
We're already in there.
Um, so kind of having, it's just freemium,
I guess, but having that freemium model.
Where you can get loads done.
Um, and, and not try and like
kneecap people with, uh, all these
useful, critical features are gonna
be hidden behind a table you can
get so far but you can't publish or
something, you know, crap like that.
Giving them an actual genuine experience
but then just saying, oh, if you want
these complicated, confusing, um, like
shared design libraries or shared style
guides and things that involve our
servers doing loads of work, I gotta
charge you some money for that cuz
the server has gotta do loads of work.
And I, I think that's just a
nice way of going about it.
Just like, yeah, genuine freemium stuff
to get your foot in the door as well.
It's like a win-win for everyone
josh_twist: Yeah.
Help people solve real problems as well.
And we, well also actually, the,
the premium tastes great for us.
Like we get a lot of good feedback
from people who use our free product,
and they're probably not gonna
become paying customers anytime soon.
But they've been some of our best
customers in terms of helping
us build a great experience.
You know, these folks who are doing this,
not for their job, but for, for fun or
for their hobby or their side gig, they're
trying to start, you know, um, they're
doing it from a real place of passion.
And so their, their feedback's
especially interesting to us.
Track 1: Tell us more.
So you're talking about a p
management, we've mentioned that
gateway is kind of one aspect of it.
Um, but a p management
is a huge nebulous topic.
There's a million different parts of the
life cycle that you might be managing.
Um, and actually another
stoplight mention, they're
not sponsoring us anymore.
I don't work there anymore.
At some point I'll shut
up about stoplight.
Um, but , um, Jason Harmon, the cto,
wrote his really good blog post for, um,
is it a blog post if it's for Forbes?
I don't know, whatever
he wrote for Forbes.
Um, talking about how it's basically
impossible to cover every single
aspect of the API lifecycle.
Properly.
There's a lot of companies
pretending that they do, but they
don't because you've got, um,
especially his design, there's a api.
Design management has, has been separated
out as its own kind of, um, vertical.
But you've got kind of the designing,
um, which you kind of do, cause you've
got an editor, you've got mocking, you've
got docs, you've got testing, kinda,
you were talking about some contract
testing on a chat the other day, right?
There's um, there's the whole
like developer portal getting
new API keys, which hooks in
with the actual production stuff.
Like what parts of the life cycle are you
going for and what are you not going for?
I know you're just trying
to do it all like a madman,
josh_twist: No.
Uh, we're definitely not, not yet.
I mean, you know, I think maybe there's
a world where we continue to sort of
eat up adjacencies, but our focus, um,
you know, we do have a designer, but
I don't think we're trying to become
an alternative to stoplight or to, um,
you know, postman, I think as, as sort
of has some good tools here as well.
Um, that's not our intention with the
designer, the designers though really,
again, to give you that sort of very,
very easy onboarding experience.
That's, that's, you know, we're, we're
not suggesting anyone tries to design
an open API document in our designer.
Don't do that way, I
mean, it just won't work.
Um, but if you're coming in and
you just wanna get started, it
kind of gives you this very gradual
glide slope to being successful.
But then if you look, when
you're designing whatever you're
designing, it's just generating a
text file in the background, right?
Um, and in that you can do a lot
more than our design could do.
So we're not trying to own API design.
I don't think at this point we,
it's hard to say exactly where the
stages are, where they end, uh,
where they begin and where they end.
I think one of the, first of all, we
wanna make you it easy to have a, like a
great runtime like running and operating.
Uh, an API needs to be great.
So the fact that you're protected, um,
the fact that, uh, you have analytics
and understand what's going on,
and, you know, we have integrations
with like Datadog for, for logging.
So sort of operations is, um, is covered.
That's the, that part is the
real focus for us at this point.
And the reason we have tests
is really just in support of
getting people to that place.
So one of the biggest things
we've spent time on is, is what
is the deployment story for Zulo?
So, I mean, you mentioned great
open source companies, actually,
I think like Versace is a company
we admire, uh, tremendously.
Um, and you know, they had Op Xjs is open
source and then the, the paid products is,
is the sort of segue I'm going for there.
Um, they also, along with
Netlify, have this great GI ops
model where everything's in.
In GitHub and you, um, you
push a commit and then it'll
deploy, uh, for each branch.
Well, we have exactly the same behavior.
So, uh, we make it crazy, easy to deploy.
And part of that is being
able to test easily.
So really that's why we built the testing.
We don't think of ourselves as like
the ultimate API testing platform.
Not at all.
Um, rather, we wanna make sure that
when you're running and operating these
tier zero mission critical APIs, as
they are for most of our companies, that
you're not gonna deploy something bad.
So we want, we want to help you
to help yourself effectively.
So that's why we have things
like the, the testing.
I am definitely interested
in helping teams.
because there's blurry lines at
the edge of that part of just like
running and operating an api, right.
And managing it.
It, there's, there's, there is this
idea of, well, how can I put it?
What my experience of customers
using API gateways, like most of
the, or API management products in
the market is that the, the gateway
lives on like an iron throne in the,
in the business, in the enterprise.
It's guarded by a team of
architects dressing like Knight
outfits as I'm going for the full
on Game of Thrones thing here.
Uh, you know, and no
engineer can touch it.
They probably have to fill in a
Google form to make request changes.
And it's just, it's just BS frankly
from like how engineers normally work.
And so we wanna fix that.
And so now, Creating a new deployment,
creating a new environment in zoo PLO
tech, 20 seconds and you'll have it live.
I have a customer paying for 250
concurrent production environments,
and that's cuz every team gets
a preview environment, gets
multiple preview environments.
They just wanna throw, create them,
play with them, throw them away.
Every engineer gets to
do that where we are.
Where I am interested in going a
little bit further is, so how do we.
You know, those architects, now
they've kinda lost control, right?
How do we give them
governance with a little G?
And we really wanna do
that in automated ways.
So some of the stuff we're, we're
playing with now is the, the
tests have to pass before you can
promote this to the true production
environment or the true QA environment.
Um, maybe some lin rules are gonna
come into play, like, Hey, you know,
we have a set of standards here.
And, um, and it, you can do whatever you
want on your, what we call working copy.
That's like the pri developer's
private gateway we give them.
Um, but if you wanna get that into
production or QA or staging or whatever,
then it's gonna have to pass these rules.
You're gonna get warnings, and then
they're gonna turn into errors.
So there's blurry lines, but really
we're about, you know, operating,
um, operating a large API at scale.
Track 1: That's, yeah, that's interesting.
Cause that's one thing I wanted to
ask about is like who, who operates
it, like who's in charge of it.
Right.
Because I've worked at a bunch
of companies where, You don't,
you almost don't even know
that the EPA gateway exists.
It, it's like a, or any of the,
you know, I, I throw around gateway
and management interchangeably
sometimes cuz they're pretty close.
But, um, like they'll, they'll
just kind of like sneak it in.
You, you build whatever Rails app you're
building or whatever, and then someone
will just like slide this layer in, in
front and you get rate limiting, which
you never had to think about Cool.
Or whatever.
Um, and you might get a bit of like edge
caching or something else, but like, it
is just kind of this, this like DevOps
implementation detail that you, it's
more like infrastructure, um, but it,
it kind of sounds like you are looking
for other people to get involved.
Right.
So the, the developers maybe getting
a bit more involved, but like, is
there any, is there any room for
the client side to get involved?
Because you were showing me,
um, the caching feature and
I can absolutely, I, I bet.
There's people out there.
Kind of my frustration with the way that
people talk about Graph UL a lot is that,
that there's, there's lots of people out
there that are really upset with bad rest
APIs that are then building their own
kind of API layer in Graph UL building
bff so that, you know, they're a client
team, but they're building a BFF to
solve ship problems with that shit api.
Um,
and I could just kind of
josh_twist: other
Track 1: oh, sorry.
Backend, backend, backend for front end.
josh_twist: Oh, okay.
Okay.
Back in for
Track 1: So, yeah, like say, say you are
building a React app and you've gotta talk
to like six different APIs that all have
completely different, um, authentication.
I've been in that situation and I was
like, I don't think that every client
should have to build their own BFFs
to, to solve all these inconsistencies.
We could just use an API gateway to
remove those inconsistencies and it
would use the same authentication system.
But I could imagine that the clients would
also have a bit more control if there, if
there's just this one shared repo that's a
bit less freaky to try and configure than
some like hosted gateway somewhere else.
Um, then they can add some cash headers.
Just like, you know, you, you assure
me how to add cash headers to my badly
built API and then my client was quicker.
Um, is that a use case that
you kind of intended or
josh_twist: Uh, no, I, I guess we
hadn't thought much about the, the, the
client as in the person calling the api.
You mean, just to be a
hundred percent clear.
Track 1: Yeah.
Yeah.
The api, API
josh_twist: React app or something?
Yeah, the API consumer.
Um, no, we wanna give them a great
experience, particularly the developer.
We care about that.
We care about, we know, we think
engineers are cramps people, and so
we, we want, we wanna build something
they're proud of, sort of saying they
have their name attached to, but we
don't think about it much beyond that.
what'll happen is there's, there's
a company, it has, it's, it's
typically gotten a little bit bigger.
It's not one of the
startups we're working with.
And now it has like seven teams building
microservices and they want those
teams to run really independently.
But they also occur as an organization
that their API is beautiful, is consistent
and is ideally one single thing.
So that react clients
aren't calling 12 APIs.
But that's hard to organize in the sort
of, in the setup you just described, Phil,
because there's this magical gateway,
but how do I add new routes to it?
Like what's the process to do that?
So if you can, if you can create
it, so it's very self-serve
for the engineers inside those
organizations to add new route.
They can just go and clone the gateway,
have their own copy of it that they
run with, add in a bunch of new
routes, and then there is a process
by which that goes to production that
the architects or the, the leadership
still feel like they can manage.
Then that, um, then we
feel like that's a win-win.
And that's actually one of the
things where, where folks are really
excited about zpa, it's one of the,
the main wins we ways we win deals
with like medium sized businesses.
Does that make sense?
Track 1: Yeah, that makes sense.
Um, I'd like to ask Giant, uh,
never-ending questions that
are mostly just statements.
mike_bifulco: So I've definitely found
your outreach strategy interesting.
And it's been cool to see, uh,
Zulo showing up at, um, various
events and bringing , content to
conferences and things like that.
Um, I'd imagine education is a big
part of this and, and trying to
figure out how to, uh, make the
call to API developers that this is
something that they should consider.
Is there like a segment of the market,
a way that you're trying to identify
sort of, uh, API devs who, who you
should be talking to, or devs who
don't consider themselves API devs
who, uh, you know, should be spun
up on this sort of information?
josh_twist: I wish I had
a better answer to this.
Not yet.
We're, we're really kind
of exploring that still.
You know, we're, we're kind of early.
People are finding us
by one means or another.
Um, some of our sponsorships,
like the one we're doing with you
folks, you know, is, is great.
Uh, uh, so sort of our sort of just
talking startup business for anyone
trying to build something like this,
you know, one of our initial strategies
was we were just doing cold outreach
and hitting people with like emails and
trying to sense when they might be ripe
to be thinking about an API gateway.
And then, you know, that's hard because.
Um, if someone's already got Apigee
or Cong or something, you are not
just gonna send 'em an email that's
gonna make them, you know what?
I changed my mind.
Let's, let's uninstall this thing
and let's replace it with Zpl.
That's just not gonna, you know,
that's not gonna happen easily.
Um, so you've gotta time it where
they're already thinking about that.
And that's like shooting arrows into
the woods with a blindfold on at
night and hoping to hit some prey.
Um, um, weird analogy
for a vegan, but okay.
. Um, so then we said, maybe a better
analogy is actually we, we go and put
trip wires out, um, around the forest
where we think these people are running.
And so, like, you know, we did,
we'd done a bunch of content around
rate limiting, around sponsoring,
uh, spaces where people work.
Like, uh, we've had a successful
sponsorship with, um, have
you seen Jason Schema?
Um, by Jack Wooden.
Um, so yeah, that's a, a really cool
online designer if you wanna design
Jason's schema documents using a tool.
So we sponsor that.
We've had a great relationship with them.
There's another developer portal,
an open source developer portal
called Raddock that we sponsor.
Um, uh, because again, like people in that
area might be starting to think about like
maturing how they're approaching APIs.
So they'll, they'll see zulo,
the, the sponsorship we've done
with you folks@openapi.tools.
That's, that's one of the ways
we're trying to reach out to people.
But I think we're just beginning.
Um, some of the stuff we've done,
um, is creating YouTube content,
um, for super based developers.
You know, this idea that if you're
working on super base and you suddenly
going, how do I build an API out of
this that's actually feels like an
api that's like not, not rest over
data, which is what you kind of get
with, um, Postgres, I think they're
using, um, I want it to feel custom.
So all zla can be a very easy gateway.
On top of that, that's a dot.
So we made a bunch of content for
that, which has gone great for us.
Um, so we're still, we're still
really finding our way of doing it.
I don't, I won't say we've
cracked it yet, but, um,
mike_bifulco: Yeah, sure.
I, I feel like you, um, you laid out
the, the breadcrumb for me earlier
that I feel like you should be writing
an incendiary blog poster, making a
YouTube video that has a title, something
along the lines of like, use Effect
is costing you money, uh, and, and
go publish that on the web and you'll
get a billion
josh_twist: making notes here right now.
mike_bifulco: for sure.
Yeah.
Yeah.
You can put me on the byline for
that one if you want, but I, I like,
those are the sorts of things that
people don't realize, you know?
Uh, and, but it does
give people's attention.
They know they're having problems with
use effect doing, you know, rendering a
billion times or whatever the case is.
But, uh, they, they don't often have
the solution to that, and that's why
you find the same four Stack overflow
threads that are, you know, as
condescending as Stack Overflow can be.
Uh, and, and as unfriendly as
you could, you might imagine.
josh_twist: Yeah, actually
a great chance for a plug.
We're actually trying to hire a developer
relations developer advocate right now.
Our first, a full-time developer
advocate would be creating
lots of content like this.
So if anyone listening to the
podcast is interested, you know,
where to, you know, where to go.
Hope you guys don't mind
me sneaking that in there.
Um, we did do one in, oh, sorry.
One interesting article that again was,
was quite popular when we designed our
api I key, um, service like the, the
fact, the fact that you can sort of
add API I key authentication to an api.
We did a lot of research,
like how do people do this?
You know, we, even though I worked,
they're poured over stripes implementation
cuz they're still sort of seen as the
gold standard, I think of like APIs.
Actually, I, I'd be curious on what
you guys think is the best today.
You know, we looked at Twilio, we
looked at the same group, we looked at
all these companies, looked at GitHub
and we're like, how do they do it?
What are the rules?
What are the best practices?
And so we thought, you know, it'd be,
even though it's kind of IP for us
really in a way that research and that
knowledge, we thought, well, let's write
it up in a really detailed article.
And share that knowledge with folks.
It might mean they don't use zoo PLO
when they go and build it themselves.
It's fine.
Go and do that.
You know?
But also people may hopefully, um, see us
as someone who's sort of, you know, done
some thought leadership in this space and,
and potentially will come and use us as
a solution so they don't have to build
that stuff and manage it all themselves.
And that, that went well.
And we'll keep doing things like that.
Like the way, one of the things that
Unico Zulo is it runs at the edge.
So it's not, it's not, you know, it's
not, um, an engine X or an Envoy Fork.
This is built from the ground up.
We had to build this thing
from scratch pretty much.
And, uh, so we run on edge compute like
CloudFlare and Fastly and Dino Ploy, if
you've heard of those folks using sort
of, um, JavaScript, um, worker technology.
And there are some hard, there are some
hard lessons for someone if you do that
for the first time and try and build
like, real infrastructure on the edge.
It's just, it's just different, you know?
How do you do rate limiting
in a consistent way if
there are 250 data centers?
Each with a thousand processes in it.
I mean, how does that work?
Right?
So we have spent a lot of
time solving that problem.
Um, and, um, and yeah, we'll be
willing to, I just haven't got
around to writing it up yet.
We'll be willing to share our learnings
though, and hope that like, you know,
we're seen as like, oh, these guys are
real experts at this, so maybe we should
just use them versus try and roll around
Track 1: writing.
Yeah, that's a brilliant segue.
You, you don't wanna roll your own.
So you want to use something like an
API gateway that will, that will handle
something like authentication for
you, but you have just rolled your own
josh_twist: I'm caught here.
. The, the, because it's edge
technology, there isn't really
much we could have built on.
I mean, we, we probably would've done, I
mean, we used a few open source libraries
that were compatible with workers, but you
know, things like N Engine X and Envoy,
they are designed to run like on native.
Hardware with access to like file
systems and, and you just don't have
that in this, in this technology.
You know, there's a bunch
of advantages though.
Um, and so we deliberately
made a trade off.
We said like, what, what does the
best gateway in the world look like?
It's like, well, it runs
at the edge, obviously.
So if you use caching, like, like, uh,
Actually the, the cashing trick we did
Phil, was we were cashing in the edge.
So when you made your second request,
uh, request, when when we did that,
it was still making a request.
We didn't set the cash outs.
We can do that too.
Um, but in that case it's just, we
just kept it there on that worker.
So if you'd have had two clients,
would that two browsers request that
they'd have both received the cashed
version from the edge so that it's
not just a question of browser cash,
we can actually use server caching as
well, like a bit like a cdn, right?
Cause that's what the edge is good at.
And so that means everybody gets
a 50 millisecond response time
wherever they are in the world.
Um, so there's lots of advantages to
building a, a gateway at the edge.
And that's why we decided to sort of
take a risk and, and build our own.
We would've happily used something else.
I think if there'd have been something
suitable, but we didn't find anything.
Track 1: something .Yeah, fair enough.
It's, um, that's just always
the, the tough one, I think.
Yeah.
Trying to find the balance of like using
a few open source libraries to, to, to
josh_twist: and we do like credit to
people like, uh, path to RegX, which is
the, the open source library, uh, that
powers like express JS in node happens
to be compatible with worker technology.
So we use that for our routing.
Nobody wants to write that stuff again.
That's a really great library.
Um, although actually I think there's
one shipping now is a standard called
URL patent, which is super interesting.
So we'll probably move
over to that at some point.
It's actually based on Pat RegX, but it's
actually part of the, the, like it's on,
um, uh, which, who owns the standard?
I'm not sure, but it's on MDN
and I E T F and all that stuff.
So yeah, it's, it's actually
shipping as part of browsers.
Track 1: And so something else, uh,
obviously we're big fans of Open API here.
I bang on about it all the
time, um, for some reason.
And, uh, you mentioned there's a
little bit of open API coming to
to
Zulo.
josh_twist: a backstory actually.
So I have a sort of a love-hate
relationship with Open api cuz when
it, when I first encountered it was
when I was working on API management in
like 2013, I think it was still called
Swagger and it was a burgeoning standard.
It wasn't very popular.
And then I went away from the space
and I came back to build Zulo,
having not worked on a specific
gateway for a while and still had
this image in my mind of open api.
And um, we, we started out, when we
built Zulo, we have a routing file,
um, that's adjacent structure that
tells us how to route your request.
And we initially thought,
should we make that open api?
And we decided not to, you know, we
thought we should own the standard.
And what we do is we build an
import for open API so it would
import the file and convert it into.
Standard format.
And what we've just seen is when, when
people come into the product, they
click that import open API button first.
Um, the, the, since I last spent time in
the space, the, the perspective on Open
API and just how useful it is and how
broadly adopt it is has really changed.
And so we really into embracing that.
Like we love embracing standards if
they're working well, you know, we just
shipped actually, um, uh, all of the
standard error responses from ZULO now
come as, um, uh, problem details, which
is a new it I E T F 7 8 0 7 I think it is.
Uh, friends of yours I'm
sure like Eric Wild and Gang,
uh, who, who worked on that.
So we, we shipped that recently.
Saw all our standards
are are problem, but h B.
and then we're like, how do
we lean more into open api?
Because this is a great community,
it's our people and, uh, we think we
can do something really specialist.
We're actually moving our routing file
to be completely based on open api and
we're just gonna use vendor extensions
to, um, to essentially plug in the things
that are zulo specific to open api.
And there's a couple of things
we're doing with that as well.
So one is you can then import.
So if you have like your public
open API doc or your primary,
you can import that to zulo.
And what we'll do is we'll take everything
that's not Zulo specific and overwrite it.
and then we'll just keep the zulo
specific stuff for you so that you have
kind of a really seamless workflow.
You know, I've, I've been told, um,
I was actually checking to someone
from another open API focus company
called cusk, which is kind of a
open source, uh, open API gateway
based on Envoy for, for Kubernetes.
And you know, lots and lots of stories
of people trying to write generators to
generate a format for Kong or ambassador
or something based on open a p i.
And I think you can really change
the workflow if you just actually
make the whole thing native that way.
So we're pretty close to
shipping that, that soon.
mike_bifulco: Yeah, I think
that's, uh, a, a good thing
to, to see the support coming.
I think we have found sort
of the same thing, right?
Like our audience, the people that
we talk to, uh, generally are coming
to us from some sort of, uh, search
term that looks a whole lot like
open API plus something, right?
Like how do I x with open api?
And I think that's a signal that, uh,
there's been a real change in, uh, the
way those thing, the, the, you know,
the developer marketplace has kind
of followed over the past, gosh, I
don't know, maybe six or seven years
since things have really changed.
Uh, and we're, we're having less and
less to tell people to call it open
API and not swagger to, to that point.
Which I think is one of those things
that was a bug bear, you know,
a few years ago and has less and
less, um, been an issue for us.
josh_twist: Yeah, I don't bump into
swagger that much now, actually.
The word, um, I don't know if
that's, I'm just hanging around
with the wrong people I'm hanging
around with, with people like you.
So, so you're all such fans of the, of
the platform, but it is awesome and,
you know, people like Darryl Miller,
who I missed narrowly when he worked
on Azure, came into work on Azure API
management, I think super open to, to
collaborating and, and, you know, gi
giving advice, people like Kevin, uh,
Schwaber, uh, and so on have helped us
understand how we can do this better.
So, yeah, it's cool.
Track 1: And Darryl, who also is
currently, um, maintaining open api.tools.
Um, cuz we both are a smidge busy.
It's really funny, it's really funny
having, um, people who work for
some of the tools listed on there.
Um, because yeah, I mean e even
stoplight was saying like, Hey,
why don't you put us at the top?
I'm like, no, I'm not doing that.
there's, there's always, I don't think
it's particularly serious, but um,
yeah, there's, there's always that like,
perception of, uh, of being biased.
And so no, we, we, we have all the
tools on there and yeah, it's not,
it's not suddenly only Microsoft
tools listed on that website.
So
josh_twist: it is the downside of picking
a company with the name Z When you go
into these catalogs, like we're always
the last entry on all of these things.
And we honored it.
When I, when I made the poll request
to open api.tools, I was like,
I, I see what they're doing here.
I'm not gonna, I'm not
gonna disrespect that.
Can I ask you guys a question?
Is that loud?
mike_bifulco: away.
Track 1: Can I
josh_twist: have you seen, since we're
talking about open api, uh, Microsoft,
I dunno if they just announced it,
but I just came across it on a blog
post, this thing called cattle.
Track 1: don't think just
josh_twist: C a d L.
Um, and it's a new a,
oh, I've caught you out.
Sorry.
I thought you might have seen
it.
I didn't mean
Track 1: it's Yeah, yeah.
I've, I haven't looked into it too much.
Um, isn't that the API design language
that Darryl's been talking about yet?
So we haven't talked about that on
here yet, but I think it's a really
interesting idea because Darryl's
basically talking about how, um,
currently open API is, is being used.
I call it an API description language.
That's fairly standard language at this
point, although people call it all sorts
of stuff an a API description and you can,
and, and he's saying that it's not very
useful for designing an API that will.
right.
So the way I've, I've said it is you
can describe the A API that you would
like as well as you can describe
the A API that you already have.
But Darryl suggesting that it's a
very terse open API is a very terse
way of describing what you would like
and you immediately get bogged down
with implementation details like paths
and headers and the names of query
strings and, and everything else.
Whereas you probably want to kind of
plan something maybe in a bit more
of a shorthand, like scratch notes
kind of way is the understanding.
I've not looked into the
josh_twist: Yeah, no, I mean, we,
we played with it just the last
few days and we're super impressed.
It's like, it's nice, it's very
terse, it's very sort of short.
Um, and then you can generate
an open API document from that.
Um, so I think it's an
exciting development.
We're, we're not sort of planning on
jumping into it too deeply at any point.
Um, but I think the great things
about these is, and the reason why
we we'd pick Open API is, is there's
just so much else going on in that
ecosystem, you know, from spectral.
So when we wanna build this lintering,
it's like we could just lean on the
shoulders of, of stand on the shoulders
of giants that are, and um, you know,
all of the things that folks can do
with open API that just make it great.
Track 1: Yeah, you gotta take a look at
some of those rule sets I was doing, um,
in, in between tree planting seasons, I
went back to stoplight for a little bit.
They gave me a bit of extra, extra income
cuz uh, yeah, when there's no trees to
plant, I'm like, wait, what am I doing?
Um, And um, yeah, they had me build
a whole bunch of raw sets and so I,
one of them was the, uh, spectral
OWA set, which is quite a fun one.
And it just, it tries to take a swing
as many of the owas as it possibly can.
Um, so you could just bake that one in
there, like have, have a, do a quick
check and go, um, that'll get you
hacked, mate, you know, just by looking
josh_twist: No, that sounds great.
And I'm definitely gonna, uh, uh, uh,
I think there was something else you
mentioned actually the other day when
we chatted, um, that I wanna, I want
to come and knock on your door as we,
as we start to work on that problem.
So,
uh, but yeah, no.
Track 1: Mm Oh yeah.
Things like, um, adding, um, request
validation and kind of response
validation, aka a contract testing.
Um, yeah, those things, I mean the,
there's just so much you can do.
Once you have open API as your source
of truth, you can then do, you know, if,
even if your tool isn't trying to touch
every single vertical in the entirety
of the APA lifecycle, you can just kind
of send people off to the tools that do.
Um, so it's, it's kind of why I was
asking about how the Open API would work.
I remember talking to, I think it was
Kong and I think Tik were quite similar a
couple of years ago, and they were like,
oh yeah, we've added open API support.
There's this one text box that
you can pay something into.
And I was like, and then what?
They're like, no, that's it.
Oh, like So like the idea that
you just have this open API in
one file that's incorrect and that
you, you know, at some point you're
done with it, that's incorrect.
Um, there, there's all these kind of,
uh, data assumptions about it and.
. So yeah, the fact that you are kind
of aware that it's an evolving thing
over time and can live and get and
can be updated with pool requests
and can, can integrate and hand off
with, with other parts and other tools
to do different bits of it better.
Like that's the beauty of using a
standard whether you like it or not.
josh_twist: Phil.
Yeah, the one, one other thing we,
we really love about it is if, if
we go open API first, cuz actually
there's a couple of, you know,
there's a couple of customers using
a zoo aren't particularly open api.
They're just trying to get
something out the door.
But, so they've gone in and
they've used our route designer,
you know, that you, you mentioned
earlier, Now in the background that
is generating an open API file.
Now it's not very fancy.
It's not, you know, it's not, it's
not as good as an open API file.
You'll get out a stoplight or something.
Um, but it's a good beginning.
You're like off to the races.
And then if you start to customize
the developer portal that we give
you, you know, again, not all of the
customers use our developer portal.
Some folks say they're happy with readme
or you know, reoc, all those folks.
And again, we're fine with that.
That's absolutely fine.
Um, but I love that now that
you know, that, that people are
automatically just getting something,
it's like some extra value for free.
They might not know it yet, but they
will in a year's time when they wanna
start linking that a p i and they've
got open a api, I, or they wanna
start, does doing a API I design first.
It's like, oh, well great, we've
already got this in Zulo and we know
it's the truth cuz it is the gateway
that is, I know this is what's
happening cuz it defines the gateway.
Um, so we're excited about that as well.
mike_bifulco: Josh, I would love
to hear what you're thinking about
in terms of other things that
are coming next what are the big
things that you're thinking about?
josh_twist: I mean, I think
there's a couple of trends
obviously that are interesting.
Like, I think edge compute
is gonna be important.
I think we see a lot
of workloads shifting.
There are, um, I haven't again, might be
one for you folks to ruminate on as well.
Obviously there's some really interesting
stuff going on with AI right now, like
from co-pilot to chat G P t writing
your code, and I'm like, I've kind of
got one eye on that going, how is this
gonna play out in the world of APIs?
And I'm not sure, I don't have
a, anything intelligent to say
on that, so I'm not gonna try.
Um, but I, but I'm curious if you folks
have, um, from a Zulo perspective, um,
we have a lot of ambitions about helping,
um, helping companies sort of govern APIs.
But with lowercase g we talk, it,
talk about it being, you know, api
again, breaking down this, this
silo of the, the API gateway being.
Um, being sort of sat on a, on a, on a,
in an ivory tower, on an iron throne.
Um, and so we're really looking
at a lot of ways we can do that.
So there's, there's all kind
of things we're being asked.
So customers are asking for, um,
they want to run these tests.
We have that, we say basically
make sure they, they're mostly
like smoke tests, right?
That the API they're shipping
is not bulked in some way, or
they've not mis wired a route.
But then they're saying, I want to have
other rules now that say someone can't
go to production unless they've written
tests that give them, and I'd never
thought of this concept before, unless
they have like 95% route coverage.
So, you know, we think of code
mike_bifulco: interesting.
Yeah.
josh_twist: right?
But imagine a gateway that's like, you
know, you've got tests, but you're only,
you're only adding 30% of your routes.
Playing with so many percentage
of parameters and leaders
in these organizations.
They wanna be hands off.
They wanna let their
developers do what they do.
And so the idea of creating automated
rules and so on, that, that enforce
the standards they're looking for.
So Lin is one, but this
testing is another.
So we're exploring a
lot of stuff like that.
Um, and you know, we're, what I like doing
there is we're building it with customers.
So we're, you know, we're not, we're not
inventing this, or we're sort of, there's
a customer saying, I want this, and we're
building it in partnership with them.
So if anybody listening is interested
in something like that, then we'll be
all ears and very open to potentially
sort of partnering with you and
building it out as a POC for you.
And then we'll, we
productize it basically.
mike_bifulco: Sure.
Yeah.
I think that's fascinating.
gosh, uh, I guess I'm gonna admit
to this on a recording, but I would
identify myself as someone who spent a
disproportionate amount of time poking at
AI to see what's actually going on there.
Uh, and, and ha have gone as far,
actually, when I was at Stripe,
I was building a product with AI
just to show people how to build
something using stripes, APIs, right.
And sort of like a menial product that
doesn't do anything, uh, earth shattering.
But as a result, got me going
down every rabbit hole under the
sun, trying to find things out.
Um, and I, I think from
a generative code based.
Thing.
The, the things that strikes me that AI
and APIs might get really interesting
are things like writing better tests
and writing better documentation.
Uh, because it's pretty good at that.
You can, you can, uh, have it sort of
intro, spec, um, a bit of code and say
like, explain to me what this code does.
Uh, and to me, documentation is less
mission critical than writing the,
the code itself in the sense that
like, if you write documentation and
it's not great, it's not going to
open up security holes necessarily.
Uh, so it's a good place to start
from, uh, in test case just as well,
you could say, you know, write me
a test case for this, that tests
a dozen different ways that zip
codes might not work for, you know,
validation or whatever the case may be.
Uh, and that ends up being pretty quick.
Um, I've also found it to
be invaluable for learning.
So, uh, if, if it was something like,
explain to me how to do this with, uh,
you know, zola's management, uh, APIs or
something like that, it's good at that.
Would I trust it to build a bank for me?
Probably not anytime soon.
You know, that's a different story.
But, um, the, it's the, it's the, I don't
know, the liminal space between, uh,
the, the actual creation of something
and connecting it to other things that
I think AI is very good at right now.
Um, I will also say, I'm on
the record saying I think AI is
pretty dangerous because it looks
authoritative when it isn't always.
Uh, and I'll, I'll drop
a, I'll link in the notes.
I'll send it to you as
well, Josh, about one
josh_twist: hallucination they call
it or something where it's like, um,
halluc, is that the name I've seen?
Yeah.
I mean, I've been following it.
I'm, I'm really interested in it actually.
I thought it was a great answer
that Mike, actually, the idea of
testing seems like a really, I,
that, that's another startup almost.
Right?
Someone should just go and do
that, like build an API testing
company that, that is AI generative.
Um,
Track 1: when it comes to
documentation, I'm not sure.
Um, I mean with most open
APA documentation, it's like
peram user ID description, the
josh_twist: that's like the,
it's like those comments that
say, you know, the comments say
the same thing as the function.
It's like, this is the request parameter
and this is the food parameter.
And you're like, yeah, thanks for the
comments.
So you don't want documentation like that?
mike_bifulco: Yeah,
well, it'll save you a bunch
of keystrokes in writing the
JS doc that surrounds your
thing or, you know, the, the
Ruby equivalent or whatever.
Um, I, I will say I need to caveat this
with the most important AI story I have,
which is, um, early on, in early days,
I was trying to see if I could get AI
to generate an interesting blog post for
me about, uh, human psychology, like a
thing that I found really interesting.
And so I plugged this stuff into,
uh, um, uh, open AI open api.
Yeah.
Gosh, now I'm getting all crossfire
open AI's, uh, G P T A api.
Right.
And I asked it to write me an
article about this very specific,
like, psychological thing, and
it wrote me a story and cited
a marketing case study from.
, uh, yellow Tail wine and it said
Yellow Tail Wine did all this stuff
and here's how they made a billion
dollars with this marketing campaign.
And like came up with examples
and all these other things.
And I went to look up the campaign that
they had cuz it was , a um, campaign
where they were bashing themselves.
Basically the campaign was called Yellow
Tail Wine Tastes like Crap, right?
And that was like the whole thing.
And, and the AI out of thin air
completely made up this entire case.
Study cited numbers provided, uh, names
of campaigns and things like that.
And near, as I can tell, it never existed.
Track 1: Yeah, that's a known thing.
It just makes up citations.
Like all of the scientific, all of
the scientific studies and like all
of the researchers and all of the
psychology, like all of the citations
are invented for no apparent reason,
but it's always like, Three random white
dude names with like, you know, middle
initials to make it sound intelligent,
but done from the University of
josh_twist: amazing.
I've seen some examples of hallucination
where like, it's getting some stuff
wrong or some like obvious math problem
wrong, but I've not seen anything
that, that sort of elaborate where
it looks almost like deliberately
fraudulent, you know, with like citation.
I hadn't seen that.
I wonder what the, the phenomenon
that's actually occurring there
must be fascinating to someone
who understands how this stuff
works.
Track 1: there's a, there's a thing.
I can't remember what it was,
but it's like intentional.
They have some particular
reason for intentionally making
up citations.
I
josh_twist: Wow.
Okay, well I've got some
reading material here myself.
These are great show notes
for me and I'm on the show.
That's awesome.
Track 1: some, yeah.
I'm also wondering if the
open AI G P T API has an
open api.
That's the most important question here.
josh_twist: That is the hardest
sentence that has ever been
successfully said in a first take ever
Track 1: ever.
I honestly don't know how I said that.
I
am
shocked and impressed,
josh_twist: done.
Yeah, no.
I wonder if they do.
I know they use Off zero actually.
They're not using Zulo.
Not yet.
Maybe, uh, maybe, uh, if anyone
has a connection with Sam, we
can um, we can get 'em over.
Um, Yeah.
mike_bifulco: So the, the one thing
I feel like I would be, um, remiss,
uh, if I didn't ask you Josh, is
for developers who are building API
products and, uh, building API projects
as side hobbies, things like that.
Um, where do you go for news?
Where do you go to look for things,
uh, that are not APIs you won't
hate.com, uh, or open api.tools?
Like how do you keep your eyes on
what's coming and how do you know,
um, you know, when, when changes
are coming, like edge compute
and things like that?
josh_twist: Yeah, I, I'm not
super strategic about this, sadly.
I wish I had a better
answer to this question.
I mean, I spend a bit
of time on hacking news.
I just, it'll be like the obvious
places, you know, um, often I'm looking
for, I, I, I probably, it just comes
across my path now cause of what I do.
Like someone on the team's gonna send it
to me or something so that I, I kind of
have like a bunch of curation happening.
I proactively spend time
where I think people will be,
Asking questions about this.
So, you know, I recently found, I hadn't
seen this before, I was kind of amazed.
There's this site called Indie Hackers.
I dunno if you know it, I think it's
created by someone at Stripe actually.
Um, and that's a great place for
conversations if I'm from thinking
about what are the problems
those people are trying to solve.
So I'm, I'm a bit more strategic about
trying to go out there and discover
the things people are talking about,
the problems they're trying to solve.
Cause that's, I think, that's
where I can come in and add value.
Um, I'm not super good at keeping up
with, um, with, uh, all the latest trends.
I follow the usual people, Ken Lane, you
know, uh, Kevin Sch fiber, you guys, um,
you know, I, I probably could share a
list of, of people I enjoy, uh, Kenneth
Thunberg, um, these folks, and they tend
to flag, flag things I'm interested in.
But yeah, that's, that's
my, I'm not super strategic
mike_bifulco: Sure.
Um, well, that's reasonable to me.
My, um, I've, I've abandoned Twitter
somewhat recently, and so I've been having
to look in different places for, uh, you
know, expertise and learning and all that.
And apart from having Phil send me a link
every now and again to something that,
you know, uh, learns me this and that,
uh, I've, I've really had to change, like
my, my behaviors and places I've gotten
to learn are really changing lately.
So,
yeah.
josh_twist: You're on
mike_bifulco: I am, yeah.
josh_twist: I, someone needs
to teach me how to use it.
That's the only problem.
I, uh, I'm, I'm hit by that wall of like,
it's bowser level one problem, right.
That we talked about before.
It is tricky, but, uh, I, the,
the, you feel the reward is
there.
It's worth it.
mike_bifulco: Um, I'm not sure.
Uh, I, I will say I benefited quite a bit.
Early days when I first
moved over last summer.
Uh, someone who was touting themselves
as, uh, mastodons, unofficial
Derell, uh, was posting some really
great tutorials on how to mastodon
correctly, and that was really useful.
Um, I've, I've, um, really just kind
of turned down the taps on all of that
for myself, like less, less mastered
on than I was doing on Twitter.
I've started posting on LinkedIn
and I really don't like it.
Uh, it's just not like the, the
kind of place that's validating
for sort of expertise I seek.
Um, and so like, I don't know,
Google blogs, things like
that, or, or podcasts, right?
Or where a lot of my learning comes
from YouTube disproportionately too.
josh_twist: Yeah,
Track 1: Yeah, I don't know
where I would go to to be able
to just be the same person.
My, my, the people that follow me
now are the most weird collection
of people of like hardcore old
school PHP nerds and API nerds.
And then more recently, like a bunch
of counselors who are like, mostly
are like trying to get me to help
them remove invasive species from
their woodland around the corner.
And I'm just effing and blinding and
banging on about computers and then
getting really nerdy about
josh_twist: might be the way
this Twitter stream might follow.
Actually, it's definitely up there.
It's like, why am I
following this guy again?
What's here,
Track 1: this guy again.
josh_twist: It's good content.
It's just random.
It's
just out there,
Track 1: here's me showing you
how to fix a, a, a flat tire
by shoving grass in there.
And then next, like, it's
just, there's such a weird
mixture of stuff.
mike_bifulco: Yeah, Phil, I routinely
tell people that you are, uh, the,
the, the person I know with the highest
talent for telling people when to go fuck
off, uh, and exactly why they're wrong.
Uh, and, and I want to channel
some more of that in my life,
for sure.
Track 1: Well,
I'm currently getting into an
argument with a whole bunch of
people cuz the Wildlife Trust and
HS two, the high speed rail line.
Um, I just tweeted and said they're
both going at each other like an
overserved hen party fighting over
who gets to hold the inflatable cock.
Um, and they, uh, yeah that's
super professional off me
mike_bifulco: Oh, we all have
something to learn from you, Phil.
I think
josh_twist: I think there's a
training course there, a Udemy
course on, on, on the skill.
You described that Phil has like
a, like a, a self-help course
and um, there's a book like that.
How to Give
Less.
Track 1: Anyway, that, That's
probably about time to call it a
day .Cause it's just, it's
just send it into nonsense that
that
that always
happens at
mike_bifulco: Josh, where can
our listeners find you and where
can they find
Zulo?
josh_twist: Uh, they
can find me on Twitter.
I'm not super active.
Um, uh, Josh Twist, they can
find zulo on Twitter as well
at zulo, um, and uh, zulo.com.
Um, I'm super chatty, so you can
email me@joshzulo.com as well, and
I will almost certainly respond.
So yeah, um, reach out, say hi.
Those are easy places to find me.
I'm on LinkedIn as well though,
Mike.
Uh, , that's a thing.
Track 1: make
mike_bifulco: Perfect.
I'll, I'll send you my, uh, list
of 10 things I do to make my
josh_twist: There we go.
mike_bifulco: on LinkedIn.
Uh, you also mentioned before that
you're hiring for at least one role.
Where's the place to go for that?
josh_twist: Uh, you can actually just
email, just email josh zulo.com if
you're, if you're interested in the
developer advocate role, um, it, it is
on our website, um, listed as a role too.
You can email jobs zulo.com as
well, but I'll be person looking
at 'em, so, so
yeah, get in
touch.
mike_bifulco: Perfect.
Well, thanks so much for your time.
It was wonderful chatting with you.
And thanks for, uh, your sponsorship as
josh_twist: Yeah,
Track 1: your talk.
Yeah, thank you
josh_twist: Yeah, I had a laugh.
That's great.
Thanks folks.