j'ai besoin d'un API qui est comme, comment je fais ça ?
C'est quelque chose que j'ai fait dans le passé, ça s'en s'occupe.
Donc, on a décidé de tous les choses qui sont faibles avec les API keys en général,
et comment ils font le marché difficile.
On a basically essayé de les solider en haut-front,
et en ce moment, c'est possible.
Hello, welcome to the DevTools FM podcast.
This is a podcast about developer tools and the people who make them.
I'm Andrew, and this is my co-host Justin.
Hey everyone, our guest today is James Perkins.
James is a co-founder of Unkey, which is open source API key management solution.
We're really excited to talk about that today.
James, you had also previously worked at clerk,
which is kind of sort of seems to be booming in popularity.
I hear about it like relatively often these days.
So that's a user management service,
sort of terms, styles itself.
But James, it's great to have you on before we sort of dig in.
Is there anything else you'd like to tell our listeners about yourself ?
Yeah, not really.
Yeah, my name is James.
I also run a YouTube channel where I do like tutorials
and talk about tech in general.
Super excited to be here.
Can't wait to chat about Unkey and everything else.
Cool.
So before we get to Unkey,
I think it'd be good to set up your journey to Unkey
because I think it's pretty interesting how started is like a full time side project
and then move to your full time.
Full time.
So at clerk, what did you do ?
And if you could fill our users in a little bit more about what Clerk is, could you do that ?
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.
Clerk does that.
And essentially the way that clerk is kind of different from everyone else
is they just give you react components
that you can just drop in on your page and that's it.
You're done.
Login page.
While I was there, I did a variety of things.
So I originally started as their dev rail.
When I first was hired, I knew Colin and Braden for a while.
I did some contract work for them.
And then over time, you know, with every start up,
your job kind of transforms into a bunch of different jobs.
So I did dev rail 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 support plus like product feedback loops
through different channels.
But yeah, that was my role at clerk
and I had a really good time there.
And yeah, probably still the best authentication product out there.
And I would, if you haven't checked it out, definitely worth doing.
Clerk reminds me a lot of Stripe from the model of like how,
like how it approaches like providing APIs interfaces.
I mean, it's one thing that I think Stripe has done really well over time.
And this is like, you know what, we're just going to give you a check out page
or give you the components to build the check out form or whatever.
And I think that is a pretty nice model.
Yeah. And I think, you know,
if you look through the history 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're 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 B2C stuff,
here's a couple of dropping components and you're done.
Yeah, especially with Auth,
it's like the worst thing that it's like,
you, 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.
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 TechTweeter,
it's talked about daily by somebody,
whether it's like, this is my top tech stack or whatever,
or like, I just use Cloud for the first time.
And it's very much getting into that like,
resell almost level of like people talking about it now,
where, you know, oh, I deployed to for sale for the first time
and it took two minutes, like it's in that vein now.
And it's super exciting to see the growth that they've had.
Yeah, so Unkey started as a sort of a side project
during that time.
What, like, what sort of led to that thought?
I mean, as I was reading sort of some of the docs,
it's like thinking about like API key management.
It's just an interesting problem to tackle.
So I was like curious, what were the struggles
that you were seeing initially?
Yeah, so I didn't come up with the idea.
So my co-founder, Andres,
actually sort of pitched it to me, but not really.
So he had implemented this on a couple of side projects
over, you know, 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?
And then you implement it one time and it's kind of rough,
but then you're like, oh, it works, whatever.
You kind of ignore it and you move on.
And then you 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.
And we had been friends for a while.
He works at Upstash.
And so we'd been talking back and forth
about a few things.
And 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.
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 going to be
the API is rate limited
or is it every key is rate limited?
And the benefits of having per key rate limiting
means that if you just didn't 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 Justin's fine.
He's got a little bit extra in his rate limit today.
And then, you know, or you become an enterprise customer
and you need more.
You can give that just to that specific 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
because then it's super fast.
It's only as fast as where you're getting the data from.
So if I'm 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 got to 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.
And it's basically in 36 regions right now.
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,
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.
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 we have this thing called fast rate limiting,
which is basically almost a sliding scale,
which is done all in memory.
So assuming the user is always coming from the same region,
that rate limit should be accurate.
But in the case where someone was doing 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.
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 they expire today?
Like, I want to give you a free trial.
It's one week, but I don't want to 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
and playing text anyway,
so like, how do you do that kind of stuff?
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 in the same kind of vein,
which is AI with token-based requests, right?
So you could say to your user pays you,
say $10, and they get 100 API requests.
With Unkey, you can essentially say,
like, this key only has 100 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 API keys in general
and how they make the market difficult.
We've basically tried to solve them upfront
and as quickly as possible.
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 going to think about that upfront.
You're not going to think about like global.
You're not going to think about like temporary keys
and all these things.
So it just makes sense that like, oh,
managed service makes a lot of sense.
Yeah, exactly.
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,
because they're I'm in the US East one
and they're all the way out in Europe.
Like, how do I fix that?
So we just decided, let's do it right first time
and let people just manage it.
Just kind of similar to clerk.
That's really cool.
I mean, I think 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
and some meaningful way.
And like API keys in particular
are interesting because they have
like this security ramification.
It reminds me of like GitHub
and how GitHub's API keys
or their personal access tokens
have sort of expanded over time.
Originally, they had these like really coarse scopes,
you know, and it's just like very broad.
You're like, you know, I really want
to like get more detailed here.
And now, you know,
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 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?
Yeah, so we have definitely thought about this.
It's actually what we're working on right now,
which is essentially what we're going to give you
is almost as Zanzibar style permissioning.
And if you're not sure about the Zanzibar model,
basically it's like the catchall of any type of permissioning.
So you could do role-based
or you can do access-based
or you can do mix of both.
And it's very easy to understand.
It's like human readable.
And we feel the same way
where you could give a key with a policy to say,
you know, Justin can read and write,
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 free form 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.
But yeah, we're working on Zanzibar style model right now.
And we should have that pretty soon.
That seems like a pretty big, like kind of like scope increase
from just API keys now to like user access management.
Yeah, so unfortunately,
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 going to be somebody out there
that needs that use case of like,
I need to be able to differentiate between read keys,
write keys, read and write keys,
you know, all those kinds of things.
And we just want to 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.
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 going to take a while for us to really build.
But once you get it,
the DX will just be second to none.
You won't have to worry.
Yeah, I mean,
that is an important part of the whole thing.
And, you know,
there's this interesting thing is,
I feel like the downstream implications of any system
like, you know, building API keys as a feature
or just thinking about authorization layer.
They're rather complicated,
you know, sort of by their by necessity.
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 tremendous value add
just from the perspective of like,
you know, take a company again,
like GitHub,
GitHub being just amazing organization.
And like, you know,
I see their REST API as like one of the best REST API
sort of ever built.
This is like,
not perfect, of course,
but, you know,
it's like a good model of like how to build a solid REST API.
And, you know,
the note that it took them a while 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,
you know,
Unkey could provide a lot of value out of the box
is like, hey,
here's how we think you should,
you know,
define your scopes and,
you know,
I don't know,
make resources available to your API or whatever.
Yeah,
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 are like REST API works,
essentially,
you already have access to your user data wherever.
So if you already know all of these details,
you can just insert them 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?
And we just know that,
you know,
at some point,
yeah,
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.
And we definitely just want to give you the best advice
and then you can run with it
and use us
or you can delve in
and do your own permissioning somewhere else.
This week's episode is un-sponsored.
If you'd like to sponsor DevTools FM,
head over to devtools.fm slash sponsor.
There you can see the various ways
you can advertise with DevTools FM,
whether it be one to 10 episodes.
We would like to take this time
to advertise our newsletter.
In 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 released something.
And of course,
don't forget about our shop.
If you head over to shop.devtools.fm,
you can buy some DevTools 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 DevTools 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.
Our review wouldn't hurt either
or a comment depending on where you are.
With that, let's get back to the episode.
So we mentioned it a little bit,
but you started working on Unkey
while you were still at clerk.
And I think I and many of our listeners
know that doing two programming jobs at once
is a lot of work.
So how did that go?
Yeah, it's a lot of work.
It's not for the faint heart,
if that's for sure.
I think the only good things that came
really the only good things is that
both Andres and I were super passionate
about the project from the get go.
And once we had implemented the first
like 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?
And I'm very fortunate that Andres is in Germany
and I'm in the US now.
So essentially Andres would finish his day
at my lunchtime
and then he would start working on Anki
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 out of 10
like couldn't ask for a more support system
and she definitely encouraged me to,
you know, go out and seek this
the way it is.
And I don't think I would have been able to do it without her
and her support
because yeah, we were, you know,
taking meetings and talking to people
and getting feedback
and bug fixing at like 10 p.m. at night.
And, you know, all those crazy things
that come along with like deploying a production product
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 super supportive.
So I couldn't ask for anything bad than that.
Yeah, that's great.
And an incredible benefit to that time for sure.
Something that's like super necessary,
you know, it's one of the things
that we have to make these explicit trade-offs
when we're trying to sort of build these projects up.
It's like you do, you do sacrifice time
and 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
where you're really just trying to figure out like,
okay, what is the sort of basic shape of this?
Or were you actually just like thinking
about how you build off the business
and like going deeper than that?
Yeah, so when we talked about the project,
we were both,
we knew that everything was going to 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 want to 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're 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.
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 want to make sure that we're, you know,
providing this easy to access open source project.
So 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.
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.
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 you'd be fine.
But yeah, that's basically the managed services
is all of the bells and whistles.
At what point did it like, did it like really crystallize
to use 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.
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 interest, you know,
that started to happen a lot.
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 Clark,
I treated Clark as if I had found it Clark.
Like I was a very early person in 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
in the beginning where we were trying to get the traction going
and I slowly saw myself being like,
I'm less worried about Clark now
and I'm more worried about the success of Anki.
And that's when the sort of bell curve started to happen.
For me, it was a difficult decision.
I never really, you know,
that we're all still friends in the grand scheme of things.
Like 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.
Yeah, for sure.
I mean, at a certain point,
you really have to say, am I going to give enough fuel for this thing
to turn into a real fire
or am I going to just like, you know,
keep it as a side project?
And also, I feel like it's really hard 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?
Yeah, you definitely get spread tooth in
and I was talking to Andrew before we start recording
about how like I do YouTube,
but that gate, I had to give that up.
Like I didn't record a video for like 35 days.
That 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 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?
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 you know, it's open source forever
and we'll maintain it as a side project.
But 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 friends or relationships in general.
And you definitely don't want to give those up
in favor of business, in my opinion.
Yeah, I found the same thing.
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.
Yeah, and that's how I felt.
Like, you know, it would be the weekend
and I'd be working on Anki sort of like, you know,
just the laptop on the lap
and just kind of sitting around doing stuff
and 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 capacity to go and do it
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.
Yeah, well, I mean, massive respect
for being able to pull it through
and make the decision to really focus.
I mean, cause especially at the point
where you're already feeling burn out,
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
and it can be hard to sort of manage recovery
while you're like really doubling down and focused.
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 whatever you felt like?
Yeah, it worked out very well.
So like Andres is still full time in his role.
So right now it's like a part time and a full timer
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 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 can just walk away and I, there's no guilt
because before when I was doing it part time
and doing club 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 the guilt would start
in the back of my mind of like, shit,
if we don't do X or Y tonight,
it's not going to get done until 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 starts to play that mental fatigue even more.
But now, yeah, like I feel,
mentally, I feel great right now.
You know, it's only been a couple of weeks
since I really made this full time switch,
but like, yeah, 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 going to 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're like getting to do that now
versus having to spend all that time
kind of worried about that in the back of my mind.
So like, clerk unki kind of has like many front ends
in the case of unki,
you have lots of different SDKs.
So what platforms do you guys support
and like which ones are you like most excited about?
Yeah, so from like a code standpoint,
we support TypeScript, Rust, Alexa, Go, Python,
all the big sort of back end we have available.
And some of those come from the community, right?
So 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.
So we have a lot of that, but the, yeah,
so we're most excited about TypeScript and Go really
because that's basically the entire platform
to build on those two things.
And yeah, those two excite us a lot,
but the benefit 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 want,
the ability to just tap into that REST API
and only having a few endpoints
and all those endpoints kind of work the same way
makes it really, really easy.
But yeah, TypeScript's always something I'm excited about,
Go is something we're always excited about
because most of it's built in either one of those
and those are pretty popular in today's world.
One that just jumps out to me
that's like different from all the others in your docs is NUXT.
Did that one come from a community member?
Yeah, it came from Daniel.
Yeah, yeah, he, he, he's, yeah, of course.
Who else is going to come from, right?
Yeah, he's a friend of ours.
He hopped in and was like, hey,
like love to just build like a wrapper for NUXT.
And I think he was the first SDK
that was community driven.
I think it was either him
or we have a community member that did Python.
It was either one of those and it was very, very quick.
That man is an elemental force and open source.
It is crazy at this point.
Yeah, it just appears out of nowhere.
And he's 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 ping him and he's like, yeah, I'm on it.
This is crazy.
Yeah, I'm still not convinced
he's not a machine learning.
Yeah, I agree.
I agree.
So obviously with a product like this,
security is really important.
I mean, this is, you know,
the way that you're securing access to your API.
So could you talk a little bit
about your security posturing,
how you sort of think about these things
and sort of how you communicate it to customers?
Yeah, so security is super important for, you know,
everything and everyone.
It was one of our main things that we were concerned about.
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 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,
there's no way for us to essentially give that,
give those details out.
And then like for like,
the other part of that is,
is 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've got un key open.
There's no way for them to just go and grab a key
and be like, oh, I've got your keys now.
And then just like off they go.
And so those things are treated pretty heavily where we are.
And we do a lot of, you know,
audits around how that's working.
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 me go and look at the details of it.
You can see every request, where it came from,
where it was, you know,
like where the request originated from,
where we process 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.
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 100,000 requests
and they weren't yesterday,
why they suddenly spiked.
You can see that and you can look and see.
And we tell you, you know,
if we've rate limited them or whatever,
all that stuff comes with it.
So yeah, we're 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 outside of,
you know, what keys they're supposed to have
for what environment,
we try and keep that pretty locked down.
And then we use clerk.
So then all our use data is stored.
So yeah.
So yeah, so we have that as well.
So like, you know,
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
because we just use clerk.
So we don't have to worry about like,
accidentally leaking emails or things like that,
that those things don't exist either.
Do you guys have any like monitoring in place?
So like if that person does like,
you see a key go to 100K,
you can be like, oh, get an email.
Yeah.
Yeah.
So we have a lot of monitoring,
mostly because, you know,
we're like on the critical path.
So if something goes down,
breaks or like we get a huge bike in traffic,
we need to know right now.
So we have,
so we use discord for pretty much everything.
So we have 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.
And that's caught a few things,
to be honest.
There's been a couple of times where like,
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
because they're in that area
and we get an error
and then we reroute their traffic somewhere else.
And that's really helped too.
But yeah,
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, oh,
little spike,
little dopamine hit
as someone else uses the product.
So yeah,
it's pretty well watched.
That's fun.
So I mean,
it sounds like you're,
you know,
still pretty early in this journey,
like implemented some pretty critical features.
You're working on the sort of Zanzibar,
like authorization system,
which would be really cool.
What do you have like other ideas for features
that you're wanting to implement down the road,
something you're really excited about?
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.
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 a Tike is a good example.
They claim that they're globally distributed.
They're not.
They replicate some data around,
and you can only do a specific amount of regions
and things like that.
So we think we can still do the same model we have today,
but globally distribute gateways too.
So it'll be just as fast mission critical.
And we have a POC
that we've done a couple of times.
And yeah, it just works.
Like what we have right now just works.
We've got to implement a lot of security features
and things that come along with that.
And yeah, we're super excited about it.
We think it will be a refreshing change for,
again, similar idea of like front and 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, a couple of clicks,
and I'm done.
Okay, cool, great.
I can like move on.
And that's kind of what we're aiming for.
So as one of those front end developers myself,
that mainly does design systems and apps,
I have no clue what an API gateway is.
So what is it and like, why would I want to use one?
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 just like a big routing table
that tells everywhere where it can go
and how many times they could access it.
And based upon permissions, could you actually read, write,
get this data back, all that kind of stuff.
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.
And you need to do it as scale
and you need to essentially put it in place
and then have the data around where everything is happening.
And it usually, you don't get one until you scale to X
and then all of a sudden you realize you need one.
So that 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 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.
And yeah, it's essentially our key system
will be like a gateway drug into gateways.
You'll get to a scale point where you realize
that issuing keys all the time is just not going to work anymore
and you'd rather just stick this in front of it
and deal with the traffic that way.
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 conjunction.
Yeah, 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 Unki 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.
Yeah, and that's what we've seen.
So when we first were talking about gateways,
we spent a lot of time just trying to sign up
for gateways, whether they were open source gateways
or just like, you know, they gave you a free tier
and you could try out and stuff like that.
And they always tout 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 then we won't have to worry about it.
And the biggest thing we saw with gateways
was that you literally needed a PhD to just get it to work.
And we were like, if we're struggling
and this is the industry that we're in,
there's something wrong here.
And then layer on top of that,
you want to like distribute it maybe in two locations.
Then you need a second PhD to figure out
how that all communicates together.
And yeah, it was rough.
It was really, really bad.
And we just looked at it and went, we can do that.
And we can do it better.
We can make it easier and accessible.
Yeah, I think overall I like this trend
of like really focusing on the early user story,
really focusing on like, you know,
going from the usability side of this
and going deeper into the technical thing.
I feel like it does put a really good angle on it
and ends up, because it's like,
there's always this challenge of,
and I see this economy 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
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 mean to like be reductive here,
of course there are many people
and this is a generalization,
but sometimes you can have like worse APIs
that end up coming out of that,
because it's just like the sort of methodologies
and thought processes of how they think
about building these things.
So it's just different, you know,
they have different mindset or whatever.
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, no, don't want it, you know.
Yeah, and I think we've seen that more and more
probably since, you know,
Vercel actually became Vercel,
you know, because they were Z at one point and now
and like when they did that change over
and they started to push this mentality of like,
yeah, you could go to AWS and 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.
That methodology then sprouted
a bunch of different services, you know, like Render
and you know, people started moving away from Heroku
because they decided they were better than everyone else.
And you know, like these mentality shifts
started to happen and you know, even off went that way.
Like your option was like all zero.
That was it.
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 and UX
that you could get that didn't involve you doing it all yourself.
And now, yeah, there's this new generation of developers out there
that are like, yeah, I don't want to think about this.
I just want it to work and then when it works,
I don't want to think about it again.
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.
But now, yeah, there's definitely this new age
of developers out there.
Yeah, for sure.
Yeah, so now we're moving on to more future questions.
Well, before we do, I have one,
I have one like thing to maybe round off this section.
So a lot of one key is open source.
All of it is open source, ostensibly.
Yeah, which is great, which is great.
We are huge proponents of open source.
And we talked to a lot of people who are building businesses off of open source,
but it can be a non trivial thing.
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 sort of what are the challenges
you think you're facing and stuff like that?
Yeah, so I think with any open source project in general,
there's 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?
And so we've kind of taken the approach of similar, you know,
commercial open source software out there like cow.com,
where we try and be open and honest about everything.
And we kind of have this like idea of, while yes,
we understand that you're going to run into issues
and we're going to have to fix them.
And yes, you could do it yourself by opening a PR or whatever.
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.
And then secondarily 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,
we have it be open source and you could look and fix it yourself
if it's something that maybe you feel 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.
And so those things together kind of build out this philosophy of like,
everything we do is as open as possible.
Like 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.
And then like also on the flip side of that is that,
yeah, as a commercial product, it's very hard to be open
on all 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.
And we just try to emulate cal.com
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 when we start, we have money, we raise funds,
we do all those kinds of things, we'll open that up and you'll be able to see that.
We're not hiding pretty much anything, we build everything in public.
So if you follow me on Twitter, you'll see constant updates of like,
hey, by the way, we two X star amount of verifications last month
and then in two days I'll do another one where we five X or whatever the number is.
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 moving in the same direction.
It's going to take us a while to do like manifestos and things like that.
But we just believe that, you know, if you're open and honest,
most people will trust the product.
And then from the community itself, like, we'll trust you to help us
and guide us along the way.
So it's a great perspective.
And I did not know cal.com was fully open source.
That is pretty cool.
I just went to their website, scrolled to the bottom
and they have a GitHub link right there.
Yeah, so they're completely open source and 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, every employee that works there.
Like everything for them is open.
So there's no hiding what they're doing behind the scenes.
And I think it's a fantastic model.
And I think the team over there should be incredibly proud of how
they've handled this open commercial viable products.
And I think, you know, if more people kind of go that trend
and we're seeing it more and more these days,
I think it will lean to a better place and a better,
like, you know, software in general.
OK, so yeah, now moving on to like more future questions.
One question I've been liking to ask all the developers that come on
is what's your spiciest dev take?
I don't know if it's the spiciest dev take, but I've always had the...
So, you know, I think I've ruffled enough feathers in the industry
that I still think that like people are upset about it.
But anyway, I think, you know, if you use a good authentication
management product, you don't need a users table.
I've been a proponent of that for a while.
I've ruffled a lot of feathers.
I just think it's...
If the product you're using is good enough,
then why even bother redundantly storing user data on your own?
And I don't work a clerk anymore, so people can't just be like,
oh, it's because 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 users table,
get a good authentication product if you're not doing it yourself
through third party libraries,
and just free up that table and figure a better way
to link everything together.
It's not overly spicy.
Well, it is, but it's not.
But yeah, that's definitely one of my spiciest ones.
It's a good take. I like doing less work.
Yeah, exact.
Right. It's one, it's less work.
And, you know, two, it just makes it easier for you to be like,
okay, well, I know they have a unique ID in my authentication product.
I'll just use that as my identifier across my database tables.
All right.
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,
all that goes away.
And yeah, and I think, you know,
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.
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 can get tricky,
you know, they always go out of sync.
Absolutely.
And I think, you know, that that's a valid argument that people come up with,
which is like, yeah, well, you know,
what if something changes in this product and that's out of sync with this product?
Like, yeah, it definitely is tricky.
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.
And yeah, but, you know, we don't ever use this table at Anki.
We just roll it as is
and we reference everything via tenants
and that has been working really well for us.
So you've been working in this space.
I mean, I see Anki as being very sort of tangentially related to clerk.
As you've worked in this space of sort of these service providers,
like critical service providers to gating this deeper product,
what do you think the future of this space is?
And maybe this is like more broadly the sort of,
I won't say back into the service,
but these critical opponents as a service,
like, yeah, I don't know, where do you think the space is going?
So I think you're going to see more of these,
whether it's like, you know,
another authentication provider
or maybe another database provider
or whatever it might be that's in this critical path that we're all on.
I think you're going to see more of them.
And the reason is because these services that are on mission critical are so hard.
They're so hard to get right.
And if you're scaling at any level,
whether you're building a side project
or you're 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 is a potential that you outgrow this service that you're using,
whether it's an off provider or whoever.
There is a point where you may outgrow that.
And then at that point,
if you're outgrowing your service provider,
that means you have the team in place to actually do it right.
And it's not an emergency.
There's no like, oh, God, I've got to get off of clerk tomorrow
because if I don't, like, the whole world's going to explode.
That doesn't exist when you're using one of these.
Unless, you know, they're down for seven days in a row,
then sure, then it's mission critical.
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 going to try and do it yourself,
but that's fine.
It becomes less mission critical.
You can do it correctly the right way,
with the right people in place,
with the right security measures.
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 Andre,
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 B2B stuff,
I don't have time for that, but, like,
Clark 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 I'm worried about it.
And I think you'll see that more and more
in other parts of the industry,
whether it's, you know, another Orph provider,
or another, you know,
Sentry-esque open source project,
or something like that, where that kind of comes in
to play, like, all of those monitoring systems,
like, I think all of that stuff,
you're going to see more and more of them.
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.
And some will succeed.
And I think the next five years are going to 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 going to 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.
Yeah, it's almost like the componentization of back-end.
Like, components have become a huge thing in front-end.
Like, I want the same thing in the back-end.
I want to be able to put Lego blocks together
and build my application.
I don't want to have to whittle my own Lego blocks.
Right.
Yeah, I mean, I did that for a number of years,
and it was horrible.
Like, building out mission critical services to...
Like, I worked at one point for online registrations
for motor vehicles.
So if you bought a car in Pennsylvania,
they could issue the tags right there.
And I built some of that behind the scenes.
And that was the worst thing ever,
because you're trying to build out this service
that's mission critical for dealerships,
and 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.
And we were building around that, and it was the worst.
I have 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 you will see more of that in the back-end,
I think, in the coming years, where people realize that,
hey, it works in the front-end.
Let's do this in the back-end,
and you'll get the same experience.
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,
which makes, like, you know, branching off
and using a service a great idea.
And then the landscape is just becoming
so much more competitive.
Partially, because of the consequences,
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 going to swallow you whole.
So that's a big, I think,
a big driver of this overall space, too.
Yeah, and I think 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, monolithe,
that, you know, 10 years ago,
they were laughing at these monolithes 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 cow.com's a great example of that.
Like, if you look at Candle,
which is their direct competitor,
like cow.com ships so much all the time
for, like, if you look at their releases,
like, it's just insane the amount of releases they do.
And you look at Candle, they're releasing, like,
one, one every quarter, maybe?
Like, one big feature a quarter?
And, like, why do you think cow.com's 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,
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, two, three, four weeks, you're, like, wow.
Okay, yeah, I'm gonna use their product
because they can ship this at speed.
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.
Exciting time to be a front-end developer,
or a web developer, at least.
Indeed, indeed.
Okay, with that, let's transition to tool tips.
First up, this is a repo I found
thanks to a former guest Steve Manuel.
This is WasmNizrTS from Intel,
and what it does is it'll take some TypeScript code,
it's a subset of TypeScript,
they're working to support all different language features,
but you can take some TypeScript code
and compile it into a Wasm module.
That seems super cool to me,
and you might go, like, why would I want to do that?
I got node on a server somewhere,
but I think this would probably provide
lots of security benefits because of the sandboxing.
You can create a TypeScript program
and run it now in any other language
with something like Ecstism,
or something that supports Wasm.
So if you've been looking for something like this,
this seems like the go-to repo
since it's been updated in the last two days
and is from Intel.
Exciting to see where all the Wasm stuff is going.
Yeah, Wasm seems to be really taken off recently.
There's been a lot more in the industry
than probably six months ago.
It's crazy to see how much the active development is in that space.
Yeah, sandboxing is really hard,
so having something that has a solid sandboxing model
is already so much further ahead
and then having a lot of compilation targets.
Yeah, I think it's only going to continue to explode.
Really exciting time for that, too.
Next up, we have Verticalize.
This is kind of a weird library that I saw,
which is very creative.
So it's making a pipeline-like operator
just using a function, or a proxy, essentially, I guess.
So if you've seen the JS pipeline proposal
where you can have a function
and then pipe other functions to it,
essentially that,
it's just using a novel sort of function chaining syntax,
or whatever.
I personally would much prefer that we actually get
a proper pipelining syntax in the language,
instead of doing this,
but this is very clever and it's super small.
It's 200 bytes minified, so it's basically nothing.
Yeah, it's a pretty novel idea.
They use the V character there pretty well.
Yeah, it really makes the I flow down through the control flow.
Next up, we have Reflect Notes.
We actually talked about this a little bit
on the last episode, I think.
Oh, nice. Yeah, yeah.
So this is my shout out to Andreas,
who first switched over before I did.
Yeah, I'm really bullish on this right now.
Some of the features, it's just absolutely insane.
So right now, because we take a lot of meetings,
we do a lot of stuff,
being able to essentially link your calendar
and then just have notes for every calendar invite
and being able to sort of have that
is made it really easy
and being able to search through them and have it.
I'm not a huge note taker,
so I don't take a large amount of notes
just because 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.
I've used Notion in the past,
and I've used Obsidian,
and I've used every other kind of...
And this is the only one that's made it easy enough
for me to be able to trade between devices
and sync everything together
and really make it easy.
And having that calendar built in
has just been like game changer for me,
because I'm like, oh, sweet.
I can just take a quick couple notes here
and I can share it with Andres,
and Andres can share it with me.
Yeah, it's been super worth it
and definitely highly recommended
if you're looking for something
that you can just do all even note taking in.
Yeah, one of the things I really like about Reflect
is they make people as like a first class entity
in the system,
which I really appreciate.
People and meetings being first class entities,
which for a lot of things that we do in life
is like people and events are super important.
Yeah, and when you take like,
if you take two or three meetings with somebody
or maybe even if you're a manager
and you're doing one on ones,
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 three or four meetings
is so useful.
Yeah, when I was at clerk,
I would do that, which was all my team
have that one on ones,
and 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.
Yeah, it's so good
and definitely worth the $10 a month.
And next up in line with my last tool tip
is a package called Carton,
which allows you to take
machine learning models
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, in their docs,
they show them loading up
in stuff in various languages.
They have a TypeScript API
or Rust API,
and I like that it's just like a layer
in between me and all the complexity
of machine learning models.
I'd love if we could move to a place
where using an ML model
is just a one line of code thing,
and I don't have to think about a lot of other stuff
because it's pretty hard
and not very portable
because everything's in Python,
so I just like seeing more projects
that are making it easier to use ML
and stuff that just isn't Python.
Yeah, that's one of my only reasons
not to do ML stuff, really.
There's any investigation.
When it got really popular
for a while where it was really booming,
I did a little Python-y,
and I was like, man, I don't like Python.
I remember why I never did scripting in Python.
So, anything that makes it easier
to use in your language of choice
is definitely something that I'm super interested in.
Yeah, and it seems to have
some awesome built in there,
so maybe you could run this in a browser.
I'm not sure how fast any ML model
would run in a browser,
but the fact that you can do it,
it's still pretty cool.
Next up, we have DinoQs.
Yeah, I actually mentioned this in our last recording,
but this is a new feature that Dino released,
so Dino has already had a key value service,
and the API for their key value service
is just so nice.
There's so little to it,
and now they're releasing a Q service.
The thing that...
I guess I'm pretty polished on Dino overall,
and the thing that I really, really love
about these services that they're integrating
is they fill language features.
They're just so intuitive.
It's like not some crazy API
that you're trying to wrangle or whatever.
It literally feels like more of a native,
like JS thing,
or TS thing in this case,
and I'm super excited about that.
I'm also super excited and hopeful
that they come out with the rest
of the core set of functionality
that you need to build basic services.
The KV and the Qs are already
a huge step forward,
with some blob storage in there.
They're going to be a really compelling offering
in this space,
so I'm sort of excited to see that evolve.
Yeah, it looks pretty cool.
Next up, we have Rise,
the calendar that works for you.
Yeah, this is another one of me.
I promise you guys I do have some code one
at the end, I promise.
But yeah, Rise is really, really good.
So let's say you've got a team,
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 focus or whatever,
so that even if your calendar gets filled up,
it will put blocks on your calendar
automatically once it gets too full,
so that you can actually work on
doing software development,
or whatever you do at your job.
But then on top of that,
if for example all three of us are a team,
and we need to meet with an external person,
or maybe 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,
what's the best times to meet,
and it will basically give them a cow.com link
that they can then pick a time,
and then you can approve it.
And then on top of that,
because I work cross time zones,
it has a built-in feature
that tells me what time it is for my team members.
So Andreas shows up,
and if I go and open my Rise right now,
it says it's 10.35 p.m.
So I know for a fact that he is
probably not going to want to meet right now,
but I can find a time,
and it will advise,
based upon 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 to meet would be 11 a.m.
and then you can send a request
and give it to your team.
Yeah, and it's just been super helpful
trying to keep everything in track
and trying to do this cross.
It's hard when you have to do
mental math every time.
Oh, he's in Germany plus six.
Okay, the time will be this for me,
but then, okay, this person's in west coast.
So now I have to do the math
to add the extra three hours in,
and then it's 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 will work.
Any of these times will actually work for both of us.
So yeah, it's been super nice,
and it has a great free tier.
The free tier is like five team members,
and everything else is included.
So you don't even have to, you know,
buy extra stuff.
Everything is 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 yeah, it's super great.
Really, really impressed.
Yeah, that looks pretty good.
We might have to look at switching this
if it's free for two people.
That sounds very nice to me.
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.
Yeah, living in California,
it is like the second worst place in the world
to be if you want to 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.
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 want to be up at eight in the morning,
and Justin doesn't want to be
super late either.
So yeah, definitely a hard problem to solve.
The world's a big place.
Yeah.
And then now for the last
dev tool tip,
Hango.
So Hango is authentication and user management.
But it's specifically built right now
for PASKIES, which is becoming
incredibly popular.
And if you don't know what PASKIES is,
it's essentially like you can use
for example on your Mac.
It allows you to sign in without actually
providing any details.
And it's stored securely
in a key chain.
So even if they get compromised
or you get compromised or whoever gets
compromised, there's no way
for anyone to access anything.
It's basically
the future of how things are going to work.
It's all password-less.
And yeah, so I used this
recently. I was just checking it out
for just like a side
mess around kind of thing.
So I like to just look what's going on in the industry.
And it was super great.
It's very similar to kind of what Clerk is doing
in Orph, where it's got elements
and you just kind of drop those on.
And then based upon
whether PASKIES is enabled or not,
you get different routes.
So you could just do email with an email code
or you could just log in with PASKIES
or social providers
like Apple, Google, etc.
And it's super impressive.
You can get up and running in minutes.
Very similar style.
And yeah, they just started to build out.
They are open source and
it's been super interesting.
That's cool. I don't think I've logged in
this way yet on any service.
This was the first time I've ever done it too.
I was like, oh PASKIES, finally someone's doing it
and it's like their main focus. Let me try it out.
And it's super interesting
how it works. So when you first
sign up
it will essentially
send you an email code.
And then immediately after it will ask you
hey, do you want to use PASKIES?
And then you click it and if you're on
an app, Mac device,
it will just ask you
do you want to enable this for this device
and you just click continue and then
anytime you sign in to this, you just click PASKIES
and it will just sign you straight in. Use your biometrics.
Super cool.
That's nice. Yeah.
Throw one password out, it's no password where it's now.
Yeah, yeah, exactly, exactly.
Yeah, exactly. No need for PASKIES
ever again. Just get rid of that.
Get rid of your PASKIES for everything.
Yeah, it would be a nice future.
OK, that wraps it up for tool tips.
Thanks for coming on James.
This was a fun conversation talking about
backend components and what you're doing
at Unkey. So good luck with that and thanks for coming on.
Yeah, absolutely. Had a blast.
Please reach out if you want to chat again.
Or if you want a CTO,
let us know and I'll make Andreas
get up early or late early
where you're the one.
And we can chat again. But yeah, had a super
great time. Yeah, I just echo Andrew.
Thanks for coming on. And API keys
is actually something I've been thinking a little bit about.
So it's something that is on the docket
for implementation at Oxide.
It's like top of mind.
So, you know, I'm glad you are working on it.
Definitely.
I'm, you know, excited to see
more innovation in the space allowing
people to just focus on their products,
which is cool. So best of luck to you
and yeah, thanks for coming on.
Thanks so much.