APIs You Won't Hate: Recent Episodes

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.

View Details

Show notes* Sandeep Dinesh + LinkedIn + GitHub + Twitter * Mercoa + GitHub - mercoa-finance + LinkedIn

Transcript [00:00:00]

[00:00:00] Mike Bifulco: Hello friends. Welcome back to APIs you won't Hate. My name is Mike Biko, your co-host and APIs you won't hate. Co-founder leading you on this journey through API Tech in the world. I am super happy today to get to sit down with Sandeep Dineh from Meco to talk about the product he's building. And I think this actually may continue a bit of a weird streak I have where I have some lots in common with the folks who have been interviewing on the show.

[00:00:22] Maybe that's a bit of self-selection, but in this case, I think Sandeep is working on something that is. At least tangential to a world I used to live in . And he also happens to be a YC co-founder. Sandeep, thank you so much for joining me. How are you doing today?

[00:00:33] Sandeep Dinesh: I am great, Mike. Thanks for having me on.

[00:00:35] Mike Bifulco: Of course. Yeah. It's, my privilege and pleasure to be able to chat with you.

[00:00:38] Why don't we start here? So you, you are founder of mea. Tell me about Meco. What's the elevator pitch?

[00:00:43] Sandeep Dinesh: Yeah, so Meco is an API for accounts payable. And so a lot of folks don't know what accounts payable is, but when you're a business, you got bills to pay and usually when you're at a certain scale, I. You have approvals and invoices and vendors to manage and this whole process that your [00:01:00] accounting team is probably really familiar with.

[00:01:02] And so we help our customers launch accounts payable products to their customers.

[00:01:08] Mike Bifulco: Got it. So a bit of a, whether that's a B two, B2B, or B two B2C or how, how does

[00:01:12] Sandeep Dinesh: B two. B2B. Yeah. So I think the best way of looking at that is Stripe has Stripe Connect really popular product for marketplaces. So let's say you have like Uber drivers they need to get paid. So you pay, I. Uber and then Uber pays out to the drivers. That helps 'em get paid. We help make payments out.

[00:01:32] So you have a bunch of customers that have their own vendors and they're managing their whole back office on your platform. We help you launch bill pay and accounts payable so your customers can start paying their bills on your platform.

[00:01:45] Mike Bifulco: Sure. Okay. That makes a ton of sense. And I think especially for someone my, like myself with a background primarily in engineering and less so on the finance and business side of things, I'm always fascinated to hear a bit about the history of how you got there and like what, what caused this to [00:02:00] happen.

[00:02:00] And I also think we just hit a world record or maybe a, a show record for quickest time to me needing to give a disclaimer that in a past life I worked for Stripe on the developer advocacy team. Had a great time there. It was a good job. I'm no longer at Stripe. But it's probably just worth calling that out to begin with since it'll likely come up here and there during the conversation.

[00:02:17] So, Sandeep, with that being said, tell me about how you got here. What, what caused you to you know, take a path that had you build, has you building an accounts payable product?

[00:02:25] Sandeep Dinesh: Yeah. So in order to answer that correctly, I think we gotta go back around 10 years. So 10 years ago I pretty much just graduated college. I was working at my first job and I was really bored. And so I actually met my current co-founder at that company. And we did a few hackathons together and we did our first startup way back in like 2014. That crashed and failed real hard. But it was a great learning experience. And we've been working together for the past 10 years. But after that I actually joined Google on the developer advocacy team for Google Cloud. And so I was our [00:03:00] early hire on the cloud advocacy team there. And yeah, that was a great place to start my career as an engineer.

[00:03:07] You know, I've been coding for a long time, building websites since I was a kid and all that kind of stuff. But I think just learning how some of the best developer advocates go ahead and talk about APIs and developer tools. And kind of really seeing Google Cloud grow from Yeah. They have a cloud platform, I think, to being in the same conversation as like Azure and AWS.

[00:03:29] Was a really cool experience. And so I did it about for about five years. And right before the pandemic me and my co-founder launched a fully bootstrap startup. So beginning of 2020. So we built that for about a year. And then I joined a small byc company as a lead engineer. And so I learned a lot about. Kind of the, the venture world and shipping fast and kind of. Doing that kind of stuff. And then I joined Stripe as well. So yeah, I think a [00:04:00] lot of career similarities with you, Mike. And yeah, so at Stripe I was a engineer on the revenue recognition team, and so we were building some cool products for accountants.

[00:04:10] And so while I was there at Stripe, my co-founder was actually a product manager@bill.com. And so he was working for a company called Invoice to Go that did invoicing for small businesses. They got bought by Bill and one of his projects@bill.com was trying to build Bill dot com's account payable into invoice to go's platform.

[00:04:32] So basically trying to turn bill.com into an API into an embedded, uh, API, and then embed it into like an internal project for that. And the thing that he really realized was other companies were coming to bill.com and asking for this kind of functionality. And bill.com really couldn't support them because their organization wasn't designed to sell APIs and developer tools.

[00:04:59] And so we [00:05:00] started MEA because we saw this opportunity of like, if we are API first, if we're developer first, can we go ahead and help people launch their own accounts payable products? In a, in a, in a way that kind of competes with all these different AP systems out there.

[00:05:14] Mike Bifulco: I'm really interested in all of this because it seems like there's a, there's a real confluence of things happening where you're both working at companies where, you know, opportunities are ripe in, in sort of the payments world, especially around this time period. Right? The past few years has been pretty crazy and, and all this stuff.

[00:05:27] But also to be to have you at Stripe where developer journey is everything. And your co-founder at a company where they, they're desperately in need of a solid developer journey, feels like the, the birth of your product is a sensible outcome. From there I'm curious for yourself and your co-founder did you either of you have sort of like business education background or were you both sort of traditional engineers going into this?

[00:05:48] Sandeep Dinesh: So my co-founder has an economics background. He's not an engineer. Lot of product experience, sales support, customer service. So he's, he's had the whole go to market kind of [00:06:00] experience from a career standpoint. For myself I technically have a business background. I graduated with a degree in marketing and computer science.

[00:06:08] I don't know how useful that degree in marketing was.

[00:06:11] Mike Bifulco: You a job in developer advocacy, I think it probably went a a really long way. Yeah.

[00:06:15] Sandeep Dinesh: Yeah. So I think that really helped getting that job as a dev in Dere. But yeah, I think so to your point about kind of things just kind of converging together, I think learning about developer tools and dere at Google, learning about the accounting side of things at Stripe having my co-founder also super interested in FinTech.

[00:06:35] Having the startup experience prior getting into yc, all these things kind of just combined in a way that made starting meco pretty, pretty obvious to do. Yeah.

[00:06:46] Mike Bifulco: So you've, now come together with the idea you have people with, interesting backgrounds that sort of knit together to build something that makes a whole lot of sense. What was your story for chasing down your first actually, maybe let's talk about it this way. Your first use case, like what was the first thing you built and then [00:07:00] how did you convince your first users to jump on?

[00:07:02] Sandeep Dinesh: Yeah, so we started talking to customers before we had anything built. I think. We've gone down the road of like building a bunch of stuff and then figuring out you built the wrong stuff plenty of times. So we started having phone calls with folks through, in our network, through LinkedIn.

[00:07:18] We've been very fortunate that we've done a lot of people coming in talking to us through LinkedIn. So yeah, we had a lot of folks, we talked to them, try to really understand what problem they're trying to solve what's important what's difficult about this. And we kind of sprinted to create a demo.

[00:07:35] And so we had like a nice happy path of like, you can embed this into your, into your product and now your customers can start paying bills. And that first demo was basically an I frame that you drop in and the word I frame kind of like burns the ears of many folks out there. They hear that and they're like, I don't like that.

[00:07:55] But it was kind of the fastest way for us to validate that. Hey, drop this in, see if it [00:08:00] works. We had an API, it was hand documented. Hand rolled pretty bad. But, you know, we just wanna validate does this, does anyone even care? And so we started getting folks who were interested. We started signing some pilots.

[00:08:16] And then we got started getting really serious about how do we deliver this product. So that was kind of the beginning. And I can go into more, but yeah.

[00:08:23] Mike Bifulco: Yeah. Okay. I'm, I'm already hearing things that make me think that maybe having a marketing background was probably pretty helpful there. But, but maybe also having built and been through the ringer with. PR past companies, especially bootstrapped ones is really interesting there. I talk about this a lot and I almost feel a little I don't know.

[00:08:38] I, I always feel like it's hard to really land this with people until you've actually experienced it in some way. But many first time founders will go and build a product with an idea that is, I. Whether good or not not told to enough people and then they don't go and chase down enough feedback before building the thing.

[00:08:53] And

[00:08:53] Sandeep Dinesh: Yeah,

[00:08:53] Mike Bifulco: you know, the, the trope for me is someone who talks about like, well, it's not ready yet. I haven't shared it with anyone 'cause it's not ready.

[00:08:59] Sandeep Dinesh: Never [00:09:00] ready.

[00:09:00] Mike Bifulco: just now Yeah, it's never ready. Nothing is ever done, ever. That's the whole whole thing with software. What you've just described for me is it.

[00:09:06] Entirely the inverse of that, right? Like we didn't build anything. We went and talked to a bunch of people first, and then built something that was no, nobody's favorite idea, but at least better than what existed before. That, that's a skill that takes some time and is definitely a, a nuanced approach, especially as compared to, I don't know what I would call maybe the traditional, like first time founder thing.

[00:09:24] And so. When you do that, what are the signals that you were looking for to even pursue further? So I'd imagine you got some early signals that people were using it and liking it. Is it, Hey, I want more, or, Hey, we think we could make this better for you, or, or find a thousand more of you, or what was, what was what you were looking for at that point?

[00:09:40] Sandeep Dinesh: Yeah, so it's actually really funny. I think we went about Meco in a way. Completely different from our other products. So I think one thing is we are building financial infrastructure. So that takes quite a lot of time to build and it takes quite a lot of time to build trust in that product, right? So like, we're moving millions of dollars.

[00:09:57] You're not gonna wanna just [00:10:00] trust who, random guys who build a product in a weekend to do that, right? So I think for us, we were really trying to figure out. Is there market demand for something like this? First? Can we find those people in a, in a repeatable process? And then what are those people's biggest like need?

[00:10:19] Right? And so at the end of the day, our product is pretty complicated. We call it like the eight components, and each one of those components can be used a la carte. By itself together. So it's a pretty like complicated platform. So the first thing that we really wanted to do was validate, Hey, are there people out there?

[00:10:38] This is like a market that even exists. And I think we did that by just trying to talk to as many people as possible in the industry. Are you building this yourself? We got a lot of, yep. This is on my roadmap for next year. For next year. I don't have any resources against it, but I wanna do it. And we're like, okay, that sounds really interested.

[00:10:55] It's like, do you wanna partner with someone? It's like, yeah, absolutely. If someone would build [00:11:00] this for me, I would definitely wanna talk to that person. We're like, okay, that's great. And then the last challenge was how do we find these people? And I think for that it was really a struggle. 'cause there's no like, list of vertical SaaS companies and that's who we primarily sell to is vertical SaaS.

[00:11:15] So it's really hard to find those folks 'cause there's a bunch of founders starting them all the time. They have a lot of deep expertise in like, let's say the construction space or dental or home services, right? And so they maybe they've worked in that industry for a while. Maybe they've run Airbnbs and they wanna start a business to help other folks in that industry.

[00:11:35] Like how do you find these folks? Was really difficult. And for us, we really try to solve that by being the most helpful folks. Out there. So a lot of people starting these companies don't have FinTech or finance backgrounds. And so we started writing content on how do you monetize this kind of like platform.

[00:11:51] What are your customers looking for when it comes to like payments and just trying to be really helpful. And so we actually wrote a 28 page guide [00:12:00] on how to build Meco from scratch. And so it's like. If you wanna just build this yourself here is like the PRD for you. And yeah, we got a lot of hits on that.

[00:12:09] I think people were like, this is really cool. It was just a Google doc. And so that was, that was our first, I think, real sign of, okay, there's something here. Let's invest more.

[00:12:17] Mike Bifulco: I think that sends a strong signal too, that it's like, well, we don't have secrets. This is just a hard thing to do. Like you're, you're welcome if you want to go and, you know, go on this journey. But it's probably the sort of thing that you need a few people and many, many person hours of engineering time to get through.

[00:12:31] And even then your industry background probably helped quite a bit there

[00:12:35] Sandeep Dinesh: Yep.

[00:12:36] Mike Bifulco: Right on., I'm super into that as a path to go and very, very much a show of strength there too. Like, cool. Here, have all our secrets. Good luck. So where, where does Y Combinator come into the picture?

[00:12:46] Sandeep Dinesh: Yeah, so I was at Stripe. I. Basically just joined. I was about almost like a year in I felt like I was fully onboarded at this point. And my co-founder was, Hey, let's apply to yc. And we would apply to YC plenty of times for other [00:13:00] ideas and like, Hey, let's throw in an application. So we threw one in very last minute.

[00:13:04] And then we got in, which is a very happy surprise. We took the weekend and we're like, yep, this is, we've been waiting for this opportunity for a long time. I don't wanna live my life thinking, what if I think this is a huge opportunity. Like, let's go. They're gonna give us some money, let's go try it out.

[00:13:21] And we just hit the ground running really hard. So we quit our jobs and started building, started talking to customers. Basically like as my co-founder was lining up these meetings trying to validate that idea like I was talking about. I was like, what is the smallest demo we can throw in front of people to kind of give them an idea?

[00:13:38] So we did Figma to start and then very quickly moved to like a clickable demo. And that was all before we actually started the, started yc. So we were winner 23 and so we were doing this in like November and December. And so YC started in January and, I think within the first month we signed our first contract.

[00:13:58] And so that was like a big validation for [00:14:00] us.

[00:14:00] Mike Bifulco: yeah, of course. Again, to, it is funny. I don't know this off the top of my head, but to clarify, winner 23 is. Starting January, 2023 ish, or was that into, okay.

[00:14:10] Sandeep Dinesh: yeah, yeah. First three months of, yep, yep, yep. Mm-Hmm.

[00:14:14] Mike Bifulco: And so you've, you've obviously come a long way since then. One of the things that I found valuable when Kraftwerk went through Y Combinator was we were really focused for a few months during YC on set, set an ambitious and, and hard goal that is meaningful and do everything you can to build a narrative towards that.

[00:14:30] It sounds like you, you headed into YC with a working clickable demo and were maybe chasing down customers. What was sort of your North Star at that point?

[00:14:37] Sandeep Dinesh: Yeah, so we wanted to close 10 customers, very aggressive. We did not get there. We got pretty close. I. I think again, our goal through that three months was can we kill this idea of like, what do we do to lose conviction that this is the business we wanna build? I think both of us are, you know, kind of mid-career.

[00:14:55] We both are married and all that kind of stuff, and so it was like. [00:15:00] You know, it's not our first rodeo doing a startup. We know how difficult it can be and how easy it is to lose motivation. And so it's like, let's do that fast rather than slow. So I guess like fail fast. I don't know if you wanna call it that. But yeah, I think that was kind of the whole goal was like, I. Can we just lose conviction on this idea and kind of just shut it down? And everything that we did went the other direction of like, oh wow, okay. We've kind of gained conviction. And I think at the end of that, we were like, yeah, this is what we wanna spend a long time building because we think it's gonna be really big.

[00:15:35] And I think we have the right team to do it. And so that was kind of our internal goal at yc, obviously. I think they talk about this a lot. You know, you have the two week check-ins with the group partners. And so we had pretty aggressive goals on trying to close new customers and leads. And so yeah, that was kind of like the external goal, but I think really internally it was, can we kill this idea?

[00:15:54] And not even launch it.

[00:15:56] Mike Bifulco: Sure.

Debate me!

[00:15:57] Mike Bifulco: You're absolutely the first founder I've talked to who is, [00:16:00] is going about this by way of like the debate me route. Like, you know, convince me this is a bad idea. I, I really like that, especially in the case where like you're, you're being forces you to be maybe intellectually honest with yourself which can be really hard to do.

[00:16:12] A lot of, a lot of people get almost delusional about their idea and we'll go a really long way before they decide that like. Oh, you know, it turns out the thing that I'm building is just not a big enough molehill to be scalable at, at the scale that we need it to be. Especially once you start taking on investment, that becomes a much, much bigger molehill to tackle too.

[00:16:30] Okay. So you finished YCS program at the end of last winter, so March-ish of last year. What, what's happened since then?

[00:16:37] Sandeep Dinesh: Yeah, so I think we've learned a lot about what is kind of the, what is an MVP versus an MLPA minimum lovable product. So I was talking about the iframe. Yeah. No one likes that. Our API has gotten a lot more complicated. So I think you've had Danny from Fern on on this podcast before. So we are big users of Fern.

[00:16:57] We use 'em for server side, [00:17:00] client side and docs. And so we basically moved our whole. API over to Fern during the batch. And so we were batch mates together, so very glad I met them early in the business. So I think one thing that we've learned is just how important developer experience and API documentation is for our sales process.

[00:17:20] And so I think a lot of folks in FinTech the bar is very low for good APIs in FinTech. I think Stripe is like way up there. And everyone kind of assumes that everyone also has like stripe level documentation, SDKs, all this kind of stuff. And no, it is like pretty bad. And so I think like the bar is low, but we wanna go really above and beyond to kind of provide that really good experience. And I think the big reason why is, well twofold, one. We sell to product teams, but a technical co-founder or VP of engineering or lead engineer, whoever it might be, depending on company [00:18:00] sides, does have a very big say in the go, no go. Right? If they look at our SDKs and APIs and they're like, this looks like my team is gonna struggle to implement, I don't think they're gonna be serious about this.

[00:18:13] We are not gonna win that deal. Right? So like the features and all the check boxes might look really cool, but at the end of the day, because we are a embedded product, we are API first, we don't make money until you start using us, right? And so like that implementation's all about the technical kind of coupling of our service to yours.

[00:18:33] So the API SDKs are a huge part of our Go-to market movement. So that was a big learning. I think we. We're trying to build as fast as possible and the docs went outta sync and they didn't look good, and our guides weren't great and we invested a lot of time into like trying to make that onboarding experience really nice.

[00:18:53] And so that was a big thing. I think Fern was a big help there. So for folks who don't know what Fern is, it [00:19:00] basically lets us define our APIs in a Fern yaml. I think they also support open API specs and it actually generates our server side routes and client SDKs for a bunch of different languages.

[00:19:12] As well as our docs. So every time we make a change, all three of them are always in sync. And so we can get basically guarantee to our customers that like, everything is well documented, always up to date. And it's like what you, what you see is what you get and people really like that. So that was a big part of our investment.

[00:19:29] The other side on the dev side was our front end. So we talked about the iframe, iframes. I, I love iframes. They let you move really fast. Uh. With things like JWTs where you can pass in custom props, you can actually customize iframes pretty easily. I think a lot of companies that deliver their solution with iframes do that, but I think a lot of her customers were like, this is even with, this is not good.

[00:19:52] I don't like, it's a black box. My, like, observability tools don't show me what's going on. If a customer has a question, [00:20:00] I'm just kind of stuck on you guys to, to figure that out. And so we had built that iframe with react components underneath the covers. And so moving that from internal React components to an external library was a really big deal.

[00:20:15] And, you know, I think like react components as a delivery mechanism. I think like Algolia does a really good job. It's a company called Quill. They do embedded analytics. They does a really good job, but it's kind of like a, a new. Way of delivering an embedded product. And so.

[00:20:31] Mike Bifulco: think so. Yeah.

[00:20:33] Sandeep Dinesh: There's really not that much like best practices out there.

[00:20:35] So we've had to like learn a lot. So we're using storybook for a long time to do kind of a documentation, but that's really great for like UI libraries and that's not really what we're doing. And so we're actually migrating to a fully manual documentation for that where we put our components, we talk about how you can use them.

[00:20:52] All of our components take can take in a child component. Then we just pass you a bunch of hooks, right? Like that's not really a [00:21:00] common use case for like UI libraries. So I think like that's been a big learning of like, how do we help our customers move fast? And that's the reason why they wanna partner with someone like us and not build it in-house is time to market, right?

[00:21:13] And so I think the backend is really complicated. That's, you know, kinda expected. We have a lot of good documentation tooling for APIs. But then the front end, the react component side, I think that's kind of like a new world that we're exploring and trying to build a lot of tool that kind of tooling ourselves. And yeah, so that's been a big learning for us.

[00:21:32] Mike Bifulco: Yeah, that's a really fair point. I don't think I've really heard it put that way, but it's definitely something I've felt maybe as a beneficiary of it, as an end user of these sorts of things. That many of the SaaS products that have come to love are ones where I essentially consume it through NPM install.

[00:21:47] And become an end user that way. And I can think of a few off the top of my head. Clerk does authentication very much in that way where they ship a bunch of React components that you just toss it into your React app and suddenly have authentication. Post hog does a really good [00:22:00] job. They have some really nice React libraries.

[00:22:01] They'll let you add. Product analytics and do a whole bunch of tracking and ab tests and all this stuff that you know, in prior days would've been a much deeper build out with loads and loads of code and docs that you could imagine, and certainly a few others that I've used. And there's something to be said for that too, that, that is scaling your developer experience by way of taking advantage of the massive amount of time and love and care that folks from these other companies are putting into their.

[00:22:24] A deeply focused slice of the thing. You know, like authentication is something that I never wanna become an expert on. And I'm sure I've said that on the, the podcast a billion times by now. But being able to effectively hire out smarter people than me for a price that scales with my success is like, sign me up, let's do it.

[00:22:39] That's great.

[00:22:40] Sandeep Dinesh: The interesting thing with these like embedded, so clerk embedded authentication like the thing there is, it's the same for everyone, right? Like almost 90% of what you're trying to build with these embedded providers, it's the same as everyone else.

[00:22:53] And I think that's just kinda the same thing for us. We're say like, you know, 80% of bill pay is like the same. It's an accounting process. Like there are gap [00:23:00] principles that everyone follows to like pay their bills.

[00:23:03] Mike Bifulco: Right.

[00:23:03] Sandeep Dinesh: Just add your secret sauce on top that's like in specific for your industry or your vertical or like your, your customer base.

[00:23:09] But why are you trying to reinvent the wheel? And I think that's kind of like the, the bread and butter of embedded SaaS, right? We're fully white labeled. You don't know that we exist, but we let you move fast and like not worry about like the things that you don't wanna worry about.

[00:23:22] Mike Bifulco: Yeah. And again, to that point, you, you meco is successful only when your customers are, and there's an alignment of incentives there. That's really interesting too.

[00:23:30] Sandeep Dinesh: I'll try.

[00:23:30] Mike Bifulco: Another case where maybe solving the boring problem, so to say is great for everyone involved. You can stay focused on your thing much the the way that, you know, say a clerk would be focused on authentication.

[00:23:41] So I wanna talk a little bit more about how Meco is built. So Fern is, is super interesting because they give you so much of that sort of love and care in the world of SDK Cogen. So now Meco is available sort of. Pseudo natively in a bunch of languages, I'd imagine as, as installable packages, SDKs, whatever you wanna call 'em, and you get documentation out of it and [00:24:00] all that.

[00:24:00] What, what is the underlying system that you're building then that that speaks to Fern? Like, what's your architecture look like, maybe what's the size of your team? Those sorts of things.

[00:24:07] Sandeep Dinesh: Yeah, so bit of background on me At Google Cloud. I was on the Kubernetes team, so microservices were like my bread and butter. And so very specifically not doing that with Meco. So team is very small. It's basically on the engineering side. Right now. It's just me. So we've kept the team pretty small on purpose to move very fast, kind of find product market fit, and then start scaling it out.

[00:24:29] And so it's pretty simple. We are running on Google Cloud Run, so fully serverless. And our database is on CockroachDB, which is also fully serverless. So that's for folks who don't know what CockroachDB is. It is a Postgres compatible database kind of based on Google Cloud. Google Spanner and Spanner is a.

[00:24:48] Horizontally scalable asset compliant database that uses like crazy atomic clocks and all this kind of stuff to keep transactions always in sync as you scale out. And so we've kind of [00:25:00] chosen technologies that let us scale by default because I don't wanna deal with that. So really simple. It's a monolithic TypeScript, no js backend. We use kind of. The, the normal tools, GitHub and Sentry and all that stuff for monitoring. But yeah, we kept it very simple just so we can move fast. I've worked at teams where, you know, everything was split out into its own microservice and it just kind of, as a small team, very hard to deal with that.

[00:25:24] So yeah, we just kinda, how can we move really fast and how it deliver a product that, you know, customers really want. And then we can think about breaking it down in the future.

[00:25:34] Mike Bifulco: Right, and you mentioned you, you're the only engineer, is it just you and your co-founder currently as well?

[00:25:39] Sandeep Dinesh: Yeah, full time. It's just me and my co-founder. Yep.

[00:25:42] Mike Bifulco: Amazing. Definitely very small and lean and mean at that scale. And what I, if you're listening to the podcast, one of the things I would encourage you to do, which I think is maybe a good data point to like put side by side with that is me's site. Does not convey a two person team even slightly. It looks pretty, pretty intense.

[00:25:59] There's a lot going [00:26:00] on there. So you know, a, a applause is due to you and your co-founder. There's loads of stuff there, and I'm sure you're standing on the shoulders of giants in many ways by using lots of interesting tech there. But it speaks to what you can get done with, with some focus and maybe a bit of a marketing polish on things too.

[00:26:15] That's, that's super cool.

[00:26:16] Sandeep Dinesh: Thank you for the compliment. I think, yeah, definitely building on the shoulders of giants. I think like we try to use as much tooling as possible. We try to partner with vendors that can move us really quickly. But I think at a small, small team size, you know, our secret sauce is just customer support.

[00:26:32] And I think YC says this also where it's like, what can you do that like Stripe or Google can't? And that is just like. Really, really focusing on the customer and really delivering solutions to them. You know, we don't have a lot of red tape. If someone really needs something, we can ship it tomorrow. We wanna move very fast.

[00:26:51] We wanna be very thoughtful and, back to the original point of no secrets. I think like even if you don't end up working with us, we still want to make you successful. 'cause maybe in the future [00:27:00] you will, maybe you won't, but at the end of the day, we wanna move the whole industry forward. It, it's really painful when you see folks still using like pen and paper or checks or spreadsheets to do their finances.

[00:27:10] Like can we just move the world away from that is kind of like the goal, right? Like maybe it's us, maybe it's not, but let's move the world forward. Is kind of like the big picture. Yeah.

[00:27:20] Mike Bifulco: Yeah, you, you've painted a very cool story as well around like having a focused idea and building something that addresses a direct problem that you understand really well. Often on this show we talk a little bit about, like, talk about a problem, a project, a product. Fern was one, Danny's been on the, the show where we've talked to him before about what they're doing and sort of the pitch for API developers at that point is something along the lines of like, how do you know if you are someone who should be interested in using Fern?

[00:27:45] I would imagine there's probably a very direct story there for Meco too. So for, for a, for devs who are used to integrating with APIs and building products what's a sign that Meco might be solving problems that they should be interested in?

[00:27:56] Sandeep Dinesh: Yeah, so I think the big one with MEA is if you're trying to [00:28:00] build the financial back office for your customer. I think a lot of folks start with invoicing to start, right? So helping your customers get paid. Then kind of the next natural thing is banking. So helping them store those funds, manage those funds and then you can go into payroll, you can go into spend and expense management, and you can go into accounts payable.

[00:28:18] And so basically we wanna help you create that financial one-stop shop for your customer. And so that's money in money management and then money out. And so we plug into that money out piece. And I think the reason why a lot of folks don't really understand the opportunity in the money out side of things is I think when you're thinking about money in, it's like, Hey, Stripe charges me 2.7% plus whatever.

[00:28:44] Okay, cool. I can charge like a fee for invoice processing, right? Like. That's pretty like cut and dry. Like I don't understand how that works. When I'm storing funds, you know, I can make some float interchange interest maybe I can like give you some like credit cards or debit cards to spend and I can make something called [00:29:00] interchange on those cards.

[00:29:01] But then when you get a invoice for a thousand dollars, you gotta pay a thousand dollars, right? Like there's no middleman to take a fee there. And so I like think a lot of people are like, there's no opportunity here to like, monetize the payments. Maybe I can charge like. Some SaaS fees, like 20 bucks a month or something to my customer to like have them manage their bills through my system.

[00:29:22] But kind of the secret here is that all these big account payable companies have found is your customer who's using your product, really wants to keep cash with them as long as possible, right? But the folks they're paying wanna get paid as fast as possible. So we basically have a mismatch in, in incentives here where.

[00:29:44] The payer wants to hold onto money as long as possible, and the vendor wants to get that money as fast as possible. And so you can offer financing on both sides of that equation either accelerating the payment to the vendor or delaying payment from the payer to help both sides manage their cash flow.

[00:29:58] And that's really [00:30:00] where the unlock comes in on monetization.

[00:30:02] Mike Bifulco: Oh, super interesting. So you're, you're running financial mechanisms underneath this then that people are keying into on both sides. Really cool. Wow. And so, man, I, I that's a part of the world that I know enough about to be scared of. Does this mean you also then had to go chase down, I'd imagine compliance and certification and all sorts of things to be able to offer those.

[00:30:20] What's that journey look like?

[00:30:21] Sandeep Dinesh: Yeah, so I think we have a lot of flavors on how we do this. So right now we're using a lot of partners to kind of do those services. And so our big value prop is. one is gonna take your fancy financing product until they have a workflow that matches what their accounting and finance teams really want to use.

[00:30:38] Right? So we spent a long time kind of building those workflows, those react components, those backend APIs so that you can deliver a product that'll actually be used, right? Because if you just have like a. Pick a financing button, like it's not really, it doesn't fit into that workflow. So our first step is kind of building something that your customers will actually use.

[00:30:57] And then we work with a bunch of vendors to provide [00:31:00] that financing, to provide those payment rails. And eventually we'll bring some of that in-house. But I think our big value prop is we will go ahead and integrate with all of these platforms. And so then you just have one API to implement, drop it in, and then you get best in class payment rails out of the box.

[00:31:15] Mike Bifulco: Yeah. Nice, clear story there too. That's fantastic. Okay. I do wanna ask, maybe the inverse of the question I asked before is you know, what, why would an API developer recognize that meco is something they should be interested in? I also think there's a good number of people that listened to this show that may be sitting in shoes similar to, to yours from a year or two ago, where they may be getting signals that they're.

[00:31:36] Experiencing things or learning things at work or seeing problems that might make their way into a good company at some point. Do you have any advice for people like that? For how to test an idea how to, how to prove something out as a business

[00:31:48] Sandeep Dinesh: That's a great, great question. I think experiencing that pain yourself at a big company definitely a good sign. You know, at Google and Stripe, we have so many internal [00:32:00] tools that like I wish existed outside. Good, great example of that is, you know, both companies have like a launch process that you had to go through to launch anything public. And it's pretty, it's, it's, it's one's process, but it's like really well thought out. Like on the Stripe side, like if you do anything that touches an API, someone from the developer relations team will come review, make sure it's consistent across the board. So like that kind of stuff, like is there a product that you could build externally?

[00:32:25] There's also really simple things like, I think there's a company called Go Links. We use 'em at mea I think like Google had that originally. And it's a whole company now where you just like go slash and you put a link name in and then it redirects you to a page and it's so useful and you're like, I had this at Google now I don't like, let's go build a company about this.

[00:32:41] And so I think like, how do you validate? That was kind of the question that you asked. I think having it yourself is great. And then going to, talking to your friends, going and talking to your people in your network, right? Like if you're an engineer and you're building a developer tool, I'm. I think you probably know some other engineers, like either work at your company, [00:33:00] work, went to school with you, you worked previously with Met at a meetup.

[00:33:04] I don't know. Right? Like, but you probably know somebody, so just go talk to them. People like talking about their problems. I think that's something that especially first time founders are really afraid of. They're afraid of getting, being rejected, being like, I have this great idea. I don't wanna talk to anyone because what if they say, say it's bad? And for me it's like, that's the best thing then I don't know how to waste my time building this thing anymore. Right. Because you know, it's so easy to burn out building something that no one uses. Like you can spend years and years and years. Building something and then you launch it and then you, it just crickets and then it just feels super bad.

[00:33:37] And then maybe your next idea is gonna be the billion dollar idea, but you're just so tired from working on something that no one used that you don't even try it out. Right. And so my advice to anyone kinda listening who wants to dip their toes in startup is just talk to people. Validate it. Get your idea in front of as many people as possible.

[00:33:55] No one's gonna steal it. In fact, they might give you ideas on how to make it better. Right. And [00:34:00] honestly, being part of yc something like that I didn't realize before I joined was, you know, it's a filtering function for really great founders and we're, we are fully in person in San Francisco.

[00:34:09] There's a lot of other YC companies here too. There's a lot of events where we meet up and I think talking to other folks, they give us ideas that we're like, oh my God, this is gonna. I didn't think of this. This is like a easy thing, low hanging fruit that just unlocked like some like big win for us, right?

[00:34:26] And yeah, just sitting in your, in, in your room coating is not going to to help you. You do have to do that. A lot of coating, but you also had to get out there. Yeah.

[00:34:37] Mike Bifulco: Yeah, that's, I, I will pile on and add to that, that at some point it's not about coming up with good ideas, it's about being able to execute on them and identify the problem space that matters. And one thing that I wish, like I get a lot of folks who ask me questions about starting a company or they wanna talk about an idea they have.

[00:34:54] And I, I always wish I could talk to people like a year or two or three or four before they, they start with [00:35:00] pursuing a business to, to plant a seed with, with you, whoever you are, wherever you are, that one of the most important things you can do is learn how to find. People find the network, find the problem space, get embedded in the conversation.

[00:35:11] And for a lot of developers who are maybe a little more introverted or you know, reticent to communicate openly online that creates a problem. If, if you woke up tomorrow and said, I wanna start a startup, and you have. No you know, no following on LinkedIn. You don't have a public GitHub, you don't have a website, you don't have anyone who you talk to about these things.

[00:35:28] You're starting at a massive disadvantage. So I'm not saying you need to go and be an influencer, like, I don't even think that's even remotely the answer, but I do think you should be able to participate in open source, right? You should be comfortable with jumping into GitHub conversations, looking to Reddit for answers, helping people out diving into things and, and learning.

[00:35:45] And you'll start to knock out the bad ideas just as well as meeting people who have really interesting, good ideas and. Don't have time to pursue 'em, you know?

[00:35:52] Sandeep Dinesh: Yeah. I think just to add on to that one, if, if you're doing a startup because you were like, I wanna try a startup, may, maybe not the best reason. [00:36:00] I think like

[00:36:01] Mike Bifulco: Yeah, yeah,

[00:36:02] Sandeep Dinesh: the, to your point of like being in these communities, like you probably wanna care about this problem enough that you're already there or like.

[00:36:10] You want to, you like, you naturally want to go and like help those folks. And then like the startup comes after, right? Where it's like, oh, I see there's a bunch of people to help. I can probably build a business to help these people. Then it kind of makes a lot more sense versus like, I'm gonna take this and shove it down their throats and make them buy for me.

[00:36:28] Maybe not the best way to do it.

[00:36:31] Mike Bifulco: For all but the most extreme outliers, your startup idea at best will take 10. 10 years, right? You'll be working on a problem and it has to be something you can be interested in for that long. I. Odds are, it's probably already something you're interested in or at least related to a problem you've had that would, would make life better.

[00:36:46] Otherwise you're you know, punching from the back foot or whatever the phrase is there. Sandeep be, before I let you go, I want to hear a little bit about what's coming next for Meco. So what are you working on now?

[00:36:56] Sandeep Dinesh: Yeah. So we are relaunching our React documentation. [00:37:00] So stay tuned for that one. We're pretty excited. We're. Always trying to improve our developer experience. So that's a big one. We have a few cool payment partnerships coming out too, so hopefully we'll be announcing that. But yeah, aside from that, you know, just come check it out.

[00:37:13] If you are at all interested in FinTech APIs developer experience send me a note on LinkedIn or Twitter. Happy to chat. However I can be helpful, I'm happy to help.

[00:37:25] Mike Bifulco: I appreciate that. I will make sure I put both your LinkedIn and your Twitter profile in the show notes here for folks to find you. And where's the best place to find Meco online?

[00:37:34] Sandeep Dinesh: Mea.com. This is a, it's, it's exactly how it sounds. It's spelled M-E-R-C-O-A. And then we do a lot of content on LinkedIn. So we're gonna start doubling down on that as well. So if you want any of our content, you can probably find it there. But yeah, our website is probably the best place.

[00:37:50] Mike Bifulco: Amazing. That will obviously also be in the show notes Sandeep Dinesh from mea. Thank you so much for chatting with me. I really appreciate it. It's been fantastic to learn from you and really cool to hear about your story. Feel [00:38:00] free to join us anytime to give us updates on where things go between now and then.

[00:38:04] Sandeep Dinesh: Thank you. Yeah, Mike, this was great. I had a great time, so I really appreciate you having me on.

[00:38:08] Mike Bifulco: Of course. Take care.

[00:38:10] Sandeep Dinesh: Thanks.

View Details

Chapters* 00:00 Introduction and Guest Introduction * 00:52 The Future of Voice AI * 01:56 Wapi's Elevator Pitch * 03:27 Challenges and Opportunities in Voice AI * 05:11 Building Voice AI Solutions * 11:00 The Genesis of Wapi * 16:39 API Design and Developer Experience * 21:23 Docker vs Kubernetes: A Developer's Perspective * 22:28 Hello World with Wapi: A Hands-On Experience * 23:34 The Developer Experience: Making APIs Accessible * 26:09 The Future of Dev Tooling with AI * 28:43 Use Cases and Real-World Applications * 33:23 Technical Deep Dive: Building with Node and Kubernetes * 37:59 Team and Future Plans * 39:15 Conclusion and Final Thoughts

Show notes* vapi.ai + github + openapi spec + twitter + linkedin + blog + docs

hyperbound.ai - call bots to practice selling

Transcript [00:00:00]

Introduction and Guest Introduction

[00:00:00] Mike Bifulco: Welcome back to APIs you won't hate. My name is Mike Biko, one of the co-hosts of the show, and I am sitting down for an interview this afternoon with someone who I'm really, really excited to chat about. You, you may know if you've been listening to the show long enough for hearing me p along on the internet for long enough that I.
[00:00:15] Worked for a while on the Google Assistant team in the world of voice tech and voice software and the land of assistance and iot and automation, all that stuff. That is one of the reasons that I'm super excited to, to chat with this founder. And the other reason, of course is that Nikhil Gupta is joining me from Wapi.
[00:00:31] He's. Also a Y Combinator founder. So we're, we're we have many sort of related parallel lives seemingly going on here. I'm super excited to talk about what you're building. The pitch on the website, the, the H one on your site says Voice AI for developers, which I think paints a lot of story for a lot of people listening.
[00:00:46] But Nikhil, thanks a ton for joining. I appreciate you being here today. How are you doing?
[00:00:50] Nikhil Gupta: Thanks for having me, Mike. Excited

The Future of Voice AI

[00:00:52] Nikhil Gupta: to chat about Wapi and so curious to hear kind of the stories of voices like Google Assistant and what's happening [00:01:00] there Now, everyone but everyone is wondering now too, if you have any needs to share with us that would be great. And it's super fascinating the, the whole world around us, just like. It's gonna change, right? Like the way we talk to com, like the way we interact with computers, the, maybe we interact with like microwaves. I think that's all about a change in the next like five years. I like the fabric of like interaction. And I think that was pretty clear to people when they saw that G four oh demo. So it
[00:01:26] decided to get into it. Yeah.
[00:01:28] Mike Bifulco: of course. Yeah. So we're, we're a couple weeks out, out from GBT four Oh which is the O stands for O Omni. Channel Omnis Omni. Yeah, just omni in general. So this is the first like multimodal GPT from OpenAI which I think has really changed the way a lot of people are thinking about the software.
[00:01:45] And, and so we're definitely in a changing landscape, especially since, so I, I left Google Assistant two years ago at this point. And at that time things were very different. But before we get into that, let's start with you here.

Wapi's Elevator Pitch

[00:01:56] Mike Bifulco: Give, give me first of all the elevator pitch for, for Wapi. What's [00:02:00] the, the, the story?
[00:02:00] What do you sell it to people as?
[00:02:01] Nikhil Gupta: Yeah, sure. The elevator pitch is, yeah, voice effort, developers. The you wanna add voice spots to your phones, website apps, we provide like a modular interface that's easy to use, easy to configure, and get you up and running very quickly. The, the, the, I guess like the, the, the favorite thing for developers is like the modularity of it. You don't like open ai, you wanna use Entropic, you can use Entropic. You don't like 11 Labs. You can use play hd. There's like different options for like transcribers hey, you want to like integrate, like make Zapier, like tools, like multi assistant, like all that kind of configurability that I think exists a lot out there for like chat you can bring to voice. And the future I guess, is pretty clear to people, right? When you call into a restaurant, most likely you'll be talking to an ai, and that's kind of what we're building. The, the, the bricks and pieces the [00:03:00] shovels to help you get that up and running in a day, in a couple hours instead of like months.
[00:03:06] Mike Bifulco: sure. Something that would've sounded like an absolute miracle just a few years ago, maybe even a few months ago. If you think about it,
[00:03:12] Definitely compelling for, for anyone working in a world where your end users are especially consumer focused. I'd imagine there's lots, lots to be said there, but in service industry, that's really interesting.
[00:03:22] And customer service of any sort myriad use cases for that. That's, that's super cool.

Challenges and Opportunities in Voice AI

[00:03:27] Nikhil Gupta: I mean, I think one thing I want to highlight there is like, I think everyone dreads like calling into United, right? Like, like at t, like tax like IRS, but I, it's pretty conceivable that we would love calling them in the future. Because they, they'll be like, they have like such great ai, they're so patient, they have so knowledgeable and you just call them in and like they can immediately answer like, what's happening with their flight?
[00:03:51] Like, can they like cancel, move it around. So there is an interesting kind of change there too. Like one, the experience improves, but does it also [00:04:00] mean like the, the world went from like phone calling to like chat
[00:04:03] because like these, it, it's very expensive for these companies to like host voice experiences because it, it involves humans in the background where it's like chat could be more structured. And now it's like what is the inherent desire for people? They wanna do, use a voice or chat. But that I think is also gonna be interesting in the future where you can just call into at t and it'll be like a great experience. Which is weird to think, but it.
[00:04:29] Mike Bifulco: Sure. Yeah. I love the one word you used there, which is really interesting to me, is patience. Like having an operator on the phone who's patient is kind of also a pretty big game changer. I, I don't think people think of it this way, but usually if you call in customer support somewhere, or even if it's a restaurant for example, you call in and speak to someone.
[00:04:46] They're a complicated person with a busy day and probably lots going on, and you're almost certainly not the first chat they've had that day and. I would imagine many customer service people have had negative experiences just about every day with someone who's mad about something. And the nice thing about [00:05:00] building a voice agent programmatically is that they don't get tired.
[00:05:03] They might not experience that, and if they're kind and polite and all that, it really changes the way that people interface with things. That's super interesting.
[00:05:09] Nikhil Gupta: I, yeah. Yeah.

Building Voice AI Solutions

[00:05:11] Nikhil Gupta: And maybe I can talk a bit about, like, you know, right now, if you were to kind of try to create this future maybe you wanna build a company, maybe you wanna build, like a small agency or maybe you're a small business, like there's kind of different personas here of like who would, who would wanna use, like why ai? There's a couple options, right? Like you can take 11 labs deep Graham and open AI off the shelf and like try to switch them together. That process will take you at least a couple weeks, like if not months. Once you have stitch it together you would have to kind of figure out how to like scale that system because these are what's interesting about like multimodal and like, I guess voice specifically as soon as you enter like rounds outside our text is these are stateful long lived jobs and maybe this
[00:05:58] technical center, but. [00:06:00] When you hear stateful long lived, I think that's like alarm bells go off for people. It's like, oh, that sucks. Like, it's like, but that's the reality, like where these GPUs are running, which contain the context of the conversation. So ultimately when a person is calling, they have to be pinned to something like a resource in the backend.
[00:06:20] So scaling that out as a system is like a very complex undertaking, and that's kind of the value we bring in where if you harken back to like. Twilio or Stripe, right? Like early days payments could be done where you just had to fill like this ENT form with like Wells Fargo and like you could get set up like to accept payments on your website. Same for like Twilio, like if you wanted to send a text, like it's totally possible you could. Had a contract with like Verizon at and t. But Twilio just offered like, here's an API give me the number you wanna call, gimme the text you wanna send them done.
[00:06:55] So that kind of ease of use is what we are trying to bring to like [00:07:00] voice AI world where here's the number I wanna call, or here's my number and here's the position prompt I wanna use. And that's it. Done.
[00:07:09] Mike Bifulco: I, what I love about this is that it represents such a big change for, for this world. So clearly I'm gonna go pretty, pretty deep and nerdy on the, the things that have changed in voice tech in the past few years. But thinking back to the dawn of the first voice assistants the I, I'm reticent to say their names on a recording because I'll kick off actions on people's phones around the world.
[00:07:29] But you know, Apple's, assistant and Amazon's and, and Google's are all the initial programming interfaces for those were almost quite literally like, imagine a tree structure for the types of conversations you want to have and build that tree for everything anyone could possibly say. And have escape hatches for everything.
[00:07:46] And that's changed so dramatically by now that AI is way, way better at picking up with the context of the conversation and inferring things. And even like if you stutter into an ai, it won't freak out. It can understand that as well. It's, it's super interesting and you [00:08:00] really are at the dawn of something where people can build very compelling things without a lot of work without having to catalog the whole conversation.
[00:08:07] Nikhil Gupta: Yep. Yep.
[00:08:08] It's exactly like, that's, I think, the common thing we hear. So there's it, it's, it's interesting because like when we started Vai about a year ago, we were doing something else before, and when we started Vai, we were expecting that there's a new platform being built kind of the same way that iPhone kind of ushered in this like apps era.
[00:08:27] And then no one predicted like Uber would be the thing that like. Was a killer app. We were expecting like voices capability, that thing unlocked as a platform. There would be like some really cool apps. And I still believe that, you know, like there'll be completely crazy apps, infrastructure like applications out there that are voice experience based.
[00:08:46] And I think we are seeing that in learning a little bit. They're, they're hitting multimillionaire or I know they're hitting like. They're on track to hit like, you know, a billion dollar companies or multi-billion dollar, even ars. But that was like our kind of [00:09:00] pieces where we wanted to. I'll be this kind of infrastructure for this new platform where a lot of like new experiences are gonna be formed around voice. But the, to tie in what you were saying, oh, a lot of use cases and surprising amount of like volume, like an insanely large volume exists in like the old world of telephony. And. In like systems that people are built, like people have like teams of like 5,000, like they're designing like these like flows, these conversations. And clearly that's like shifting to like prompt, like here's the system prompt. And making better bots faster is like a, is a thing that resonates with like this crowd of like, telephony, which we are seeing a lot of adoption is I, I feel like, I don't know, I'm like hopeful. I really want, like, new experiences, new interfaces.
[00:09:51] That's why we have like, for example, like a Python, SDK, but you can like, set up like a AI toy with, it's not used
[00:09:58] as much as like [00:10:00] the polyphony stuff, but like I would love for that stuff to come. You know, as things happen.
[00:10:06] Mike Bifulco: Some of this I feel like people need to, I. Come to the understanding that there is this like creative space where, where you can build things. Now that used to be much harder to do. And the fact that someone could pick up a Python, SDK and in a few hours build a pretty impressive demo is like not necessarily obvious.
[00:10:23] Even if you've used chat GPTs, you know, new, new audio features in the interactivity built into that from their app, it, it still feels kind of like magic is happening on your device. It's, I feel like it's that new, you know.
[00:10:34] Nikhil Gupta: it could be, it could be, it could be the, the, just the newness of it. I also wonder like how much of it is like there's a bit of like stasis, I think because open air is moving so fast
[00:10:42] that people are like not sure what to build because AJ is around the corner, right? Like, what would be, what even is the point of like building anything.
[00:10:49] It's totally fair. But like at the same time, everyone knows there's like so many huge opportunities. I'm just like not seeing them being capitalized as I guess as much which is, which is interesting.
[00:10:59] Mike Bifulco: let's [00:11:00] take a step back.

The Genesis of Wapi

[00:11:00] Mike Bifulco: You mentioned a minute ago that, that you're only about a year old into building this product, or you've only been building it for about a year. Can you tell me about how Vapi got started, like what you were doing beforehand? Where and, and what was the genesis of all this?
[00:11:13] Nikhil Gupta: Yeah. Yeah. So we were building ai, meaning note taker and it was called Silver Power. It was great. Hit profitability and we kind of realized the next milestone for us was like to get it to like 10 mil error, which is the usual, you know, milestone when you hit that kind of number. And we just, like, we didn't wanna spend our twenties like selling meeting software. It
[00:11:37] was. Not the most challenging not the most like forward-looking impactful thing we could be doing. We just felt like there's like a bigger technical challenge we could take on and that like we were engineers and like, we just love technical problems. So started stumbling around on like finding what we could do. The, this my co-founder one day in his. [00:12:00] Depression of like pilot pivot, depression made this thing because we over like like over the course of like our startup, we have spent around like 30 to 50 KI think on like coaching, like founder coaching. We
[00:12:13] started at the company when we were like right outta college immature. Didn't know how to work with emotions, communicate the, the usual thing of like founder complex and worked with a coach who was saved our company. Like he helped us articulate what we need from each other and
[00:12:32] worked through ourselves and our own mind, and that that coaching was transformative. So transformative.
[00:12:39] We were like, oh, that, like when, so my co-founder Jordan, he created that same experience basically with an ai where that AI could like help him. Reflect back his thoughts, his emotions, kinda like a Yeah. Therapist.
[00:12:52] The experience got better and better. But ultimately we realized there's still like, like the company that's focusing, that's focusing on like, [00:13:00] making this experience better. It needs to be that needs to be the company itself. Like we cannot take out the problem of like making a great voice experience and making it like a great therapy. But, those have to be separate companies. And we are like, oh, that's actually kinda great because we are, we love technical, we are technical, we love technical problems, we love technical customers. Like we, we just wanna work with startups and like really technical people. That it was just like a perfect alignment where oh yeah, like this is, this feels right, like making APIs that feels right for people.
[00:13:32] And that's how we got into it.
[00:13:34] Mike Bifulco: sure. Yeah. I think, I think especially if you've had some coaching around like trying to reach scale and get to a point where if, if at that point you had taken on investment, like you really need to tackle some gargantuan problems. And to your point before about not wanting to spend your twenties selling meeting software like.
[00:13:52] You would need to sell all of the meeting software to really hit the scale that a lot of investors are looking for. And that has happened, right? Zoom certainly had a, a bit of a rocket [00:14:00] launch over the past few years, but you know, how many times can that happen? And almost the meta problem here is, is also really interesting too.
[00:14:06] Yeah, that, that's really fantastic. I.
[00:14:08] Nikhil Gupta: Yeah, you're right. Like there's like, you know, something about like the space you're in which limits, like, what you can do as a feeling. I, I do find like, I, I, I go between my, in my mind between, like, I think the, the tam is never the market. The tam is the founder, which is like,
[00:14:23] but you wanna just keep finding new ways to like, go, like expand Tesla, you know, like robotics now it's like, it says random as hell. Like SpaceX became starlink. Cool. So I, I do find like the tan isol as a founder, but yeah, like focusing, like for us it was just like, we wanna spend our time solving hard technical problems and offering great experiences for developers.
[00:14:45] Mike Bifulco: There's a lot of wisdom in your words. It sounds like you, you've probably been through, like ingested the coaching in a way that was really healthy and have lived through a, a hard pivot with another founder. Having been down this. Startup wrote a few times myself. I've had the good, bad and middle experiences [00:15:00] of, of you know, many lifetimes I feel like wrapped up in building startups.
[00:15:03] It's always interesting to hear someone who, who acknowledges that challenge as part of building the, the company too. That's, that is a big thing that we don't talk about a lot in general, I think.
[00:15:13] Nikhil Gupta: Oh yeah. I mean the, we've been trying for like four and a half years now. Like at it,
[00:15:20] We were Winter 21.
[00:15:21] Mike Bifulco: Good for you.
[00:15:23] Nikhil Gupta: It is kind of, I, I, I mean, I think there's something to, like, something to, like, I think PJ and Michael, lets to say this where pg where it's like what sometimes like founders are founders because they don't have anything else to do.
[00:15:38] Like I, I don't know what else I would do.
[00:15:41] Mike Bifulco: Yeah. Agreed.
[00:15:42] Nikhil Gupta: yeah, so, so we just gotta figure it out. That's, we
[00:15:47] had another choice but to figure it out and that's where it's been a lot of fun. So I think for people, I guess kind of wondering, like develop, I'm guessing obviously very technical, wondering like what to do.
[00:15:58] I, it is, [00:16:00] I guess like the, the, the seed, the seed of like, that feels so good. I know I'm spending my time serving people I like a lot.
[00:16:11] And that is enjoyable in itself, like no matter what happens to Wapi. So that like the feed of advice that people give around, do keep doing the things you really like, that you feel like especially passionate about.
[00:16:20] And like that the moat or competitive advantage will come from that because you
[00:16:25] just have like so much experience, like so much love for that thing. So much love and serving that thing.
[00:16:30] So that's been
[00:16:31] Mike Bifulco: It has to be a, a problem you can care about for 10 years, you know, not just a, a 18 months or something like
[00:16:36] Nikhil Gupta: yeah, a hundred percent. And like.

API Design and Developer Experience

[00:16:39] Nikhil Gupta: Like the, when I think about like, the common thing I hear, and maybe this could be a bubble, is that people love our API. It's like people
[00:16:47] love, like the design of it. It's like it's easy to use. It makes sense. The validation is great. And that's just like, I'm like really in know about like the little details where like it
[00:16:57] has to be like, for example, like. [00:17:00] Singular, not plural. Like it has to be like consistent in this format. There has to be like the same crud interface to all of these things. It has to be a noun. Like all these best practices that I'm sure people that I'm talking to here know about. But it's like, you know, it's surprising to me when I look at other APIs, it's like, just like, what was the design process here?
[00:17:18] Like, what the fuck was going on in that head? Like making this interface like, like makes no sense to me. Where. Having this opinion of like a good developer experience, like really caring about that gives me joy. So that
[00:17:32] I've been a lot of fun
[00:17:33] building.
[00:17:34] Mike Bifulco: you and I are just meeting for the first time, but I came into the world of APIs by way of studying user user experience and human computer interaction. And so being, being deeply embedded in the world of design, one of the things that I often say to people is that learning design is interesting because anyone can learn it.
[00:17:48] It's not something you're born with,
[00:17:50] but the curse of it is as you learn these rules and as you learn the, the. Things that break the rules. You see it everywhere, right? So like by focusing on building an API that follows all these [00:18:00] rules and uses plurals correctly and is thoughtful about the way interfaces are presented, you start to see all of the inadequacies of your own product, also other products.
[00:18:07] And they become more and more like little red irritations across your life. And,
[00:18:12] Nikhil Gupta: Yeah.
[00:18:12] Mike Bifulco: it's a blessing and a curse I think.
[00:18:14] Nikhil Gupta: What's your favorite API you think out there?
[00:18:16] Mike Bifulco: So I'm, I'm definitely biased here because I also used to work at Stripe, so I was on the Derell team there.
[00:18:21] Nikhil Gupta: Yes. Fair.
[00:18:22] Mike Bifulco: obviously Stripe is the gold standard in many ways to work with. And I've, I've, you know, through the course of my career, especially working in developer advocacy for a while, played with many APIs, small and large to kind of build demos and show people how to do things and.
[00:18:36] I think a a So Stripes, API is wonderful. The documentation is incredible. The team is top notch, like super cool to see, but there are also smaller companies making things that are really interesting to use as well. Lately I've been looking at weather APIs for various purposes for my current company for craft
[00:18:51] Nikhil Gupta: Yeah, yeah, yeah.
[00:18:52] Mike Bifulco: the most thoughtful APIs that I encounter are ones where I don't have to become a meteorologist to understand how to use it. And that's, that should be the bar for everything. Like [00:19:00] my, my lowly self should be able to get to your API and understand what's going on, you know?
[00:19:04] Nikhil Gupta: Yes, yes. Yeah. Yeah. And like yeah, like that's. Also would love to hear from people. It's like, like I always wonder like when people show up, like like we have a swagger, right? Like they show up to this. Does everything just make sense? Like it just, if you
[00:19:17] just to look at the top level concepts that exist in the API, does everything come together? Yeah. Strip is great because you don't strive is very painful, but it rewards you like you go through the pain
[00:19:28] and because it's so complex. But everything kind of does make sense. I think that's like where. A lot of like teams like lose, I guess, like you, the more complexity you add can everything still seem coherent? Like as, as you learn? Does the world, does the world of your, does your world make more sense or does they make less sense because there's contradictions everywhere, like different ways to do things? Or is it just like there's one way to do thing and like, yes, it's very complex, but like if you learn everything, it'll make sense.
[00:19:59] Mike Bifulco: [00:20:00] Totally.
[00:20:00] Nikhil Gupta: does a great job. Great job of that for sure. I, I think there's something about like probably like, I don't know if like AWS counts, but I think a Ws
[00:20:11] is like is also kind of the same thing where, pretty complex, like very hard to work with. But like once you learn it, it's pretty okay.
[00:20:19] Everything makes sense. Actually, you know what my favorite API is Kubernetes.
[00:20:24] That's, that's Kubernetes? Yes. Kubernetes. I, I might even say I like it better than Stripe.
[00:20:30] Mike Bifulco: Oh, that's interesting. That's a new take for me, for sure. Yeah.
[00:20:34] Nikhil Gupta: It is, I find like the documentation when you read through it, like they, they read your mind. I think maybe that the problem is that Stripe has too many customers.
[00:20:44] Mike Bifulco: Hmm.
[00:20:44] Nikhil Gupta: So when, when you, when you enter Stripe documentation, like they're trying to walk you through how to handle like subscriptions, they're trying to walk you through how to handle the invoicing. They're trying to walk you through how to handle usage based billing. And they try their best and it's [00:21:00] great. Kubernetes, you enter the doc and they'd already know what you're trying to do. They know that you're
[00:21:05] trying to deploy something that can scale, so they talk you through different concepts. Like the first thing they'll talk about is here's pods, here's services. If that's, it's just the documentation gives me joy reading it,
[00:21:19] like I, it's a conversation with like, the person who wrote it is
[00:21:22] awesome.

Docker vs Kubernetes: A Developer's Perspective

[00:21:23] Mike Bifulco: I, I wonder if you'll think of this as a hot take. But I, I see Kubernetes documentation and the, the way that they describe things in stark contrast to the way that Docker's developer experience is and was for a very long time. My, my feeling on Docker and figuring out how to make Docker work for, for a really, really long time was Docker can't tell you what Docker is, and you have to figure it out by trial and
[00:21:45] Nikhil Gupta: No. Yeah, I think Doctor has excellent like dev interface, like, you know.
[00:21:51] Mike Bifulco: Yeah. Yeah.
[00:21:52] Nikhil Gupta: Docker form makes it really easy to like, get things up and running. Like Kubernetes is harder to get up and running. But yeah, like, and [00:22:00] Docker logs for example, like everything sort of works, but yeah, like it's, they have no clue what they're doing.
[00:22:05] It's kind of the vibe that you get for sure.
[00:22:07] Mike Bifulco: Right. Yeah. You, you kind of have to know that Docker compose and docker's form exist to be able to figure out what they do. And it's not obvious what either does, you know, from the name alone. So let's talk about your, your use case.
[00:22:19] So you've, you've spent all this time building a, a great API. What is it like to use wapi? Like, what, what does hella world look like?
[00:22:25] Nikhil Gupta: Yeah. The hello world is and I'm curious to get your thoughts on it.

Hello World with Wapi: A Hands-On Experience

[00:22:28] Nikhil Gupta: The hello world is you go to a dashboard, you don't even touch the API first, right? You go into the dashboard and the first thing you'll see is like and prompt to create an assistant. And you, you select like there's some templates options there.
[00:22:42] Like, Hey, I wanna make like a game NPC, or I wanna make like a customer service. I wanna make a, on my scheduling. You click one of those assistants, you get a template, and after that one click you should be able to, there's a button, right, that will show which like talk to assistant. And that is like [00:23:00] kinda the hella world there.
[00:23:00] It's like you have quit an assistant that you like. And you can talk to it. And the, what you'll see front, right front and the center is like, what's the configuration? Configuration of the assistant. It's like, oh, like my name is not Domino's. My name is like Pizza Hut. You know? It's like, welcome to Pizza Hut.
[00:23:18] Like that's changing
[00:23:19] that, that, that should give you the first like satisfaction of like putting, cutting the system and being able to talk to it. Then you, you know, the dev experience, which is like, okay, where do you wanna put this assistant? Do you wanna put it on a phone number? Do you wanna put it on your website?
[00:23:32] Do you wanna put it in your app?

The Developer Experience: Making APIs Accessible

[00:23:34] Nikhil Gupta: I guess like that's where APIs and the experience, like dev experience enter. I haven't figured out the hello world for it, but that then you would go to our documentation and then they're kind of like. It's like, you know, choose your own journey.
[00:23:46] It's like I'm gonna create a phone number. Then you go to this doc, you wanna create like a put on a website, go to this doc.
[00:23:52] Mike Bifulco: I think it's an interesting case because there's a lot to be said for being able to just poke around with a thing and try it, especially with the case of what you're [00:24:00] building. Kubernetes is a great example. If I know that when I get the API calls correct for Kubernetes, that I'm going to have something that does all this nice orchestration for me, and the, the outcomes of that are clear from the onset.
[00:24:11] But for the product you're building, the outcome is like. A little more ambiguous and perhaps less clear in that, okay, if you execute these calls correctly, you now have a voice service. Is that any good? Right? Like the first thing you need to sell is, is the outcome of all this dev work going to be valuable?
[00:24:25] And I think inverting the experience in that sense is honestly probably a really good choice.
[00:24:29] Nikhil Gupta: That's like smart. Yeah. That's pretty smart observation. I've never thought about it that way. All I know is like as a developer, I think the thing that probably like now I know like I have to do Stripe, right? But like, I, I, wish Stripe just gave me like more joy, like before I even get started, like, do I, will
[00:24:46] stripe even work for me? I think it takes me a long time to figure that out, that answer to that question for most dev tooling. Whereas I think we are trying to answer the question like, yeah. Bobby, will this work for you? This is, here's a assistant, and then it's your, the, the job is to [00:25:00] just figure out how to like, get that assistant in the right place that you need, which we have all the AP ideas for.
[00:25:05] But that I, I think about the law too where like, it's like, what is like in my, like where dreams, like what would I love as a developer from this experience? You know, it's like, what is like the, the, the most beautiful, amazing experience coming into Wapi? I don't have an answer to that question, but like, yeah.
[00:25:21] The hello world is don't code. Just go in,
[00:25:24] try something and then if it looks good, get, get, get cracking.
[00:25:29] Mike Bifulco: I think it's pretty compelling, and I, especially for this audience that we're talking to. So for API developers, you get two things out of the box before writing your first line of code. One is you can go and try the thing, right? You, you go to the dashboard, do that, do your own experience. But naturally, I think most of the people listening to the show will also go to your API.
[00:25:47] Reference, right? Go to the docs themselves and see what's there. And like, there's a lot of good, juicy stuff in there that's, that in itself is exciting. And you can kind of see some of the thought and, and usability that comes outta that straight away. And to your credit too, there's a handy [00:26:00] little button on a lot of pages on your site, maybe all of them that says ask ai where you can maybe get some answers, some questions answered pretty directly too, right?
[00:26:07] Nikhil Gupta: Yeah, that's awesome.

The Future of Dev Tooling with AI

[00:26:09] Nikhil Gupta: Like too, where I think now this like dev tooling, like, like there's, so, I think there's gonna be so much, like, so much rich experience around like dev tooling because a lot of it more, a lot more can exist thanks to like ai. Like,
[00:26:23] like before, I think like if I was to think about like integrating a new API, it'd be like, oh man, I don't wanna figure out the documentation.
[00:26:30] It just seems like insane. Like, that sounds like a lot of work. Now I can go to the documentation, talk to the AI and be like, okay, like I need to do this. Can you gimme the code for it? It gives me the code I just put in my code. Like that
[00:26:40] is transformative.
[00:26:42] I think to like composing, like composable APIs, I think we're gonna see a. So many APIs, I think in this like next, like two, three years it's pretty, pretty exciting for me. But yeah, I think for people like, who are considering, I guess like yeah, like what would [00:27:00] for API builders, I guess, like the question you, the reason, the way you would, the reason you. It's like, maybe you should ask yourself if, like, what are you trying to build?
[00:27:09] Like, are you, A lot of our users are startups, right? Because they're trying to explore prototype, whether they wanna sell into like a small, like a particular niche, like Vertical sa or I guess like the, like everyone knows Activity four Oh will be everywhere. Like that experience that this showed, I think that's going to be in every phone. Every microwave, every car those
[00:27:33] assistance. So now the question is do you wanna bring that experience? Do you wanna help get that experience deployed in different places and you can wait for four to come out, or you can use to get started on that right now. And then when we do have gbd four, we'll just plug it in and then you'll just have, won't have to do any work to switch it over. And, and then I guess it is for us to figure out like what other value we can add, [00:28:00] which will be like observability, tooling. Like you feel like a million calls that you're doing, are you gonna really use like the raw for opening API or are you gonna use like. Some production ready tooling around to make sure that your calls are going well.
[00:28:16] There's a visibility, tooling, but that kind of thing is I think people, what people would use this for and that's what we are here to provide. So yeah, I think I'm drawn to people like if you think voice cool. If you think multi model is cool, give it a try. Like make something prototype. It's so easy to prototype nowadays.
[00:28:33] Mike Bifulco: Sure, yeah. The imagination should run wild and, and go build the things that you definitely wouldn't have been able to, you know, in 2022 or, or however you wanna look at that.

Use Cases and Real-World Applications

[00:28:43] Mike Bifulco: Can you tell me about maybe an interesting use case or two that you've seen? With api, I.
[00:28:47] Nikhil Gupta: sure. I can tell you the UCSA. Yeah. WC this is our first customer that we worked with. They do sales training. They're called hyper bound. And you can go to their website. It's really fun. It's [00:29:00] called hyper bound. I don't know the actual domain, but so hybrid, it will show, it should show up and you can call these boss to practice selling. So the founder, you can imagine, like, it's pretty learning how to sell is like a pretty key skill and pretty hard. You can practice on real humans, but then you're leasing losing real deals. So with practicing these bots, and these are bots are really hard to sell to. Like they would like hang up you on you all the time. So that, that's an interesting kind of role play is a very interesting use case that we see where like having AI to represent like hard conversations, having represent like sales training. So that's like one category. The other one that's pretty obvious is customer service, where people call into this, this restaurant, it's like, I want pizza here, or I wanna book a reservation.
[00:29:46] Like, here's an availability for the reservation. That kind of like function calling, tool, calling use cases are another, what are other popular ones?
[00:29:55] Mike Bifulco: I am. I'm curious you mentioned your founder created a coach bot early on. [00:30:00] Do, do you or your co-founder have any that you use for yourselves? Maybe internally, externally, personally, I.
[00:30:04] Nikhil Gupta: I, I use for testing my, my Kill bot.
[00:30:07] But I don't know if I do, I have like I mean, there's one thing which is I don't like the experience of like CGBT, like voice.
[00:30:17] As much, 'cause I mean, right, right now they haven't deployed it before, I think in production for voice and being able to kind of brainstorm because like I'll get stuck on a problem and I just need to
[00:30:31] like, talk to something. It's like. I'm, I need to think out loud with someone that's like intelligent and used, I used to do this with my co-founder all the time, and now I need to do
[00:30:40] less with him, just with the ai. I dunno if that, what that speaks for human connection, but it's just like, yeah, just, I just loop it out and then I talk to it, but like I'm just holding it down because I'm still processing and I just like pick up a thing and it response. So brainstorming is a very common use case for me.
[00:30:56] And yeah.
[00:30:58] Mike Bifulco: have a I have a weekly [00:31:00] newsletter that I write on my, my personal site under my own name, Mike, by full code.com. I publish a newsletter for startup founders and JavaScript developers. And often I'll sit down in the morning and just brainstorm, like talk, paddle through some ideas and try and you know, expand the idea to something that kind of has a beginning, a middle and end.
[00:31:16] And yeah, I, I agree with you. I don't think 4.0 is deployed yet to that audio experience, and it's a little irritating when it doesn't work well. The, the biggest change and the most valuable thing for that is that now it has memory context where I had previously been like, fine tuning things over and over or re-uploading transcripts.
[00:31:31] And now, now at least that part is getting better and that's been a big helpful change.
[00:31:35] Nikhil Gupta: That's awesome. Yeah. Yeah, exactly.
[00:31:36] I, I think my co-founder and I have a bet around like whether as like years go by or months go by, people like. Will there be a wide widespread love for AI or widespread like skepticism around ai? My, like, it's open, open question because we will be like, oh, AI's getting better, taking my job, or a lot of negativity or responsible, like, I just think like when you look at activity four, [00:32:00] oh, like talking of the thing is like magical like that demo and it'll be hard not to like that experience and like want that thing.
[00:32:09] Everywhere. So very curious to see that, that sentiment shift on ai what will happen. But thanks. Four.
[00:32:18] Mike Bifulco: It is hard to tell, and I think that the mindset is very split right now in many directions, old and young. I think men and women have different feelings on this. I think different generationally, you know, gen Z and millennial and, and all that. There's, there's lots of different opinions on this stuff, and I think
[00:32:32] we'll figure it out over time.
[00:32:33] Yeah.
[00:32:33] Nikhil Gupta: Yeah, but I guess like, I don't know if you run into this, but like, for example, my mom, she's like not very technical savvy. And for like, for example, like she needs to, wants to learn how to, like, she's figure this out now, which is great. Like how to post something on Instagram. And the process for that is like you sharing your screen and you're just kind of pointing her to a button, like press this. Talking about it, like, to me it just [00:33:00] seems like, like yeah. Would be so good at that. Like, I think all people would love it. Like, it's like it, it's patiently just kind of looking at her screen and like talking you through like how to like, do something
[00:33:11] Mike Bifulco: Yeah.
[00:33:11] Nikhil Gupta: that is pretty compelling.
[00:33:14] Mike Bifulco: Yeah, a very a big potential for a tender and loving experience that helps you grow at your speed which is super interesting. Yeah. Yeah. So cool.

Technical Deep Dive: Building with Node and Kubernetes

[00:33:23] Mike Bifulco: Tell me a little bit more about how you're building Matthew.
[00:33:25] Like what, what is underlying your your software?
[00:33:28] Nikhil Gupta: So, yeah, we decided to use Node because the thing, so what's that? Like, why is voice harder than chat? Right. And like open A is now running into this, like getting, trying to deploy multimodal systems is because the chat it's synchronous like, it's like one thing after the other thing that after the other, the voice the person is talking, they might stopping stop again at any point and then you start talking, but they might interrupt again.
[00:33:53] So there's like a very dynamic environment which makes it hard to write like code for it. [00:34:00] And so for us, like given that there's so much like, like there's, you're getting audio every 20 milliseconds. You given that there's so much activity, you clearly need the event loop, right? You need like event loop, like audience coming in, like process that is there something you wanna say?
[00:34:15] Like send that out? If you need an event loop now for an event loop, you could try to build, use Python, you could use something else. You can make custom event loop in rust. But, but I was like, no, no is such an obvious answer for me because. I'm standing on the shoulders of Giant, like this event Loop has been optimized the heck out of it.
[00:34:38] Like, because the entire world browsers running this thing. But the event loop is really good, basically like that. I cannot, I can't imagine all to do anything better. So we use Node to manage the asynchronous nature of our workload, which is like you're getting on audio base all the time. You, you're sending out audio all the time, and there's like so many checks between those two. [00:35:00] So the a harass nature node, these stack for the API interface, we use nest js.
[00:35:06] Because Nest has like an excellent experience around like structuring, like making sure they get very opinionated interface around like how to get data moving and get, get, get operational. And then also exposing that, like, exposing that in docs, exposing that in like exposing, having validators on it. So Nest js is like kind of our choice for an opinion and framework in Node, like we can run in node. And then for the database side of things, like I love Postgres. I've always loved Postgres. It's just awesome. Never had any issues with it. And then so we use base for it, I think has an awesome managed offering that. Kind of, I think, gets to the heart of it where you have nest node. And then of course we have like, kind of a we have many different like GPU services that need to run. Like there's
[00:35:55] things that you can often turn on, like, for example, you wanna turn on emotion detection. That's a good GPU [00:36:00] service. You wanna turn on Denoising, that's some other G service. So we, our cluster is like this main API gateway. Sharding to like different workers and different services for different stuff. And we use Kubernetes so as everything because That's great. Oh, one thing I think that's kind of underrated that we love is Lummi.
[00:36:23] So if you use, you've probably used Terraform before to spin up everything. Lets you do that in your programming language of choice. And we, I love it where it's like, you can imagine like, so for example, we have many different reds that we use. We specify, we specify a list of them and then we can just literally write that code. Or cons, Redis of red. Like, it's like, before I do this, like it's like, and it'll actually do it. It will, it just works. It's crazy to me, like that, that is possible. So Lummi for orchestrating things [00:37:00] yeah.
[00:37:00] Mike Bifulco: That's an unsung hero. And so I, I think you mentioned before you publish an open API spec with swagger. Is that right too?
[00:37:06] Nikhil Gupta: Yes, yes.
[00:37:07] Do you want me to link to it?
[00:37:09] Mike Bifulco: Sure. Yeah. I'll make sure it's in the show notes. You,
[00:37:11] Nikhil Gupta: Yeah. Yeah,
[00:37:11] Mike Bifulco: welcome to drop it in here.
[00:37:13] Nikhil Gupta: Yeah.
[00:37:14] Mike Bifulco: That's something that our audience will be super interested in. It's we talk a lot about open API in that world here for
[00:37:20] Nikhil Gupta: I love open a PII like, I think this is the concept of like, like I just envision, you know, everything to live in my code. I editor, like, I just create this thing and then this open API like is like kind blossoming into like this types everywhere. Kind of the, the dream world for me it doesn't exist right now as much.
[00:37:39] I don't think there's like as yeah, it, it getting there, but open a open API is awesome.
[00:37:45] Mike Bifulco: Yeah, it's, it is super helpful. We we have lots of hard opinions on, on when and how and why to use it around here. And this is one of the things I like about this community is I'm always learning from people smarter than me about, you know, tools and things available in that world too. Cool. So, Nikhil I'm, I'm curious what's next for you?

Team and Future Plans

[00:37:59]
[00:37:59] Nikhil Gupta: [00:38:00] Yeah. For us, I think more observability, more monitoring kind of like going into Wapi and then being able to see how your calls are doing knowing that they're doing well. That is kind of like what's next for us, like giving people security that like, like, their voice, AI is doing the work for them.
[00:38:20] I think that that would be a big thing going forward too, where like, you have all these agents, but like how can you be sure that they're actually doing what you want them to do?
[00:38:27] Mike Bifulco: Yeah, making the black box a little less black is a very, very valuable feature especially when your business relies on it. If I'm standing up a customer service endpoint of some sort, I want to know that it's doing great customer service.
[00:38:38] Nikhil Gupta: So for us it's
[00:38:39] like all about like that, that satisfaction of knowing it's, it's working well.
[00:38:44] Mike Bifulco: Super, super cool. so we've talked about how you build things. We've talked about yourself and your co-founder. How big is the team right now?
[00:38:50] Nikhil Gupta: We are a team of like six right now.
[00:38:52] And definitely always looking for the next great hire. If you love making, if you love [00:39:00] voice ai and are curious about like this whole world of modality and getting the deployed. Which we feel really passionate about and like making great experiences for developers to make it easy. We get it deployed everywhere. Yeah. I would love to chat.
[00:39:13] Mike Bifulco: Yeah. Perfect. That's great.

Conclusion and Final Thoughts

[00:39:15] Mike Bifulco: And so just, just to wrap things up then, where can people go to find.
[00:39:19] Nikhil Gupta: Ai, we, we are kinda everywhere where you can find us on Twitter, LinkedIn, ai. We have a blog. Again, if you're a developer and you love docs, you know, this is actually, this was a learning for me. People don't go to our website. Like they'll just go straight to go to our docs. Like, they don't go to the dashboard, they don't go to anything.
[00:39:35] They, there's like, oh yeah, just like read through the docs. I'm like, oh, cool. That's that's, that's interesting. So docs, we have ai, just Wapi V be
[00:39:46] the.
[00:39:46] Mike Bifulco: have definitely found yourself in the right place to get to people who want to go straight to the docs and read. Of course, will make sure that there's links to everything you just mentioned in the show notes.
[00:39:55] Nikhil Gupta: Thanks.
[00:39:55] Mike Bifulco: Nikhil. Thanks so much for joining today. It's been a real pleasure chatting with you, and I'm, I'm really excited [00:40:00] to get in and poke around with some voice assistance myself.
[00:40:02] Please, please feel free to join us anytime if you have more news to share or things that you're interested in chatting through and sharing with the audience. We'd love to have you back. Thanks a ton for joining today. I appreciate it.
[00:40:12] Nikhil Gupta: Having, ​

View Details

  • Unified.to - one API to integrate them all
    • twitter: @unified_api
    • linkedin: Unified-to
  • Roy Pereira online:
    • roy@unified.to
    • @roymap on twitter
    • linkedin
  • Use Promo code APISYOUWONTHATE2023 for 3 free months on Unified's Startup Plan

View Details

Sagar Batchu's from Speakeasy.dev shares his insights on helping devs live the dream of building APIs that have world-class developer experience.

View Details

  • Sagar Batchu
    • join speakeasy slack
  • Speakeasy - SDKs for your API https://speakeasyapi.dev
    • join beta
  • sdks as runtimes - terraform
  • openapi for chatgpt
  • OSS
    • openapi validator
    • templating engine
  • AI release - clippy for your OpenAPI Spec

View Details

  • OpenCage: Convert coordinates to and from places
  • OpenCage Client Libraries
  • Environmental Commitment
  • Ed Freyfogle: Cofounder of OpenCage (freyfogle.com, LinkedIn, Mastodon)
  • OpenStreetMap
  • Localistico -  Taking Customers from Search to Store
  • Paper Towns
  • GeoMob
    • meetups
    • podcast
  • OpenCage on Mastodon

Creators & Guests

  • Mike Bifulco - Host
  • Ed Freyfogle - Guest

View Details

Show Notes* Permit.io - Never Build Permissions Again * Opal - open-source project: Open Policy Administration Layer * Or Weis - @orweis * Or's talk about onboarding and complexity - https://youtu.be/1_Iz0tRQCH4 * Permit elements - ready-made UI components for user management and access controlFoaz - front-end only authorization

Transcript[00:00:00] Track 1: Hello and welcome back to APIs you won't hate. Uh, as always, I am your host, Mike Fulco. I am sitting down here today to talk with a new friend of mine named or Weiss from permit.io, or it's great to sit down and chat with you. How are you doing today?

[00:00:14] Or Weis (Permit: I'm great. Super excited to talk with you, Mike.

[00:00:17] Track 1: Yeah, likewise. Likewise. Uh, it's, um always interesting to meet people who are working in the developer experience world, especially around, uh, APIs and things like that, which is obviously why you and I are talking today. Um, yeah. So let's start here. Why don't you tell me a little bit about yourself, uh, and your, your sort of history before, uh, uh, permit.io, which is what you're working on right now, uh, and how we got to permit existing.

[00:00:41] Or Weis (Permit: Sure. Sounds like a plan. So, um, my name is, or Weis, you probably gathered that by now. My background starts in the intelligence score in the idf. I was an officer, developer, reverse engineer, engineer team, yada, yada. Basically a cliche, an Israeli entrepreneur. Uh, afterwards I [00:01:00] worked in a startup called Antigua, where we built containers before containers were a thing.

[00:01:04] but with a terrible go-to market. Even worse than Dockers after they ruined their go-to market. Um, I worked a couple startups, founded a startup called React that was acquired by metadata io was a VP of r d and a cyber security company. And, uh, between late 2016 till up, uh, almost three years ago, I co-founded and ran a ceo, a company called Brook Out. Uh, which is another, uh, dev tool, uh, production debugging solution. I didn't go as far as saying the company that created the production debugging space. And, uh, during my time at Rout, I ended up building access control to our product times when the company wasn't even three years old. And I just said, stupid. I don't wanna do it once, let alone five times. reflecting on it. I realized that throughout

[00:01:56] my career I've been building this crap part of my French for [00:02:00] thousands of times, and I get at no point, at no point did I want to. um, I got together with a friend of mine myself. We are now friend. We know each other for 18 years, which makes me feel old. And he, uh, aside from serving with me in the unit, he also worked at Facebook Meta where he worked on their internal developer tools and in infrastructure and authorization. And he saw that they've invested a team of 30 people for half a decade to build the level of access control that they have. So we did the math and we quickly realized that it's not only a huge problem now and a huge annoyance now, it's only gonna get far worse down the road as the complexity of software continues to arise, and as more machine learning agents are mixed in.

[00:02:44] So if you think it's hard to manage users and their access to your product, wait till you need to manage their machine learnings, uh, machine learning models as they talk to your machine learning models. I, I just got back from con eu. uh, in Amsterdam [00:03:00] and if some one thing was apparent is that every company now is plugging in a machine learning model, a chat G p t like thing into their software. Um, and that's gonna make access control there and security there quite a challenge, I'd say.

[00:03:15] Track 1: I'll say. Yeah. Yeah. It's a really interesting, uh, feature set to be working on. I feel like every product team I've worked on, every product I've worked on, every project I've worked on, whether it's for, for a formalized company or not, this feels like one of those things where it's like, ends up being engineered into the product later on, right?

[00:03:32] Like

[00:03:33] prime on the list of tech debt is, oh, we'll put in permissions later. For now, we'll just only give logins to the people who need it, that kind of a

[00:03:39] Or Weis (Permit: Yeah. Yeah. You know, everyone starts, like we all talk about permission models, but everyone starts with the most classic one, which is called admin. Not admin, meaning I'm the developer, I'm the admin. All of you guys will stick with whatever else I, I'll leave out. And then requirements start to funnel in, and then your stakeholders want permission, so you go, okay.

[00:03:58] Okay. Okay. So we'll have. [00:04:00] admin, super admin, I'll be the super admin, and then, uh, just a regular user. And then it moves to access control lists, and then it moves into our ARB is like the bread and butter of this world, right? Roll based access control. You have a role that gives you permissions, but then it continues.

[00:04:18] Like a lot of people think it's, it ends there, but it doesn't. You have attribute based access control, like how do you define a policy like only users that have paid for a feature can use it. Is that like a billing, like a paying roles? What, what, what would be that? And then you have role based access and control and just on and on.

[00:04:37] This is, I like to say the permissions is the gift, the gift that keeps on giving. And I, I mentioned my story at Rout, so. I, I literally went through the same thing, the same point, same pain point. okay, I'm done with this. Like the fourth time or fifth time I built it, I was like, I have built the best dam access control solution out there. It's perfect. I'm never gonna have to touch it [00:05:00] again. And I remember it really shattered me. Uh, one of our, uh, business partners, Cisco came in, they were co-selling out, and they came in and said, at some point, we want our own back office. And I was like, ah, shacks. I didn't think of that one. Okay. Out the window.

[00:05:17] Start from scratch yet again. And because every product is a snowflake and because every product manager is a unique being, and because your security compliance is always your own thing, there's constantly new things that each product needs to tackle in a proprietary way.

[00:05:35] Track 1: Sure. Yeah. I think that's pretty easy to imagine. Um, especially with these sort of like evolving product scape where, where, um, project teams will add features to their product that add complexity or add, uh, collaboration needs and things like that. Um,

[00:05:49] one thing that I feel like has been coming up quite a bit lately, which is probably related to what you're working on, is everyone and their brother is building an AI-based tool, which is.

[00:05:58] Uh, usage based. And so you may pay [00:06:00] for credits per use or something like that in advance, and that's sort of a different view of access control, right? You may only get, I don't know, call it a hundred executions of some bit of functionality per,

[00:06:09] uh, you know, payment that you make. And so that's a very different feeling than do you have access to this thing as a user?

[00:06:15] It's do you have access to this thing as a user and have you paid for it and you still have, you know, leftover bits of credit.

[00:06:21] Or Weis (Permit: Yeah. These kind of quotas add challenges both in how you manage the data. your

[00:06:27] authorization layer needs, also in the realtime event driven aspect that you need for it as part of your application, it's no longer something that you can manage statically or you can manage with periodic updates.

[00:06:39] It's alive with the same pace of change of your application, and it's in a performance critical way. Sometimes, like if you were. Allow them to exceed the quota, or if you allow them, or if you allow the quota to be miscalculated when it's kind of in a race condition, it can even really break things and affect the financials. So you need the authorization layer [00:07:00] to not just be well organized and well modeled. You also need it to be extremely performant and event driven, and it's really hard to do if you haven't planned for it in advanced, and if you haven't set the groundwork for that. So a lot of what I try to do when I work with, uh, the community that we've built around our open source project, Opal and around permit as a company, it's not just, um, these tools, it's also providing the best practices and tools to think about this problem.

[00:07:29] I spend most of my time and also the best, like this is what I like the most about my job, talking to fellow kindred spirits and just geeking out on the tech and helping people like myself solve, solve this problem. So it's we, we really try to also bring in the best practices to the table. The decoupling your policy and code, creating a separate microservice for authorization building in and.

[00:07:51] Event driven architecture that will enable you to scale it out and, uh, keep it with the pace of the changing requirements of your application and the [00:08:00] pace of the application itself. Like a lot of people don't realize this, but like in a average microservice application, you need to handle three authorization queries on average for every incoming request. So unless you have something that is ready for that scale and pace, you're gonna have a bad time.

[00:08:17] So, and if you plan for it though in advance, even if you don't build. Even if you don't use any tools, if even you don't use the open source, but you just couple out the things that you need to be independent, like the policy from the code, like the data plane from the authorization engine itself, um, you can save a lot of pain just by having a little bit of foresight.

[00:08:39] Track 1: Yeah. You know, it's interesting. I feel like we, we've dove in headfirst here and one of the things that. I find comes up a lot with people who may be new to building applications that have sort of a user facing feature, uh, of any, uh, form is the, the important difference between authentication and authorization.

[00:08:58] Uh, right. I feel like those things are easy [00:09:00] to, uh, confuse. So, um, can you maybe help disambiguate that? What is authentication, what is authorization and what do they have to do with each other?

[00:09:07] Or Weis (Permit: Yes, of course. I, I do that disin variation basically, uh, three times a day. So happy to do so.

[00:09:13] Track 1: Perfect.

[00:09:14] Or Weis (Permit: So maybe first let's start with identity management. So I am identity management and access control. So you have identity management authentication and authorization permissions. These are all three cascading waterfall like tiers that connect to one another. So identity management happens on the organization side. That's just deciding which identities you have, which are part of the organization, which are not, and what data or attributes or claims you have about them. Then as you move towards products or applications, those users or identities want to consume you move through authentication, which is the main responsibility for that. Is to verify the identity. So it's talking to the identity management, talking to other sources of identity, biometric data, um, uh, one time password tokens that you send over [00:10:00] SMS multi-factor. And that's allowed to determine if you are who you say you are. usually culminates in creating adjacent web token. That's like, uh, it's a cryptographically signed document,

[00:10:12] Track 1: Mm-hmm.

[00:10:13] Or Weis (Permit: kind like your passport that you take with you either in your cookie or in your http enters or whatever else you use to communicate with your end app. And then you go and you get into the app itself and you have your identity and a lot of times additional claims like. You belong with this department. Your current location or residency is this country. Um, and then the application needs to decide what you are allowed to do or not, which is very different from authentication. That's authorization or, uh, permissions. There. You need to evaluate a policy, take in the relevant data of what's happening now and what's the current context like.

[00:10:50] Where are we in the world? What this, which service am I, uh, what are they trying to do, et cetera, et cetera, and come up with an answer. Can they do this or not? And the [00:11:00] challenge there is that that's deeply ingrained into the code, into the product. Unlike authentication that just happens once at the gateway. Authorization needs to happen for every little request interacting with the system. Otherwise, it'll be vulnerable.

[00:11:13] Track 1: Yeah. Yeah. That is a, uh, great synopsis there. And I think maybe the biggest disservice that new developers run into is that we tend to refer to both of them casually as off, right. Problematic, very, very problematic that those two things have different functions and they're, they're codependent and use the same name.

[00:11:31] Or Weis (Permit: Honestly, in defense of every developer out there, the ecosystem hasn't done us any favors. If you

[00:11:37] Track 1: Yeah.

[00:11:37] Or Weis (Permit: it, you, even in HTTP when you, there are multiple authentication methods. One of them is called the Bear Token, and you literally write in the http headers, it's authorization, and then the bear token, the adjacent web token. So for Authe, we are literally calling the authentication, the authorization. So everyone's confused and you have things like O off. And [00:12:00] specifically o uh, oof two, um, which talks about authorization, but it's part of, uh, like in single sign on in, uh, it's how you do authentication.

[00:12:12] Track 1: Yeah.

[00:12:13] Or Weis (Permit: it's really a mess out there.

[00:12:14] I, I think our predecessors kind of, uh, left a lot of technical debt for us to fix. Um, that's, that's being engineers we

[00:12:23] built on the shoulder of giants and on the crap they left as well.

[00:12:28] Track 1: for sure. Yeah. Maybe it's, uh, an opportunity for us that the, uh, the language creates such ambiguity in what we've got going on here. Uh, there's also quite a.

[00:12:37] Or Weis (Permit: I try to call this permissions just to avoid the

[00:12:39] Track 1: Yeah. Yeah. Okay. Actually, that's perfect. So my next question is, uh, I, I feel like I hear people use permissions and entitlements, uh, in, in the same context often, and this is probably something I'm guilty of, that I sort of think of those two things as the same.

[00:12:55] Is that in your world, is that roughly the same thing?

[00:12:58] Or Weis (Permit: So they're very different[00:13:00]

[00:13:00] Track 1: Perfect.

[00:13:01] Or Weis (Permit: but I don't, uh, begrudge anyone confusing them or interchanging them. I think it's okay. It's like we don't need to make a big issue out of it. But if you wanna be, uh, if you wanna be nitpicky, um, permissions are what you're allowed to do or not. Entitlements are, um, Claims or values or, uh, information that can be used to make those deductions. So for example, you can have the entitlement of a manager or an admin in a system that can be even coming from the, uh, identity management that would still need to be translated into an application level role. In the applications that you are providing, and that needs to be translated into specific permissions. So I like to think of a permission as the intersection between identity, resource, and action. So, or a principle. So instead of a identity, if you prefer [00:14:00] this person with this context, or this entity with this context can also be an automated agent. Obviously this entity with this context. What are they allowed to perform this action against this resource or not? Uh, and in, literally in permit. So we really, we really put a lot of effort in building a simplified ux. Part of the cool things about permit is that we have a low-code, no-code editor that generates policies code for you. So we literally took that concept in tri, translated into a table. So when you, you wanna say, oh, I have the permission. Uh, an admin as their permission to delete a file. You literally click a check box at the intersection between file and delete

[00:14:43] Track 1: Yeah. Yeah, that was a wonderful explanation, and I can tell that this is something that you've done more than once, and clearly this is not a part of the, the stack that I, uh, dip my toes into too often. Uh, this is one that I'm gonna keep in my pocket very, very handily as a hey, even, uh, someone who's been around the block a few times, [00:15:00] uh, gets the answer wrong pretty regularly, you know?

[00:15:03] Or Weis (Permit: Yeah. And, uh, by the way, I get these kind of, there's a lot of these little confusions out there, both

[00:15:09] in the implementations of things and all just the names that you have of things. And, um, so what we try to do with that, like, I really just make it approachable for people as much as possible. So I spend a lot of my time, like, I encourage people listening to us reach out to me and like, uh, or WISE, or w e i s on.

[00:15:28] Twitter on GitHub, on LinkedIn, whatever, like, and I'm happy to help. I'm happy to answer questions like even silly ones. Um, so

[00:15:36] Track 1: Yeah. Perfect. Yeah. Thank you. Um, so I'm, I'm interested in hearing maybe some of the basics of about permit then. So, uh,

[00:15:44] Or Weis (Permit: mm-hmm.

[00:15:45] Track 1: maybe let's start here first. Uh, how does it work? Is, does permit essentially work as a middleware? Is it something that you integrate into, um, your API side? Uh, does it, is the generated code something that I inherit?

[00:15:56] How does, how does it work?

[00:15:58] Or Weis (Permit: Terrific question. [00:16:00] So at the core of it, we are providing a policy engine for you to work with. So maybe you've heard of open policy agent opa, or maybe you've heard of Cedar from aws, and there a bunch of others. These are engines that are general purpose. You load them with policy. You load them with data and then you can query them. So we provide that agent for you, bundle up all nicely in a container that you can run it as a sidecar or as a cluster next to your app or if you, and soon it'll be available from aws. You'll have Amazon verified permissions. So that's a service that will be running that agent for you. And we can, and we layer on top of that. So we, but we enable you to run this next to your software and that's very important. For two reasons. Two, actually three reasons. Uh, the first one is latency. As I said before, every microservice application on average handles three authorization queries per request. Even if you just go out to an external cloud, uh, for one, for a 50 [00:17:00] milliseconds roundabout, uh, you'd be killing the performance of your app. So this needs to be as little latency and ideally zero latency. So by deploying the service next to your app, ideally is a sidecar, or at least on the same physical machine, you remove the latency aspect. Yeah. For part, obviously permissions or security is a critical aspect. If that doesn't work, you, you, you don't want your app to work, let's put it that way. So if you're dependent on the external availability of, for example, our SaaS service or any our cloud, Well, you're gonna have a bad time, so you want everything, that decision engine to be able to answer everything locally. this is where our open source project Opal comes in. Opal Open Policy administration layer is a way to keep policy agents up to date with the policy and data that they need in real time. So you opal subscribes to, uh, policy management from permit or your own use of it as an open source project and it fetches the instructions for data and [00:18:00] policies. It needs policies arrive directly from GI repositories cuz we want to manage them as policies, code and data arrives from whatever you needed, including your local database. So this is where the security aspect comes in. You can load data into your authorization layer with permit. Without being dependent on, uh, sharing it with permit at all. Cuz Opal sends instructions on where to get the data instead of the data itself. we now understood the pdp, the container that can, that runs in your app. We also provided hosted, but ideally in production, at least you run it as part of your app. All that's left is for your app to consume the decision point. Uh, via enforcement points. Um, there are multiple ways you can do so. You can, uh, apply it in the code and you can apply it externally, like in a reverse proxy or API gateway. But applying it in the code is the most classic in what, uh, most people do. So we provide a function and SDK function in para basically in every language you want called permit duct check. [00:19:00] receives three arguments and I think will sound familiar to you. Identity, resource, and action. you're basically saying this identity, the identity being the Jason Web token that you got from your authentication, by the way, that's how we seamlessly connect your authentication providers and identity management without having to replicate any of them at all. Um, so you have the identity performing this action on this resource. So in your app, you are describing what's happening instead of describing how you should handle it. You, so you don't put the policy there, you're just doing the description. With that permit, that check flow. By the way, even for people who doing the open source option or doing, uh, completely building on their own, I really recommend this pattern decouple your policy and code and work with identity resource action.

[00:19:45] It simplifies reasoning. It allows you to put this sec the policy separately and it gives you a lot of elasticity with mutating your app or mutating your authorization there afterward. So you put in that permit check, it directly talks to that [00:20:00] PDP that lives inside your app. So zero latency, you get authorization decisions and you're good to go. Now we only need to do is manage the policy. So this is where the para permit, uh, control plan comes in. We have a policy editor UI that I'd like to say a monkey can use, or even a product manager if they're smart enough.

[00:20:18] Track 1: Ah,

[00:20:19] Or Weis (Permit: by the way, the product managers love that joke. I'm not sure why, but they just love it. Um, so we generate code for you. The policy editor is something that you can, uh, do some clicks with. It does both Rback, role-based access control and avac. So you can do very complex policies, but with an interface that you can easily use yourself and obviously easily delegate to other people. This is actually one of the most important things that I think. um, we have permit recognize is that you don't want to do this. Like you don't want to build the policy and take care of it all day. Groom it like a bonai tree. You wanna get rid of the scrap, so you wanna bake something in and delegate this to [00:21:00] the other people. Product security, compliance, sales, professional services, support, whomever, everyone and everyone needs to connect in the end of the day.

[00:21:08] Building access control is about connecting people and systems to what you've built in a secure fashion. and any company building a product, that's what you're doing all the time. So you want to enable all the people around the table to do so without turning yourself into a bottleneck. So that's what that, um, policy, uh, low-code, uh, policy generator does for you. But still, you get off the best practices here cuz it's a low code interface that generates code. So, for example, if you're choosing Rego or Cedar, we write that code for you. Uh, by the way, these are complex languages. They're not like, Um, Python or do, uh, derivatives of data log or prologue. So

[00:21:49] those are basically a rule engine that recursively runs between all of the rules and functions that you wrote. So it's kind of, it's not a run of your me run of the meal, uh, [00:22:00] language. So it also can be a lot of, uh, annoyance just to learn this new thing. So we just take that off the table. You can just generate the policies for you, but they get pushed into GI and in Git you can add more code on your own if you want, you can do code review.

[00:22:13] So if that product manager creates a policy, you can review it. You can do tests on the, you can do benchmarks. So you, while you delegate access to the access control, you don't lose the control yourself. That's something that is very important, by the way, I think with every developer product, every developer, pro product should be very powerful, uh, but easy to use and you can choose on that slider as a developer, how much you want to go deep into the reads, but you never should be forced to.

[00:22:40] You always should be able to, but never forced to. That's my, in general, my philosophy about, uh, dev tools.

[00:22:46] Track 1: Sure.

[00:22:46] Or Weis (Permit: generate that code for you. And, uh, we provide a lot of other interfaces like user management and the audit logs and, uh, interfaces that you can embed for your end customers. But that's, uh, in just a basic concept.

[00:22:59] Track 1: Yeah, [00:23:00] there's, there's a lot to digest there. Um, I think one of the fundamental things that. Um, maybe is a, is a subtle point that I feel like is probably something that permit is using quite, um, elegantly. Is that all authe, um, make sure I'm saying this right, authentication providers who use JWTs,

[00:23:16] uh, is JWT is a secure but also a mutable thing, right?

[00:23:20] Like you can send information within that token, uh, which is important. It sounds like you're tapping into that functionality to be able to, uh, you know, provide the permissions information to enable, um, various scenarios for, for whatever the cases may be there. Um, That is, that's a subtlety that I think a lot of, um, uh, author, uh, yeah, authentication providers don't get across super well.

[00:23:40] Like they tend to say, they dangle it in front of you. We use JW T, but I think the breadth of what that means is, uh, a little trickier than, than maybe not trickier, but a little more, uh, deep than it seems on, on first glance.

[00:23:52] Or Weis (Permit: They, they actually do something that is, that is more insidious. They tell you that they provide rule-based access control for you [00:24:00] and they're doing two major sins at once There. One, they tell you that they've done rrb back for you, so you are done. But then you get that Jason web token and you still need to write code. to actually enforce access. And

[00:24:13] what happens is when the claims change or if the, uh, identity management, uh, for the customer, uh, ends up sending different things, they, you actually haven't built arrb. You've built claims or entitlements, and now you need to process them into your actual policy and you actually need to write code or something to handle that. And the second part is that they're actually confusing the term roles. So there are two kinds of roles here. There's the roles that you have in the organization and the roles that you have in your app, and they're not the same thing. If you were the, for example, the VP of marketing that, what does that mean in the app?

[00:24:51] Are you an editor? Are you an admin? Are you a monkey? What

[00:24:54] does that mean? So the translation, a critical application concept, [00:25:00] logic, translation, needs to happen and. A lot of times they, they try to kind of minimize the difference there. Um, but that actually creates more work for you as a developer. So recognizing that early, by the way, I'm not saying don't use those claims.

[00:25:15] Those claims are great. Those are amazing attributes that allows you to connect to the customer side and have, uh, the ability to build complex attribute based access control policy. but you need to recognize that, that there, that thing that you need to manage that complexity and not just assume that some magic ferry would come in and, uh, make it all work for you.

[00:25:36] Track 1: right? Yeah, that's a fair point. Uh, so I wanna talk about onboarding then for permit. What are, what does your typical, um, use case look like when people are coming to permit? Like where, where are they at in the product development lifecycle? Are they brand new? Are they working on something where they're trying to shoehorn in permissions or are they reworking permissions entirely?

[00:25:56] Or Weis (Permit: So most often than not, it's someone that's already has something in place, but [00:26:00] a new requirement has come in. As I mentioned before, permissions is the gift,

[00:26:03] the gift that keeps on giving. So every three, six months. There's new requirement comes in and you either completely refactor or, uh, refurbish your, uh, authorization layer. Um, and so we do get some people starting from scratch, but most people have something in place and something that we recognize is that you don't want to touch it as long as it's working. As long as you don't have another requirement or an issue, you, you should, I encourage you, stick with what you have. but once you do come to that point when you need to upgrade, Recognize that it's probably not the last time. And then it's a question of how do you best utilize your time to both meet the current requirements and make it easier next time you need to upgrade. And that's, and that's where the best practices come in. Decoupling policy in code, working with policy as code, making it event driven, creating the interfaces for the ever stakeholders. There's a talk that I gave at covering all of [00:27:00] these in details, so I couldn't just Google it.

[00:27:03] Track 1: Yeah, I'll make sure I put a show note, a link in the show notes as well.

[00:27:07] Or Weis (Permit: Sure. Uh, so I don't, I won't go too much in, in the reads into that, but by recognizing that you can really improve things, a lot of times when people, uh, I get a lot of calls, like we have a LY link on the footer of our website. I get a lot of calls for that and, uh, I tell people like, what do you actually need to do now? You shouldn't like refactor everything at once. Let's be focused here. We need to be cost effective, but let's also recognize what are the easy things that we can implement that will minimize technical debt later. a lot of times it can be even something very simple, like, uh, just decouple it out. Just create the microservice for authorization if you don't have one.

[00:27:48] It can be even a, like a lamb function that currently just returns true for everything,

[00:27:53] Track 1: Yeah.

[00:27:53] Or Weis (Permit: can gradually add more logic into it and then switch in place, add, replace it with a different container or a different service, or a different [00:28:00] open source project. Okay. Um, but, but by starting to have that modularity, you do two things. A, you set the ground for what you actually want to build, and you are communicating to the re to the other engineers, uh, about where this is going. Th this is, by the way, the mirror image of this is where most of the pain comes from. By putting the authorization in the app itself, what do you end up having is organic drift where people just, other engineers just add more things into it.

[00:28:26] So you find a lot of these if conditions that have logic, both for the app itself and for the

[00:28:31] authorization there. And then when you wanna change it, you have to cherry pick and kind of go one by one to fix it up. by putting it separate, you are communicating to everyone. This is a separate thing. Don't push your silly if condition here.

[00:28:44] It, it doesn't go here. Uh, so you are also, um, more, uh, dirt or unrelated stuff accumulating there. Uh, and that will also say you work later. You less cleaning to do, aside from just setting [00:29:00] the stage.

[00:29:01] Track 1: Yeah, I have personally done that many times where I've had to go in and, uh, dees up that if statement that I wrote months and years ago or someone else wrote months and years ago, uh, as complexity increases. And I think that's one of those things that, um, you're paying yourself a big favor in the future if you're able to sort of, even just at the early stage, like you said, kind of.

[00:29:20] Plum plumbing and if true, or whatever, you know, a return true statement there. Um, very, very similar weirdly to, to, um, in a, in a recent past life, I was doing developer advocacy at Stripe, uh, and

[00:29:31] changing your pricing strategy, uh, you know, months down the line is an infuriating process if you haven't thought of it in advance.

[00:29:38] Uh, so giving yourself, like decoupling all of the logic of everything so that you can plug and unplug things is really helpful, especially in a world where you may need to test or iterate on things or. Uh, you know, add complexity too. That's, um, that's a bit of wisdom that is not to be taken for granted.

[00:29:52] Certainly.

[00:29:54] Or Weis (Permit: I, by the way, I really love Stripe. We drive a lot of, uh, inspiration from. from the play there. I really love [00:30:00] both the developer alignment and the thought around the how a product should grow and how you, um, not only provide it for the developers, but. For the developers, for everyone else. That's a philosophy that I really subscribed to,

[00:30:14] Track 1: Yeah.

[00:30:15] Or Weis (Permit: one of the features that we ended up creating for permits is something that we call permit elements. And we just reaped up the concept directly from Stripe Elements, right? And so with Stripe Elements, you have readymade UI components for billing, for, uh, like a checkout, for example, that you can abandon your app. And so we've done the same with, uh, With permit elements, these are already made experiences for user management and access control. And actually, when you think about it, these are the main things that you actually do with access control. These are experiences, you know, like things that you've seen a billion times. Uh, user management. With the ability to assign roles, API key management, secrets management audit logs for yourself, for your end

[00:30:57] customer, multi-tendency management approval [00:31:00] flows.

[00:31:00] One user starts from action, another user approves it, invites permission, requests, emergency access, personation, and this list just goes on and on and on and on. So the philosophy is is not unique to any app. Why? Why in the hell should I build this? Why can't I focus on what actually my apps needs to do? So we just provided, already made, you can always build it on top of our api. Again, that's the same philosophy. You should always have the power to do whatever you want. You're the developer, you know best, but if you don't want to, you shouldn't be forced to. And so we provided off the shelf.

[00:31:37] Track 1: Yeah, I think that's very smart. The, um, UX designer part of my brain also really loves that because you're not reinventing the wheel, uh, and you're taking advantage of presumably permit elements. If, if I went in and looked at the UI library, it would look awfully familiar, and just by seeing it, I would be keyed into what the likely functionality of that bit of interface does, uh, which is.

[00:31:58] A wonderful thing because you're taking [00:32:00] advantage of all the deep, you know, ingrained psychology that we've given ourselves from using, uh, software for all these years. Um, yeah, definitely always a good idea to reuse things and not, uh, create, you know, clever, um, parallel patterns for things when you don't have to.

[00:32:13] Uh, so, or we, we've talked a little bit about, um, your product from a. I guess from a ground up standpoint. So, um, really interesting to hear, you know, the, the very basics of where the problem came from and then sort of why, uh, it's important to think about this from the beginning of, uh, building out your software, but then also what it's like to take on complexity and why permit can help with that.

[00:32:35] Um, I, I know, um, There's a lot of developers who will come to this thing with a, okay. I think I fit the scenario you're talking about here. Um, what, what is the first thing that a developer does when they jump in with permit? What is sort of Hello world?

[00:32:50] Or Weis (Permit: Uh, so the yellow world is picking, so per permit is very granular. So you can put pick, if you just apply it to like a single function, a single microservice, a single [00:33:00] route, a single middleware, single application, whatever you choose. So it's about picking the right granularity for you to start. Like, what do you actually care about now?

[00:33:10] What do you actually wanna try? Adding that one permit check and seeing how you change things from the editor, they propagate into get and in real time, propagate. into the, your live application and you are able to change the permission, just toggle one action on and off very quickly. That's the, that's usually where you get it. And, uh, and then you move to like, okay, let's add another role and assign it very quickly. Now

[00:33:36] let's make the roles dynamic and assign it very quickly. Now let's have different, two different applications or two different tenants with slightly different policies. And it gradually, everyone kind of drifts from there into their own snowflake scenario. Um, and it's, uh, it's very easy to start and the end of the day it's just embedding an SDK or potentially a microservice. Um, you don't have to put in the microservice initially [00:34:00] if you just wanna tr test that we hosted for you, but again, please put it in production. It's highly recommended.

[00:34:06] Um, so yeah, that, that's kind of the basic flow.

[00:34:09] We try to keep it

[00:34:10] as simple as possible.

[00:34:12] Track 1: sure. Yeah. When evaluating developer tools, I think that's an important thing, and it kind of keys into what you were saying before, that you should be able to opt into whatever depth of thing you need. Um, but a lot of devs who may be listening to this may need to go sell this to their team as, Hey, this will make our lives better.

[00:34:27] Uh, and it's really, really genuinely better if you can do that by implementing it in a small place and saying like, this is what this thing does in an atomic version of itself. Uh, Can you, like, either we can see the value in this or not, and by not having to go and rewrite your entire application structure, your entire, uh, API stack, whatever it may be, you at least are able to have the discussion and sort of sell that to your PMs or, uh, business stakeholders wherever the case may be there.

[00:34:52] That's, uh, a very, very helpful set of features to have.

[00:34:55] Or Weis (Permit: Yeah, you also wanna build confidence in this on your own. Just

[00:34:58] as your, as a [00:35:00] professional, you wanna say, this is something that I trust. This is final thing that has the performance profile that we

[00:35:05] need. This would actually have the features and, uh, interfaces that we need. So we also encourage our people to run this side by side with their existing, uh, authorization solution.

[00:35:14] Initially, don't actually gate, don't actually enforce the fossil. Just

[00:35:18] see that it produces the same result. At the same pace as what you already have in place, then you gradually build confidence. Sometimes people would give it like a couple days to run. Often they don't get to that. Like they see that it works and they start running with it. But it's malleable enough for you to pick the, the level of trust that you have and gradually grow it and see that it doesn't bite your back just because you deployed it.

[00:35:43] Track 1: right?

[00:35:44] Or Weis (Permit: very email thing. Right.

[00:35:45] Track 1: Yeah.

[00:35:46] Or Weis (Permit: and we've actually, when it comes to. making this more relevant for the bigger team. Uh, this is where a lot of features that we have that people don't necessarily think about when they're building [00:36:00] authorization come in.

[00:36:00] And those are the cur features of authorization for authorization or

[00:36:05] permissions for permissions or roles for roles. for example, we have a concept called a project and a concept called an environment. These are silos for your policy and data. A project would be an application that you run and you can have different applications with different policies. An environment would be a separate deployment of, uh, the same application also can have, you want different policies in staging than you have from production, for example.

[00:36:30] Track 1: Sure.

[00:36:30] Or Weis (Permit: Um, and you can assign specific access to specific people to specific deployments. Um, so for example, and that also enables kind of more complex r and d patterns as opposed to individual comp, uh, contributor patterns.

[00:36:45] So for example, you can say something like, um, as part of our preview branches, we, every time we deploy a new preview branch, um, we want to create an environment, a deployment environment thread, and we wanna control the access to it as well. So use our API and you create a, [00:37:00] uh, permit environment and you assign access to it only to the developer that deployed it. And so suddenly you have these dynamic patterns that are very easy to use, that are not just about these, uh, uh, permissions and access control for your app, for your customers. It's also how you as a developer with your team work on this in a way that you don't st stop on Trevor's toes. And these are the things that, that, hey, it's really hard to build on your own or even realize that you might need,

[00:37:29] Track 1: Right. Yeah,

[00:37:30] Or Weis (Permit: I think, a big enabler for developers to work on the, as a team on these things.

[00:37:35] Track 1: I can certainly imagine why it makes sense to spin up an entire product around that too. That's represents a level of scope creep that started from, Hey, we need two different types of users to, uh, you know, an entire galaxy of permissions and complexity that comes along with that. It's super fascinating.

[00:37:48] Uh, so tell me about what's next for permit? What are you working on now?

[00:37:52] Or Weis (Permit: Uh, so we're working with something very exciting that is, uh, Um, I think, uh, even a little groundbreaking [00:38:00] and, uh, also kind of puzzling. It's called uh, ez, which stands for front end only Authorization. which, uh, I think only by the, that title, like front end only authorization, like that sounds like an oxymoron because how can you have authorization something secure in the front end? Um, and the, the reason the explanation for that is it's front end only, just like, uh, serverless has no servers. So

[00:38:27] we provide basically the, uh, backend component that will do the authorization for your front end. But the idea is that you'll be able to consume sensitive APIs directly from the front end without writing any backend code. And I'll explain, let's say you want to use, uh, Twilio to send an sms. Or strive to send an invoice, or you wanna talk to a chat bot in Slack, you wanna do this in your front end, just one, click a button. The user clicks a button, and that happens. Currently you can't do that. You have to [00:39:00] write backend code.

[00:39:00] It will add the secrets. We'll check for permissions and we'll actually call that external service. Otherwise, if you put that. In the front end, it's exploitable. Um, first of all, everyone's gonna steal your account key and second, they'll just circumnavigate your permissions cuz they're, they could just edit them in the front end. So what do you usually do is you, if you're a front end developer, you go and ask a backend engineer to write this for you. Or if you're a full stack or you're savvy enough, you'll go and write backend code in addition to the front end code that you actually want to write. Uh, but with FOAs you can just take that off the table cuz Foaz is a generic purpose, um, implementation of that backend component.

[00:39:41] They need to write. So it includes

[00:39:44] the, our policy engine that can do any enforcement that you want on when this is okay for the identity running in the front end. Now to consume or use that external service. And you can apply the application logic, not just the end account, like the Twilio logic, the [00:40:00] actually what it means in your application, and it injects the secretes that you need for like the token for the, for Twilio or Stripe or whatever. And then proxy is your call. From the front end to the actual end service and returns the answer to you. So you can securely use that from the front end without giving up any of the security, while not having to write glu code, which is like literally, uh, the amount of time people wrote That line of code adjusted proxies things to Twilio is, uh, I dread, I just dread the thought so much wasted time. Um, And by the way, also, this also applies for your own code. Let's say you have a backend service that you want to consume and you want, you want to let people use, but you don't have the granular permissions that your customers want there. ideally, you'll end up embedding permit into that service. But let's say you don't wanna open it up right now, you just want a quick solution. You can apply for as, as a gateway there as well. So you can slap on [00:41:00] permissions on whatever you need. and focus on what's important for you now, but gradually already build up, build up that, um, groundwork to scale into a more complex permissions model. So, so that's, that is for as front end only authorization, and we are launching it soon in two ways.

[00:41:17] One, as a standard, as an open source standard and how you take general purpose decision engines like opa, couple them with Vault solutions to manage the secrets. Um, and with a proxy that will do the actual calling bundle those together with this standard and the schema and APIs we offer. And this, uh, and you can implement foz on your own and obviously is a service that we just provided.

[00:41:40] We have this proxy component. We have the, uh, management APIs and management UI just get started and consume all of those, um, uh, sensitive services directly from the front end. And I think this is also. very empowering for front end developers. a you're in, you have [00:42:00] less dependency on the backend and backend engineers. And I think it finally, and I think this is important and finally brings front end engineers into the actual conversation of security. You're not just tagging along with the rest of the org. You can actually lead that conversation. I think that's important. We need like, Security is something that is really based on the weakest link. And if we

[00:42:25] have places where the, the conversation around security is not strong enough, this is where those vulnerabilities are going to arise. So we need to embrace everyone into that conversation and hopefully this will enable front end developers to do that.

[00:42:39] Track 1: Yeah, sure. I can think of a lot of devs who will be happy that they don't have to think about splitting things out to the server side. And, um, it's also an interesting problem for, um, devs who are learning the ropes, right? Where it's not obvious when you come up with an idea for like, oh, I wanna build this simple project for whatever it may be.

[00:42:57] Uh, and then one day you stumble into, oh, I, [00:43:00] you know, I, what does the secret key mean? Why is it a secret? Who is it a secret from? And you suddenly realize that you've left yourself open to attack and things like that. Um, generally speaking, right to date, certainly the, um, path to take for that is to go spin up a server somewhere or to use a lambda, or in some cases an edge.

[00:43:17] Uh, edge deployment to be able to execute that code. Um, why do you think it's, uh, interesting to do this now and why is this, um, an important use case to start tackling?

[00:43:28] Or Weis (Permit: So first of all, we are seeing an emergence in this, the entire IAM space as the complexity of software continues to arise. This entire space with us and regardless of us is constantly evolving. We're seeing new products come in, as also we are seeing more threats come in. Um, applications become more complex, they also store more value and more data, and more people want to, um, take advantage of that. the risks that we are facing are also on horizon. This entire space as a result of that, is also on horizon. So, [00:44:00] and then that's basically supply and demand. More engineers need these things. More engineers need to build more of these things. More engineers need more velocity against this, these things. So they wanna just build their software, but they're stuck building all these security features, all of this glue code or, um, security additions that need to that. So, want to simplify that. We wanna take it back to basics. We wanna enable the front end code to focus on being front end code and easily consume the services without having to build the actual security components, but be able to consume them. Um, so I think, uh, at the basics, just supply and demand. And for us, we've already built this general purpose, easy to manage, uh, policy engine that you can do all the policies you want with, uh, as I said, an interface that a monkey can use. Uh, so that really can take that friction off. And this is, I think what you want here is a front end developer.

[00:44:54] You want the velocity to build your app without a hassle. So that's what we're bringing to the [00:45:00] table.

[00:45:00] Track 1: Yeah, maybe it'll allow my fellow front end developers to stop needing to call themselves full stack developers to get any respect around here. Uh, you know, especially now that GitHub co-pilot is, is able to cough up people's, uh, dirty secrets in their code, like, uh,

[00:45:14] I think that was one thing that was found pretty early on is API keys that GitHub co-pilot knows about from someone else's environment that actually got, accidentally got committed to Git and all that.

[00:45:22] Um, yeah, it's a super fascinating use case. So you, you're in early access right now? Is that what you said?

[00:45:27] Or Weis (Permit: Yes. So we we're launching it for everyone very soon. Maybe when this is launched, it's already when this, uh, podcast goes live. Maybe we've already launched it. Um, but otherwise it's very, very soon. And, uh, for those that want early access, there's a button on our website. Uh, sign up and you'll, you'll get that access as well.

[00:45:47] Track 1: That's great. Well, I will make sure that we also have a link to Foaz in our show notes here. Uh, and it sounds like, or you're a pretty accessible guy on the internet. So, uh, for for listeners to the show, I would encourage you to reach out to or, [00:46:00] um, it's, uh, been a very, very fascinating conversation and I think you're under some really cool stuff.

[00:46:05] Uh, at permit. Uh, I would be, uh, more than interested in chatting with you again in the future as things develop and as the I am space tends to keep changing too. Um, or Weiss, thank you so much for joining today. It was really a pleasure to have you on APIs you won't hate.

[00:46:18] Or Weis (Permit: Pleasure, Thank you, Mike. Uh, look forward to, uh, staying in touch

[00:46:22] Track 1: Thanks again. We'll do it

[00:46:23] Or Weis (Permit: everyone don't Yeah. Reach out

[00:46:26] Track 1: All right. Thanks Laura. Take care.

[00:46:28] Or Weis (Permit: Take care. Bye-bye.

[00:46:29] Track 1: Bye.

[00:46:30] ​

View Details

Mike chats with Alexander Karan, CTO of Climate Clever, where "You can't manage what you don't measure" is a mantra. Climate Clever is an API-first company helping businesses, schools, and homeowners in Australia manage and minimize their carbon footprints.

  • Climate Clever - https://www.climateclever.org/
  • Alexander's recent Article on APIs You Won't Hate: Modern API deployment options in the cloud
  • Scope 1 and Scope 2 Inventory Guidance - US EPA
  • Alexander Karan (@alexanderkaran_) on twitter

Thank you so much to our sponsors:

  • Lob: https://lob.com/careers
  • Treblle: https://treblle.com/apisyoulove

View Details

On this episode, Mike talks to cofounder of Merge, Gil Feig, about building a service that integrates with many APIs.

  • Find Merge at https://merge.dev
  • Gil Feig @GilFeig
  • Merge is Hiring!

Thank you so much to our sponsors:

  • Lob: https://lob.com/careers
  • Treblle: https://treblle.com/apisyoulove

View Details

Mike speaks with Sean Falconer, head of Developer Relations at Skyflow

  • IEEE Conference on Security and Privacy
  • Skyflow blog
  • Sean's article on storing SSNs
  • Robinhood data breach
  • Sean's article on Software Engineering Daily, Why Everyone Needs a Data Privacy Vault

Thank you so much to our sponsors:

  • Lob: https://lob.com/careers
  • Treblle: https://treblle.com/apisyoulove

View Details

  • Mike is starting work at Stripe!
  • What the world looks like for Open API and JSON Schema going forward https://json-schema.org/blog/posts/json-schema-joins-the-openjsf
  • Mozilla's 2020 Layoffs
  • Writing for APIs You Won't Hate - https://github.com/orgs/apisyouwonthate/projects/4

Thank you so much to our sponsors:

  • Lob: https://lob.com/careers
  • Treblle: https://treblle.com/apisyoulove

View Details

Links from today's show

Phil's reforestation charity

  • Protect Earth

Posts on APIs You Won't Hate

  • Contract Testing a Laravel API with OpenAPI
  • Creating OpenAPI from HTTP Traffic

API Tooling

  • Akita https://www.akitasoftware.com/
  • Optic https://www.useoptic.com/

Serverless functions in JAMstack frameworks

  • Remix.run API routes
  • Next.js API routes
  • Gatsby serverless showcase
  • 11ty serverless

Thank you so much to our sponsors:

  • Lob: https://lob.com/careers
  • Treblle: https://treblle.com/apisyoulove

View Details

Thanks to Lob.com for sponsoring APIs You Won't hate - join the lobster pod at https://www.lob.com/careers 🦞

  • Support Phil's Charity: Protect Earth
  • Dark Sky's API is shutting down
  • Personal Weather Stations: Ambient Weather
  • Ecoping.earth - Tools to reduce your company's website carbon emissions & boost performance
  • Squoosh.app - a great utility for resizing images for the web
  • NEW POST! Creating OpenAPI from HTTP Traffic

View Details

Matt and Phil are joined by Matthew Reinbold, director of API Ecosystems and Digital Transformations to discuss Postman's State of the API 2021 report, detailing various data points from around the API world from which specification people turn to, to how confident people feel deploying their APIs. They also discuss various topics around remote work, how APIs enable more remote work and what will happen in the next few years for APIs.

Notes:
Matthew on twitter: https://twitter.com/libel_vox
Postman's State of the API

View Details

  • Should endpoints be named after the action, like
    • /getThing
    • /updateThing
    • or after the resource with different HTTP verbs, like
    • GET /things
    • POST /things?
    • What are the reasons to go with one or the other?
  • Async operations with REST APIs - how do you do it?
    • long callbacks, short callbacks
    • polling
    • pubsub
  • What's the point of a Webhook?
  • "Working with Webhooks" Lorna Mitchell @ PHP Barcelona 2019 link

View Details

Matt, Mike and Phil get back together after a wild summer vacay of drinks, sand, trees and getting hit by a car while out on a bike. We catch up with Phil and Stoplights efforts to reshape API Documentation as well as responsible OSS Community Involvement.

Notes:
Matt's photography site
Stoplight Elements
Stoplight Discord
APIs You Won't Hate Community

View Details

Matt is joined by Taylor (@taylor_atx) and Kin (@apievangelist) to talk about the API Specifications Conference (ASC). We talked about how the conference is shaping up, the kinds of talks they are hoping to put forward in the program, how it is organizing a conference under the Linux Foundation and how can you get involved with such an important, yet very niche, topic in our community.

Notes:

@apispecs on twitter
ASC conference website
Call For Papers
Conference Sponsorship Information

View Details

Sparked by this tweet, Matt and Mike have an informal chat about the whole Swagger to OpenAPI transition and why OpenAPI hasn't really been able to step away from the shadow of Swagger. We discuss ways communities members can help with pushing the OpenAPI naming over using Swagger, how SEO plays a fair bit into the whole thing and why naming things is just plain hard. 

View Details

Matt and Phil are joined by API developer Hunter Skrasek, a friend of the pod, to talk about his experiences moving their APIs from a monolith to a microservices architecture and his team is utilizing API Gateways and Service Meshes

Links:Hunter on Twitter
API Gateway
App Service Mesh

View Details

Phil, Mike, and Matt get together for a discussion about how to safely sunset an API endpoint with the end goal being deprecation. We take a look at why its important to be overly communicative about it, what an appropriate length of time is from announcement to deprecation and how you can do it in a way that doesn't make your team or external consumers angry. We talk about the HTTP Sunset Header and the potential HTTP Deprecation Header and how those can make the process of knowing when APIs are being deprecated a lot smoother. We also looked at a few popular JS libraries and discuss how they deprecated themselves.

Show NotesRequest.js deprecation notice
Moment.js deprecation notice
IEFT HTTP Sunset Header Field RFC
IEFT HTTP Deprecation Header Draft
Facebook botching a feature deprecation

Sponsor
Interested in sponsoring this podcast to get the word out about your API product to our listeners? Drop us a line at @apisyouwonthate on twitter and lets get it set up!

View Details

Phil, Mike and Matt sit down to talk about Parler and why their APIs were so great for hacktivists who wanted to make sure that the data was never lost. We talk about degraded services and circuit breakers, two big things that probably could have kept the data from being exposed as well as stripping files of EXIF data from uploaded images. We also venture into the topic of what is the role of service providers and social media going forward.

Sponsors:Stoplight makes it possible for us to bring you this podcast while we nerd out about APIs. Check them out for their tooling around documentation with Studio, an app that makes API documentation an absolute joy to work with.

Show Notes:
Auto-incrementing IDs - Giving your data away
HTTP/REST API File Uploads
How Parler's Data Was Harvested

A transcript is currently being made and we will update the description as soon as we get them.

View Details

Harsha Reddy, a Senior Software Engineer on Internal API Platforms for Wayfair, joins Matt and Phil to talk about what its like to build tools for developers that use a myriad of languages from PHP to C# to Python and some Java thrown in for a good time. We discuss how Wayfair empowers their developers to pick the right language for a job and then what kind of tools they employ to make their day to day lives at Wayfair easier.

Sponsors:Stoplight makes it possible for us to bring you this podcast while we nerd out about APIs. Check them out for their tooling around documentation with Studio, an app that makes API documentation an absolute joy to work with.

Links:

  • https://pactflow.io
  • https://eng.uber.com/microservice-architecture/
  • https://buildkite.com
  • Harsha on Twitter: https://twitter.com/stymied_sloth

View Details

Phil, Mike and Matt get together before Phil leaves the UK in search of roads he can bike on. We talk about what is coming up for new Stoplight releases and then we take a sharp pivot to talk about mental health and how it affects Matt and what he is doing to take care of himself.

Sponsors:Stoplight makes it possible for us to bring you this podcast while we nerd out about APIs. Check them out for their tooling around documentation with Studio, an app that makes API documentation an absolute joy to work with.

View Details

A quick note before we get started: We recorded this episode back in April of 2020 when everyone was quarantining and making bread to post on instagram. Fast forward to now, in June, American cities, and cities around the world are joining in, protesting the systemic racism that has long been an issue in our societies. While our energy and focus turned to current events, editing this episode took a seat on the backburner. That said, we have it ready… but it couldn’t be released at a worse time. Three white dudes talking about APIs while our friends in other communities are fighting injustices that have long kept them down seems to be a bit tone deaf, and we know that, recognize that and commit ourselves to being involved. There are a lot of conversations we want to have around this topic both in the API world, and outside of it. We don’t want this episode to take away from the discussions going on around such important and heavy topics, but we hope this can serve as a way for you to take a break while you travel to and from a protest. If you are going to protest please be safe, drink as much water as you can to stay hydrated in the heat and know that things are changing for the better. To all the Black API developers out there: we see you, we're fighting with you, and we want you to know that we're listening. From all of us at APIs You Won't Hate: Black lives matter.

Recorded back in April, Matt and Phil are joined by Marc-Andre Giroux to talk about the APIs he works on at Github and his fascination of GraphQL. Marc-Andre recently released a book titled "Production Ready GraphQL" where he talks about schema design, tooling, architecture and more. We take a dive into knowing when GraphQL is the right tool for the job, versus when to use REST and talk a little about the whole quarantine thing that was happening.

Sponsors:Stoplight makes it possible for us to bring you this podcast while we nerd out about APIs. Check them out for their tooling around documentation with Studio, an app that makes API documentation an absolute joy to work with.

Twitter: https://twitter.com/__xuorig__
Book: Production Ready GraphQL
APIs You Wont Hate Jobs Board: https://apisyouwonthate.com/jobs
APIs You Wont Hate Slack: https://apisyouwonthate.com/community

View Details

Phil and Matt, both in a loose definition of isolation, find time to talk to Arnaud Lauret (https://twitter.com/apihandyman) and talk about API Design and Review. We discuss why you should spend time designing and reviewing your API and the process of reviewing API Designs before the code is written. We also ask Arnaud what he looks for while reviewing, the tools he uses to review API design docs and then Phil starts dreaming up what the ideal API Review tooling looks like.

We also talk about life in quarantine, as France completely shut down and how Phil made it back in time to England before the lock downs took place.

Sponsors:Stoplight makes it possible for us to bring you this podcast while we nerd out about APIs. Check them out for their tooling around documentation with Studio, an app that makes API documentation an absolute joy to work with.

Links:

https://twitter.com/apihandyman - Arnaud's Twitter
https://bit.ly/designwebapis - The Design of Web APIs by Arnaud Lauret
https://en.wikipedia.org/wiki/The_Design_of_Everyday_Things - The Design of Everyday Things by Don Norman
http://apihandyman.io/ - Arnaud's blog
http://apistylebook.com/ - API Stylebook, a collection of API style guides

View Details

Phil, Mike and Matt talk about Matt's adventures with APIs returning 200 OK while having an error message in the body, causing extra work and frustration. We look at why this is a common thing in API development and what we can do to help people utilize the codes that are there instead of relying on 200 OK.

Mike brings up Microsoft and what they are doing with their push to not only go Carbon Neutral but also Carbon Negative to make up for their past. We wonder what that will look like, and also bring up what an individual person with a developers salary can do to start helping out more since we (developers) can generally afford it over a lot of other people.

Keeping on the environment, we also take look at some things a developer can do with code to help the environment, particularly around caching and responses.

Sponsors:Stoplight makes it possible for us to bring you this podcast while we nerd out about APIs. Check them out for their tooling around documentation with Studio, an app that makes API documentation an absolute joy to work with.

Cheers!

View Details

A while ago, we put out a call to Twitter to invite listeners to send us their questions and we would answer them. We received 4 really good questions, covering topics like supporting content negotiation, how to craft and and define an SLA for your API, why companies seem to disregard standards when it comes to their API SDKs and should you version hypermedia.

Sponsors:Stoplight makes it possible for us to bring you this podcast while we nerd out about APIs. Check them out for their tooling around documentation with Studio, an app that makes API documentation an absolute joy to work with.

View Details

In this episode, Phil talks about how his trip across the United States via train went. We also talk about how to monitor APIs and what is the best APM solution for monitoring GraphQL endpoints. We also talk about the progress being made by the Stoplight team with both their tooling around Async APIs and also work being done on Studio.

Sponsors:Stoplight makes it possible for us to bring you this podcast while we nerd out about APIs. Check them out for their tooling around documentation with Studio, an app that makes API documentation an absolute joy to work with.

Links:

Article: GraphQL Performance Monitoring Is Hard

Why GraphQL Performance Monitoring is hard

Phil's repo of companies working to help save the earth

Awesome Earth --- Support this podcast:

https://anchor.fm/apisyouwonthate/support

View Details

Last time on APIs You Won't Hate, we laid the ground work for this podcast. This time (after a failed attempt when Phil didn't press record) Mike, Phil, and Matt talk about whats new with Stoplight, how front end developers like Mike can use the Stoplight suite of OSS products to make Front End Development better, and where they are with the books!

Sponsors:Stoplight makes it possible for us to bring you this podcast while we nerd out about APIs. Check them out for their tooling around documentation with Studio, an app that makes API documentation an absolute joy to work with.

View Details

Welcome to our new podcast! Phil Sturgeon (@philsturgeon), Mike Bifulco (@irreverentmike) and Matt Trask (@matthewtrask) get started with the first episode where we talk about bikes, APIs and our goal for the podcast. We break down Phil's adventures in Europe, how his new books are going with the help of Mike, and some other nonsense.

Find us in the APIs You Wont Hate slack for questions, help, mentoring or other things!

Sponsors:Stoplight makes it possible for us to bring you this podcast while we nerd out about APIs. Check them out for their tooling around documentation with Studio, an app that makes API documentation an absolute joy to work with.