What Sucks About Building APIs (& How To Make It Better)

Captions provided by White Coat Captioning (https://whitecoatcaptioning.com/). Communication Access Realtime Translation (CART) is provided in order to facilitate communication accessibility and may not be a totally verbatim record of the proceedings.

JASON: Hello, everyone, and welcome to another episode of "Learn with Jason." Today on the show we have James Perkins, James, how are you doing?

JAMES: I'm doing well, how are you? Thanks for having me on.

JASON: I'm so happy to have you here. I feel like you've been working on some really cool stuff and I'm very excited to dig into it. Before I do that, let's talk about you. So for folks who aren't familiar with you and your work, do you want to give us a bit of a background on yourself?

JAMES: Yes, so my name is James, I have been around for a long time now, this is year 15. I've done everything you could probably think of. I started in the automotive industry. I want to gambling, did the lottery, did fintech for a while, and then most people that know me at least in the last few years is when I went to Clerk, which is obviously authentication. Now I co-founded a company called Unkey which works in a different authentication space but in the same place.

JASON: Right, right. And this is I think a very interesting space to be in, because APIs are easier than ever to start these days. Like, you can pull, you know, whatever your favorite framework is or no framework at all. You can write a handler function, and you've got an API, and it's deployed in, you know, a few seconds. So what -- with it being as easy as it's ever been to get an API up on the web, what is it that gets hard? Or I guess, what are the sneaky things about building APIs that you've noticed that made it worth creating Unkey?

JAMES: Yes, so I think you start with this vision of an API, whatever it may be, and then you start to realize, okay, I have an API now, how do I know who or what should be accessing this API? So that's your problem number one, authentication in that space, how do I know this person should be allowed this API, because if it's something with data behind the database or whatever, you don't want anybody just being able to access that info. So problem number one is like, that's an issue. Then as you kind of build it out and you're like, okay, now I have that API key and I can give that to you or to whoever, and great, that's perfect. Okay. Now my problem is, is that, well, Jason's in America, but another user is all the way in the UK. Okay, now it's super slow, because I'm only in one place, right? So I'm using U.S. east one as an example but it could be anywhere, that's where I have my API and I'm checking all my keys and now it's super slow. So now I have to figure out how do I move this everywhere in the world so anybody in the world can have the same experience as someone who lives right next to a data center? So you kind of figure that out for a while. That's a whole resource that can take an entire team to get right. So you figure it out, great, now everybody's globally distributed, it's super fast, oh, no, now somebody is doing the same thing but now they're abusing the API, right? So now you have to figure out rate-limiting, how does that work, do I need consistent rate-limiting, do I need fast rate-limiting, do I care if you slip through the cracks or do I want it to be really strict, so once you hit that rate limit you're done.

JASON: Right.

JAMES: Then you have that problem. Then you move into another problem, maybe I need a key that only lasts a week. Now I have to do something like that. So then, okay, now I have this API key that now expires in ten days, like how do you make sure that that's actually true, and the resource is available, right? And the list goes on. Maybe you're in the AI space and you need a key that only lasts for a hundred tries because you're using like, I want to generate a call picture and you pay me $10 and you can do it ten times. Like, how do you do that? So all that stuff starts to like trickle into growth. The API at the beginning, yeah, that was really easy. Then you give them API keys, that part seems fairly simple. And then you start compounding on issues that come up. And usually what happens is, these issues come up when you least expect them, right? So you build out whatever it is, and then, oh, gosh, someone is abusing our API, you have to figure out how to do rate-limiting really fast, then you implement it. You might not do it right, it might not be scaleable. All these things start to crop up. Once you've dealt with the basics of protecting your API and that kind of stuff, now you have to think about, how can I track who is using the API and what are they doing with the API, should I be up-selling they say person doing the API, because maybe they're doing ten times as transactions as the other person. Then you start to think about those parts of your API. That's another thing you have to implement, right? How do I track who is verifying keys, who is not verifying, all those things start to come up. By the time you get to the end, you've spent years building out this API and then it's just a maintenance nightmare. You've got pieces everywhere, probably half the team has left, then it just gets bigger and bigger and bigger. So getting started with APIs today, they're super easy to get, but once you start protecting those APIs and thinking about ownership and keys and revoking them and updating them and all those things, I start to scale out how long that project could take.

JASON: Yeah, I think what I've noticed in my career at least is that when I start building something, you know, my instinct is to say, well, I'm smart, I can build this. And then I'll build it in-house, it will be way cheaper, it will do all these things. And then I very quickly find myself with a bunch of bespoke systems that all need attention and care. And the amount of time that I have to build competitive features is dwindling. And all I'm doing is spending a bunch of time working on something that is like table stakes, like if the auth doesn't work, my product is broken, and I can't do anything, right? So I'm dedicating my time to these fires, operational boilerplate, basically. That to me has led to -- I've been pretty vocal about, I just don't think it's worth it to build undifferentiated software. Like, to me that is what I would call undifferentiated labor. It is you spending time on something that has no value, right?

JAMES: Yes.

JASON: Unless you're a huge company, the economics just don't work out. Like having somebody dedicated full-time to maintaining your like auth boilerplate. It's so expensive. Salaries aren't cheap.

JAMES: Exactly.

JASON: It's almost certainly going to be cheaper at the outset to pay this problem away. Like you solve this problem with money, not with time, because especially when you're small, time is so, so expensive, because you have to build something that makes you stand out, right? And so that's why I was kind of excited what I heard what you were doing here, because I have built a lot of APIs. But they never get beyond the toy stage because I don't want my job to be maintaining the productization of an API. So I just make it fun, and if it's too expensive to make it fun, I shut it down.

JAMES: That's it.

JASON: A good comment in here, it's a nice exercise at the expense of your company to learn that stuff. And I do think that learning this stuff is valuable.

JAMES: Absolutely.

JASON: Doing it all the time, probably isn't what you want to be doing as a dev anyway. The trap that I've fallen into in many of my engineering roles is, I join the company, I get really excited about solving a problem, I build something custom to solve that problem, and then I never get to build anything custom again because now my job is maintaining the custom thing I built.

JAMES: I've done that too. I've done that numerous times. I built OCR software for car registrations in California. So essentially what it did was, you could send all the paperwork to California and they would just get a giant scanner, they would throw it all in there and the bespoke software would then scan it all and basically make them into deals and then they would verify those and send out the plates. That was the whole thing. I spent like a year building it. They approved it. It was a really big contract. They approved it, they loved it. And then my entire career until I left was literally being on call, hi, yeah, okay, bug, got it, I'll fix it, okay, now try -- and that was my entire career after that. That was the last bespoke thing I ever built. After that I was like, nope, let's do teamwork. If you look in today's world, like authentication is a hot space right now in general. If you look at front end auth which is where most people think of authentication, auth zero, what they were doing five years ago, what Clerk is doing today, they were entirely on the same idea of scale but they're doing completely different things. Clerk is definitely all about, I want you to go as fast as possible today, and then tomorrow, you know, we want to give you all these features that are going to allow you to scale, et cetera, et cetera. Auth zero, you get the whole package, enterprise is really expensive, and then like almost every single time, whenever you talk to anybody that uses a third party auth problem, they're always the same question is like, oh, well the cost is going to be so high by the time you get to a million users or a thousand users or 5,000 users or whatever the number is, right? But if you're in a revenue-driven model, it's going to be pennies on the dollar, right? But you've saved yourself probably three to six months of implementation and then years of maintenance. You've got a whole deal of updating and maintenance and features and you don't have to worry about that.

JASON: Somebody will start doing the math, this will cost me 70, $80,000 a year, and I'm like, how much does an engineer cost, so where is the time coming? And that to me is, like, if you can afford to put the engineer on it, you can definitely afford to pay for the service. And I have this -- like I very much understand, I have this relationship with money where paying for something I can do myself gives me this like physical sensation of, ugh. But the other physical sensation I get is depositing checks and not maintaining that software.

JAMES: Exactly. It's like a twofold something.

JASON: That is a much better -- [laughs] any pride I get from building it myself, I can massage that pride with the extra money [laughs].

JAMES: Exactly. You can roll this all yourself, I'm not saying you can't, go ahead, do it, whether it's auth, API auth, rate-limiting. But I would rather spend my time building feature sets or improving other parts of the products where I can capture more enterprise users or business users or whoever I am, I would rather capture those people and be like, please give me your contract and I don't have to, oh, my API auth this month cost us $1,000, eh, I've got these contracts now, now it's like 1% of my overall cost, like who cares? I never have to worry about it.

JASON: Yes. And I think when that scale becomes a problem is, far beyond most -- like what most companies are dealing with, like sure, the Amazons and the IBMs and the Googles of the world, they've got scale that we don't really fathom. And the economics are different for them. But like, for the average SAS product, what we're really looking for is like a thousand paid users.

JAMES: Yep.

JASON: There's so much money in those scales of like, you know, a thousand to a million users, like we're not doing the millions of throughput and, you know, the petabytes of transfer and all that stuff that usually makes these things economically infeasible where suddenly you do want to have your own data center but almost certainly you don't until you're a trillion-dollar company.

JAMES: Yes. And if you look in any of those sort of builders that are out there today that are building products, like, I mean, if we use Theo as an example with upload thing, great products, genius idea of like simplifying uploads for files and images, right? But like if you look at the product itself, they're using Clerk, so auth, Clerk for organizations, another piece of their B2B gone, so Mark and Theo and Julius can all focus on, hey, we want to build this really good product and now we've got rid of this entire layer of stuff we don't need.

JASON: Exactly.

JAMES: If there's a problem, I reach out to Clerk, it's broken, what am I supposed to do, whoever fixes the problem for them, they release it, great, thanks, we move on. If you can reduce the time it takes to get to market, you don't have to be the first person to market. You don't have to be the third person to market. But if you offer something that seems shinier or better than somebody else, that's how you build success.

JASON: Yeah.

JAMES: And that's proven here, just with Unkey, some of the back story behind it was, Andreas, the co-founder, people already know him in the open source space, he's probably in the chat right now doing work and listening, but his whole thing was that he built an API, and then built out these features, didn't do it very well, then had a second product, did the same thing, buildout was a little more scaleable, but still it had boilerplate, stuff you couldn't really need. Then the third time, okay, if I'm building this every time, you're copying and pasting it, surely at some point there must be other people out in the space doing it. And that's kind of how we got started, was just like, yeah, this is a thing, and this is a problem, just like front end was five to eight years ago, auth zero was the option or you did it yourself. Now you look in the space, there's Auth0, there's Clerk, there's Stitch, there's Panko, a million different options out there, each of them has their own special set of features.

JASON: What's amazing about this space, you listed off all those companies, you could have made up at least one of them and I would have had no idea and I definitely believed every word you just said [laughs].

JAMES: That's the thing, you know the big players in the space and everybody else is in there doing their own thing, cutting their own slice of the market. It's a crazy time. From 15 years ago, where, you know, I was building Java software and there wasn't any options for anything and everything was in-house built and it was hard, and it sucked, and then like watching the years go by, every year something new and -- in the space or something pushed it out further, whether it was, you know, they were like, hey, look at this cool thing we've built, now you can deploy with one click, Netlify, click GitHub and now you can deploy every time. That didn't exist when I was around, we were manually copying files and hoping it didn't break.

JASON: [Laughs] I remember, I had my Cyberduck window open and we would just drag the folder in and hope [laughs].

JAMES: I remember when DACA was a new thing that had taken over that space and we had like a guy who was super great, I still keep in touch with him, he was like, we should do DACA, it will allow us to roll back really quickly. If it breaks, we can get the old image, put it up and it will immediately be available again, we can make like a little -- so he built his own in-house like deployment system, similar to like GitHub Actions, where you can like click deploy and it would push the DACA file out and you could click rollback and it would -- and that was the most amazing thing we had ever seen in like five years that we were working in this space.

JASON: You know, what I think is fascinating is, like you just said that, and it sounded so similar to other companies where I worked, where they had the same thing, they saw this thing, it would make their lives easier, they didn't have any way to do it easily so they built something in-house. And it was CICD, it was some like deployment tool, it was some auth thing, and it was so cool when they did it, and it slowly became an albatross around the company's neck because, you know, they didn't know how to get off of it. And the person who worked there, who built it, was promoted on something else, they had left that team, they left the company, and the people who inherited it like mostly understood it but not entirely. So the thing went into like permanent sunset mode. There was no new features, we're just going to keep it alive.

JAMES: So many times I saw that.

JASON: But this is what's interesting to me, you just listed off all of these companies that have entered the space for auth specifically.

JAMES: Mm-hmm.

JASON: This is after I think the pretty clear appearance that Auth0 was the only thing we needed in the space, it was over, auth was solved, Auth0 does it, if you don't need what Auth0 does, you do it on your own, and if you're too big for that, you get Okta. The appearance of these companies to me shows the strength of having access to these tools that let you only focus on differentiation. Like this is why I get excited about this space, if I know that for me to stand up an API that does something novel, takes a few minutes to spin up on Vercel, Netlify, whatever I want to use, and securing it in a way I trust, with rate-limiting, individual keys and all that stuff, only takes me a few minutes, if I can sign up for a service to do that, and getting the auth into the web app like the dashboard part only takes a few minutes using a service, then all I'm ever spending my time on really is marketing and features. Like I'm telling people it exists and I'm building things for them to use. And that becomes such a good iterative cycle that allows me to have an idea, build the idea, try the idea, see if people pay for it, get the feedback, change, ship, get feedback. And we're just in a space now where this is possible at a speed that has never been possible before, because all of these services allow us to just offload so much of the boilerplate that used to be an absolute showstopper for somebody who is a solo dev. Like, can you imagine ten years ago trying to build an API as a service and like get even close to a funded company's level of features and quality? Like, there was no chance.

JAMES: Never. Today you could do it in, you know -- I think like AI is the perfect example of the space right now. Like, the bubble is weird right now, and there's a lot of AI companies out there, but if you look at the space, like tomorrow, someone's going to launch another AI product, right? Like I think today we saw, you know, there's a new AI buddy for your phone, there's things out here, right? And just the open AI space, having that ability, okay, cool, I can integrate AI in minutes and now I have this API I can talk to, I can use something like Clerk, now I have auth, I have bot protection, disposable email protection, I have all these things that I don't have to worry about, no one can abuse my products, and three, I can ship the feature, whether it's making calls, generative AI, or I'm using ChatGPT 4 to produce essays or whatever, get the feedback, do all that, and people are making hundreds of thousands of dollars a month just doing that, because like all they have to focus on is they have this cool idea for AI. Ten years ago, if we did that, if open AI was a thing ten years ago, but the rest of the space wasn't here, so we didn't have Vercel, we didn't have an auth provider, we didn't have planet scale for databases or Vercel or whatever, that idea wouldn't even get off the ground. You would be like, I have a cool idea and I'm never going to think about that again and I guess I'll go back trying to figure out how to make node work ten years ago, or Java you know mapover correct things in Java. It was wild back then. You had to be willing to dedicate your entire life, if you have an idea, there's no -- there was no iterative like let me release an alpha and see what happens. It was like, I'm all in and this product has to do well and if it doesn't, I've just wasted two years of my life or whatever. Now it's like, I have two weeks because I've taken off from my regular day job, let me build a side project and see what happens.

JASON: The thing that's really fascinating to me, we're seeing a playing field that is more accessible than any I've ever seen, where if you have any amount of programming skill, you have access to launch a product on your own. Like, you don't have to be a full stack dev to build a full stack product anymore. So me that is such a game changer, because like you've always only been limited by your ideas, because you didn't have to build a web app to start a business. And so I'm not saying that like this is the only way. But for somebody whose skill set is building for the web, you no longer need to become a database ad man or become a cryptography expert or become back end dev ops expert. You can leverage companies to do it for you. You can go out, have an idea, build it in, like you said, a weekend, a couple of weeks, ship it, see if anybody wants to pay for it, and if it doesn't work, who cares, you're on the free tiers, shut it down and move on. You can iterate and iterate and iterate. It's never been possible like this. So I think web dev is easier and harder today than it's ever been, easier because of the access to these tools, harder because it's just complex. There's a lot to know. Having access to these tools does not replace knowledge of how they fit together, right? So it's not like we're taking anything away from the level of complexity of building something like this. We're just taking away from the level of effort required to get it plugged together once you understand how it all fits. And that to me is the exciting part, is you can really say, I want an API that somebody pays for that is protected by an API key, that allows them to do this thing, as you said, ten times, and they can pay me for another raft of API calls. I have no idea how I would build that. I know how I would build that, I wouldn't. I would talk myself out of it.

JAMES: Exactly. And that's what you see, right? It's just like, oh, yeah, I want to build this thing. When AI kicked off, yeah, I want to build this thing. We've seen some crazy stuff come out of the space. And then there's probably been, you know, another ten or 15,000 people that are like, I want to build this but I don't know how to do this part of this whole project. And like, there's nothing out here in the space, what do I do? And, you know, now, yeah, I think it's easier than ever to figure out how to plug the pieces together. You have the idea, you kind of play around with all these different tools. You build the project. Yeah, if it works out, great. Cool, revenue, or whatever, you've unlocked whatever it might be. If it doesn't work out, learning experience, now you know about this product and how it works. You know about, you know, how they integrate with other parts of your project, how can I make it faster, what can I do better next time. And then you start to think about -- more about architecture and building and how all these things link together. And that allows you as a developer to grow in different ways than before, where it was literally you were a back end developer, you're a front end developer, and that was it, back 15 years ago, that was it, you were one or the other. You were never a full stack, you could never be in that space. Then full stack engineer came along and you could do both, you were skilled on both sides. But now it's like, if you're a front end dev, that's it. If you're a web dev, you're just a dev, you can do any part of the stack without any worries. Next year is a great idea of building a full stack out where you don't need to know about a lot of stuff. If you don't worry about servers and you're not worried about that, having the server space and being like, I need an API, I make a folder or a route and call it whatever I need it to be, it's done, next, I just need the logic that fits in there. We never had that. That was wild to me. I remember when that came out, I was like, oh, my gosh, the world has changed.

JASON: Yesterday I was thinking about -- Sunil was talking about serverless, trying to figure out how web sockets fit in a serverless space. It occurred to me, are we thinking about servers and serverless unless we're the ones building the Frameworx anymore? Like, you don't choose server or serverless with Next or any of them, you just deploy. And depending on where you deploy, under the hood they'll choose if it's going to be server or serverless or static or whatever. But whatever, it's an implementation deal, it's fully abstracted away now. I don't even wonder, I'm like, oh, I have a remix site, I'm going to deploy it to Render or to Vercel which is serverless. It doesn't matter, who cares? It's a complete implementation detail now. And what I really like about that is that it's yet another level of complexity that only matters when you have edge cases. Otherwise it's just become a part of, when I hit a key on my keyboard and a letter shows up on the screen, I'm not thinking about all the things that happen to make that happen. I just know if I push a key, the letter shows up. And that's sort of what I'm feeling with deployment these days, is like, if I've got a site, I deploy it to Git and whatever server I have it hooked up to takes it to the Internet. I don't have to think about any of that shit anymore.

JAMES: That's exactly it. Unless you're building out a product or a language or whatever, you don't have to worry about what's happening behind the scenes, is this server or serverless, should it be this, should it be that. It's, cool, I push this button and whatever product I've chosen as my deployment area is done, awesome, thanks, everyone, check out my cool website that's super fast. And you don't even have to worry about why it's so fast, all that stuff is taken care of, CDMs and all that other stuff you had to worry about, all that's gone away now. In the API space, that's kind of where we're moving to, going from five years ago, where you're right, Auth0, that was all you needed, you just -- if you didn't want to build it in-house, you signed up for Auth0, you put in their web thing, it redirected you to their site, you clicked sign in, and that was it. And similarly now, I think the explosion in the API space is really happening. Whether it's API management or API documentation or, you know, STK generation, all these things are starting to appear, because people are figuring that, yeah, okay, the front end part of web dev is always super complex, and now that's kind of being served by a bunch of different companies, whether it's in the auth, database, whatever, Frameworx, et cetera. Now I think we're starting to see that, hey, now back end developers need some help, it's like, start building in that space and making it more easy to get these things going. And like you'll see startups less rely on things like CICD or even the way that like middleware, you used to have middleware engineers, I don't even know a company that has one anymore, but you used to these middleware engineers that would be reliant on things like gateways and that kind of stuff, that was their job, was like, make sure that this gateway doesn't go down, and make sure it doesn't -- I don't think they exist anymore. They might. I'm sorry if you are a gateway --

JASON: They trained us, if we were middleware, because I was middleware, I drifted into building like the back ends of -- I built a lot of stuff in the back ends of Gatsby when I was there, and then moving on to, you know, the Next, they've all got their middleware tiers right now, those are just sort of -- we're converging on patterns where all the Frameworx look so similar these days, like they've all picked up some form of like hooks pattern, they've all picked up some form of signals at this point, you know, the good ideas of View got adopted by React, the good ideas of React got adopted by everybody. It seems like we're all borrowing ideas at this point and we're converging on some patterns that make it possible for, you know, what you're talking about with APIs and with moving into the back end space. I think a lot of that is because we can confidently say we've arrived at standards. Like we're using jots when we do authentication through APIs. We're dealing with like specific flavors of like oh, Auth2 is what everybody landed on. We're not arguing about that anymore. Those sorts of decisions are driven by our Frameworx, are driven by the way we fit everything together. And oh, my goodness, we have been going for 30 minutes. James, normally we hit a natural stopping point, clearly it's time to look at code. But I've got to cut us off. I could go all day. Are you ready, can I bring us over and let's do some code?

JAMES: Yeah, let's do some code, let's talk about Unkey, let's show it off and we can go through it all.

JASON: All right. Here we go. Before we start I'll do a quick shoutout, we've got live captioning happening today being provided by Lee at White Coat Captioning, thank you, Lee, made possible through the support of our sponsors, Netlify and Vets Who Code, to make the show more accessible, which I appreciate. We're talking about Unkey today, let me throw that up on a link for everybody. James is the person giving us the lesson. And that's all I know. James, if I want to start learning, what should I do first?

JAMES: So the first thing you need to do when you want to use Unkey, the first thing you should do is sign up for an account. If you click the start for free or the dashboard button it should take you to the sign-in. It should take you to any auth provider or you can sign in with your email. Once you get signed in, you're dropped into a space where we essentially onboard you through the products. Your screen has gone black, that's interesting. Is that you or us? There you go.

JASON: It was just thinking.

JAMES: It's in dark mode, apparently. This is your workspace, essentially a way to group APIs together, think of it as a giant space where you can put all your APIs, development, approach. It will create the workspace for you and you can create your first API. You can call it whatever you want.

JASON: What should an API be today, what should we be delivering?

JAMES: I don't know. Something spooky because it's Halloween.

JASON: It is spooky season.

JAMES: Perfect. Essentially we onboard you through how Unkey works. The first thing is we have this thing called a root key. The root key is essentially a way for you to create other keys, access resources, update keys. They are essentially a version of, you know, like a secret key or something in the space where like stripe, for example, stripe secrets, secret key. Essentially this is the keys to the kingdom.

JASON: This is my admin user, if I have this I'm allowed to do anything.

JAMES: Yes. Essentially this allows you to create new keys for users, all that kind of stuff. Go ahead and create your root key. We'll only show this to you once. So once you click create, we'll copy it somewhere offscreen for now. Just wherever you want.

JASON: Let me find a spot I can toss it over here.

JAMES: Perfect.

JASON: Okay. Got it.

JAMES: Cool. Then the second code block here is actually a way to create a key that could be used for your API. So if you actually copy this code request, we'll show you how it works, if we drop it in a terminal of choice, we can delete the root key or whatever later, I'm not worried about that. You can do it with VS code if you like.

JASON: Let me just do one of these and one of these.

JAMES: So we provide you with, this is the key on the left. That's the actual key that you would give to your end user. And the one on the right is the key ID that you can use to identify the key in the user, either in the API itself or in our UI. So now you've created this key. If you copy this key as well or keep hold of this key because we'll use it in a second, we'll just paste it offscreen, and then go back to the UI, then we can move on to the next step, which is essentially the most important step of this entire thing. So you click on verify a key. This is essentially verify endpoint. This allows you to verify the key you just created to see if it's allowed to access a resource of your choice. So if you copy and paste that in and drop the API key that you had.

JASON: So let's do that.

JAMES: Then put the key you created, which is just above so why really need to copy it, and then drop that key in there. Paste that in and hit enter. Okay. So you get this response back right now, which says valid true, which essentially for us is saying, hey, this guy is good, let him access whatever API you want or whatever resources. Okay. So let's flip back to full screen and we'll just do a few more things. Click let's go. Okay. You get dropped in. Here is essentially your Unkey workspace. In here you can do a bunch of different things. Let's talk about, if you click on your API there, this boopy stuff, inside this is the usage tracker here. In dark mode it's not as good, but in light mode it's -- but --

JASON: You're going to make me do --

JAMES: You can change it if you go to settings. It will let you change it so you can keep dark mode on forever. If you go to settings on the side, I think it's under user, and scroll all the way down, there you go, just change it to light mode. All right. Our dark mode is still kind of a work in progress. That's better. As you can see here, you've got this big black bar. Essentially that says this is a successful verification. If it was rate limited, it would be a different color. If you succeeded, it would be a different color as well. This is an overarching look at what it looks like. It will show you what dates are the most popular, how many verifications where successful, unsuccessful, those kind of things. How many keys are here, how many active keys, et cetera. If you click on keys tab here, this is the key we just created as part of the onboarding flow. As you can see, it's very limited, it doesn't have a lot of info here. If you click the three dots on the right hand side, and click details, here you can actually see a breakdown of this in key. The request, how the request was sent, what region of the world you sent the request from, was it valid, invalid, you basically get an up to date verification, you can kind of dig about and see, if someone is reporting, I tried to use your API and it said this, you can look and change those settings.

JASON: Yeah.

JAMES: Which makes it really good for business purposes and all that kind of stuff, you can dig in and say, oh, that's weird, why did this request come from a different IP than it's come from before or a different region, and you kind of dig in. And then before we start coding this, just a few more things in the UI that I think are pretty cool and neat, if you click settings here, you can actually update the key itself. So you can enable remaining uses and say like this can be used a hundred times. Then yes, if you click that type a number in there and hit save, and that should save, and then now you should get back a different response. It may still be cached right now, maybe. Let's check. If you go to the overview in the UI one more time, you'll actually see how many usage -- yes. So I think we've probably got a caching issue that I'll have to talk to Andreas about there. But we can create a key in a second, I'll show you how you do it through the API. But essentially in here you can change all the settings, you can put rate limiting on, you can turn it off, all those kind of things. And yeah, you know, you can make its expire, you can add some metadata, you can give it a name so you know which key it's for.

JASON: Oh, and so metadata, we can even do something like rules or whatever, and give it like the -- I don't know, post create or something.

JAMES: Yes. So right now we don't have authorization, like roles and stuff like that. But that is the feature that comes in November.

JASON: Oh, okay.

JAMES: There you go. Andreas says caching might take 60 seconds to reflect updates, it will get faster. I knew he would be around. If you do it in the API, it's better. But yeah, so essentially here you can put in metadata, you can put your roles or whatever you needed, maybe it's a stripe ID, all those kind of things that you might need that you need access to on the key. And then the final thing we'll show off in the UI, then we'll start doing some stuff in code, if you go back to the API section, click on the API again. We probably could have done that easier. And click create key in the top right hand corner. You can actually create your own key here, give it a prefix, for example, so it will be -- so you can put prod or dev or spooky or whatever you want in there, you don't need to underscore, we'll put it in for you, I'm pretty sure. And then you can add like the owners, you can put Jason or, you know, whatever you needed in here. And then in the advanced section you can actually put in -- go ahead.

JASON: Sorry, I was -- something was clicking in my head. So if I'm creating this, so if I say I've built an app, I'm using Clerk for my users to log into my web app, I would be able to put the Clerk ID here.

JAMES: Bingo.

JASON: As the owner, so I know this API key is associated with this Clerk user so I can then easily like, oh, this user deleted their account, go delete every API key associated with this.

JAMES: Exactly.

JASON: I get it. Very cool.

JAMES: And vice-versa, you can do, oh, this user is really aggressively using the API, let me send them an email and figure out what are they doing and how can we help them, those kind of things. But in here, yeah, so in here you could add like rate limiting, you could add usage, the metadata again, the expiration date, this will get added to the key immediately and you'll be able to use it from there.

JASON: Okay. So let's add a number of uses. We'll give it -- let's give it five uses so that we can actually break it.

JAMES: And when you click create key, it will give you the key and give you the verify, you can copy it and hit the API and that should give you immediately -- you see now we have this remaining 4 on here. If you continue to do that, remaining 3, remaining 2, remaining 1, and then remaining zero, and the next time you hit the API you see valid is now false and then you've got this remaining zero and a code here, key use is exceeded, you can go and look up what that key looks like, like that error message, you can go look in the docs. If you click keys and go to that one and click the details on the right hand side, and now if we look at that, you'll see now we've seen how many uses they've tried, which was six. You can see that five of them are successful, one was usage exceeded. Then you've got all the details below. Now you've got this whole picture of how a user may actually be using your product. And of course --

JASON: So this is for a single API key. Then when I come back out, we've got all of our calls.

JAMES: Yep. But we don't have the usage exceeded on there right now. You'll see that in the future. We've changed a bunch of our metadata, so right now you only see one. The same idea, the same vein, that will show as, oh, that's usage competed, that's rate limited, so you can get an overall picture of the API.

JASON: This is super handy because if the thing you're doing right out of the gate is just trying to give people API access to something, and this has a lot of -- like this is everything that I would need aside from payment.

JAMES: Yes.

JASON: And that is really nice, because it just lets me try. I got the data, I think people would pay to use it, let me put this up for sale, I prototyped this in a day, and I can just ask for the first, you know, stripe payment. If somebody is willing to pay it, I can see if anybody is using this API, how are they using it, what calls are they making. That kind of stuff is really powerful for quickly validating something. And boy, do I find it tedious to implement myself.

JAMES: And exactly, right? So in a similar vein, as every classic company is built upon itself, so Unkey is built -- we use Unkey under the hood. So we have the similar idea, which is like, yeah, we need these analytics, right, we need these details to figure out like who is using it and what's being used and all that kind of stuff. And so we basically built the analytics as like, these are all the things we need, let's make it available to everybody. Like, we shouldn't hide this behind our whatever, we should give it to everybody and they can decide from the get-go if they want this or not or if they're going to even use this, because maybe you want to pipe it somewhere else and you use it in your own analytics, out of the gate we give it to you so you don't have to worry about it. As a side note, every piece of Unkey is open source. You can look at how we built Unkey and how we're driving analytics. If you go to GitHub, the top right before the dashboard, that should bring you here. This is actually the code. You can see what we're up to, what we're doing, how we built it, every piece of Unkey is here, nothing is hidden, nothing is private. So you can go and look at how we implemented it or how we implemented this. So you can really get an understanding of our SDKs, all the packages and everything like that. It's 100% open source, so you can go ahead and play around with it. If you haven't already, everybody should just star it so we can finally get to a thousand, we're almost there. But yeah, we're super happy that everything about Unkey is open source. That's the key element there, if you use Unkey today, and then like you decide you no longer want Unkey as the cloud platform, you maybe don't want to pay the services, maybe you already have ways to stand up Unkey, you can 100% do that. You won't get all the -- you would have to handle all of the, like, distribution and caching and everything else. But you can essentially do this all yourself and do it that way, if you prefer, as we've found. Bigger companies want to sometimes self-host their stuff behind racks and stuff and don't care about -- so it's 100% there, you can go and look at it and contribute if you would like. We're always happy to take on whatever you have. Let's move on, let's actually get some coding, let's do some code, that will be fun, right?

JASON: Let's do it.

JAMES: That's what people are here for. Let's make an app.

JASON: Create next or create next JS?

JAMES: NPN create next app. I think it's -- it's NPN -- maybe it is there. I type it so often that --

JASON: Yeah.

JAMES: Let's make it -- yeah, that's it, I believe that's it.

JASON: Oh, you know what I need to do before we do this, I have to move up a layer. NPN.

JAMES: Inside "Learn with Jason" dot dev, that would be really confusing.

JASON: We'll call this API auth her yes.

JAMES: Yes, whatever you want.

JASON: Use the source directory. I haven't used the app directory so you would have to teach me.

JAMES: It's going to be app directory anyway by default. It's basically the same thing, you'll be okay.

JASON: Okay. All right.

JAMES: Or if you want to do -- if you prefer, do no and we can do pages, less pressure on you, happy to --

JASON: Honestly, it's been so long since I built a next site, you'll have to remind me how this work. Yolo, let's ship it. I'm not customizing it. Okay. So we're installing dependencies into here. And I'm going to open this up.

JAMES: Cool.

JASON: And shut that one down.

JAMES: So the first thing we'll probably want to do is head over to the docs because we can kind of drive through docs as well as teaching. So it's just Unkey -- perfect. The first things that we -- you probably want to do is install the TypeScript package we have so that will allow you to do API stuff without having to use Rest. It's probably not in the quick start because that's in the UI. If you go in the sidebar in the top left there, yeah, there we go, if you go to libraries at the top tabs, keep going up to the right. And then you want that one. So yeah, it's just an NPN install at Unkey slash API. This basically gives you access to the SDK, you get things like automatic retries and things like that. If for some reason the API does reject it, it will try five times, making it easy to essentially try building out your API. From there we need to do two things. So with an API, you need -- and you're selling it, you need two things, one is to create a key for a user and the second one is of course you want to verify that against whatever resource they want to use, right? So those are the two things we really have to worry about in this demo. So what we can do first is, we can probably just create in the app directory, if we just create a folder there, and we just call it API, just to keep it simple, and then we create one called create, another folder called create, sorry, and then just route dot TS. And then we create another one called verify, for example, and then with route dot TS. Great. So those will be our API points we'll use for our users. Essentially create, we'll just put in some fake data, maybe we'll create a form in the page page. And we'll just, you know, put something in there. And then to verify we'll have a button that says verify. So the easiest thing to do here is probably work backwards. Let's do the API work first and then we'll do the form afterwards just because it's easier to kind of handle. So the first thing you want to do is go to create or route there. And then we have to remember how to do route handling in XGS because it's all new. It should just be an async function where we tell it post or get, it doesn't really matter.

JASON: And let's see -- you want to post?

JAMES: It's up to you. I was going to say, with a post request, you have to pass something like a user ID or just some data, we can pretend exists. Okay. So we've got that. So first we need to import the Unkey method that we need. So for this, if you go back to the docs, because I like to reference our docs at the same time, just so people can drive at the same time. So we need to do this part here at the beginning, which is the Unkey root key stuff here. So just import Unkey. And then essentially all we need to do is create something that substantiates Unkey.

JASON: Are you doing this inside or outside?

JAMES: We can do this inside the post request, that's fine. Perfect.

JASON: Then the root key is going to be -- is next still using process dot M?

JAMES: Yes, process dot M.

JASON: Unkey, root key.

JAMES: Perfect. Then we need to make that go down here. Is it dot --

JAMES: No suffix needed.

JASON: Unkey root key is going to equal -- we already showed everybody, I'll just roll this upstream.

JAMES: It's fine. We'll probably have to tell it because it's TypeScript, it will think it's undefined. Yes, it thinks it's going to be undefined because the process can be undefined. We can just tell it never be undefined, we promise. So now we have Unkey here. Essentially now you can make calls to Unkey however you want. If you do something like Unkey dot, you'll have a bunch of options there. So we have APIs, keys, and retry. We're going to be using keys here because we have keys.create. Essentially with the create, there is required field which is the API ID and the rest are all optional fields you can put in there. So the --

JASON: My API ID is, I'm going to intuit that it is this one here.

JAMES: That is indeed your API ID. You can put that as an EMV if you want or just paste it right in there.

JASON: I feel like we're going to use it enough that I may as well abstract it out. Then we'll process EMV dot -- what did I call it?

JAMES: We're both guessing, it's fine, it's fine.

JASON: I prefixed it. Okay.

JAMES: There we go. Tell it I'm going to be undefined. Cool. That's the API -- there's a question in the chat right now that says, that's the API ID for the root key? The root key actually belongs to the workspace, not the actual API. So you can use one root key for all your API IDs. If you had ten different APIs you could use that single root key. It's obviously easier if you have separate root keys for separate things but essentially you can make as many root keys as you need. It's actually the workspace that owns it. At this point, this key is actually basically going to be created when we call this endpoint. We could probably -- yes, timely response, and then just return Jason to stringify, perfect. If we're making this as simple as this, let's just make this a get request and after this we can make it into a post, maybe. Great. So now we have this key. NPN run dev. We should be able to call that endpoint, it should be local host 3,000/API/create. And that should give you -- there you go. There's a key ID. That's how quick and easy it is to create your keys. At that point you're ready to use this key whenever you want. We can kind of flesh this out in a second, but let's do the inverse, let's now verify this key. The way that Unkey works, just as we're kind of talking through this, we can make this a get request as well, and make it a post request and pass the key in, but just for simplicity, while Jason is typing furiously to get through all this, the way Unkey works is, every key is essentially prewarmed and cached as soon as you create it. So your first request as fast as your second request, versus in other spaces, for example -- actually I'll show you a different method that doesn't require that in a second.

JASON: That doesn't require this?

JAMES: You can delete that out, we actually have a method that --

JASON: I'll get it out of here.

JAMES: Everything is going to be super warmed and cached, as soon as you use the key the first time it will be as fast as the second time. There's a method here called verify key. And this doesn't actually require you to use your root key, because we're verifying the key, we don't require the root key as part of the verification step. So here --

JASON: Oh, nice, okay.

JAMES: You can do something like verify key and then pass the key. I think it's -- yeah. That should be it. That will verify a key.

JASON: That returns --

JAMES: Then that returns a result or an error. So you can use that as your const. The result will be, if it's successful, and an error will actually be if the API actually errors. So the result will have either result.valid will either be true or false. That should make it nice and easy. And then we should just be able to use that result.valid. I think it's -- yeah. I am right.

JASON: That's Boolean, we probably want to do something like -- we can do something like return new response unauthorized. And then we want a status 401. Otherwise --

JAMES: Just one this, this verify key is also asynchronous, you have to -- yeah. There we go. Perfect. And then, yeah, now if we actually make this get request to this verify endpoint, now we should see something else. There you go.

JASON: It works, then I can -- let's give it a broken API key.

JAMES: And yeah, there you go. So you can see how -- aren't we so good? It's like we've been doing it or something, it's like we know what we're doing. But you can see how fast the response is. You're not having to wait hundreds of milliseconds. It's like tens of milliseconds. Average time is the critical path in your decisionmaking tree. If it's slow, then what's the point? You might as well do it yourself.

JASON: Yeah, I think this is one of the things that gets really hard. As you build out a system and the system has more complexity, each of those steps in the chain needs a little bit of time. And those start compounding and this is how you end up with like a bank website that takes 14 seconds to load or something, because it's just like step, wait, step, wait, step, wait, and all we see is a spinner. But if you look at the network tab it's like, this API, then this API, then this API, and you finally see whatever page you were trying to go to. So yeah, maybe doesn't seem like that big of a deal in isolation if your call takes 300 milliseconds. But if this is one 15, 300 milliseconds is -- what is that, 4.5 seconds of waiting for that chain of 15 calls to resolve.

JAMES: Yes. And if we're the bottleneck, we've failed, essentially. The idea here is, your decisionmaking, whether you're going to get to a database or other service or whatever it might be, our part in this process should be the shortest amount of time.

JASON: Yes.

JAMES: And we should be able to give you a response in under 30 milliseconds, whether it's let them get to this resource or don't let them get to this resource. And by the way, that's really tough. Shoutout to Andreas, he's probably still in the chat somewhere, he gets distribution like no one I've ever met before. And his work on making it incredibly fast right from the get-go was incredible. He did a lot of work behind the scenes to make it as fast as possible. I can take no credit for that part, that's all him. I can take credit for the log-in screen when you sign up for an account. I can't take credit for anything else. So let's sort of make this a bit more -- like you can now do a bit more with the key creation. Let's add remaining or an expiration or whatever you want to add to your key creation here, because the response from us changes based upon what you've kind of got here. If you put 10 in there and we make a call to that, and then you take that key and you plug it into our verifying point, and this is kind of important to understand now, if before you do that, it's going to come back valid anyway. But if you go back to your response here, and you just put the entire -- like stringify the result. And then what you'll see here is, we'll actually return the remaining for you. Now, this is another key piece to the puzzle. You want to know, if you're using remaining or rate limiting or whatever you're using, you need to know for either yourselves for tracking purposes or for the end user, so if this was an AI product that we were building today, we would want to tell the user, by the way, you've only got nine more generations before I'm going to cut you off, because they have to make that decision in their own mind, like, okay, is Jason's next app worth paying another $10 for or did I get my fun for this ten bucks and now I'm out?

JASON: Right.

JAMES: Or maybe you don't get paid until next week and you say, I'll wait until next week, I can come back and kind of do that. So we could make another route here called update and we can actually update the key instead and say like, hey, this person is paid, let's give them a new, you know, remaining or something like that. And you can actually copy the one from your create here because we're going to use -- yep, pretty much the same thing here, except from create there is an update here. And what this takes in is not an API ID. If you take that away, you should see that you need a key ID now. Instead of the actual key, we need the key ID, which is different. And that's just our way of identifying. Because that key, for people that may be concerned about security or whatever, we never store the key in our database. So like that's why we only show it you to once and then enough see it again because whether to store that stuff. It's just a hash of the key so we have a way to verify it's a key you own. But there's no way for us to actually get the key right now. So yeah, you could put like Matt Damon here and if you call that endpoint, and then --

JASON: We can update to ten uses again.

JAMES: And if you call that one, now you'll get a different result. First you click update. And that should give you a result of nothing, which is what we expect. And then if you go back to your verify, it should give you a different result. And there you go. So now you've got -- and you're back to nine remaining because you've updated to ten. Obviously you decremented one there when you used it. Now you have this way of essentially using these keys, how it works for your business, right? So if you, you know, change something or a user pays more money or whatever it is, you get to essentially update the key. You don't have to issue them a new one. You don't have to give them a new API key and say you've paid again, like here's a new API, you can just update the old one, which is essential if you're building out API products, you want to be able to maybe, you know, a customer confuse had for ten years has suddenly gone from a business plus to like an enterprise user and now they're on this big contract. You want to give them the keys to the entire API kingdom. You can now update their key and say, a new key, now you can do a million requests a minute, we're good for that, we've provisioned you, you're good, thank you so much for this contract, and there's no like if, ands, or buts, it's just done.

JASON: This is like, you've covered usage based payment. You're covering rate limiting as like the free tier can handle ten requests per second, but if you want -- you know, if you need more than that, then you have to pay and we'll up it to whatever and if you're enterprise, we'll up it even further. You're covering like -- it covers most of the ways that I've seen people monetize an API.

JAMES: Yep.

JASON: It does it just for me and all I have to do is make sure their payment went through before running this update call.

JAMES: Yep. And similarly, right, maybe your version of an API is a free trial, seven-day free trial, unlimited usage. We cover that too. We have an expiration. You just have to give it to us in Unix timestamp. I think it's milliseconds. I can never remember.

JASON: Renew date. Wait, no.

JAMES: You're going to ask me something I haven't used in a while.

JASON: Then you have to add -- let's see. Is it milliseconds? So a thousand milliseconds times 60 seconds.

JAMES: Here we go, Andreas has put it in the chat for us because we're not smart enough.

JASON: Did you for doing the math for me because this would have taken us the rest of the show.

JAMES: Then you times it by a thousand and we get it to the end.

JASON: That's a week, excellent.

JAMES: It gives you a week expiration. If you save that and run the update again, and then you go back to your verify, you'll see that -- did we save that?

JASON: Did I save this? I did save it, I thought.

JAMES: Let's just run that one more time. It should have given you an expiration. Verification is not returned -- oh, verification is not returned. Oh, that's possible. Some of the stuff we don't return.

JASON: Oh, so like I'll find it in here.

JAMES: Yeah, you should be able to find it -- if you go to whichever key this was, there you go, expires in seven days, already has it in the details. If you look at the details there, he's creating a linear ticket, look at him, best co-founder you could ever have, screen linear tickets to make sure we remember to do things. You can see, expires in seven days. Last usage, total usage, remaining. Everything is here for you to consume and do things and make decisions. We make it as easy as possible to do this. Now, of course, one of the worst things you can ever do is your end user doesn't know anything about security and then decides to accidentally expose a key to the world and now you're worried about API keys, oh, you've exposed this one, now you're going to -- we also have a way to revoke them. Maybe they don't pay you, maybe they accidentally leak it, let's start another route, we'll call it revoke, and you have a way to revoke it. We're taking care of all these different things that you were truly concerned about. And --

JASON: I thought it was going to let me do that, it wouldn't let me do the revoke. I'm assuming I can copy this again.

JAMES: Yeah, just drop it in there. Revoke, and then you don't need any of the extra stuff, just the key ID. And we'll immediately revoke that key from usage. And then --

JASON: Question here, so there are several ways that I would want to revoke an API key, right? So this one, does this delete the key? Or does it mark it as inactive?

JAMES: It will remove the key entirely. So this would be like a very permanent state of like, I don't want them to do this. If you were -- if you wanted to do more of Luke a, okay, I'm going to stop you from using it, the easiest way, right, yeah, so we are going to do a soft delete, it's coming next month, but right now, if you wanted to do it today, you could just set the update to remaining, turn that on and set it to zero.

JASON: Right, because then the key is alive but it won't work.

JAMES: Yep. Then when they pay you again or whatever happens, you can just say, okay, either remove that by sending a null down or, you know, set it to a million or whatever the number is.

JASON: Does that work with the expiration date too? Because my other thought is, if I put somebody on a free trial and they like the service but miss their expiration date and they come in a couple of days later and they pay --

JAMES: If we're using expiration remaining or rate limiting, for example, that key is still active, it's just expired. You can say, oh, they paid me now, they missed their free trial, update the key, boom, they have access for another 30 days or whatever it might be.

JASON: If there is no expiration date, do I set it to false?

JAMES: You set it to null, he says with complete confidence.

JASON: I thought you sounded very confident.

JAMES: What's good about this is I have a co-founder to correct me if I'm wrong. Set it to null and it will turn it off. What we're trying to do here is make it easy for you to say I want to build an API. Whether it's a product you already have, so we have customers that had a product already and they were like, I need an API, because like that's the next step forward, right? Whatever it might be, whether you're white labeling your product or maybe you just have an API that you need to allow people to do whatever they want. We want people to be able to do that as fast as possible and also get all the security features they need today, and then if it's something we don't have, you know, they can ask us and we'll build it for you. We have IP whitelisting for enterprise customers. If they only want their keys to run on one IP, we can do that today, no problem, while white list that IP, boom, we have that feature. And essentially what our idea here is that this is just the beginning. So API key auth is something that scales. But it only scales so far, right? If you think about like if I'm -- I don't know, Amazon, I'm not going to issue a key to every customer, right? I'm going to have to do something else. So the next thing we want to do is unlock gateways for people. So in a similar space to like Kong, Tyk, et cetera, et cetera, we want to make this DX experience where it's like, okay, I want a gateway, I want to make it quick, fast, and easy, and I want to be able to globally distribute them or whatever. We want to be able to unlock that key too. So future company stuff, just for anybody that's interested, that's what we're going to build out next. So you don't have to be a dev ops guide or a middleware guy from before or back into dev who mostly deal with API gateways, they mostly deal with that stuff. If you've never done it before, similar to auth or API auth, we want you to be able to click on a couple of buttons on the dashboard, here's how to use it, and you can start funneling stuff through it and we'll take care of all sort of data for you, we'll give you analytics, where it's coming from, where we're processing the data, where it's going to, all that stuff will come with it. You'll still be able to use API auth alongside it but it gives you more things you can do. Next year will be when that really kicks off. And then the next thing before that is permissions. Like we talked about, where maybe you want to do like a Zanzibar model that says like, yet they can create read update, all these things, but they can't access this resource at this time, all those things, we kind of take care of for you. And that's our next project. That's going to start in November. We're almost there. If you've never done Zanzibar, Auth0 has a nice academy thing about it. The essential idea is it's like a complex model that allows you to scale to some crazy thing without having to do essentially making a database full of like read, write, update. It's very simple, it's not just RBAC or access based, it's a mix of all of that together in one spot.

JASON: That is definitely something that I have -- like I know, like RBAC, role based access control, I get it, I understand, that's how GitHub works. And so I know the words. But it just starts to melt my brain when I actually start building it into things.

JAMES: Yeah.

JASON: I'm always on the using side of this sort of auth, never on the building side. So I like the idea of not having to think through it. I like the idea of knowing that this worked for somebody way bigger than me, and if I just do it like this, it will scale if I do get lucky and this company blows up to massive proportions.

JAMES: Exactly. And our idea here, again, is that like Zanzibar model is very complex. It's like ownership and relationships and all sort of things come along with it. What we want you to be able to do is basically say, hey, this key can do click click, okay, I'm done. And you don't have to worry about what's happening behind the scenes, it's just, yeah, they can read and write to this, or read, write, and update, read, write, create, whatever it might be as part of your model, and you don't have to worry about anything else. It just happens and Unkey just goes, cool, we know what you've clicked behind the scenes and you never have to think about it again. That's the problem, when you start to build out these relationships and permissioning, it's so complex, and it gets bigger and bigger, more and more complex. We want you to be able to do is to hit an API and say this person can do these things and this person can't do these things and never have to worry about what's happening behind the scenes, just assume, if you've said this, this, and this, Unkey will take care of it for you. That's basically what we're doing. We're trying to be I guess the easiest way is like Clerk of APIs, is like a nice way that, you know, really good DX, really simple to use, and you never really have to think about it, you just toss it in there, we support a variety of languages, whether it's TypeScript, Python, Elixir, Go. We just did some cool stuff with the redwood guys. Like, we have a lot of stuff coming up. And yeah, that's us. I think, you know, I think that covers pretty much Unkey in a nutshell.

JASON: I mean, it's very cool that we were able to do kind of the boilerplate of what I would do for managing an API, like managing access to the API. All of these pieces are under 15 lines of code, I guess 16 in this case, and we are able to basically manage everything I could imagine needing to test out an idea, including making it, you know, rate limited. Like you said, especially with some of these ideas around AI, where it costs money to run the request, you need somebody to basically buy tokens to use that. And this -- I'm already thinking of things that I could build that I wouldn't have attempted without knowing that this was here, because I've got a bunch of ideas. Somebody would be willing to pay five or ten bucks for it. I don't think enough people are willing to pay five or ten bucks for it for it to be worth me building out an entire authentication system [laughs].

JAMES: That's the thing, right? I think someone may pay us five bucks to do this but I have to go in and put five or ten hours a day for the next, you know, five weeks to even make five bucks. And if it's a passion project, maybe it's worth it, to you, or it's a learning project, it's definitely worth it. But both of us are very much idea guys, loads of ideas are always floating around if our heads, it's why we do YouTube, it's why we do Twitch. We can't afford to do five weeks on everything. If we can reduce the amount of time it takes to get from A to B. Let's say you had an idea today, I want to do generative AI icons, I don't know if that's a thing, you can do it and have it as an API service or have an API that does those things and instead of taking five weeks, it now takes three days, because you've done, you know, 50 lines of code here, maybe. And now you've got an entire fleshed-out API authentication platform. Now all you have to worry about is stripe, they make it fairly easy to do stripe, maybe you need front end auth and you use Clerk or Auth0, whatever, and now all I have to worry about is produce the icons, done.

JASON: Yeah, it points to maybe a shift in our industry where the real leverage for devs these days is less in knowing things top to bottom and more in being like an APU wrangler because just about everything is being offered these days as a service. And if you can stitch those APIs together, you can build anything. And that's a really powerful place to be as a web dev. And I think it just feels -- I don't know, it gives me a lot of hope. It makes me excited about what's possible out there. And even for somebody like me, like the older I get, the less interested I am in -- like no project is interesting enough for me to give up all my nights and weekends on it.

JAMES: Exactly, right? That's exactly it.

JASON: But I would love to take, I don't know, maybe a Saturday next month, and spin up an idea and see if it's worth -- if anybody thinks it's worth paying for. That is really fun, right? That to me is worth doing. So it also I think helps with not just the people who are willing to burn the midnight oil to chase an idea, but with people who otherwise wouldn't have access to the extra time required. Like, this is -- it's such a leveller. And I love it so much. And I'm very excited to see what this unlocks for people. And again, I feel like we could talk all day because I want to keep going, but we're almost out of time, so I'm going to move us now to, if somebody wants to go further with this, where do you recommend they go? Like what are the right places to head next?

JAMES: So if you want to check out Unkey in general, first thing I would do is maybe check out Unkey.dev/templates. There are some jumping-off plates there with a couple of different things. Oh, no, it was down for a second there.

JASON: That's me. I'm down.

JAMES: We've got examples there, and some of our product users, it shows you how to integrate into a full-blown product or a template, just things to get you started. Outside that have, join our Discord, we have a Discord you can find at Unkey.dev. If you hit the dropdown menu there, it shows up I believe as Discord, you can join that. You can come chat with us, talk about your ideas, we can help you decide how that works. And then yeah, just follow us on Twitter and keep up with what we're doing. Follow me on Twitter, follow Unkey on Twitter, follow Andreas on Twitter. Any of those things will allow you to keep up to date with us. We've got some really cool stuff happening. I think if you go to our nine followers, I'm pretty sure one of them is probably him. There he is, the first one on the bottom. There we go. That is Andreas. We're doing a lot of stuff. We would love to -- if you're into open source and you've never done contributions before, we've got plenty of things to work on. Lots of example stuff that we think would be cool. You can help us with docs, you can help us with code, if you find bugs, we're always willing to help guys out. I know it's Oktoberfest, we're not really doing things this year per se, but if you come talk to us and say, I found this bug and I want to fix it but I also need it for contributions, I'll slap a tag on it for you, no problem. Yeah, overall, come check us out. We're always around doing something.

JASON: Well, I am very excited for what the future holds for Unkey. I feel like this is something that hearing what it's capable of makes me reconsider what I'm capable of. I like it when a tool makes me feel that way. It makes me want to go build a bunch of ideas that are in my ice box right now that I was like, I don't have time for that. And with that I'm going to take us home. So this episode, like every episode, has been live captioned, we've had Lee here from White Coat Captioning, thank you so much, Lee, for being here, that is made possible through the support of our sponsors, Netlify and Vets Who Code, kicking in to make the show more accessible to more people, which I appreciate. While checking out things on the "Learn with Jason" site, make sure you look at our schedule, we've got an absolutely killer schedule. We're going to have 3D in React with a visual editor, which is not a sentence I thought would ever make sense, but it does, we'll learn how it works. We're going to do Svelte 5, with Rich Harris, we'll write some emails using JXS, which I hate dealing with email but I write a lot of emails, so I'm excited to do it in a workflow I enjoy, so looking forward to that. And lots more that I haven't had a chance to put up on the site yet. If you have something you want me to see, make sure you let me know, click the icons so you know what's going on with the show and are aware of things that are happening. James, anything before we are done?

JAMES: Yeah, just go build something, go have fun.

JASON: I got nothing to add to that, what a great way to end it. We're going to find somebody to raid. And we'll see you next time.

JAMES: Thanks, everyone.