Don't roll your own API Management tools, with Josh Twist from Zuplo

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.

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.

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,

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?

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.

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.

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.

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.

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.

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.

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

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.

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,

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.

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

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

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?

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?

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,

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.

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

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.

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.

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.

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.

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.

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

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

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.

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

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.

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.

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

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.

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

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.

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

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.