SDK types
Clerk categorizes its SDKs into three different types:
- Frontend-only
- Backend-only
- Fullstack
Take a look at your framework and check which type it enables. Then place your SDK into one of these three categories when first creating it. Arguably, creating a fullstack SDK is the most work so feel free to start off with frontend-only/backend-only SDK — you can still make it fullstack at a later point. Also, the framework you’re building the SDK for might evolve in the future, so maybe naturally your SDK will also need to change over time.
| SDK Type | FAPI HTTP client | BAPI HTTP client | Hotloading ClerkJS | window.Clerk UI components | Authorization header verification | __session cookie verification | Handshake support |
|---|---|---|---|---|---|---|---|
| Frontend-only | ✅ | ✅ | ✅ | ||||
| Backend-only | ✅ | ✅ | ✅ | ||||
| Fullstack | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
Frontend-only
Frontend-only SDKs are used in frameworks that only support client-side rendering (CSR) or static site generation (SSG) with rehydration. The app is rendered in the browser using JavaScript and this bundle doesn’t contain any authenticated information itself but uses client-side code to fetch the authenticated data.
Examples: Vite React, Vue, iOS/Swift
SDK Examples: @clerk/clerk-react
Backend-only
Backend-only SDKs are used in frameworks to build APIs without directly serving HTML. They provide authenticated data to power your frontend.
Examples: Express.js/Hono with a Vite React/Vue frontend
SDK Examples: @clerk/express, @hono/clerk-auth, clerk-sdk-go
Fullstack
Fullstack SDKs are used in frameworks that support SSR and subsequently can render HTML from a server with authenticated data.
Examples: Next.js, Rails
SDK Examples: @clerk/nextjs, clerk-sdk-ruby
Feedback
Last updated on