James: I have to have API keys, like how do I do that? This is something I've done in the past. It sucks. So we basically have decided all the things that are wrong with, API, keys in general, and like how they make the market difficult. We've basically tried to solve them upfront and as quickly as possible.
Andrew: Hello, welcome to the Dev tools FM podcast. This a podcast about developer tools and the people who make 'em. I'm Andrew, and this is my co-host. Justin.
Justin: Hey everyone. Uh, our guest today is James Perkins. Uh, James is a co-founder of unkey, uh, which is open source, API Key Management Solution. We're really excited about to talk about that today. Uh, James, you had also previously worked at Clerk, uh, which is kind of, sort of seems to be booming in popularity.
I hear about it like relatively often these days. Uh, so that's a user management service is sort of how it, uh, terms styles itself. Um, but James, it's great to have you on. Uh, before we sort of dig in, uh, is there anything else you'd like to tell our listeners about yourself?
James: yeah, not really. Uh, yeah. My name is James. Uh, I also run a YouTube channel, uh, where I do like, uh, tutorials and, and talking about tech in general. Um, and yeah, super excited to be here. Can't wait to chat about Unkey and everything else.
[00:01:17] Working at Clerk
Andrew: Cool. So, uh, before we get to unkey, I think it, it'd be good to like set up your journey to unkey. 'cause I think it's pretty interesting how started as like a, a full-time side project and then moved to your full-time, full-time. Uh, so at clerk, uh, what did you do? And if you could fill our users in a little bit more about what clerk is, could you do that?
James: Yeah, yeah, for sure. So Clerk is a complete user management tool. So imagine, you know, you need to add like a login page where you need like social logins or email and password, or maybe just email. Uh, clerk does that. Um, and essentially the way that clerk is kind of different from everyone else is they just give you, uh, react components that you can just drop in on your page and that's it.
You're done. Login page. Um, while I was there, I did a variety of things. So I originally started as their. Devrel. Um, when I first was hired, I knew Colin and Braden for a while. I did some contract work for them. Um, and then over time, you know, with every startup, your job kind of transforms into a bunch of different jobs.
Uh, so I did Devrel for a while. I was the running docs as well and support all at the same time. and when I left sort of the last sort of six to eight weeks, I was doing developer success, which was essentially, uh, support plus like product feedback loops through different channels. but yeah, that, that was my role Clerk and I had a really good time there.
And, uh, yeah, probably still the best authentication product out there and I would, if you haven't checked it out, definitely worth doing.
Justin: Clerk reminds me a lot of stripe, uh, from the model of like how, like how it approaches like providing APIs and interfaces. I mean, it's one thing that I think Stripe has done really well over time is just like, you know what? We're just gonna give you a checkout page or give you the components to build a checkout form or whatever.
And I think that is a pretty nice model.
James: And it, yeah, and I think, you know, if you look through the history of, of Clerk, like they started as like a Ruby package, like all the way back. It was like a Ruby gem. And then like they realized that nobody wanted that. So like maybe we should change to something else. And they realized that front-end devs just don't know how to do this.
If you haven't been in the industry long enough, you just, and you are just been doing like react for the last few years, you just don't know how authentication really works behind the scenes. So they try to make it as easy as, as fast as possible, similar to Stripe, where it's like, yeah, here's just the bits that you need and make it work for your business needs.
And if you need business, you know, things like organizations and teams and things like that, we can provide that. Or if you just need B two C stuff, here's a couple of dropping components and, and you're done.
Andrew: Yeah, especially with auth, it's like the worst thing that it's like, you ha it's a thing I have to implement and fully understand and fully get right. And if I don't, there's like drastic like business ending consequences. So it's like that's, that's the solution I would want to go for is like something that's just like, I plop it right in and it just works and I don't have to care what's going on in the black box.
James: Yep. Exactly. And, and that's why they saw such an incredible boom. I think, you know, when I, when I joined it was sort of, kind of starting to pick up a little bit and, and now, you know, if you just look at go to tech Twitter, it's talked about daily by somebody, whether it's like, this is my top tech stack or whatever, or like, I just use Clerk for the first time.
And it's very much getting into that, like Vercel almost level of like, people talking about it now, where, you know, oh, I deployed to vercel for the first time and it took two minutes. Like, it's in that vein now. And, uh, it's super exciting to see the growth that they've had.
[00:04:49] What is Unkey?
Justin: Yeah. So, uh, unkey started as a sort of a, a side project during that time. What, uh, like what sort of led to that thought? I mean, as I was reading sort of some of the docs as like thinking about like API key management, um, it's just an interesting problem to tackle. So I was like curious, what were the struggles that you were seeing initially?
James: Yeah, so I didn't come up with the idea. Um, so my co-founder Andres, uh, actually sort of pitched it to me, but not really. So, uh, he had implemented this on a couple of side projects over, you know, the last few years where it's like, I need to give an API as a service. Okay, now I have to have API keys, like how do I do that?
Um, and then you implement it one time and it's kind of rough, but then you're like, all it works, whatever. You kind of ignore it and you move on. And then. He did another side project and the same thing happened again. It's, oh, I need it again. Let me copy and paste it from here into this project. Let me make some changes.
Kind of go from there. Um, and, and we had been friends for a while. Um, he at, uh, upstash. Uh, and so we'd been talking back and forth about a few things and uh, he pitched it to me and I was like, I'm in. This is something I've done in the past. You know, I've been in this industry for a long time. Uh, it sucks.
Let's build this the right way. and the bigger issues that really come up when you think about key management is one rate limiting. How do you handle that? Like you have to decide whether it's gonna be the API is rate limited or is it Every key is rate limited and the benefits and, and of having per key rate.
Limiting means that if, you know, you Justin, suddenly get this big spike in traffic. We can bump you and not worry about bringing down the entire API platform. We just know that, oh, Justin's fine. He's got like a little bit extra in his rate limit today. Um, and then, you know, or you become an enterprise customer and you need more, you can give that just to that specific like customer. So we thought about that for a while. And then the next issue that comes up is how do you distribute this across the globe? Edge is super popular today, right? So everyone wants everything on the edge. 'cause then it's super fast, but it's only as fast as where you're getting the data from. So if I am in Germany, for example, and my data center is in the US it doesn't really matter if I'm on the edge because you still gotta go all the way to the US and back.
There's a big latency there and that sucks, right? And with API keys, you want the. Request and verification to be almost instantaneous to your end user. You want it to be tens of milliseconds, not hundreds of milliseconds. So we figured out a way to essentially globally distribute all of these keys. Um, and it's basically in 36 regions right now.
Um, so if you're in Germany or if you're in Asia, or if you're in the US you should see the same speeds regardless. And then comes with that. It's like how do you decide on rate limiting, right? So with rate limiting, again, you, if you're globally distributing, you have to make a decision consciously about things like, well, do I really care if it's exact on my rate limits?
If it's not exact, that's fine. Uh, so we have two types of rate limiting. One is that it actually goes all the way to a database and verifies that that's actually the rate limit. And then we have this thing called fast rate limiting, which is basically almost a sliding scale. Um, which is done all in memory.
So assuming the user's always coming from the same region, that rate limit should, should be accurate. But in the case where someone was doing like a burst or something, it may not be accurate, but it's under a few milliseconds before we catch up and we can rate limit the user. Um, and then yeah, it's just adding things on top of layering on top of API keys, like what else could you have?
Well, what about keys that expire today? Like, I want to give you a free trial, it's one week, but I don't wanna have to chase you and figure out how to disable that one key or remember which key I've given you because you shouldn't be storing the API keys in plain text anywhere. So like how do you do that kind of stuff?
Uh, so we introduced a way to essentially just say on this date it'll expire, and after that the user can no longer access the product. And then the last kind of feature that we really have that's big is, um, in the same kind of vein, which is AI with like token based. Request. Right? So you could say to your user pays you, let's say $10 and they get a hundred API requests with, with unkey.
You can essentially say like, this key only has a hundred requests, and after that, shut it off. And the only way that they can do it again is by paying you and you can update that key and give them more requests. so we basically have decided all the things that are wrong with, uh, API, keys in general, and like how they make the market difficult.
We've basically tried to solve them upfront and as quickly as possible.
Andrew: That's pretty cool. It reminds me a lot of clerk itself, where it's like taking a hard, like maybe on the surface, like simple problem, oh, I want API keys. But then it's like all that stuff you talked about, you're not gonna think about that upfront. You're not gonna think about like global, you're not gonna think about like temporary keys and all these things.
So it just makes sense that like, oh, managed service makes, makes a lot of sense.
James: Yeah, exactly. And that, and that's the thing that we found is that every time we've done it personally, you always think about that thing after you've done the implementation. You're like, oh, someone's complaining. They got really slow latency. Well, yeah, obviously. 'cause they're, I'm in the US East one and they're all the way out in Europe.
Like, how do I fix that? Uh, so we just decided, let's do it, do it right the first time and let people just manage it. Just kind of similar to Clerk.
Justin: That's really cool. I mean, I think, uh, one of the challenges of all of these like products that like provide you a really solid. Front end. So API key management or user management or whatever is, there's also, you know, there's always like this downstream effect of like, okay, now I need to integrate it into my stack in some meaningful way.
And like API Keys in particular are interesting because they have like this security ramification. Um, it reminds me of like GitHub and how GitHub's API Keys or their personal access tokens have, uh, sort of expanded over time. Originally they had these like really coarse, um, scopes, you know, and it's just like very broad and you're like, you know, I really, I want to like get more detailed here.
Um, and, and now, you know, they, they do have these more like sort of granular access tokens, which in my opinion could still use a little bit of love, but they're, they're, they're definitely better than they were. so have y'all thought a lot about that or is a lot of that on the user and their implementation and how it bridges.
James: Yep. So we have definitely thought about this. Uh, it's actually what we're working on right now, which is essentially what we're gonna give you is almost Zanzibar style. Permissioning. and if you're not sure about the Zza bundle, basically it's like the catchall of any type of, uh, permissioning. So you could do role based or you could do access based, or you can do mix of both.
Um, and it's very easy to understand. It's like human readable, uh, and we feel the same way where you could give a key with a policy to say, you know, Justin can read and write, uh, but Andrew, sorry, you can only read like, we'll be able to handle some of that for you. the way we handle it today is we give you a freeform metadata field.
So if you already have that kind of implemented somewhere else, maybe in your user auth or something, you can put that directly in the metadata and we'll return it to you as part of the key verification so it's there available so you can read it and play with it and do what you need to. Um, but yeah, we're working on Zanzibar style model right now, um, and we should have that pretty soon.
Andrew: That seems like a pretty big, like kind of like scope increase from just API keys now to like user access management.
James: Yeah, so unfortunately they, they kind of go hand in hand, very similar in the authentication space. Like at some point authorization has to play a part. Now whether you use another managed service to do that or whatever. but similarly with API keys, we just know that there's gonna be somebody out there that needs that use case
of like, I need to be able to di differentiate between read keys, write keys, read and write keys, you know, all those kinds of things.
Um, and we just wanna make it, you know, clickable essentially. So you just say like, I want this user to be able to do this, this, and this, and I'm done. And then you just give them the key and off they go all through the API. Um, and we just think that's the next thing that people really need. And we're willing to build out this giant model that's gonna take a while for us to really build.
But once you get it, the DX will just be second to none and you won't have to worry.
Justin: Yeah. I mean, that is an important part of the whole thing and, and. You know, it, there's this interesting thing is I, I feel like the downstream implications of any system, like, you know, building API keys as a feature or, or just thinking about authorization layer, they're rather complicated. Um, you know, sort of by their, by necessity.
Um, and also, you know, having, at least being able to provide good opinions downstream, even if you're not the one enforcing those opinions, I feel like is a, is a tremendous value add just from the perspective of like, you know, take a company again like GitHub, GitHub being just, just amazing organization and like, you know, I see their rest API as like one of the best rest APIs sort of ever built.
This is like not perfect of course, but you know, it's like a, a good model of like how to build a solid rest API. And, you know, the note that it took them a while to, to sort of improve tokens and, you know, I'm sure there's a lot of reasons for that, but, you know, I could see where, uh, you know, unkey could provide a lot of value outta the box is like, Hey, here's how we think you should, you know, define your scopes and, and, you know, I don't know, make resources available to your API or whatever.
James: Yeah, and I, and I think it goes, you know, if you've already got that system in somewhere else, so maybe you've just got your users that are already part of some org or whatever that has those teams and stuff, you can, because of the way that our, like rest API works, essentially you already have access.
You can already have access to your user data wherever. So if you already know all of these details, you can just insert 'em into this key. And then you never have to worry about is the user logged in? Can I get this permission somewhere else? Do I have to figure out who this owner is before I can do these checks and balances?
Um, and we just know that, you know, at some point. You may not use our Zanzibar style model. Maybe you'll just do your own and that we give you the ability to do that. Um, and we definitely just want to give you the best advice. Um, and then you can run with it and use us, or you can delve in and do your own permissioning somewhere else.
[00:15:30] Ad
Andrew: This week's episode is unsponsored. If you'd like to sponsor dev tools, FM, head over to dev tools.fm/sponsor. There, you can see the various ways you can advertise with dev tools, FM, whether it be one to 10 episodes.
We would like to take this time to advertise our newsletter. And the newsletter, you get a weekly breakdown of all the cool things happening in the developer tooling world, as well as a little post episode, recap of our thoughts about the episode that we released that week. It also serves as a good reminder that we release something.
And of course, don't forget about our shop. If you head over to shop.dev tools.fm, you can buy some dev tools, FM merch. We have some cool stuff. We recently added a TypeScript T and a bunch of different colors. It also comes in a tank top now. Or my personal favorite thing, a dev tools, FM bomber jacket. I've been wearing that bomber jacket to every conference that I go to. It comes in black and has the Devtools FM logo in gray.
And if you haven't subscribed to us on the platform, you're listening to us on, please go ahead and do, or you wouldn't hurt either or a comment depending on where you are. And with that, let's get back to the episode.
[00:16:31] Working 2 Jobs
Andrew: So we mentioned it a little bit, but uh, you started working on unkey while you were still at clerk, and, uh, I think I, and many of our listeners know that doing two programming jobs at once is a lot of work. So, uh, how did that go?
James: yeah, it's a lot of work. Um, it's not for the faint hearted, that's for sure. I think the only good things that came really, the only good things is that both Andreas and I were super passionate about the project from the get-go. And once we had implemented the first like. You know, production, deployment that went out and people started signing up and we saw the growth go from zero to like a hundred essentially in a week. That showed to us that what we were building was actually something people needed. And then two, it's like, okay, we can, how do we figure out how to divide our time in a way that made sense? Um, and I'm, I'm very fortunate that Andreas is in Germany and I'm in the US now. So essentially what Andreas would finish his day at my lunchtime, and then he would start working on Unkey, and then I would finish my day and he would be going to bed.
So there was always somebody sort of working on the project. And then on the weekends we would just collaborate as much as possible because that was the time where we were pretty dedicated. I was super fortunate, like my spouse, 10 outta 10, like couldn't have asked for a more support system and she definitely encouraged me to.
You know, go out and, and, and seek this the way it is. Um, and I don't think I would've been able to do it without her, and her support because yeah, we were, you know, ticking meetings and, and talking to people and getting feedback and bug fixing at like 10:00 PM at night and, you know, all those crazy things that come along with like deploying a production product.
And, and my wife never said anything about like, yo, can you put your laptop down for five minutes and like, come and help me with X or Y. She was just there and, and super supportive. So I, I couldn't ask for anything better than that.
Justin: Yeah. That's great. And, and, uh, an incredible, benefit to that time for sure is something that's like super necessary. Um, you know, is it's one of the things that we have to make these explicit trade-offs when we're trying to, to sort of build these projects up. It's like you do, you do sacrifice time and uh, uh, you know, I'm glad you had the support for that.
So, when you were working on it initially, was this just the like open source side of it? Were y'all really just trying to figure out like, okay, what is the, the sort of basic shape of this? Or were y'all actually just start thinking about how you build out the business and like, going deeper than that?
James: Yeah, so when we talked about the project, we were both, we knew that everything was gonna be open source from the minute we talked about the project, but we knew there was a commercial viable product here. So the business has always been there in the back of our minds and how we can one, make it accessible for anyone to use, right?
So like, if you don't want to use the cloud service and you wanna do everything yourself, self-host and worry about that, right? We wanted to make it as easy as possible to essentially remove the pieces you don't need. So like, if you don't need stripe, because you, you are using it internally, you don't need stripe, you can just throw an environment variable in there that says like Stripe false.
And that will just disable all the Stripe stuff. Or if you don't want to use tiny bird for analytics, which is what we're using behind the scenes to provide all the key and API analytics, you can just turn that off and you can use your own. Um, and we knew that we wanted to make it commercial, so the business piece was always there.
But yeah, right from the get go, it was like, okay, how do we make this sellable as a cloud product? But also we wanna make sure that we're, you know, providing this easy to access open source project.
Andrew: So, uh, to kind of draw the lines is like the open source project, just the way to like, manage keys and then the paid thing is like that distributed at the edge and fully managed for you.
James: Yeah. So that's essentially it. So you could take what is in our open source project today and deploy exactly how we are in production today as a managed service. Um, but yeah, the managed service essentially is, you know, we manage everything from the analytics to, you know, user management, everything, everything's on the edge, globally distributed, all that stuff is there.
You could choose not to globally distribute and just have it one location and, and, and you'd be fine. Um, but yeah, that's basically the managed services is all of the bells and whistles.
Justin: At what point did it, like, did it like really crystallize to you as like, okay, this is the thing, like I need to, you know, leave the job that I'm currently doing and like really hone in and focus on this.
James: Yeah, that was a really difficult thing in general. So. There was a, there was definitely a tipping point where we realized that this is a thing and potentially this thing is, could be a full-time business. and the tipping point for me, I think really was the point where we had VCs just knocking at the door.
Like we would get three to 10 emails a day from VCs across the globe being like, are you run? What are you doing? Are you raising funds? 'cause we could be interested. You know, that started to happen a lot. Um, and then, yeah, I just think that plus having so much passion for the project itself and always having this kind of founding mentality of, like, even at Clerk, I, I treated Clerk as if I had founded Clerk. Like I was a very early person in the, in the, the thing. And I'd been there since the early days when they had a really. Horrible react components. and so I was always invested in it, so I would work godly hours for them too. Um, in the beginning where I was, we were trying to get the traction going and I slowly saw myself being like, I'm less worried about Clerk now and I'm more worried about the success of unkey.
And that's when the, the, the sort of bell curve started to happen. For me, it was a difficult decision. I never really, you know, the, we're all still friends in the grand scheme of things. Like every, there's no hard feelings on both sides, but it was just very much like a, if I don't do this now, I don't think I would, I think the project would just die on the grapevine essentially, because we just can't keep doing what we're doing every day.
Justin: Yeah, for sure. I mean, at, at a certain point, you really have to say, am I gonna give enough fuel for this thing to turn into a real fire, or am I gonna just like. You know, keep it as a side project. And also I feel like it's really hard to, to sort of like, give any one product enough attention to make it good when you're focused across like many things like that, you know?
James: Yeah, you definitely get spread too thin. And, and I was talking to Andrew before we start recording about how like I do YouTube, but that ga I had to give that up. Like I didn't record a video for like 35 days. There was just a period I was just like, I cannot, I don't have anything left in this tank to give you a YouTube video.
And it was the first time I'd ever taken that much time off YouTube since I began my YouTube channel. And, and you're right, like there's only so much you can give to a product and like YouTube to me is like another product in my, like, business, right? Um, and, and, and I just felt it was unfair to not go and challenge myself and be like, okay, let's do this.
Like if we go and do this full time and we can get funding, then the worst thing that happens is we try, we fail and. It's open source forever and, and we'll maintain it as a side project. But, um, yeah, for sure, like there's only so much you can give and I think there's only so much you can take away from family or, or friends or relationships in general.
Um, and, and you definitely don't wanna give those up in favor of business, in my opinion.
Andrew: Yeah, I found the same thing even, even in high school. It was like, I can do like maybe two things full time. Back then it was like school and a sport. If I do a third thing, my life is just like lost and I have no energy for anything.
James: Yeah. And that's how I felt like, you know, it would be the weekend and I'd be working on unkey sort of like, you know, just the laptop on the lap, just kind of sitting around doing stuff and I'd, I'd prefer to be going, you know, go out with my wife and go and do something. Or like, you know, maybe there's some chores around the house that need to be done that I've just been ignoring because I just don't have the, like, the capacity to go and do it.
And, and, and yeah, it was definitely getting to that point where I was like, oh, I'm burnt out to. I'm more than burnt out at this point. Like I'm a crisp essentially at this point.
Justin: Yeah. Well, I mean, massive respect for being able to pull it through and make the decision to really focus. I mean, because especially at the point where you're already feeling burnout, I know that, or I can imagine that that was just. Pretty hard too because, you know, there's this, even after you like say, okay, well I'm gonna like put down this one job and really focus full time, there is still this like, okay, now there's a mountain to climb.
You know, it's just like, that's where the work begins. Uh, and it, you know, can be hard to sort of manage recovery while you're like really doubling down and focused. Did, did you find, like after you decided to go full-time, were you able to like instill a little bit more balance or was it like really heads down just to try to, you know, catch up or, or whatever you
James: Yeah, it, it was, it worked out very well. So, like Andreas is still full-time in his role, so right now it's like a part-time and a full-timer. And, and the benefit now is that. I can work 15 hours in a day if I want to, but also I can just work a regular eight hours and just be like, okay, I've, I've done a hard shift today.
Like I've been focused, we've done a bunch of stuff, we've really good, done a few releases, whatever, and I, I can just walk away and I, there's no guilt because before when I was doing it part-time and, and doing clerk full-time, right? You'd finish, like, I'd start at seven and finish at four, and then I'd be like, okay, I need like 10 minutes.
And then I'd, the guilt would start in the back of my mind of like, well, shit, if we don't do X or Y tonight, it's not gonna get done till tomorrow. And then like, oh, what if a customer's waiting for this? Or, you know, like those things start to trickle into the back of your mind and then it, it, it starts to play that mental fatigue even more.
But now, yeah, like I feel mentally I feel great right now. Um. You know, it's only been a couple of weeks since, since I really made this full-time switch. Uh, but like, yeah, I, I feel that if I leave at the end of the day and I go and like, you know, do something outside, like no one's gonna be like messaging me and be like, holy shit, we need to do these 10 things.
Like, those 10 things have been done, so we are like getting to do that now, uh, versus having to spend all that time kind of worried about that in the back of my mind.
[00:26:52] Unkey DX
Andrew: so like Clerk unkey kind of has like many front ends. In the case of unkey, you have lots of different SDKs. Uh, so what platforms do you guys support and like which ones are you like most excited about?
James: Yeah. So, uh, from like a code standpoint, we, we support TypeScript, uh, rust Elixir, go Python, um, all the big sort of backend. We have available. Um, and some of those come from the community, right? So the, the, the joy of open source is the community wants the help and if the language doesn't exist in the language, they'll build it because they need it for their own projects.
Um, so we have a lot of that. But the, yeah, so we are most excited about TypeScript and, and, and go really? 'cause that's basically the entire platform's built on those two things.and yeah, those two excite us a lot. But the benefit is, is our rest API is really, really good. It's well documented, it's really easy to work with.
So even if you, we don't support a language that maybe you, you know, you want, uh, the ability to just tap into that rest API and only having a few endpoints and all those endpoints kinda work the same way, um, makes it really, really easy. Um, but yeah, typescripts always something I'm excited about. Go is something we're always excited about.
'cause most of it's built in either one of those and those are pretty popular in, in today's world.
Andrew: one, one that just jumps out to me that's like different from all the others on your, in your docs is next. Did that one come from a community member?
James: Yeah, it came from, uh, from Daniel. Uh, yeah, yeah. He, he, he's a Yeah, of course. Who else is it gonna come from? Right?
yeah, he's a friend of ours. Uh, he hopped in and was like, Hey, like, love to just build like a rapper for n uh, and I think he was the first SDK that was community driven. I think it was either him or, or we have a community member that did Python.
It was e either one of those, and it was very, very quick.
Andrew: that man is an elemental
force in open
source. It is crazy at this point.
James: Yeah. He just appears outta nowhere and he is like, Hey, I did this thing for you guys, and then like disappears. And then you're just like, thanks. And then yeah, if you ever need anything from him, you just pinging him and he is like, yep, I'm on it.
This is crazy.
Andrew: Yeah, I'm, I'm still not con uh, convinced he's not a machine learning
James: Yeah, I agree. I agree.
[00:29:06] Security
Justin: So, um, obviously with a product like this, uh, security is really. Important. Uh, I mean, this is, you know, the way that you're securing access to your API. So, so could you talk a little bit about your security posturing, uh, how you sort of think about these things and sort of how you communicate it to customers?
James: Yeah, so security is super important for, you know, everything and everyone. Um, it was one of our main things that we were concerned about. Um, so the first thing we did was if you just go to our docs, like we tell you exactly how we deal with security, which is in basically in two ways. we don't store the API keys, we just store a hash of that key.
So, you know, and then that's stored in the database. So there's no real way, like if we ever were compromised, um, there's no way for us to essentially give that, give those details out. and, and then like for, like, uh, the other part of that is, is that if you use our front end product, if you create like a, say a root key, which is a way to create resources in our product, we show that to you one time and you can never see it again. So there's no way for someone to just like, you know, socially log in, figure out, or, you know, you leave your laptop open and you, you've got unkey open. There's no way for them to just go and grab a, a, a key, and be like, oh, I've got your keys now. And then just like, off they go. Um, and, and so those things are, are treated pretty heavily where we are.
And, and we do a lot of, you know, audits around how that's working. And, and we give you analytics on your resource keys too. So if all of a sudden you're like, man, somebody's been like, this one person seems to be accessing our, and I don't remember, like them paying or whatever, you can go and look at your root key and say, okay, I only have one root key.
Let go and look at the details of it. You can see every request, where it came from, where, where it was, you know, like where the request originated from, where we processed that request, what the IP address was. We have all that data for you so we can just give it to you and say, Hey, by the way, like we found this.
Um, so even if you had some sort of weird anomaly in your API, you can go and look either, whether it's just a key that's acting a bit strange, and you're like, well, this person suddenly is doing a hundred thousand requests and they weren't yesterday. Why are they suddenly spiked? Uh, you can see that and you can look and see.
And uh, we tell you, you know, if we've rate limited them or whatever, all that stuff comes with it. so yeah, we, we, we are very conscious about that. And then obviously we do the standard kind of stuff like in environments and like local environments, like no one really has access to anything, um, outside of, you know, what keys they're supposed to have for what environment.
We try and keep that pretty lockdown. And then we use clerks, so then I'll, uh, use data is stored. So, yeah, so, uh, that, yeah, so we have that as well. So like, you know, if, even if you are a user, like that'll never be compromised. There's no, we don't store any kind of actual real user data anywhere. 'cause we just use clerks so we don't have to worry about like, accidentally leaking emails or things like that, that those things don't exist either.
Andrew: Do you guys have any like monitored MO monitoring in place? So like if that person does, like you see a key go to a hundred K, you can be like, oh, get an email.
James: Yeah. Yeah. So we have a lot of monitoring, uh, mostly because, you know, we're like on the critical path. So if something goes down, breaks or like we get a huge spike in traffic, we, we need to know right now. Um, so we have, uh, so we use Discord for pretty much everything. Um, so we have, um, Axiom with monitoring set up.
And then some other features in there. So if anything happens, like we get big spikes or for example, you know, we get two or three errors in a row, we'll flag that and then it's responsibility of whoever's awake to go and look and see what's going on. Um, and that's caught a few things, to be honest.
There's been a couple of times where like, uh, one of our machines has gone down and we haven't realized because, you know, it just hasn't been used and then suddenly someone goes to use it 'cause they're in that area and we get an error and then we reroute their traffic somewhere else. Um, and, and that's really helped too.
Um, but yeah, we, we monitor everything. And to be honest, because we're in such a growth stage, like the dashboard is currently on my other screen right now and it just refreshes every like, you know, three or five minutes and I'm like, Ooh, little spike, little dopamine hit as someone else uses the product.
So yeah, it's pretty well watched.
[00:33:32] Future Features
Justin: That's fun. Uh, so I mean, it sounds like you're, you know, still pretty early in this journey. You've like implemented some pretty critical features. You're, you're working on the sort of zanzibar like, uh, authorization system, uh, which would be really cool. Uh, what are, do you have like other ideas for features that you're wanting to implement down the road?
Something you're really excited about?
James: Yeah. So after we finish that, or potentially at the same time, we may do them in parallel, they may end up just working together, is that we want to build out essentially a gateway product in a similar vein. So usually with API management, you start with a small basic product and then it kind of grows out and at the end you end up in gateways.
Just the way it works, like if you look in the industry that you always end up there. Um, and we're super excited about that. We think that we can do globally distributed gateways, which is something that really doesn't exist in the industry. If you go and look at big players like Tyke is a good example.
Um, they claim that they're globally distributed. They're not, uh, they like kind of replicate some data around and you can only do a specific amount of regions and things like that. So, uh, we think we can still do the same model we have today, but globally distribute your gateways too. So it'll be just as fast mission critical.
Uh, and we have APOC that we've done a couple times. Um, and yeah, it w it just works. Like what we have right now just works. We just, you know, we've gotta implement a lot of security features and things that come along with it. Um, and, and yeah, we're super excited about it. We think it'll be a refreshing change for, again, similar idea of like frontend devs or devs that have never done this kind of work before, instead of having to rely on an entire team to set up a gateway.
Couple of clicks and I'm done. Okay, cool. Great. I can like move on. Um, and, and that's kind of what we're aim me for.
Andrew: So as one of those frontend developers myself, that, uh, mainly does design systems and apps, I have no clue what an API gateway is. So, uh, what is it? And like, why would I wanna use one?
James: Yeah, so basically it's like a way for your, it sits between like your client and service. So imagine it's just like this piece in the middle and that basically gets to decide where the traffic goes, who it goes to, are they allowed to access that route? It's essentially like, uh, just like a big routing table that tells everywhere where it can go and how many times they could access it.
And, you know, based upon permissions, could you actually read, write, get this data back, all that kind of stuff. Um, and essentially you end up doing that because you have an API system of some nature or services that need to talk to each other and all that kind of area. Um, and you need to do it as scale and you need to essentially put it in place and then.
Have the data around where that, where everything is happening. Uh, and it usually, you don't get one until you scale to X and then all of a sudden you realize you need one. It's like one of those things you don't really think about and then it's too late. You need one already, and like, you know, then you're, you're scrambling around trying to figure out who can give it to you the quickest and who can give it to you with the feature that you need.
Um, and yeah, it's, it essentially our key system will be like a gateway drug into gateways. Uh, you'll get to a scale point where you realize that issuing keys all the time is just not gonna work anymore, and you'd rather just stick this in front of it and deal with the traffic that way. Um, and then the advantage of that is those keys will still work with the gateway, so you'll still be able to use those keys in, in conjunction.
Andrew: Yeah, a, a pattern I've seen in like front end tools a lot is like we like especially with like you could look at like just rendering websites. We attack things from the front end and then like work our way back and I see unkey kind of doing the same thing where it's like the front end of all of this is your API key and you're starting from a place of like nice DX and like good user experience and working your way back to the more complex features.
Whereas like I think Solutions of Old probably did the opposite and we're like, oh, we're an API gateway first, and then we added on API keys and they kind of suck.
James: Yeah. And that, and that's what we've seen. So when we first were talking about gateways, we spent a lot of time trying to sign up for gateways, uh, whether they were open source gateways or just like, you know, they gave you a free tier and you could try it out and stuff like that. And they always touted things like, oh, we have API keys.
Or like, you can issue keys. And then you start to use it and you're like, how do I, one, how do I do this? I don't understand. And then two. When you finally got it working, it just was that like, oh yeah, you can tell this was tagged on as like a, or we can sell this to enterprise users and, and then we won't have to worry about it.
Um, and, and the biggest thing we saw with gateways was you literally needed a PhD to just get it to work. And we were like, if, if we are struggling and this is the industry that we're in, there's something wrong here. And, and then layer on top of that, you wanna like distribute it maybe in two locations, then you need a second PhD to figure out how that all communicates together.
And, uh, yeah, it was, it was rough. It was really, really bad. Um, and we just looked at it and went, we can do that and we can do it better and we can make it easier and accessible.
Justin: Yeah, I think overall I like this trend of like really focusing on, um, the early user story, really focusing on like, you know, going from the usability side of this, like, and going deeper into the technical thing. I feel like it, like does put a really good angle on it and ends up because it's like, there's always this challenge of, and, and I see this dichotomy in a lot of places.
It's like there are different mindsets in engineering and if you have like a really deep systems mindset, you are used to a certain level of pain. Uh, that I think that users coming at it from a different perspective, like are usually not great. So if you have someone who has a deep systems mindset, and I don't, I don't mean to like be reductive here.
Of course there are many people, and this is a generalization, but sometimes you can have, um, like worse APIs that end up coming out of that because it's just like. The, the sort of methodologies and thought processes of how they think about building these things. It's just different, you know, they have a different mindset or whatever, um, and it's totally fine, but you know, we're getting to the age where like, UX is so critical and it's so competitive now too, where if like the UX and DX isn't really good, people are just like, nah.
Don't want it, you know?
James: Yep. Yeah, and I think we've seen that more and more probably since, you know, vercel actually became vercel you know, 'cause they were Z at one point and now, and like when they did that changeover and they started to push this mentality of like, yeah, you could go to AWS do all of this. Or you could just come to us and give us the GitHub repo and we'll just do it for you.
Um. That methodology then sprouted a bunch of different services, you know, like render and, and, and you know, people started moving away from Heroku 'cause they decided they were better than everyone else. And you know, like these, these mentality shifts started to happen and you know, even off went that way.
Like your option was like auth zero. That was it. That was, that was your big option for a really, really long time. And when you look at it now, you think, wow, like you really, it's not the best dx, not the best ux, not the best experience, but at the time it was the only DX in UX that you could get that didn't involve you doing it all yourself.
Um, and now, yeah, there's this new generation of developers out there that like, yeah, I don't want to, I don't wanna think about this, I just want it to work. And then when it works, I don't wanna think about it again. Um, and you know, 15 years ago when I started that didn't exist. It was just like, oh, good luck.
Slug it out on your own buddy. And good luck. Hopefully there's some package out there that might do what you need to. Um, but now yeah. There's definitely this new age of developers out there.
Justin: Yeah, for sure.
Andrew: Uh, yeah. So now we're moving on to more Futurey
questions.
[00:41:30] Open source business
Justin: Well, before we do, I have one, I have one like thing to maybe round off this section.
Um, so a lot of unkey is open source. All of it is open source
ostensibly. Uh, yeah. Which is great. Which is great. Um. We are huge proponents of open source, uh, and we talk to a lot of people who are building businesses off of open source, but um, it can be a non-trivial thing.
Uh, so, you know, there's some definite trade offs that you make. There's some definite advantages. So how are y'all thinking about this journey of like building an open source product and really trying to monetize it? Like what are the principles you're putting in place to sort of make it viable and, and sort of what are the challenges you think you're facing and stuff like that?
James: Yeah. So I think with any. Open source projects in general. There's this, this idea of like, oh, with open source comes this like ultimate power of the community, right? So there's this like idea, but they're also the worst enemy, which is the community can be really mean and harsh and unreasonable, right? Um, and so we've kind of taken the approach of similar, you know, commercial open source software out there like cal.com where we, we try and be open and honest about everything and we kind of have this like idea of, while yes, we understand that you are gonna run into issues and we're gonna have to fix them.
And yes, you could do it yourself by opening a PR or whatever. Um, we, we want to make it as easy as possible to understand the direction of the company and like where we're actually going as a viable product. Um, and then secondarily is, is that. When you come and open an issue, whether it's through support, through Discord, through GitHub, whatever it might be, is that there's a clear understanding of like, uh, we have it be open source and, and you could look and, and fix it yourself if it's something that's maybe you, like you can do yourself, but there's no onus there that just because we're open source, we expect the community to fix our problems.
Um, and so those things together kind of build out this philosophy of like, everything we do is, is as open as possible. Like we, we, we try and make it as easy as possible for you to understand where we're at, what we're building, what we're releasing, what we're doing. Um, and then like also on the flip side of that is that, yeah, as a commercial product, it's very hard to be open and honest about every single thing that's happening behind the scenes.
There's like stuff that happens that you probably don't need to know about. Um, and we are just trying to emulate. cal.com and, and, and similar where we try and make everything open, so not just the source code, but the commercial offering itself is open in the sense that, you know, we, we, when we start, you know, we have money, we erase funds, we do all those kinds of things, we'll open that up and you'll be able to see that, um, you know, we are not hiding pretty much anything.
We build everything in public. So, uh, you know, if you follow me on Twitter, you'll see constant updates of like, Hey, by the way, like, you know, we two Xed our amount of verifications last month. And then like, you know, in two days I'll do another one where we five Xed or whatever the number is. Um, and we, we just try and keep it as open as we can.
And cal.com is like the gold standard that a lot of people kind of push towards and we're, we're moving in the same direction. It's gonna take us a while to do like manifestos and, and things like that. But we just believe that, you know, if you're open and honest, most people will, will trust the products.
Um, and then from the community itself, like, we'll trust you to, to help us and guide us along the way.
Andrew: So it is a great perspective and I did not know cal.com was fully open source. That is pretty
cool. I just like, I just went to their website, scroll to the bottom, and they have a
GitHub link right there.
James: Yeah, so they're completely open sourced and you can, you can look at, you know, how much everyone gets paid there. You can look at all those stats, how much they've raised, who they've raised from, uh, every employee that works there, like everything for them is open. So there's no hiding what they're doing behind the scenes.
And, and I think it's a fantastic model and I, I think the team over there should be incredibly proud of how they've handled this open, uh, commercial viable products. Um, and I think, you know, if more people kind of go that trend and we're seeing it more and more these days, um, I, I think it will lean to a better place and a better, like, you know, software in general.
I.
[00:46:00] Spciy Takes
Andrew: okay, so yeah. Now moving on to like more futurey questions. Uh, one question I've been liking to ask all the developers that come on is, uh, what's your spiciest dev take?
James: I don't know if it's the spiciest dev take, but I've always had the, so, you know, I, I think I've ruffled enough feathers in the industry that I still think that, like people are upset about it. But anyway, uh, I think, you know, if you use a good authentication management product, you don't need to use this table.
Uh, I've been a proponent of that for a while. I've ruffled a lot of feathers. Um, I just think it's, I, I, if the product you're using is good enough, then why even bother redundantly storing user data on, on your own? Um. And I don't work a clerk anymore, so people can't just be like, oh, it's 'cause you work a clerk.
No, I believe it. I think it's one of these things that like, yeah, you can get rid of that user's table, get a good authentication product if you're not doing it yourself through third party libraries. Um, and just free up that table and, and figure a better way to, to link everything together. Um, it's not overly spicy.
Well it is, but it's not. But yeah, that's definitely one of my spiciest ones.
Andrew: It's a good take. I, I like doing less work.
James: Yeah, exactly right. It's le one, it's less work and, and, and you know, two, it just makes it easier for you to be like, okay, well I know they have a unique ID in, in my authentication product. I'll just use that as my identifier across my database tables. Alright. Now I don't have like an additional table that I have to like keep up to date and if I need to add and, you know, or remove fields, like I have to figure out how to migrate that.
Like all that goes away. Um, and yeah, I think, you know, I. I started a whole Twitter war about it and I really got caught up in that and it was fun. But yeah, like I think, you know, I think it's still viable today.
Justin: I definitely do think one of the hardest problems we face generally, which is such a simple seeming problem, is like having two data sources representing the same entity get tricky You know, they, they always go outta
sync.
James: Absolutely. And I think, you know, that that's a, a valid argument that people come up with, which is like, yeah, well, you know, if, what if something changes in this product and that's out of sync with this product? Like yeah. Uh, it definitely is tricky. Um, but I think, you know, if you're using a good authentication provider, whether it's clerk or Zero, or whoever, they have mechanisms in place to make sure that you always get back in sync at some point.
Um, and, and yeah, that, you know, we don't have a users table at unkey. We just roll it as is and, and, and we reference everything via tenants. And, and that has been working really well for us.
[00:48:31] Future of Managed Backend Services
Justin: So you've been working in this, uh, space. I mean, I, I see unkey as being very sort of tangentially related to, to cleric, uh, as you've worked in this space of, uh, sort of these. Service provider, like critical service providers to gating this, this deeper product. Um, what do you think the future of this space is?
Um, and maybe this is like more broadly the, the sort of, uh, I won't say back into the service, but these like critical components as a service. Like, yeah. I don't know. Where do you think the space
is going?
James: So I think you're gonna see more of these show up, whether it's like, you know, or, or another authentication provider or maybe another database provider or whatever it might be that's in this critical path that we're all on. Um. I think you're gonna see more of them. And the reason is, is because these com, these services that are on mission critical, are so hard, they're so hard to get right.
And, and if you're scaling at any level, whether you are building a side project or you are trying to build a startup, you don't have time to get it wrong. You have time to move off of it later. Right. So there's, there is a, a potential that, you know, you outgrow this, the, this, this service that you're using, whether it's an off provider or or, or whoever. Um, there is a point where you may outgrow that. And then at that point, if you are outgrowing your service provider, that means you have the team in place to actually do it. Right. And there's no, it's not an emergency. There's no like, oh God, I gotta get off of clerk tomorrow because if I don't like. The whole world's gonna explode.
That, that doesn't exist when you are using one of these, unless you know they're down for seven days in a row, then sure, then it's mission critical. But, um, but if you're ready to scale off of these products, the idea of doing it yourself, I still think you're wrong if you're gonna try and do it yourself, but that's fine.
Um, it becomes less mission critical. You can do it correctly, the right way with the right people in place with the right security measures. Um, and then you end up, you know, taking it on your own back. but when you're scaling, you can't do that, right? If it's just two people, like, if it's just me and Andrea, I don't have time to figure out, like, you know, how to do organizations and invitations and all these other things that come along with building out B two B stuff.
I don't have time for that. But like Clerk gave it to me and it took me 20 minutes. I'm done. I don't have to worry about this ever again. But if we roll our own, it's easy for us to kind of. Slowly migrate off of that and, and worry about it. And I think you'll see that more and more in other parts of the industry, whether it's, you know, another FF provider or another, you know, sentry esque open source project or something like that, where that kind of comes into play.
Like all of those monitoring systems, like I think all of that stuff, you're gonna see more and more of them. And, and a lot of them will fail because they just think, oh, I can do it better than X. And then they realize, wow, this is really complicated. Um, and some will succeed. And, and I think the next five years are gonna be very different than the last five years.
Like I think we've seen a real boom in them recently, but I think the next five years are really gonna transition to this. You'll probably end up using more of those services in your next project than ever before. So the only thing you ever really worry about is business logic, not everything else.
Andrew: Yeah, it's like, it's almost like the componentization of backend like components have become a huge thing in front end. Like I want the same thing in the backend. I wanna be able to put Lego blocks together and build my application. I don't wanna have to whittle my own Lego Lego
blocks.
James: Right. Yeah, I mean I did that for a number of years and it was horrible, like building out like mission critical services to, like I worked at one point for online registrations for like motor vehicles. So if you like bought a current Pennsylvania, we, they could issue the tags right there. And I built some of that behind the scenes.
Um, and, and that was like the worst thing ever. 'cause you're trying to like, build out this service that's mission critical for dealerships and there's nobody else is doing it, so you have to build everything from scratch. There's no packages. It's like, you know, the year is 2009 where React was barely a thing and Angular was like the most popular thing.
Um, and, and, and we were building around that and it was the worst. I've never been more excited about web dev than right now. It's just so easy to get started. It's so easy to scale and, and you, you will see more of that in the backend, I think in the coming years where people realize that, hey, it works in the front end.
Let's do this in the backend and you'll get the same experience.
Justin: I think something that we're seeing too is like, well, there's a refocusing of how many engineers do we actually need to build a product and make it sustainable? That's like a real question, and people are actually starting to think a lot more about the value of engineering hours and like how you scale teams, uh, which makes like, you know, branching off and using a service a, a, a great idea.
Uh, and then the, the landscape is just becoming so much more competitive,
James: Yep.
Justin: Partially because of the consequences that it's easier than ever to spin something up. So starting new products is, you know, probably as cheap as it's ever been and. Given that we have this and folks can iterate so quickly on their core products, if you're spending a lot of time doing business infrastructure stuff and you're not iterating on your product, you know, somebody's gonna swallow you whole.
So that's a, that's a big, I think a big driver of this overall space too.
James: Yeah, and I think you're, you're seeing that already where, you know, you see these big titans of the industry that, you know, 10 years ago it was like the gold standard that's where you wanted to go and work. They were building the coolest stuff. Like they're just not doing it anymore. They're just don't, they're moving it like monolith that, you know, 10 years ago they were laughing at these monoliths of like, ahaha, like, it takes you so long to like release a new feature and now they're in the same place they were 10 years ago.
And so now all these smaller startups that can just move at the speed, like I think cal dot com's a great example of that. Like if you look at candidly. Which is their direct competitor, like cal.com ships so much all the time for like, if you look at their release, like it's just insane the amount of releases they do.
And you look at Calendly, they're releasing like one, a one every quarter, maybe like one big feature a quarter. And like why do you think cal.com is so popular? Because they like, if you need a feature, they can ship it faster than anybody else. So like you go and ask them and they're like, that's a great feature, we should do that.
And they go and build it like, and it's in there in like, you know, 2, 3, 4 weeks. You're like, wow, okay, yeah, I'm gonna use their product because they can ship this at speed. Um, and I think, you know, that's just gonna be more and more apparent as time goes on that small startups can ship way faster.
Andrew: Exciting time to be a frontend debt or a web developer at
least.
James: Indeed, indeed.
[00:55:28] Tooltips
Andrew: Okay. With that, let's transition to tool tips.
first up, uh, this is a repo I found thanks to a former guest, Steve Manuel. Uh, this i iWasmnizer-ts from Intel and what it take, what it does is it'll take, uh, some TypeScript code. It's a subset of TypeScript. They're working to support, uh, all different language features, but you can take some TypeScript code and compile it into a was module That seems like super cool to me.
And just like you might go like, why, why would I wanna do that? I got no on a server somewhere. But, uh, I think this would probably provide lots of security benefits because of the sandboxing. Like you can create a TypeScript program and run it now in any other language with something like extism or something that supports was.
So if you've been looking for something like this, this seems like the go, the go-to repo since it's been updated in the last two days and is from Intel.
James: Exciting to see where, uh, all the awesome stuff is going.
Yeah. Watson seems to be really taken off recently. Like there's been a lot more, uh, in the industry than probably like six months ago. It's, it's crazy to see how much, uh, the active development is in that space.
Justin: Yeah, sandboxing is really hard. So having something that has like a solid sandboxing model, uh, is, is already like so much further ahead and then having a lot of compilation targets. Yeah, it's, uh, I think it's only gonna continue to explode. Really exciting time for that too.
Andrew: next up we have verticalize.
Justin: This is a, a kind of a weird library that I saw, which is like very, uh, it's very creative. So it's making a pipeline, like operator just using a function, uh, or a, a proxy essentially, I guess. So, uh, if you've seen the, the, the JS pipeline proposal where you can like, you know. Uh, have a function and then like pipe other functions to it, essentially that, uh, it's just using a novel, sort of like function chaining syntax or whatever.
Andrew: Uh, I personally would much prefer that we actually get like a proper pipelining syntax in the language, you know, instead of, uh, doing this. But this is very clever and it's super small. It's like 200 bytes ified, so it's like basically nothing. Um, so yeah, it's a pretty novel idea. Yeah, they, they use the v character there pretty well. Yeah. Really makes the eye flow down through the, the control flow. Uh, next up we have reflect notes. We actually talked about this a little bit on the
last episode, I think.
James: Oh, nice. Yeah. Yeah. So this is my, uh, uh, shout out to Andreas, who, who first switched over before I did. Um, yeah, I'm, uh, really bullish on this right now. Um, some of the features just, it's just absolutely insane. So right now, because we take a lot of meetings, we do a lot of stuff, like being able to essentially link your calendar and then just like have notes for every calendar invite and like being able to sort of have that, um, is, has made it really easy and being able to search through them and, and have it, um.
I'm not a huge note taker, so I don't take a large amount of notes just because like my brain doesn't really work that way. So when I do take notes, I need to be able to find them at some point. And, you know, I've used Notion in the past and I've used obsidian and I've used every other kind of, and, and this is the only one that's made it easy enough for me to be able to trade between devices and, and sync everything together and really make it easy.
And, and having that calendar built in is just been like the like game changer for me. 'cause I'm like, oh, sweet. I can just take a quick couple notes here and I can share it with Andreas and Andreas can share it with me. And, um, yeah, it, it is been super worth it and definitely, uh, highly recommended if you are looking for something that you can just do all even note taking in.
Justin: Yeah. One of the things I really like about Reflect is they make, um, people as like a first class entity in the system. Um, which I, I really appreciate that. Like, people in meetings being like first class entities, uh, which, you know, for a lot of things that we do in life, it's like people in events are super important,
.
James: Yeah. And, and when you take, like, you know, if you take two or three meetings with somebody or you're, maybe even if you're a manager and you're doing one-on-ones, like being able to have that first class entity of a person and then clicking on them and then seeing everything that you've talked about in the last, you know, three or four meetings is so useful.
Um, yeah. When I was at Clerk, I, I would do that, which was, you know, all my team have their one-on-ones and like I could look through and talk about, okay, this is what we talked about last week, how can we like close that loop and make sure we're all good there before we move on to new things. Um, yeah, it's, it's so good.
Um, and definitely worth the $10 a month.
Andrew: next up in line with, uh, my last tool tip is a, a package called Carton, which allows you to take, uh, machine learning models, uh, from a few different types of machine learning libraries, and then package them in a way that you can use them across languages really easily. So, like in their docs, they show, uh, them loading up in.
Uh, stuff in various languages. Like they have a TypeScript, APIA Rust, API, and uh, I like that it's just like a, a layer in between me and all the complexity of machine learning models. Like I'd love if we could move to a place where like using an ML model is just like a one line of code thing and I don't have to think about a lot of other stuff.
'cause it's, it's pretty hard, uh, and not very portable 'cause everything's in Python. So I, I just like seeing more projects that are making it easier to use ML and stuff that just isn't Python.
James: Yeah, that's like one of my only reasons not to do ML stuff really is like any like investigation. Like I, when it got really popular like for a while where it was like really booming, I like did a little python and I was like, man, I don't like Python. I remember why I never did like scripting in Python.
So yeah, anything that makes it like easier to, to using your language of choices is definitely something super interested in.
Andrew: Yeah, and it, I think it seems to have some was built in there, so maybe you could run this in a browser. I'm not sure how how fast n ml model would run in a browser. But the, the fact that you can do, it's still pretty cool. Uh, next up we have Deno queues
Justin: yeah, I actually mentioned this in our last recording, but, uh, this is a new feature that Deno released. So Deno has already had a, a key value service and the API for their key value service is just, just so nice. There's, it's, there's so little to it, and now they're releasing AQ service. The thing that I, I, I'm, I guess I'm pretty bullish on Deno overall, and the thing that I really, really love about these services that they're integrating is they feel like language features, they're just so intuitive. It's like not some, you know, crazy API that you're trying to, to wrangle or whatever. It literally feels like more of a native like js thing or ts thing in this case. Um, and I'm, I'm super excited about that. And I'm also, you know, super excited and hopeful that they come out with like a, the rest of the core set of functionality that you need to sort of like, build basic services.
So the KV and the QS are always, are, are already like a huge step forward, you know, with some like blob storage in there. They're gonna be, you know, they're gonna be a, a really compelling offering in this space. So I'm, I'm sort of excited to see that evolve.
Andrew: Yeah, it looks pretty cool. Uh, next up we have Rise the Calendar that works for you.
James: Yeah, this is another one of me. I promise that, I promise you guys, I do have some code one at the end, I promise. Um, but yeah, rise is, uh, is, is really, really good. So let's say you've got like a team and, and you're trying to find time on your calendar, or maybe you need to meet with an external person.
This allows you to essentially one block off time for like focus or, or whatever, so that even if your calendar gets filled up, it will like put blocks on your calendar automatically once it gets too full so that you can actually work on, you know, doing software development or whatever you do at your job.
Um, but then on top of that, like if, for example, all three of us are, are a team and we need to meet with an external person that, or maybe an external team or another team in the department, you can essentially give them a scheduling link and it will decide based upon that of all the three people, like what's the best times to meet.
And it'll basically give them like a cal.com link that they can then pick a time and then you can approve it. Um, and then on top of that, because I work cross, you know, time zones, it has a built-in feature that tells me what time it is for my team members. So like, Andrea shows up and, you know, if I go and open my eyes right now, it says it's 10:35 PM So I know for a fact that he is probably not gonna wanna meet right now.
Uh, but I can find a time and it will advise, you know, based upon, you know, however long you set for your time limit. So there's 30, 45 and 60 at the bottom. You can select one of those and it will give you, hey, the best time tomorrow to meet would be 11:00 AM and then you can like, send a request and, and, and give it to your team.
Um, yeah, and it's just been super helpful trying to keep everything in track and, and trying to do this cross. You know, it is hard when you have to do mental math every time of like, oh, he's in Germany plus six. Okay, the time will be this for me. But then, oh, okay, this person's in. You know, west coast. So now I have to do the math to add the extra, you know, three hours in and then it is like a mess.
So for us it's been really great to just be able to give that and be like, here you go. You can pick a time and it'll work. Any of these times will actually work for both of us. Um, so yeah, it's been super nice and it has a great free tier. Like the free tier is like five team members and everything else is included. So you don't even have to like, you know, buy extra stuff. Everything's just included and you can do up to five team members. And then once you get past that, then it costs like 16 a seat and then you just get unlimited seats, but everything is included. So, um, yeah, it's super great. Really, really impressed.
Andrew: yeah, that, that looks pretty good. We, we might have to look at switching
this if it's, uh, free for two people. That sounds
very nice
to me.
James: And honestly it's been like a breath of fresh air to be like, oh, also it's a German holiday on this day. Like, okay, cool. Like I don't have to worry about that. Like I can just skip that. Like all that stuff is built in. It's just fantastic.
Andrew: Yeah, li living in California, it is like the second worst place in the world to be. If you wanna go on conference calls with people, the first worst would be Hawaii. Hawaii. You're literally never going to be able to talk to anybody. Uh, but yeah, we've had the same problem here with like trying to schedule anybody that's outside the us.
It's like, I don't wanna be up at eight in the morning and Justin doesn't want to be upper super late either. So yeah, definitely a hard problem to solve. The
world's a
big place.
Yeah. And then now for the last, uh, dev tool tip, uh, Hanko
James: So hangover is, uh, authentication and user management. Uh, but it's specifically built right now for sies, which is becoming incredibly popular. And if you dunno what pasky is, it's essentially like. You can use, uh, for example on your, on your Mac, it allows you to sign in without actually providing any details.
Uh, and it's stored securely in the key chain. So even if they get compromised or you get compromised or whoever gets compromised, there's no way for, uh, anyone to access anything. Um, it's basically the future of how things are gonna work. It's all passwordless. Um, and yeah, so I used this recently. Uh, I was just checking it out, uh, for just like a side mess around kind of thing.
'cause I like to just look what's going on in the industry. Um, and it was super great. It's very similar to kind of what Clerk is doing in North, where it's like got elements and you just kind of drop those on. Um, and then based upon whether Pasky is enabled or not, you get like different routes. So you could just do email with an email code or you could just log in with PAs keys or, you know, social providers like Apple, Google, et cetera.
Um, and it's super impressive and it, you know, you can get up and running in. Minutes. Uh, very similar style. Um, and yeah, they just started to build out. They are open source and it's been, uh, yeah, super interesting.
Andrew: That's cool. I I, I don't think I've logged in this way yet on any service.
James: This was the first time I've ever done it too. I was like, oh, pass keys. Finally someone's doing it and it's like their main focus. Let me try it out. Um, and it's super interesting how it works. So when you first sign up, uh, it will essentially send you an email code and then immediately afterwards it will ask you, Hey, do you want to use, uh, pass keys?
And then you click it. And if you're on like an app, uh, Mac device, it'll just ask you like, do you want to enable this for this device? And you just click continue. And then anytime you sign into this, you just click passkey and it'll just sign you straight in. Use your biometrics.
Andrew: that's nice.
so Throw
one password out. It's no passwords now.
James: Yeah. Yeah. exactly. Exactly. Yeah, exactly. No need for passwords ever again. Just get rid of that. Get rid of your password managers. Just use PAs keys for
everything.
Justin: Yeah, that'd be a nice feature.
Andrew: Okay. That wraps it up for tool tips. Uh, thanks for coming on, James. This was a fun conversation talking about, uh, backend components and what you're doing at unkey. So good luck with that and thanks for coming on.
James: Yeah, absolutely. Had a blast. Uh, please reach out if you want to chat again, or if you want CTO, let us know and I'll, I'll make Andreas get up early or late. Early. We we're either one. Um, and, uh, we can chat again, but Yeah, had a super great time.
Justin: Yeah. I just echo Andrew, thanks for coming on. And API Keys is actually something I've been thinking a little bit about. Uh, so it's something that is on the docket for implementation at oxide. So it's like top of mind. So, you know, I'm glad you're working on it. Definitely. I'm, you know. Excited to see more innovation in this space, allowing people to just focus on their products, uh, which is cool.
So best of luck to you and uh, yeah, thanks for coming on.
James: Thanks so much.