DEV Community: Jacob Evans

Mentorship To Me

Jacob Evans — Thu, 17 Apr 2025 22:41:12 +0000

I want to start off by saying, I think traditional mentorship has its place and usefulness, but full disclosure, I have a negative bias.
Here's the thing, mentorship doesn't have to be this formal arrangement where someone wise bestows knowledge upon you from on high. That model? It's broken for most people.
My most valuable "mentors" weren't people who signed up for the job. They were folks in communities like Cloudflare Workers Discord, T3, Theo's, Kent C Dodd's, and React circles who just... showed up consistently. Those who shared their knowledge openly without gatekeeping and those who called me on my BS when I needed it.
The best mentorship experiences I've had came from casual convos in Discord at 2 AM, debugging weird TypeScript errors, or pair programming on random OSS issues during Hacktoberfest. It was getting detailed PR reviews that made me a better dev, not just scheduled coffee chats.
When I was transitioning from military to tech, what helped wasn't finding ONE perfect guide; it was tapping into MANY sources of wisdom and building a network of peers who were just slightly ahead of where I was.
That's why I'm such a big advocate for jumping into open source. Want mentorship? Start contributing to projects you use. The feedback you'll get on PRs is pure gold. The maintainers aren't your "mentors" officially, but damn if they won't level up your skills faster than any formal program.
This isn't to say structured mentorship programs are worthless. They work great for some people! But if you're struggling to find "a mentor," stop looking for that ONE person and start embedding yourself in communities where knowledge flows freely.
Being part of Cloudflare, T3 ecosystem, Theo's, Kent C Dodd's, and the various dev communities I'm in has taught me that the best mentorship is often ambient, it's absorbing knowledge from many sources rather than one guru.
So yeah, traditional mentorship has its place, but don't sleep on the power of community-based learning and peer networks. Sometimes the best guidance comes from the people right next to you in the trenches.
What's been your experience? Hit me up, always curious to hear different perspectives on this!

Mathematical Magic with JS Sets: Demystifying

Jacob Evans — Sat, 08 Feb 2025 00:01:54 +0000

If you’re as enamored with the elegance of mathematics as you are with clean, efficient code, you’re in for a treat. Today, we’re taking a deep-ish dive into JavaScript’s Set not just as a tool for eliminating duplicates, but as a useful tool for implementing classical mathematical set theory.

Why Sets?

In mathematics, a set is a collection of distinct elements. This concept translates almost perfectly to JavaScript’s Set object. Instead of wrangling arrays and manually filtering duplicates, a Set gives you uniqueness by default. This property makes it an ideal data structure for modeling everything from simple collections to more complex mathematical operations.

Set Theory in Code

Let’s explore some canonical set operations union, intersection, difference, and symmetric difference, and see how we can bring mathematical theory to life with JavaScript.

Union

The union of two sets (A) and (B) is the set of elements that are in (A), in (B), or in both. With JavaScript sets, merging these collections is as simple as:

function union(setA, setB) {
  return new Set([...setA, ...setB]);
}

// Example
const setA = new Set([1, 2, 3]);
const setB = new Set([3, 4, 5]);
console.log(union(setA, setB)); // Set { 1, 2, 3, 4, 5 }

Spread both sets into an array, and let the Set constructor do its magic.

Intersection

The intersection of sets (A) and (B) consists of elements common to both. Implementing this operation can be done by filtering one set’s values against the other:

function intersection(setA, setB) {
  return new Set([...setA].filter(item => setB.has(item)));
}

console.log(intersection(setA, setB)); // Set { 3 }

This approach captures the essence of finding common ground between two collections.

Difference

The difference (A - B) yields the elements present in (A) but not in (B). This operation is particularly handy when you want to subtract one set from another:

function difference(setA, setB) {
  return new Set([...setA].filter(item => !setB.has(item)));
}

console.log(difference(setA, setB)); // Set { 1, 2 }

Symmetric Difference

The symmetric difference is the set of elements that are in either (A) or (B) but not in both. Essentially, it’s the union of the sets minus their intersection:

function symmetricDifference(setA, setB) {
  const unionSet = union(setA, setB);
  const intersectionSet = intersection(setA, setB);
  return new Set([...unionSet].filter(item => !intersectionSet.has(item)));
}

console.log(symmetricDifference(setA, setB)); // Set { 1, 2, 4, 5 }

Beyond Basic Operations

While the union, intersection, difference, and symmetric difference form the backbone of set theory, the potential of JavaScript’s Set doesn’t stop there. You can leverage sets in graph algorithms, implement membership checks for large datasets, or even model more abstract mathematical structures. For instance, if you're tackling a problem like detecting cycles in a graph, using a set to track visited nodes can simplify your logic and improve performance; which can be a huge win!

Performance Insights

Remember, operations like add, delete, and has on a Set are typically O(1), making them extremely efficient. However, operations that involve iterating over the set—such as our union or intersection functions scale linearly with the number of elements (sad but can't be avoided). In most cases, this trade-off is more than acceptable given the clarity and conciseness you gain (until Quantum computers take over and O complexity now longer matters lol).

Wrap up...

JavaScript’s Set object isn’t just a data structure; it’s a bridge between abstract mathematical concepts and real-world programming challenges. By leveraging sets to perform operations that are fundamental to mathematics, we can write code that is not only efficient but also elegant and expressive.

I hope this exploration inspires you to think of sets as more than just a tool for managing collections. Next time you face a problem involving unique elements or need to implement a classic set operation, remember! Sometimes, the simplest solution is the most mathematically beautiful.

Happy coding!

Follow me on Twitter or check out my GitHub for more deep dives and practical insights

Clerk in 2023: A Year in Review

Jacob Evans — Thu, 04 Jan 2024 22:48:48 +0000

This was a exciting year for Clerk, packed with new features and a growing community around Clerk’s user authentication platform. Let's rewind and celebrate some of the milestones that marked our journey!

January

Enhanced DX & Security

As part of Clerk’s mission to revolutionize DX, the focus was on removing roadblocks and streamlining workflows. To enhance security, Clerk implemented several key improvements, including eliminating third-party cookies, which can be used for malicious acts such as cross site scripting. Additionally, Clerk improved API key management for stronger access control; all of this means developers can build more secure applications with ease, using Clerk.

Upgraded Dashboard & Documentation

Clerk made it easier for developers to find answers and manage their Clerk integrations with a more intuitive interface and comprehensive documentation.

Gatsby SDK & Community RedwoodJS SDK

Expanded Clerk's compatibility with popular web development frameworks, making it even easier for developers to integrate user authentication into their projects. The major thing to highlight here is Clerk’s growing community and passion for enabling Clerk to work with the tools they love! Learn more in this changelog post.

Popular Start Template `t3-turbo-and-clerk` Powered by Clerk

This open-source template showcases the power of Clerk for building web and mobile apps with robust authentication.

February

Improved Next.js Middleware Integration

Clerk’s new Middleware allowed for seamless integration with the popular Next.js framework, allowing developers to easily add user authentication to their Next.js applications.

Fastify & RedwoodJS v4 Integrations

Further broadened Clerk's reach by offering official integrations with Fastify and RedwoodJS frameworks, empowering developers to choose the tools they love.

Documentation Overhaul

Revamped Clerk's documentation with better organization, search functionality, performance, and authoring experience, making it easier for developers of all levels to learn and use Clerk.

March

$15M Series A Led by Madrona & Acquired Clerk.com Domain!

This significant investment and domain move solidified Clerk's position as a leading authentication provider and fueled Clerk’s continued growth. Read more about our Series A in this announcement post.

SDK Performance Boost through Lazy Loading

Optimized performance by ensuring Clerk's pre-built components only load when needed, preventing initial render time delays and ensuring a smooth user experience.

Dedicated Chrome Extensions SDK

Opened up possibilities for secure user authentication in the booming Chrome extension market. Check out the starter repo on GitHub.

T3 Stack Tutorial by Theo Browne Showcases Clerk, Vercel & PlanetScale

The T3 Stack Tutorial highlighted the seamless integration of Clerk with other popular tools like Vercel and PlanetScale, demonstrating how developers can build powerful and scalable applications with a unified tech stack.

April

Clerk Becomes an Identity Provider

Clerk IdP enables large enterprise companies juggling Authentication between all their vendors to create a nexus through Clerk for Single Sign-On functionality.

Improved Phone & Email Input, Customizable Hosted Pages through Dashboard

Enhanced the user experience with more intuitive input fields and the ability to personalize the look and feel of login and signup pages, boosting brand consistency.

Full Expo 48 Support

Made Clerk a perfect fit for mobile developers using Expo, a popular framework for building cross-platform apps, and streamlined the creation of custom login flows within Expo apps. Learn more in this changelog entry.

May

Next.js 13.4 & App Router Support

Clerk swiftly followed the release of Next.js 13.4 and App Router stable by offering full support on May 5th. This made Clerk one of the first development tools and the first authentication provider to fully leverage the power of Next.js, React Server Components, and Edge middleware.

Enhanced Password Security & UX

May saw a significant upgrade to password functionalities in Clerk applications. Setting and resetting passwords became smooth and user-friendly, while breach detection and complexity tests ensured stronger security.

Developers gained complete control over password security through the Dashboard, allowing them to tailor password policies and requirements to their specific needs.

Stepping into the Public Spotlight

Clerk's presence in the community exploded in May. We transitioned from sporadic YouTube mentions to sponsoring and presenting at major conferences.

CEO Colin Sidoti's keynote at Reactathon, advocating for the power of well-designed components, and VP of Engineering Sokratis Vidros's talk at CityJS on building for JavaScript edge runtimes, solidified Clerk's position as a thought leader in the industry.

"How We Roll" Launch

May also marked the launch of the "How We Roll" blog series, offering a behind-the-scenes look at Clerk's technology and how it delivers a seamless user experience.

UX Tweaks & Optimization

Recognizing the power of well-crafted UI components, Clerk focused on subtle but impactful UX improvements. Highly customizable user avatars with hover effects and subsequent image size optimizations are prime examples of this dedication to user experience.

June

SAML

In June, SAML support was released to public beta, allowing companies to leverage Clerk to seamlessly integrate their internal tools and frontends with their SAML services. Just a few projects leveraging Clerk’s SAML offering include, Airflip a modern tool for procurement teams, Lawhive a powerful platform for finding litigators in the U.K., and Casa a LLM specialized in usage in Spanish.

Bot Detection

Clerk’s ownership of the authentication flows allows enhanced bot detection. Clerk’s hosted pages were retrofitted with layers of bot detection capabilities in June. Clerk also enabled self-service user delete, an important user privacy feature that every app collecting user data should implement.

July

Bot Detection in the JavaScript SDK

Clerk’s bot detection capabilities were quickly brought to the JavaScript SDK, including the pre-built components and hooks, ensuring that you can be much more confident about your users not being bots. This capability is a must-have for applications providing free trial or usage credits, user generated content, or social interactions, and comes with Clerk out-of-the-box with no additional configuration required.

API Improvements for Sorting Users & Organizations

The ownership of user management also comes with a responsibility - user data being stored with Clerk should not become a bottleneck when developing applications, and developers should be able to query the data however they want. July saw improvements to the APIs for querying users and organizations with advanced filtering and sorting capabilities, and better customization of the session token with custom user data.

August

Detection for Disposable Emails & Subaddressing

The defenses put in place to fight the bots got even better in August, when Clerk added detection for disposable emails and subaddressing. These capabilities make Clerk especially useful to AI products for which bots can be very costly.

Reverse Proxy Support

Another key infrastructure upgrade quickly followed - support for proxying the requests to Clerk’s Frontend API through a reverse proxy server!

The reverse proxy support unlocked an entire realm of capabilities, since your application can now be deployed on any domain (preview, staging, tenant subdomains etc) and have full access to authentication, as well as synchronization of signed in sessions.

“How We Roll” Conclusion

The blog series “How We Roll” closed out with its 10th chapter, rounding up prior chapters and summarizing how Clerk maximizes developer experience, application security, and user experience. The community made some amazing contributions to Clerk’s integrations ecosystem through a Vue, Elysia, and Rust integration, fully open source like all of Clerk’s integrations.

September

Account Portal

September saw the release of Clerk’s Account Portal, which replaced hosted pages as the fastest way to authenticate any application, by eliminating the need for the developer to build any authentication related UI at all. The Account Portal was a fresh redesign of the entire user experience, along with better control over the look and feel.

Custom Domain Registration

Clerk’s B2B offerings continue to get crucial upgrades, like custom domain registration for organizations, allowing users to automatically join organization based on their work email instead of requiring an invite from the admins.

Form Pre-Fill Ability

The pre-built components for sign in and sign up also received the ability to pre-fill the form, making them a lot more flexible and elevating the user experience.

October

Changelog & Roadmap

This is getting to be a lot to keep track of, right? We agree, and in October we addressed this through the new changelog and roadmap.

The new changelog page on clerk.com provides a one stop hub for all the important releases and announcements, while the roadmap provides a lot of insight into the ongoing efforts of our product teams and provide any feedback for a new feature or improvements.

Custom Pages

We also want to make sure as developers scale their products and require user management capabilities that Clerk doesn’t provide, they don’t have to opt out of the pre built components and build completely new UI. Custom pages in user and organization profile take their extensibility to the next level.

November

Pricing Overhaul

We want the experience of Clerk to be available to everyone, including developers who don’t have paying users. We solidified our dedication towards the affordability of Clerk with a massive pricing overhaul, which came with 10,000 free MAUs for everyone, with the user’s first day free, and paid add-ons for the advanced authentication, administration, and B2B features. Read our announcement post for further details.

Hono Adapter

Applications built using Hono, a powerful and lightweight web server known for its compatibility with edge runtimes, also got access to Clerk’s authentication features with an official adapter!

December

Account Lockout

Account Lockout is a Clerk feature that enables you to protect your users from brute-force attacks on static credentials such as passwords or backup codes. When enabled it tracks all the attempts and locks down the account after 100, the default attempts, it’s locked for an hour!

Custom Roles & Permissions

One of our most sought after features of the year, custom roles and permissions, dropped in December, just in time for the holidays. Companies were able to simplify and improve their UX around roles, permissions and access provided to their end users.

As a part of this addition, we've added helper functions and components – has(), protect() and <Protect />. To learn more, read our announcement post.

FAPI Reference Docs

Our Frontend API documentation is back and better than ever!

Fetch User By Activity

Another drop was a new endpoint that allows insight into when a user was last active, this is great for all kinds of UX or admin dashboard implementations! Check out the changelog entry to learn more.

That's A Wrap!

Let's reach new heights in 2024 with Clerk, don't stop the auth conversation! Dive into the nitty-gritty with our technical wizards on Discord. Share your ideas, get expert advice, and join the Clerk community building the future of User Management. Plus, stay in the know with @ClerkDev on Twitter for all the latest releases and sneak peeks. Your seamless journey starts here!

Updated Pricing: 10,000 MAUs Free, and a new “Pro Plan”

Jacob Evans — Thu, 30 Nov 2023 21:58:15 +0000

We’re thrilled to introduce a simplified pricing structure that’s not only easier to understand, but also significantly cheaper for most applications currently using Clerk. Every application gets 10,000 free monthly active users (MAUs)!

Brand new users will also now receive their “First Day Free,” which means their activity is not counted until 24 hours after signing up. This ensures you are not charged for users who sign up, but churn within their first day and do not return.

Since Clerk’s inception, our primary goal has been to lower the barrier to building production-grade applications. Every application deserves secure and seamless user management that takes minutes to setup, not days — freeing you to focus on what’s important: your application.

💡 Existing customers will be grandfathered into their current plans, however, it may be cheaper to switch, so please evaluate accordingly and reach out to us if you have any questions.

Our new simplified pricing structure consists of “Free”, “Pro” and “Enterprise” plans. Where each plan includes your first 10,000 MAUs free and you will never pay for an inactive user. Additional features can be added to the Pro plan via “Pro add-ons” tailor made for specific use cases.

Free Plan – Up to 10,000 MAUs

Our free plan remains generous, with no features removed. You still get beautifully designed, performant, and customizable sign-in pages on the domain of your choosing. However, we’ve now doubled the included number of MAUs! Get started, and iterate longer — completely for free!

Visit the pricing page to see all features in the Free plan

Going Pro – A complete feature set for most use cases

The new Pro plan includes the first 10,000 MAUs, and starts at $25/mo. Additional MAUs are only $0.02 each. This is a dramatic simplification, and includes 10X more MAUs compared to the previous Hobby plan. The Pro plan also now includes the ability to set a “Custom Session Duration,” which has been a key sticking point in the past.

Additional Pro plan features include:

Removing Clerk Branding
Custom Session Duration (previously in the Business plan)
Password Complexity Requirements
User Ban/Unban
Allowlist/Blocklist
Multiple Domains
SMS Authentication
SOC2 Report on Request

Visit the pricing page to see all features in the Pro plan

Pro Add-Ons – Customize to fit your needs

While the Pro plan is designed for the majority of applications, add-ons are tailored to specific business needs and are priced according to their added value. Today we’re launching with 3 Pro add-ons that will become more feature-rich over time:

Enhanced Authentication — includes MFA
Enhanced Organizations — includes domain restrictions, and custom roles and permissions (Stay tuned for this new feature 😉)
Enhanced Administration — includes user impersonation

Visit the pricing page to see all features in each Pro add-on

The Future

We know pricing changes lead to uncertainty and we’re committed to minimizing them. Our end-goal here is to continue to drop the price of authentication as we add value in adjacent areas. Building applications should be getting easier and cheaper over time, and this pricing change is just one step in the right direction. Clerk will always be committed to the developer community, and hopefully this pricing overhaul reflects that.

We’re here if you have any questions — Happy building!

Next.js Authentication with Clerk: Streamlined SSR Handling

Jacob Evans — Wed, 22 Nov 2023 15:42:38 +0000

In the ever-evolving world of web development, streamlining tasks is paramount. Clerk, the versatile User Management platform, presents a contemporary way to manage user data in Next.js applications, leaving behind the complexity of old patterns for server-side rendering (SSR). Let's explore the key differences and the value of this new approach with basic code snippets.

Navigating Next.js SSR: The Previous Approach

Previously, incorporating Clerk in a Next.js app involved intricate setups and token management. Here's a reminder of what the deprecated approach looks like:

import { withServerSideAuth } from "@clerk/nextjs/ssr";

export const getServerSideProps = 
withServerSideAuth(({ req, resolvedUrl }) => {
  const { sessionId } = req.auth;

  if (!sessionId) {
    return { redirect: { 
destination: "/sign-in?redirect_url=" + resolvedUrl 
   } 
 };
}

  return { props: {} };
});

The New Way: Streamlined Handling

These are just a few examples of the new streamlined approaches. If you are looking for a more comprehensive breakdown of the best way to read session data in your Next.js app using the Pages Router or App Router, please reference the docs.

SSR in App Router – Server Component

The modern Clerk approach in App Router simplifies user data handling with straightforward helper functions. Here's a snippet of the new approach:

import { currentUser } from '@clerk/nextjs';

export default async function Example() {
  const user = await currentUser();

  return (
    <div>
      Hello {user.firstName}, your ID is {user.id}
    </div>
  );
}

SSR in Pages Router

If you are using the Pages Router, you can find more detailed examples beyond this basic snippet in the docs.

import { getAuth, buildClerkProps } from "@clerk/nextjs/server";
import { GetServerSideProps } from "next";

export const getServerSideProps: GetServerSideProps = async (ctx) => {
  const { userId } = getAuth(ctx.req);

  if (!userId) {
    // handle user is not logged in.
  }

// Load any data your application needs for
// the page using the userId
  return { props: { ...buildClerkProps(ctx.req) } };
};

The Value of the New Approach

Simplicity: The new approaches offer a cleaner, more
straightforward codebase for effortless data access.
Efficiency: Data access becomes a breeze.
Improved Workflow: Focus on building features, not grappling with complex User Management setups.
Maintainability: A tidy codebase equals easier maintenance and fewer debugging hassles.

Dive headfirst into Clerk's innovative approach to supercharge your development process, ensuring your apps are always at the cutting edge. This newfound simplicity isn't just for show; it's here to make your work smoother, your code cleaner, and your applications more maintainable. And what's even more exciting? This flexibility isn't confined to one corner of your project; it stretches its arms to Route Handlers as well, making it the perfect fit for the demands of modern web development.

Ready to Implement Authentication in Your App?

Don't hesitate to explore our Next.js Clerk Docs for a quick and comprehensive guide on integrating Clerk’s User Management into your application within minutes, not days.

For more in-depth technical inquiries or to engage with our community, feel free to join our Discord. Stay in the loop with the latest Clerk features, enhancements, and sneak peeks by following our Twitter account, @ClerkDev. Your journey to seamless User Management starts here!

Exploring Clerk Metadata with Stripe Webhooks

Jacob Evans — Mon, 13 Nov 2023 21:51:00 +0000

Introduction to User Metadata

By putting Clerk’s user metadata types to work, developers can proficiently handle user data, making their SaaS integrations run smoother, and work harder. It's like adding a turbocharger to your product's engine, enhancing functionality and improving the user experience, for a more comprehensive, customizable, and synchronizing systems ready to build any SaaS product out there.

A great feature in the wild world of SaaS product development to power integrations
powering integrations with other powerful products. We're talking about a sturdy, malleable means for handling user data.

You've got three types of User Metadata –public, private, and unsafe. Each one has its own unique access level and use case.

Public: It’s an accessible from both the frontend and backend. It's like the town bulletin board where you post things everyone can see but can't change. Think membership levels, user roles, stuff like that.
Private: It’s like the secret stash of user data only reachable from the backend. Perfect for things like account identifiers or subscription details, you know, the stuff you don't want out in the open.
Unsafe: It might sound a bit ominous, but it is super flexible; treat it like form data and validate any user inputs. It can be modified and accessed from both frontend and backend. Great for things like user preferences, setting or just any of the nitty-gritty details that make a user's experience unique.

User Metadata Meets Stripe Webhooks

Harnessing the power of User Metadata in tandem with Stripe’s webhooks offers significant advantages in SaaS product development. Clerk Metadata's flexible user data management paired with Stripe webhooks' real-time transaction updates creates a robust, efficient system. This combination ensures both comprehensive user data handling and prompt responsiveness to transaction events. Utilizing Clerk Metadata alongside Stripe’s webhooks lends itself well for streamlined and user-friendly SaaS development.

Utilizing Clerk's public User Metadata offers significant advantages for managing user data and transactions in your SaaS product. It allows for real-time updates, such as including a "paid" field after a transaction, offering a clear snapshot of payment statuses. This use of public metadata improves transparency, boosts data management efficiency, and enhances the overall user experience.

Tutorial: Implementing Stripe Webhook with Clerk User Metadata

The first step will be setting up accounts at Clerk & Stripe. Once you have those accounts you will follow the well documented Clerk’s Next.js Quickstart Guide.
To have access to the correct data from the Clerk session you will need to access the custom session data on the Dashboard, we will edit the session data to look like this:

{
    "publicMetadata": "{{user.public_metadata}}"
}

The last part will be setting up from the Stripe quickstart, the basic Stripe webhook. We will modify it later for our own needs, and there will also be a repo for you to grab afterwards!
By the end of the quickstarts, you should have something in your .env.localthat looks like this.

Environment Variables

# CLERK 
NEXT_PUBLIC_CLERK_PUBLISHABLE_KEY=pk_test_***
CLERK_SECRET_KEY=sk_test_***

# STRIPE
NEXT_PUBLIC_STRIPE_PUBLISHABLE_KEY=pk_test_***
STRIPE_SECRET_KEY=sk_test_***
STRIPE_WEBHOOK_SECRET=whsec_***

Auth Middleware Setup

Once we have everything installed we are going to jump into a very basic app, with one private route /members, and the homepage route will serve as our public route where all the fun stuff will happen. Our Middleware is going to be handling the access.

M*iddleware Routes*

export default authMiddleware({
  // Making sure homepage route and API, especially the webhook, are both public! 
  publicRoutes: ["/", "/api/(.*)"],
  afterAuth: async (auth, req) => {
        // Nice try, you need to sign-in 
    if (!auth.userId && !auth.isPublicRoute) {
      return redirectToSignIn({ returnBackUrl: req.url });
    }
        // Hey! Members is for members 😆
    if (
      auth.userId &&
      req.nextUrl.pathname === "/members" &&
      auth.sessionClaims.publicMetadata?.stripe?.payment !== "paid"
    ) {
      return NextResponse.redirect(new URL("/", req.url));
    }
    // Welcome paid member! 👋
    if (
      auth.userId &&
      req.nextUrl.pathname === "/members" &&
            // How we get payment value "paid" is next, in the webhook section!
      auth.sessionClaims.publicMetadata?.stripe?.payment === "paid"
    ) {
      return NextResponse.next();
    }
    // If we add more public routes, signed-in people can access them
    if (auth.userId && req.nextUrl.pathname !== "/members") {
      return NextResponse.next();
    }
    // Fallthrough last-ditch to allow access to a public route explicitly
    if (auth.isPublicRoute) {
      return NextResponse.next();
    }
  },
});

We can simplify the Middleware access logic for this app, but this explicit example can show how you can have far more complex access handling. Where do we get “paid” from!? That is coming up next.

Webhook Endpoint

Since this app is our SaaS with member access, we need to provide a way for the user to pay and gain access. Let’s start with setting up the tokens for Clerk & instantiating Stripe.

const stripe = new Stripe(process.env.STRIPE_SECRET_KEY as string, {
  apiVersion: "2023-10-16",
});
const webhookSecret = process.env.STRIPE_WEBHOOK_SECRET as string;

After we have the credentials, the rest of the code should look very similar to the Stripe default logic for webhooks.

Handling Webhook Events

export async function POST(req: NextRequest) {
  if (req === null)
    throw new Error(`Missing userId or request`, { cause: { req } });
    // Stripe sends this for us 🎉
  const stripeSignature = req.headers.get("stripe-signature");
  // If we don't get it, we can't do anything else! 
  if (stripeSignature === null) throw new Error("stripeSignature is null");

  let event;
  try {
    event = stripe.webhooks.constructEvent(
      await req.text(),
      stripeSignature,
      webhookSecret
    );
  } catch (error) {
    if (error instanceof Error)
      return NextResponse.json(
        {
          error: error.message,
        },
        {
          status: 400,
        }
      );
  }
    // If we dont have the event, we can't do anything again
  if (event === undefined) throw new Error(`event is undefined`);
  switch (event.type) {
    case "checkout.session.completed":
      const session = event.data.object;
      console.log(`Payment successful for session ID: ${session.id}`);
      break;
    default:
      console.warn(`Unhandled event type: ${event.type}`);
  }

 return NextResponse.json({ status: 200, message: "success" });
}

So what is next!? We need a way to know when a Clerk User has 'paid.' Well, let's extract that switch statement and add the secret sauce. That'll make this all work when we are done!

Adding Clerk User Metadata to Event

switch (event.type) {
    case "checkout.session.completed":
      const session = event.data.object;
      console.log(`Payment successful for session ID: ${session.id}`);
            // That's it? Yep, that's it. We love UX 🎉
            clerkClient.users.updateUserMetadata(
        event.data.object.metadata?.userId as string,
        {
          publicMetadata: {
            stripe: {
              status: session.status,
                            // This is where we get "paid"
              payment: session.payment_status,
            },
          },
        }
      );
      break;
    default:
      console.warn(`Unhandled event type: ${event.type}`);
  }

Some of you may have noticed event.data.object.metadata?.userId (where did that come from!?). We will get to that one too. The reason for this is that we can’t access Clerk’s session in the webhook, so we will get a little creative.

Session Endpoint

We will now need to create an endpoint that will generate our Stripe session that will be used to make our payment and turn our Clerk User into a paid "Member". This is where the userId in the webhook will also be coming from! Instantiate stripe the same as before, it will again be a Next.js POST endpoint.

Stripe Session

// This is our Clerk function for session User
const { userId } = auth();
// We are receiving this from the Client request, thats next!
const { unit_amount, quantity } = await req.json();

  try {
    const session = await stripe.checkout.sessions.create({
      payment_method_types: ["card"],
      line_items: [
        {
          price_data: {
            currency: "usd",
            product_data: {
              name: "Membership",
            },
            unit_amount,
          },
          quantity,
        },
      ],
            // This is where "event.data.object.metadata?.userId" is defined from! 
      metadata: {
        userId,
      },
      mode: "payment",
      success_url: `${req.headers.get("origin")}/members`,
      cancel_url: `${req.headers.get("origin")}/`,
    });

    return NextResponse.json({ session }, { status: 200 });
  } catch (error) {
        ...
  }

We have now laid the groundwork for a SaaS leveraging Clerk’s User Metadata to manage User specific data! So, to really focus on the versatility and potential of this feature, the UI portion has been kept really simple. We have the Homepage with a button to navigate to /members page and to become a paid member, let’s take a look at the homepage.

Homepage Implementation

export default function Home() {
  const { isSignedIn } = useAuth();

  return (
    <main>
      {!isSignedIn ? (
        <div className="...">
          <SignIn redirectUrl="/" />
        </div>
      ) : (
        <div>
          <div className="...">You are signed in!</div>
          <div className="...">
            <CheckoutButton />
            <a
              className="..."
              href="/members"
            >
              Go to members page
            </a>
          </div>
        </div>
      )}
    </main>
  );
}

Wrap up!

This pattern can be used with any other transactions or user specific data you would like to handle in the backend and then utilize in the client. This keeps your User Management pragmatic & versatile, offloading the burden across multiple systems. This is only the beginning with what we can do with Clerk’s toolset, this time we only leveraged User Metadata! What should we do next? Let us know in the Discord and on X!
// Detect dark theme var iframe = document.getElementById('tweet-1527026488381296640-67'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1527026488381296640&theme=dark" }

Not forgetting, you will want the complete codebase to check out, and learn from!

References

List of resources, documentation, and links mentioned in the blog:

Clerk Metadata: Clerk Metadata Documentation

I'm Back! Burnout Sucks.

Jacob Evans — Thu, 26 Oct 2023 15:34:25 +0000

Why I Took a Break and Why I'm Back!

I stopped writing blogs, and shorts (like this one), other passion projects fell off too awhile back. Mainly I was focused on work and personal life, and was burnt out trying to build out my side projects at the same time.

Am I gonna start firing at 110% again trying to do all the things at once... No. That is how we end up with giant gaps in activity, the longer they are the harder it is to restart too.

So, what's changed?

Well I got a new job @authentication (Clerk) as Sr. Developer Experience Engineer (cool title I know), additionally, personal life has stabilized a bit in the last few years, though I plan on moving again shortly.

What does this mean... probably some streaming, work related and personal stuff like Dungeons & Dragons, trying to revive the Discord (more, its been active lately), a little writing and continuing Code & Life my 3 days a week Twitter Space I have been doing for 2+ years now

Ready to join the conversation? Check out our Discord! https://discord.gg/JTDfwPa2mX

And hey, don’t forget to visit my website https://osrg.t3.gg for more updates and insights.

See you around!

How I am bringing OSS contributing to Twitch, taking everyone with me and more...

Jacob Evans — Sat, 09 Jul 2022 19:56:04 +0000

Origin Story

A little over a year ago I started a community (OSRG) that I wanted to build into a new way of approaching Open Source Contributing, emphasizing on gamification, crowdsourcing & mob programming as some main pillars. Very quickly we realized the power of this when we knocked out a MONSTER of a repository in 30 days converting it from Enzyme to React Testing Library, not long after I burned out from many different things.
// Detect dark theme var iframe = document.getElementById('tweet-1350089186175553537-208'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1350089186175553537&theme=dark" }

What now?

Well during that time something I realized was a platform & system needed to be built for all this! Great! We also needed a community! We have one! Cool we are chugging along, people starting wondering "Why gamification? It is so much effort, who cares!?" Valid questions, well now I have a Twitch channel where I am merging my Nerddoms!! The plans are to take the channel building on the community, introduce more people to my passion for games like Dungeons & Dragons, coding, Open Source Contributing and combine them in the channel. Ideas like having streams with panels of people mob programming with me live on Twitch w/ people helping in chat, interacting on Discord, and even building the platform together in the open that will change how people approach coding!

Fresh New Profile Pic

Jacob Evans — Thu, 10 Feb 2022 03:54:46 +0000

Figured it was about time to change a profile pic I had been using for 4 years. I have changed it across many platforms already. Twitter, GitHub, Dev, etc...

Looking forward to not changing it again for awhile lol

Git Graft: A NPX Tool & Git Hook in TypeScript & Node

Jacob Evans — Fri, 04 Jun 2021 02:38:20 +0000

Introduction

I decided I was tired of a GitFlow process. Every time I had to write a commit I had to prepend the JIRA ticket to the commit message, "It's in the branch, why can't it just take it from the branch!?" I kept asking myself. Finally, I said, I will just make that happen.

The Idea

Enter in the concept of Git Hooks, more famously known through tooling like Husky (awesome tool btw), however, there is a Git Hook for just about any part of the process of Git, and they have examples (written in shell, I'll get more into that later) in the .git/hooks directory. Ok so it's right there, I made a hook what is the big deal? I thought to myself "It took me forever to do this because of the overhead what if I removed that for others?" So I did.

The Tool

Technologies:

TypeScript
NPM/NPX
Oclif
Enquirer

So it might come as a bit of a surprise but there are only 2 shell files in this whole CLI tool. They really just execute the JavaScript. Even crazier, I made the commit-msg hook entirely JavaScript little trick that I will get into later.

I will go over the CLI & Git Commit Message Hook in the following 2 more blog articles in the series. I want to keep this one short and more of a summary.

Labeled Breakout & GOTO

Jacob Evans — Wed, 08 Jul 2020 02:49:28 +0000

So I saw a post on Twitter, talking about labeled breaks... Which led to people fervently recommending not to do such patterns. Somehow this brought up GOTO, now this is the thing, I have never used GOTO, I Googled it. What I read was likely the correlation to the heavy abuse of GOTO in multi-loop breaks since the example was nested for loops using labeled breaks.

From what I can tell, which is limited. The GOTO was essentially abstracted away by such things as for, while, switch, do, and the like. Reintroducing the GOTO paradigm seems redundant in structured programming.

My naive thought about this is in a modern high-level language there is probably a builtin model that is optimized that does something similar. However, I brought it up here because I want to learn more about it and GOTO beyond some old code and Wikipedia.

Digital Garden

Jacob Evans — Thu, 02 Jul 2020 23:34:28 +0000

I eventually plan on building my personal website or portfolio... whatever you want to call it. I haven't because I have never felt the need too. How often has someone asked me about something I made? Too few. how often did they actually look at it after I pointed them towards one of those things? Nearly nil.

So why would I care about the personal website now? Great question, it isn't for the usual reasons. I recently learned about this concept of Digital Gardens at first I thought, "This is the same thing I already am doing..." Blogging (on Dev.to), Twitter, GitHub, etc... all feeding into the zeitgeist that is ME in tech.

Well, not so much, after looking at Joel Hooks Digital Garden it dawned on me, the potential for aggregating my thoughts, my ideas, my brainstorming and so much more in a completely abstract yet connected way is POWERFUL.

Does this mean no more Dev.to for me? Well no, I love this platform. Does it mean I will be blasting this platform with my nonsense and stream of consciousness on Dev.to? Definitely not, I would spare you all from that misery. I do plan on connecting some of what I do in my Digital Garden to this platform and others I listed, but you can think of what I bring from the Digital Garden to here as the harvested crop, the fully formulated ideas, and thoughts growing there.