Clerk with James Perkins

Episode Description

James Perkins shares his journey from management to DevRel at Clerk, explaining how the auth platform simplifies authentication with drop-in components.

Episode Summary

This episode features James Perkins discussing his career path and his role at Clerk, an authentication provider that aims to simplify user identity management. The conversation opens with how James landed a new job at Clerk just 12 hours after being laid off from Tina CMS, highlighting the value of building connections through DevRel work, YouTube, and streaming. James traces his origin story from learning Java out of a book, accidentally fixing a bug in a tech support role, and eventually climbing the ladder into management before realizing he preferred teaching and content creation. The discussion then shifts to Clerk itself, with co-host Christopher Burns sharing his firsthand experience migrating from Auth0 to magic links to Clerk, including the edge cases involved in user migration and the desire for full control over transactional emails. James walks through a Hello World setup for Clerk, covering the dashboard configuration, social login options, JWT integrations with databases like Supabase and Hasura, and API security via a simple require-auth wrapper. The latter portion explores more advanced topics, including B2B OAuth challenges, how Clerk's SDK architecture uses an open-source JavaScript core that framework-specific packages wrap around, and the team's philosophy that "a component is worth 1,000 APIs," pointing toward a future where complex integrations like Stripe subscriptions are reduced to simple hooks and drop-in components.

Chapters

00:00:00 - James Perkins' Layoff Story and the Power of DevRel Connections

The episode kicks off with Anthony welcoming James Perkins and immediately diving into his recent experience of being laid off from Tina CMS during a wave of industry-wide recession-driven downsizing. James explains how he reached out to Clerk's team within hours, leveraging a pre-existing freelance relationship, and had an offer signed in just 12 hours — a remarkably fast turnaround that underscores the professional advantages of DevRel.

Anthony frames this as a case of preparation meeting opportunity, noting that DevRel professionals are uniquely positioned to build wide networks across companies. James agrees, adding that his YouTube channel and Twitch streams compound those connections by introducing him to people he might never have met otherwise. The conversation sets the tone for a broader discussion about career resilience and the value of visible, community-facing work.

00:02:16 - From Java Books to Management: James's Career Origin Story

James recounts his 15-year journey in the industry, starting with learning to code from a dry Java textbook and stumbling into his first engineering role after fixing a memory allocation bug while working in technical support. He describes the old-world software distribution model of shipping CDs via FedEx, giving younger listeners a sense of how much the industry has changed.

He then traces his path through various roles, eventually becoming a manager at Plaid before realizing that management wasn't fulfilling. The traditional career ladder of IC to senior to lead to manager felt like an obligation rather than a calling. When Tina CMS approached him after seeing his YouTube content, he jumped at the chance to do DevRel full time, describing it as an upgrade that aligned with his original aspiration to be a teacher. His story illustrates how content creation can open unexpected doors and how stepping off the conventional career path can lead to greater satisfaction.

00:07:35 - What Is Clerk? Authentication Made Simple

The conversation pivots to Clerk itself, with Anthony and Christopher Burns sharing their initial impressions before James gives an overview. Clerk is positioned as a user identity tool that abstracts away the complexity of authentication through drop-in components for sign-in, sign-up, user profiles, and more. James explains that setting up Clerk can take fewer than ten lines of code, and recent upgrades have dramatically expanded CSS-level customization.

Christopher shares his experience integrating Clerk, noting that he built a fully custom UI because the default components didn't match his brand at the time. He describes authentication as a hidden cost in application development and recounts his migration journey from Auth0 to magic links to Clerk. The discussion touches on edge cases like handling users from previous systems and the desire to control transactional email templates, with James revealing that Clerk now supports webhooks for sending custom emails.

00:14:33 - Hello World with Clerk: A Walkthrough for Beginners

Anthony steers the conversation toward a practical getting-started scenario: building a simple guestbook app with Clerk. James walks through the process step by step, starting with the Clerk dashboard where developers choose their authentication methods — email, username, phone, social logins across 13 providers, and even Web3 options like MetaMask. From there, it's a matter of installing the React package, wrapping the app in a Clerk provider, and using built-in hooks and components.

James explains how JWT templates enable database integrations with services like Supabase, Hasura, Fauna, and Firebase, reducing what would normally be complex API work to a single hook call. He also covers API security through Clerk's require-auth wrapper, which blocks unauthorized requests and gives developers access to session and user data. Anthony adds that Redwood users can skip even these steps with a single CLI command, though Christopher notes the current Redwood integration defaults to a popup modal rather than an embedded page.

00:19:16 - Advanced Auth: B2B OAuth, SDK Architecture, and the Component Philosophy

Christopher raises two deeper technical questions: whether Clerk can serve as an OAuth provider for third-party company integrations, and how the SDK is architecturally constructed. The B2B OAuth discussion explores the complexity of authenticating users across two separate company user bases, moving beyond simple API key exchanges toward seamless login-with-company-A experiences. James notes that Clerk's new organizations feature is designed to address exactly these kinds of B2B SaaS scenarios.

On the SDK architecture front, James explains that all of Clerk's framework-specific packages wrap a single open-source JavaScript SDK, which allows the team to push fixes and updates without requiring developers to install new package versions. Christopher digs into the implications of this approach — versioning a UMD script on a CDN versus explicit NPM releases — and the conversation broadens into Clerk's philosophy that "a component is worth 1,000 APIs." The episode closes with a discussion of how Clerk has componentized complex integrations like Stripe subscriptions and the challenges of building UI into SDKs across multiple frameworks.

Transcript

00:00:00 - Anthony Campolo

Everybody ready to go? Yeah. James Perkins, welcome to the show.

00:00:14 - James Perkins

Thanks for having me. I really appreciate you guys having me on. I know we've kind of had this planned in the previous time, and now we finally managed to get here, and I'm super excited to be on the show. Thank you for having me.

00:00:24 - Anthony Campolo

Yeah, you have such an awesome story. I mean, it's awesome and bad at the same time. You got laid off, not fired, because of Tina CMS. They were downsizing, recession. We're seeing layoffs kind of across the board here. And you being a very professional DevRel person, you had so many connections that you had a job within 12 hours, I believe.

00:00:47 - James Perkins

Yeah, I had worked with Clerk previously on some stuff and some freelance stuff for Colin and a bunch of other stuff. I sent him a message and said, hey, I lost my job and want to know if you guys are looking for DevRel. And then 12 hours later, the piece of paper was signed and we were all set and ready to go. It was certainly not what I expected to happen, and I think I'm probably the luckiest person that's been hit by the recession, because even my wife got hit with the recession, too. So my wife currently doesn't have a job, so it's all a bit wacky in my house at the moment.

00:01:20 - Anthony Campolo

Yeah, well, it's true that you were lucky. There's that saying that luck favors the prepared, I think is what it is. And being a DevRel person really sets you up well because your job is to go out and make connections. So I think that the success you had speaks to both your skill and your ability to make connections and to have kind of opportunities lined up, and also the benefit of having a position that allows you to do that and make that a priority.

00:01:48 - James Perkins

Definitely. It does sort of lean towards making connections at dozens of companies with dozens of people every day. And yeah, I'm really lucky, especially with my own YouTube channel and my own Twitch streams and everything else like that. That just compounds that kind of luck that I get to meet people that I've probably never met before or never spoken to, or just because they happen to find a YouTube video or blog post or whatever I've done in the past. So yeah.

00:02:16 - Anthony Campolo

Why don't we take it back to the beginning? How did you get involved in all of this, or even how you learned to code if you want to share that story?

00:02:22 - James Perkins

I've been in the industry; my 15th year will be next year. So I've been in the industry for a long time. I learned to code from a book, a very dry book on Java, which was the worst, and I had the worst experience ever learning to code. And I got my first job just pure out of luck. I worked for a company, which is where I met my wife, and we worked in technical support for this company, and I fixed a bug randomly. I was like, oh, this is a weird bug. And just to put it in perspective, everybody who's really kind of younger or wasn't in the industry a long time ago, the software that I worked on was sent via CD. So you would FedEx a CD to the company, they would install the CD and then they would be able to use the software. And there was this weird bug where, like, if you try to print something, it would crash the application.

[00:03:10] And it just happened to be that memory allocation was not enough. It was this whole thing. And I fixed it for one person by changing an INF file or something like that at the time, or a config file, and the manager came up to me and was like, how did you fix this? Like the engineering manager. And I was like, oh, I just figured out that this is a memory allocation problem. And he said, you should apply for a job. We do mentor juniors here. You might be interested. And I applied and got rejected and then applied again and then got hired in that space. And that's kind of how my journey began. I was there for a few years, left, did some other stuff, and then I worked for Plaid as a manager, and then I got into DevRel, which was kind of around the time of Covid, really. I was kind of a Covid YouTuber, which is kind of like these Covid learners where people decided to try something new.

[00:04:01] And I decided that maybe I could teach because I originally wanted to be a teacher when I was younger. So I did a bunch of YouTube videos, taught a lot of new topics, a lot around the Jamstack that kind of got me where I was. Tina had seen a video of me doing a video on Tina. They reached out, they needed a DevRel at the time, and that got me that job there. And then Clerk reached out. When I'd used their product, I was like one of the first people to ever talk about Clerk outside of Clerk. And that kind of started that relationship. And then a year later, here we are now. I work for Clerk.

00:04:32 - Anthony Campolo

Yeah, it's another good example of being into a product or an open source project early and being kind of like one of the first evangelists for it will get you noticed by the people who do it, because if no one else is creating content around it and you do, there's an audience of one for them kind of looking at who's creating stuff. And you went from a manager to DevRel. That's interesting. I feel like that's pretty unique. Most people I know who get into DevRel are kind of new to the industry, or they were an engineer for a really long time, but I haven't heard many people who move from management to DevRel. Did that feel like a downgrade at the time, or were you just really sure that that was the role you wanted, so you were willing to take that sideways direction?

00:05:16 - James Perkins

Yeah, it was definitely in the beginning. I was unsure because I'd been doing YouTube and I'd grown a reasonable following, and I really enjoyed making content weekly, and it was fun for me. And then there was this sort of promised land of almost being a full-time YouTuber, but actually having a salary and stuff. And the reason I left management was because I just didn't like being a manager. There's this sort of progression that people talk about, at least in old school. It's less now, but like 10 or 15 years ago it was like you become an IC, you work really hard, you become a senior, you take on a lead role, then you become the manager, and then you manage the team and then you become a director and blah, blah, blah. Like that's the old school mentality. And I followed that throughout my career. I didn't have a degree when I started. And then people told me, oh, you'll never be anything but a junior unless you get a degree.

[00:06:06] So I was like, well, I'll get a degree and did that and absolutely hated going to school full time and working full time. But I did it. And then I never used my degree, which is amazing. And so I had the same mentality, right. It's like at some point you got to be a manager. Like that's what you do. You lead a team, then you become a manager and you kind of lead that team. And sort of like three or four months in, I was like, oh God, I hate this. This is not what I wanted. I have made a mistake, but let's make the best of it. I was very much a hands-on and technical manager, so I spent a lot of time doing a lot more. Hey, you're stuck with this problem. Let's talk through it. Let's decide how we get to point B and then teaching a lot of knowledge along the way.

[00:06:44] So that was nice for me. But by the time Tina had come to me and started talking, I was like, yeah, this is what I want to do. I want to educate people. I want to make content for people. I want to kind of do this all the time. It actually felt like an upgrade. When I finally took the role on, I was like, oh, this is definitely an upgrade for me because I get to do something I enjoy every day versus hating getting up in the morning and being like, cool, I've got to do eight hours of management now. So yeah, it was definitely an upgrade in the end for me.

00:07:10 - Anthony Campolo

I am not someone who sees myself on a management track for that exact reason. As you're saying, I love my job. I could do my job for the rest of my life and be very, very happy. So it's good to hear that someone who did that in reverse was happy with the decision.

00:07:26 - James Perkins

Yeah, it's definitely an odd thing when I tell people that I was a manager and now I'm just another IC who's doing DevRel. But yeah, it was definitely an upgrade to be able to enjoy my job every day.

00:07:35 - Anthony Campolo

Let's get into the Clerk stuff. I have only used Clerk once. There's a Redwood integration with Clerk, and I was doing a demo and wanted to check out some of the different auth providers. So I don't know a ton about it, but I was super impressed having used it just the one time. And I know Chris, I think, kind of scoped it out as well as a potential auth solution. Am I right about that?

00:07:58 - Christopher Burns

It is a fun solution.

00:08:00 - Anthony Campolo

Oh, you're using it right now today?

00:08:02 - Christopher Burns

Yeah. It's been in production for like a month or so now.

00:08:06 - Anthony Campolo

Okay. So it's fairly new. Yeah. I remember talking to you about it back when you were scoping it out. Great. So you can speak to it even more than me. So let's start with letting James give us the one-on-one, and then we can kind of get into Chris's experience with it.

00:08:19 - James Perkins

Yeah. So Clerk is an auth provider, as you mentioned. It's touted as like a user identity tool. The idea here is that authentication doesn't have to be complex. It doesn't have to be difficult. If you've been around or you've tried to roll your own auth, it's an absolute disaster and it's painful. How do you secure these and how do you do all these exchanges, and how do you secure something like a cookie or something like that? All of that is taken away. It's abstracted away for you. So essentially what you get is a few drop-in components that you drop in on the page, one for sign in, one for sign up, a user button, and then a user profile. And then basically your authentication provider is done. You can set up Clerk with, I want to say, less than ten lines of code. And then with those ten lines of code, you can get even more powerful by doing authorization or database integrations using JWT. And we give you these cool built-in components that we just upgraded.

[00:09:17] It's crazy, you can make clones of other websites. You can make it exactly what your brand wants to be. Before, it was pretty locked down. If our small amount of customization didn't fit, you basically had to build your own with our API. But now we're down to the level of, yeah, if you don't want this button to look a certain way, just add some CSS and we'll make it look the way that you want. And that's basically the spiel. Authentication is supposed to be easy, as easy as adding CSS to your page. We want to make it as easy as possible using built-in components. We want the front-end devs to be able to do this and not rely on back-end devs, or worry about where do I store all this information.

00:09:56 - Christopher Burns

Yeah, I guess this is now my time to talk. I integrated Clerk before this update. I wasn't happy with the default UI of the client, so I built my own user interface.

00:10:08 - James Perkins

Which is very nice, by the way. It's very, very nice. It looks great.

00:10:12 - Christopher Burns

Yeah, I added in some Lottie animations and a few other things. And my opinion on Clerk is that authentication is this really big hidden cost when it comes to building applications.

00:10:28 - Anthony Campolo

Can we get some context on what you've done previously to Clerk in terms of your previous auth solutions? I think that would be useful for the listener.

00:10:37 - Christopher Burns

My previous auth solutions. So Everfund users have been migrated swiftly from Auth0 to magic links, and then magic links to Clerk. And hopefully this will be the last time. I'm pretty positive it will be the last time for sure. And what I figured out along that journey is that authentication is really hard, but it doesn't end where the user is logged in. It goes a lot deeper, through permissions, to organization management, to even things like billing. And how do you restrict users depending on billing? There's a lot of, you could say, boilerplate code there that is very similar on almost 90% of projects. And I know this is all in Clerk's roadmap, so I should probably let you explain it more.

00:11:25 - James Perkins

I mean, you can continue on first. Let's first start with how was the authentication experience for you going from Auth0 magic links to Clerk? I know that you had a pretty reasonably good experience, but how did that actually feel going from there? And then we could talk about future things.

00:11:41 - Christopher Burns

Yeah, well, I am very unbiased, even though I'm probably biased to Clerk now. I still found it pretty annoying and pretty, what's the word? Not necessarily annoying, but it's very edge-casey still because obviously I've done migrations, so you have to say, oh, has this user logged in to the previous system? Yes. Then now you need to create their account under Clerk because you don't want a previous user to have to sign up. You just want them to log back in, like, hey, everything's just moved forward. So there were a lot of these edge cases that I needed to build in. But most of that also was I wanted social logins and I've never quite achieved that with the previous providers. So now Everfund has social logins and magic links provided by Clerk. The only thing that I really have left on my list of things that I really want to knock out is actually removing the Clerk authentication email and listening to a webhook and just providing an email myself.

[00:12:39] Why? Because I'm very pedantic and every single other email from Everfund comes out in this really nice template that I built, except for the login email. The login email is in Clerk, and it's a nice email, but I just want all my emails to come from the exact same template, line for line. They all just look identical, not like, just chuck it in there and see what happens.

00:13:02 - James Perkins

Which is fair. That is a thing that we've had requested a few times, which is like, hey, I'd love to just have a webhook that I can send my own email from or something like that, even though our emails are pretty, like you said, pretty nice. You want to be able to do something with this email, with your template and the styles and all that kind of stuff. Right now it's very much just, you know, like we give you a very basic email editing that you can edit through. I think we'll talk offline, Chris, about what we could do to make that happen today, but we can talk about that after the fact for sure.

00:13:35 - Christopher Burns

But the biggest thing, I think it's like the biggest side tangent, is emails are really hard. Actually coding a really good email template is really, really hard, especially if you've got to involve customization. Obviously we do it, Everfund does it, you do it at Clerk, and there's no standard path. We used a tool called Maizzle that lets you use Tailwind and then it compiles it down to just standard CSS for templates. And then we've spread it out across all of our providers, so obviously to Crisp for our support, to Postmark for our transactional emails. I know you can edit the email in Clerk, but I don't know how much you can edit it. It's not something I've looked at. It's something I've gone, I want to do that, but I've got 20 other things to do first.

00:14:19 - James Perkins

All I'll say on that matter is there is an option now that you can actually switch off the emails being delivered by Clerk, and you can listen for the webhook for emails and then send your own. There you go. So I think we can get what you want done today.

00:14:33 - Anthony Campolo

Luckily, when we take it back, for listeners who are kind of totally new to all of this stuff, what's going to be like a Hello World experience for Clerk? So say I have a React app or a Next.js app, and I want to create a guestbook that will let someone log in, maybe with a social provider, maybe with their email, and just write a message and then that will be saved to the website. How would I go about doing that with Clerk?

00:15:01 - James Perkins

Yeah. So with Clerk, the way that we do this is a lot of it's done in sort of the Clerk dashboard. This is where you can think of how you can set that component to look, feel, what kind of social provider you'd want. So let's say today you wanted to start a new application. And let's say it's this guestbook, right? We have this option where you click Add Application and you tell Clerk what you want to use. Do you want to use email addresses? Do you want to use usernames? Do you want to use a phone number? Do you want passwords or passwordless solutions? Tell us what kind of authentication providers you want to use. So social logins, we offer 13 standard social logins, things like Apple, Dropbox, Discord, Google, blah, blah, blah.

00:15:43 - Anthony Campolo

It's very impressive. It's a very impressive number.

00:15:46 - James Perkins

Yep. And then on the flip side of that, we do offer Web3. So MetaMask is part of that right now, and others are coming down the line. Then once you name it, whatever you want it to be, you click finish. And that's essentially now you're ready to go. At that point you've got your React app. You install the Clerk React package, you wrap your application in Clerk provider, which is essentially a way for us to tap into everything. And then at that point you decide, do I have public pages? Do I not have public pages? And you can use things like IsSignedIn, which is a component that essentially says, are they signed in, yes or no? If no, you can redirect them to the sign-in page. Or if they are signed in, you can see the application, then you've got options. At that point you can use our JWT templates to essentially hook into your database of choice. We've got things like Supabase, we've got Hasura, we've got Fauna, we've got Firebase, and we've got Nhost coming down the line.

[00:16:44] So you have these options of databases that you can automatically hook into using our JWT, which is just a hook that says get token, get token, and then whatever name, Hasura, Supabase, whatever, and we'll essentially do all of that for you. And then you can just insert whatever you want into your database. You can do things like checking for roles. Essentially all of the hard work is down to a few hooks and then a few components versus having to write a bunch of APIs and blah, blah, blah. And then we offer things like securing your APIs. Right? So let's say for your API, they must be logged in to make an insert into your guestbook. You can't just insert and not be logged in. We have this API wrapper that's called require auth. If they're not logged in, they'll just get an unauthorized request. If they are logged in, you have access to all of the clerk session and user information. So you can do things like request dot user dot email address. And that will be their email addresses or first name, last name, whatever it might be.

[00:17:47] You have access to that information that you can then use to insert into a database. So if we were making a guestbook, you'd need the Clerk provider, the sign-in components, which can be hosted or can be self-mounted. It's up to you. We host a version automatically out of the box. You need some sort of database of choice. You can use one of our JWT integrations, or you could use whatever. You can make your own JWT if you really wanted to. Then you just need to hook those together and then secure API using Clerk, and then you're off to the races. So probably you could do a whole guestbook in a few lines of code in the front end and a few lines of code in the back end, or an API for Next.js or something like that. So we try and make it as easy as possible for anybody to get started and secure their apps.

00:18:31 - Anthony Campolo

Yeah, that's pretty awesome. And I will say if you're using Redwood, you will write zero lines of code because you will run a command yarn redwood setup auth clerk and then it will write those lines of code for you.

00:18:43 - James Perkins

Exactly.

00:18:43 - Christopher Burns

It really depends though, because the Redwood plugin of Clerk has one critical flaw, and that is that it uses the Clerk pop-up as the default method. And if you don't want a pop-up modal, you just want to display it on a page, you got to go down the custom route. But I'm pretty sure that's going to be fixed pretty soon.

00:19:04 - James Perkins

Yeah, I think that's part of our roadmap for that stuff.

00:19:07 - Anthony Campolo

Yeah. But for a Hello World experience that's fine. Anyway, so that's not really an issue. It's only an issue for someone who's already running a company that needs branding.

00:19:16 - Christopher Burns

Yeah, of course, of course. There's two other things I want to really jump deep into. One of them's auth on a secondary layer. Like, could I provide auth to my clients through Clerk and authenticate a URL for another app? You know what I mean? So many apps do it these days, like handshakes to give data to a third party company. The second one is how the Clerk SDK is actually built, because this is a massive problem and a really interesting subject for sure. How do you get around CORS? How do you make sure the clients are authenticated? Do you inject the React components into the code? Do you load iframes? There are so many problems and navigation and security in this area that I think it would make a really good conversation.

00:20:02 - James Perkins

Yeah, we can talk about some of that. I probably don't have the answer off the top of my head for the first question.

00:20:10 - Christopher Burns

And that's fine, because it's a pretty complicated matter.

00:20:13 - James Perkins

Yeah, it's a pretty complicated question. And for the listener at home, basically the question is, can we do that?

00:20:20 - Christopher Burns

Be an authentication provider for a third party company.

00:20:24 - James Perkins

Yeah, right. Which makes it a bit more complex. And I think with organizations, that kind of stuff is kind of where we're leaning towards with our new organization stuff, being able to be like, okay, yeah, I have this organization A that wants to provide some sort of B2B, SaaS style software, and they need to also authenticate their users with Google auth to then pass down, maybe, I don't know, calendars or drives or whatever. That's kind of our idea with organizations.

00:20:52 - Christopher Burns

It's a really hard subject. For example, you've closed a deal with another company. Oh, I'm going to give data from Everfund into your company. Great. And then you go, okay, so now you've got two user bases, but we need to give that data from company A to company B, but how does company B authenticate that they're logged in through company A without the old style? The very classic style. The old style would be, oh, just pass an API key around, just generate an API key and stick it in their dashboard. And it would work. And very much that is true. That will always work, but a much better experience is just saying click this button to log in with company A, they click that button. There you go. You're logged in with company A, and then the connection is now complete. This is one of these things that I see constantly in big companies and think like, how do they achieve that so easily, and they don't achieve it easily.

[00:21:43] It's a lot of work to maintain our authentication OAuth style connection.

00:21:48 - James Perkins

Yeah, it is indeed. And that's the kind of thing that we're thinking about: how we solve for those sort of B2B SaaS or organizations that want to provide that kind of stuff. That's the kind of stuff we're leaning into more now than probably six or eight months ago or a year ago, where our core functionality was like, hey, how do we get B2C done? Or how do we get simple B2B done? Maybe still B2B, but like B2B with no required backchannels to each other, which I think is the kind of stuff we're looking to solve today.

00:22:20 - Christopher Burns

I was gonna say the second question. I guess I was always going to move on to it.

00:22:24 - James Perkins

Yeah. So talking about the second question where people want to know how we kind of handle this, like how do we go from Clerk to this, let's say Next.js package, and then we mount components, and how does that all work? And what are we doing behind the scenes? It's a complicated question. It involves a lot of work on our front. So with Clerk, we essentially have this sort of back-end core. And that's where all of our platform-specific SDKs kind of feed into. So we have this core functionality that's implemented. We use this backend core. And then we have things like framework middleware or platform or state handling, custom logic, all that kind of stuff that we may need to make an SDK work. But essentially what we're doing a lot of the time, if you've ever seen Clerk and we're like, oh yeah, we've made an update, and if you've come to our Discord and said, hey, I found this weird bug and I don't understand what's happening.

[00:23:17] And then we're like, hey, we've made an update and there's nothing for you to do. There's no magic for you to do. Don't install the newest package. The reason is because all of our SDKs essentially use the official JavaScript SDK behind the scenes. Essentially, we're just wrapping up this JavaScript SDK, which gives us the ability to offer all of the things that we want to do and how they all kind of work. What's cool about this is the JavaScript SDK is open source and open to the public. So you can go in there and start digging around into that and see what are we doing. In fact, basically half of our packages are open sourced in some way so that you can go and look and see how we're doing all these special things. To talk about the technical aspects of that is above my pay grade, I suppose is the right word to say, because I got to see it from the other side as a consumer for a long time.

[00:24:10] And I was like, oh, this is just cool. Like report a bug and then it's fixed and then magically it all works. And I didn't have to do anything. There was a lot of that during my time. But yeah, we basically have this JavaScript SDK that shows you kind of what we're doing and how we're doing it. And you can go and look at our back-end core, how that kind of works, how the back-end code works. So basically at this point it's mostly open source software that you can go and sort of poke around in.

00:24:37 - Christopher Burns

That's actually really interesting. So to my understanding of that is basically each library is a wrapper around a script, a JavaScript script, I guess it's in the UMD format hosted on a CDN. So you can easily version that behind the scenes without having to push forward the NPM version. This is something that I've obviously dug deep into myself and know that it gets very messy, very fast. Like, do you version control the UMD version on a server, or do you just be like, whatever Script.js is, is the latest version?

00:25:08 - Anthony Campolo

And we actually did a whole episode on this that will air before this one.

00:25:12 - Christopher Burns

Yeah, obviously it's such a big problem, but it's not really a problem. It's just like, do whatever you want because that's how the world works. Colin, your CEO put out a tweet saying, should we make something official? I am telling you, you should make the Next.js of like plugins.

00:25:30 - James Perkins

Yes. Oh yeah.

00:25:32 - Christopher Burns

Because it would be so, so useful every time that I've looked into and built JavaScript SDKs. It's such black magic and even I struggle to explain it, and I've built one.

00:25:44 - James Perkins

Yeah, I wholeheartedly agree. So the tweet that you were quoting was, should we make a Next.js-like Components for Components? So what Next.js is doing, but for components, because that's kind of what we've done. We've componentized a lot of APIs down to a level of like, hey, you just drop this component in and here's a hook and here's a component and it just works. And don't worry about what's happening behind the scenes. We're doing all the API stuff for you. Just wrap your application in it and do that. And we did that with Stripe. We have a use Stripe subscription that does the same thing. We built one, because who wants to spend four hours trying to figure out how Stripe's API works, when instead you can just install use Stripe subscription and then go from there? We believe that a component is worth 1,000 APIs. It's the saying that we have behind the scenes that you may see Colin tweet occasionally, but yeah, that's what we believe. We believe that components can simplify a lot of these annoying APIs that we've had to deal with for the last decade or so.

00:26:45 - Christopher Burns

Yeah, what I find really interesting is that it renders the UI to any framework, so Svelte, Vue, React even. What's that actual UI layer built in? Is it React that you then compile down or is it built in vanilla JS?

00:27:01 - James Perkins

I want to say that it was React, but don't quote me on that. Colin, if you're listening, don't quote me on that. Please don't.

00:27:12 - Christopher Burns

Because that is really also a hard part of building an SDK, is actually building in the UI to it. A headless SDK is so much easier because it's all just functions, but when you actually have to build in a UI to it, it gets complicated so fast with, for example, React. Do you make a hook that they call a function and it will just pop up, open something? Or do you put a JSX block in because some people would say you could do either? It's really the Wild West of this area. And I should probably get Colin on this podcast to speak about that.

00:27:43 - James Perkins

Oh, yeah. He'd love to nerd out about what goes on behind the scenes. In our Next.js package and in all those kinds of packages, we're very much just a bunch of TypeScript files and TSX files to build out those packages. But, yeah, he would love to get down into the nitty-gritty of how that all happens and what we do behind the scenes and all those kinds of things in the SDK.

00:28:07 - James Perkins

And I imagine if I send him a message, he'd be like, hell, yeah. I want to come on the podcast. Yeah. Let me on there. I love to talk about this stuff.

00:28:14 - James Perkins

So, yeah, he gets really excited. We actually just did a technical talk as part of our launch week for Components v4 that talked about how we actually built all of our new components too. So, yeah, that's something to listen to. We actually have Colin and the developer who built out all of those components and the new layers that we're using.

00:28:31 - Christopher Burns

Yeah, it's really interesting because when I'm looking at this source code now, I believe it's React, but you're using really interesting things like React.cloneElement and a lot of normalization and all that. It's super interesting what you're doing over there at Clerk in regards to not only the authentication, but also the building of these components. And I guess the biggest thing that we've not covered is why do we have to do it this way? To put it simply, CORS is a massive limiter in authentication.

00:29:01 - Christopher Burns

And what you tend to find is, say, you could build something two ways. One would be an iframe. So you just put an iframe over whatever you need to and communicate inside the iframe, but that also has limitations about sharing data between the parent DOM and the child iframe. So you got to navigate that. So you go, okay.

00:29:19 - Christopher Burns

I want to take the other method and inject actual HTML and CSS onto the page. And then you go, okay, that's when you need your view layer. You know, are you going to use something like a cut-down version of React, like Preact, or are you just going to build it completely in vanilla JS? These are things, obviously, that are very technical, probably for another day.

00:29:37 - Christopher Burns

Definitely for another day. Yeah. What is the next, would you say, big milestone at Clerk, and what are you really aiming for? You quickly mentioned Organizations, but what does that truly mean?

00:29:50 - James Perkins

Yeah. So Organizations, if you're listening and you've never played with Clerk before, we introduced Organizations as this option to allow you to create businesses inside of Clerk. So if you want to do B2B SaaS, like business-to-business SaaS, this is what Organizations is built for. Essentially, what it allows you to do is create organizations, and members can belong to one or many organizations. They can have roles within those organizations, and then you can do certain things with those organizations.

00:30:19 - James Perkins

For example, if you use Stripe, you could have payments and things like that on top of that layer, and it essentially allows you to do that kind of thing. So we have a few things that are coming up. Organizations is a big one. What we have now is an okay offering, and we're starting to see people use it and ask questions like, is there going to be an organization admin component that I can drop in on the screen and start administrating organizations and being able to do it that way? So that's next on the list.

00:30:50 - James Perkins

And then truly, it's just getting more people to use Clerk and try Clerk and enjoy Clerk, which is where I come in. A lot of people have either never heard of Clerk before, which is one of those things that, like, building in a space with dominance like Auth0, who aren't exactly the world's best authentication provider, but because they've been around for so long and they're spread so wide and they have a lot of backing, that's automatically something that someone goes to because they're like, I've heard of them before, and I see ads for them and all that kind of stuff. We just want people to try Clerk, I think, is where we're getting at the moment. And then we're going to be building up more B2B features that allow you to do that at scale and improve our Organizations. And then we got some more smaller stuff coming in, like new integrations with new partners like Nhost, for example.

00:31:38 - James Perkins

We just did another integration, which I completely forgot about, and I'm really sorry, with Graphbase, which is another one of the Netlify Jamstack Innovation Fund people. I want to say they are, but maybe they're not. Chris, you might be able to...

00:31:54 - Christopher Burns

Graphbase. No. Graphbase is Frederick Braun's startup. Yes. That's right.

00:32:01 - Christopher Burns

Sorry. Yeah. No. No. He's not in Innovation Fund.

00:32:05 - James Perkins

I get confused. There's so many people in the Innovation Fund that I'm working with behind the scenes. But, yeah, we just added them to our list, and I'm going to be working with a few of the Jamstack Innovation Fund people to do some integrations and lower-level stuff. So, yeah, that's kind of what we're working on right now, and we'll have more stuff coming up, I'm sure. You'll see a lot more of me appearing in random places like livestreams and podcasts and all that kind of fun stuff.

00:32:30 - Anthony Campolo

Yeah. Do you have your own livestream, or do you stream from Clerk's Twitch account? Like, I'd livestream myself quite a bit, so I'm curious about the minutiae of livestreaming.

00:32:40 - James Perkins

Yeah. Both. So I do livestream on Clerk. We at least livestream once a week for office hours for Clerk, which is essentially... We call it office hours, but it's not really office hours. It's more of like an hour with somebody.

00:32:53 - James Perkins

It will either be Colin, where you can ask direct questions or hang out or learn about some new thing. And then I livestream on my own Twitch channel where I do a lot of SaaS building. Right now I'm on my third SaaS, all like micro-SaaS projects. So that usually involves Clerk, even though before I didn't work at Clerk, but they always get my free advertisement everywhere. So, yeah, I do a lot of livestreams over there on my own Twitch channel about two or three times a week for a couple hours, usually at like 3 PM Eastern onwards.

00:33:23 - James Perkins

And usually, I build some sort of micro-SaaS, and I end up taking advice from my viewers. And we run polls. And we decide on tech stacks that way. So it makes it a bit more adventurous because usually I end up with stuff I've never used before. And then I start down the learning trail while trying to build something that actually functions, which is always fun.

00:33:42 - Anthony Campolo

Yeah, it's awesome and super fun streaming. I'm in a similar boat where I stream from my company stream. Are there other places on the internet that you want to direct people to learn more about Clerk or about yourself?

00:33:54 - James Perkins

Yeah. They can jump into clerk.dev. That's our homepage. You can learn a lot about what we do and how you can integrate yourself and what we're aiming to do with the industry. You can follow us on Twitter as well.

00:34:07 - James Perkins

It's @clerkdev. And then for me, you can find me on YouTube. Learn to Code with James is the URL. Or Twitch, which is twitch.tv/jamesperkins.

00:34:21 - James Perkins

Those are probably the biggest places you'll find me. I put out at least one video a week, sometimes three videos a week. Just depends on how the world spins. But, yeah, mostly come find us at clerk.dev, and then join the Discord where you can chat with pretty much everybody who's using Clerk and all of us on the team as well. We're there every day.

00:34:42 - Anthony Campolo

Anything else from you, Chris?

00:34:43 - Christopher Burns

As the developer advocate, when are you going to push out officially the new logo? That's half out, half not.

00:34:51 - James Perkins

Oh, man. Yeah. So there's a discussion right now. I can tell you secrets on the inside because Chris already knows about the new logo and everything else. We are building out the new sort of marketing pages and everything like that.

00:35:06 - James Perkins

Once we've finished all of that, we're going to push everything out all at once. Yeah. It's kind of weird because we have, like, the new logo on the Twitch side of things and nowhere else.

00:35:15 - Christopher Burns

No. No. You have it on the components as well.

00:35:17 - James Perkins

Oh, yeah. That's right. We have it on the component. Yeah. Yeah.

00:35:20 - James Perkins

Yeah. But that's it. Nowhere else. And it's funny. We've got this half-changed marketing.

00:35:25 - James Perkins

But, yes, it should be pretty soon. We're building out the homepage right now with the new marketing.

00:35:30 - Anthony Campolo

So I was just saying, by the time the listeners hear this, it'll almost certainly be the new one.

00:35:33 - James Perkins

Fingers crossed. I'm not guaranteeing anything. But, yeah, in theory, it should all be done by then, and I'm super excited. So I didn't know about the new logos until I started at Clerk. And then I was like, hey.

00:35:44 - James Perkins

What's this logo? Like, I keep seeing it, and then they sent me the new marketing pages in Figma. And I was like, oh God. We need to get this out ASAP. This is awesome.

00:35:54 - James Perkins

So, yeah, working on that right now.

00:35:56 - Christopher Burns

Building marketing websites is a fine art, in my opinion.

00:36:01 - James Perkins

Yes, and that's why I don't do any design or any marketing building, because they're probably the hardest part of the whole product. Get it wrong and no one will stick around. That's for sure.

00:36:10 - Christopher Burns

Exactly. Well, thank you so much for joining us today, and I'm sure this won't be the end of our relationship with Clerk. Most definitely not.

00:36:50 - James Perkins

Thanks for having me on. I really appreciate it.

00:36:52 - Anthony Campolo

Sweet. Awesome. Awesome. And cut.