A ‹Component/› is worth a thousand APIs

Clerk started with a simple vision. We loved the professionalism of Google's Sign Up, Sign In, and User Profile, so we set out to build developer tools that would help everyone match their caliber.

With UIs as our primary goal, we realized that Clerk wouldn't be a traditional API company. We focused on building a fantastic frontend component SDK, rather than a traditional backend REST SDK.

We chose React as our first target given its popularity, and split Google's surface area into four components: <SignUp/>, <SignIn/>, <UserProfile/>, and <UserButton/>.

Components are a higher-level of abstraction than REST SDKs. They provide UIs to end-users instead of just a function to developers, so they inherently offer more value.

But what's surprising is just how much more value. Even at Clerk, we assumed we could just "slap a UI on top of an auth API." Despite having a team full of seasoned engineers, we failed to realize just how much work sits between traditional APIs and the end-user features they enable.

Stripe example

As an example outside of authentication, let's compare Stripe's original 9 lines for creating a charge, to the sidebar for their current Checkout documentation:

Checkout has far more complexity than the original Charge API, but why? Aren't both responsible for charging a customer?

The difference is that Charge asked for the exact amount to charge, while Checkout needs to display why an amount is being charged. It needs all of the context of the Products being purchased, their Price, the quantity, the taxes and shipping costs, any discounts applied, and more. Stripe needed to build dozens more API resources and paramaters to produce the end-user Checkout UI.

Before Checkout, this additional context lived inside the developer's application. Now that it lives inside Stripe, charging customers has become massively easier. Stripe solves so much more complexity for developers today than it did 10 years ago.

Clerk example

Clerk is seeing the same patterns in authentication that Stripe saw in Checkout. To build our core components, we need to manage much more complexity than legacy vendors like Auth0.

This is particularly apparent with our <UserButton/> and <UserProfile/> components. We are the only authentication provider to offer these, and there's a foundational reason why: Clerk is the only authentication provider that manages sessions as-a-service.

Legacy vendors focus on just the sign-up and sign-in screens. Once the user's identity is verified, the session is managed within the application – not within the authentication service. This makes it impossible for them to offer drop-in <UserButton/> and <UserProfile/> components like Clerk.

And since we're not ones to cut corners, our session management solution is fully featured. We include active device management from within <UserProfile/>, so users can remotely force sign outs from other devices:

Plus, we (optionally) include account switching within <UserButton/>, just like Google's:

Beyond session management, we also enable self-serve two-factor authentication from within <UserProfile/>:

Once setup is completed, <SignIn/> will automatically request the second factor during the next sign-in:

If Clerk didn't manage sessions and two-factor authentication, developers would be stuck implementing these features from within their application – a much more challenging prospect than simply using <UserButton/> and <UserProfile/>.

On components vs redirects

Some readers may be aware that Clerk uses embeddable components while Stripe Checkout uses a redirect flow. That's completely correct, so we kept this blog focused on points that remain true regardless of how the UI is ultimately presented to the end-user.

That being said, there is one advantage to components that deserves a special callout:

At Clerk, every component we build is composed using React hooks, and the hooks we use are actually pacakaged alongside our components. So, if frontend developers don't like our components for any reason, they can still build their own UIs without involving a backend developer and a backend SDK.

This extra layer of composability has been a huge boon for companies with strict branding requirements, since we eliminated the need for backend application logic regardless of if our UIs are used.

In summary

We've seen this pattern enough to say confidently: a <Component/> is worth a thousand APIs.

Components have become the new gold-standard in developer tools – they are the new, optimal, composable building block. They save developers far more time than traditional REST SDKs, both by providing end-user UIs, and by eliminating huge swaths of code that used to be managed in-house.