shadcn-ui/taxonomy
An open source application built using the new router, server components and everything new in Next.js 13.
Full-stack blog platform with authentication, subscriptions, and rich text editing
Users authenticate via NextAuth which creates sessions stored in database. Authenticated users can create posts through the Editor component which saves JSON content to Prisma database. The dashboard loads user's posts via server components. Billing integration fetches subscription status from Stripe and allows plan changes. Documentation content is processed from MDX files by Contentlayer at build time and rendered dynamically.
Under the hood, the system uses 2 feedback loops, 3 data pools, 4 control points to manage its runtime behavior.
A 8-component fullstack. 131 files analyzed. Data flows through 7 distinct pipeline stages.
How Data Flows Through the System
Users authenticate via NextAuth which creates sessions stored in database. Authenticated users can create posts through the Editor component which saves JSON content to Prisma database. The dashboard loads user's posts via server components. Billing integration fetches subscription status from Stripe and allows plan changes. Documentation content is processed from MDX files by Contentlayer at build time and rendered dynamically.
- User Authentication — UserAuthForm calls NextAuth signIn with email/password or OAuth, creating session cookie and User record in database via Prisma adapter [Login Credentials → User]
- Session Resolution — getCurrentUser extracts session from NextAuth, queries database for full User object including subscription fields [NextAuth Session → User]
- Post Creation/Editing — Editor component initializes Editor.js with existing Post content as JSON blocks, saves changes via API routes to Prisma database [Post → Post Content Updates]
- Dashboard Data Loading — Dashboard page server component queries user's posts from Prisma with select fields (id, title, published, createdAt), orders by updatedAt desc [User → Post]
- Subscription Status Check — getUserSubscriptionPlan fetches user data, then calls Stripe API to get live subscription status, combining into SubscriptionPlan object [User → SubscriptionPlan] (config: STRIPE_API_KEY)
- Content Processing — Contentlayer processes MDX files at build time, generating type-safe objects with frontmatter and compiled content, accessed via allDocs/allGuides
- Documentation Rendering — Doc pages find content by slug in allDocs array, pass to Mdx component which renders with custom React components and syntax highlighting [Doc/Guide Content]
Data Models
The data structures that flow between stages — the contracts that hold the system together.
@prisma/clientPrisma model with id: string, name: string?, email: string, image: string?, createdAt: Date, plus NextAuth fields
Created during registration via NextAuth, persisted in database, accessed via getCurrentUser() helper for authorization
@prisma/clientPrisma model with id: string, title: string, content: JSON?, published: boolean, authorId: string, createdAt: Date, updatedAt: Date
Created from dashboard, edited in rich text editor as JSON blocks, stored with author relationship, displayed in user's post list
lib/subscription.tsobject with name: string, description: string, stripePriceId: string?, stripeSubscriptionId: string?, isCanceled: boolean, isPro: boolean
Fetched from getUserSubscriptionPlan() by combining database user data with live Stripe subscription status
contentlayer/generatedContentlayer-generated types with title: string, description: string, body: MDX, slug: string, date: Date, published: boolean, featured?: boolean
Authored as MDX files, processed by Contentlayer at build time into type-safe objects, rendered by Mdx component
Hidden Assumptions
Things this code relies on but never validates. These are the things that cause silent failures when the system changes.
The Editor component assumes post.content is valid Editor.js JSON format with proper block structure when loading existing posts
If this fails: If post.content contains malformed JSON or unexpected structure (e.g., from manual database edits or migration issues), Editor.js will fail to initialize and users cannot edit their posts
components/editor.tsx:Editor
Assumes Stripe subscription IDs in the database are still valid and exist in Stripe's system
If this fails: If a subscription is deleted directly in Stripe dashboard but still referenced in database, Stripe API calls will fail with 404s, breaking billing page and subscription checks
lib/subscription.ts:getUserSubscriptionPlan
Assumes posts are ordered by updatedAt but selects createdAt - expects updatedAt field exists and is maintained by Prisma
If this fails: If updatedAt is null or not automatically updated during edits, posts will be incorrectly ordered or query will fail
app/(dashboard)/dashboard/page.tsx:DashboardPage
Assumes NextAuth session contains user.id that directly maps to database User.id field
If this fails: If NextAuth configuration changes or session format differs (e.g., using email as identifier), database lookups will return null causing authentication failures
lib/session.ts:getCurrentUser
Assumes Stripe subscription status fetched in real-time reflects current billing state without caching considerations
If this fails: Rapid subscription status checks could hit Stripe rate limits, and stale data during status transitions (canceled->active) could show wrong billing state
lib/subscription.ts:getUserSubscriptionPlan
Assumes DATABASE_URL environment variable points to accessible PostgreSQL database with correct schema version
If this fails: If database is unreachable, has wrong schema version, or connection string is malformed, all database operations fail silently with Prisma connection errors
lib/db.ts:db
Assumes users will have reasonable number of posts - no pagination or limit on db.post.findMany query
If this fails: Users with hundreds of posts will cause slow page loads and potential memory issues as all posts are loaded into memory
app/(dashboard)/dashboard/page.tsx:DashboardPage
Assumes browser has sufficient memory to handle Editor.js instance with large post content
If this fails: Very large posts with many blocks or embedded media could cause browser crashes or editor freezing on mobile devices
components/editor.tsx:Editor
Assumes postId parameter is always a valid UUID format matching Post.id database field type
If this fails: If postId is not a UUID (e.g., integer, malformed string), Prisma query could fail or behave unexpectedly depending on database constraints
app/(editor)/editor/[postId]/page.tsx:getPostForUser
Assumes MDX frontmatter in content files matches expected schema with required fields like title, description, published
If this fails: If content authors add MDX files with missing or incorrectly typed frontmatter, build will fail or runtime errors occur when accessing undefined properties
contentlayer/generated:allDocs
System Behavior
How the system operates at runtime — where data accumulates, what loops, what waits, and what controls what.
Data Pools
Prisma-managed PostgreSQL database storing users, posts, accounts, sessions - all application state
Build-time processed MDX content as type-safe JavaScript objects with frontmatter and compiled body
NextAuth session cookies and database session records for maintaining user authentication state
Feedback Loops
- Editor Auto-save (auto-scale, balancing) — Trigger: Content changes in Editor.js. Action: Debounced API calls save draft content to database. Exit: User navigates away or explicitly saves.
- Subscription Status Sync (polling, balancing) — Trigger: User visits billing page. Action: Fetches current Stripe subscription status and updates display. Exit: Page navigation or component unmount.
Delays
- Content Build Processing (compilation, ~Build time) — MDX content changes require full rebuild to appear in application
- Database Query Loading (async-processing, ~Network dependent) — Loading skeletons shown while post lists and user data fetch from database
Control Points
- Authentication Providers (env-var) — Controls: Which OAuth providers and email auth are available
- Stripe Integration (env-var) — Controls: Subscription plans, pricing, and payment processing
- Database Connection (env-var) — Controls: Database provider and connection parameters
- Feature Flags (runtime-toggle) — Controls: Navigation items, subscription requirements, and UI features
Technology Stack
Full-stack framework providing app directory routing, server components, and API routes
Authentication library handling OAuth providers, session management, and database integration
ORM providing type-safe database queries, migrations, and NextAuth adapter for session storage
Content SDK that transforms MDX files into type-safe objects with frontmatter validation
Payment processor handling subscription billing, webhook events, and customer portal
Block-style rich text editor that outputs structured JSON instead of HTML
Headless component library providing accessible primitives for complex UI interactions
Utility-first CSS framework with custom design system and shadcn/ui component variants
Key Components
- getCurrentUser (resolver) — Extracts authenticated user from NextAuth session and fetches full user data from database
lib/session.ts - Editor (processor) — Rich text editor using Editor.js that converts user input into structured JSON blocks for post content
components/editor.tsx - UserAuthForm (gateway) — Handles user authentication via email/password or OAuth providers through NextAuth signIn
components/user-auth-form.tsx - BillingForm (adapter) — Manages Stripe subscription lifecycle - creating checkout sessions, handling cancellations, and displaying current plan status
components/billing-form.tsx - Mdx (transformer) — Renders Contentlayer-processed MDX content into React components with custom styling and interactive elements
components/mdx-components.tsx - DashboardNav (registry) — Renders navigation menu from dashboardConfig, highlighting active routes and handling user permissions
components/nav.tsx - PostItem (transformer) — Displays individual post in dashboard list with title, publish status, creation date, and action buttons
components/post-item.tsx - getUserSubscriptionPlan (adapter) — Combines local user data with live Stripe subscription status to determine current plan and billing state
lib/subscription.ts
Explore the interactive analysis
See the full architecture map, data flow, and code patterns visualization.
Analyze on CodeSeaRelated Fullstack Repositories
Frequently Asked Questions
What is taxonomy used for?
Full-stack blog platform with authentication, subscriptions, and rich text editing shadcn-ui/taxonomy is a 8-component fullstack written in TypeScript. Data flows through 7 distinct pipeline stages. The codebase contains 131 files.
How is taxonomy architected?
taxonomy is organized into 4 architecture layers: Route Handlers, UI Components, Core Libraries, Content Layer. Data flows through 7 distinct pipeline stages. This layered structure keeps concerns separated and modules independent.
How does data flow through taxonomy?
Data moves through 7 stages: User Authentication → Session Resolution → Post Creation/Editing → Dashboard Data Loading → Subscription Status Check → .... Users authenticate via NextAuth which creates sessions stored in database. Authenticated users can create posts through the Editor component which saves JSON content to Prisma database. The dashboard loads user's posts via server components. Billing integration fetches subscription status from Stripe and allows plan changes. Documentation content is processed from MDX files by Contentlayer at build time and rendered dynamically. This pipeline design reflects a complex multi-stage processing system.
What technologies does taxonomy use?
The core stack includes Next.js 13 (Full-stack framework providing app directory routing, server components, and API routes), NextAuth.js (Authentication library handling OAuth providers, session management, and database integration), Prisma (ORM providing type-safe database queries, migrations, and NextAuth adapter for session storage), Contentlayer (Content SDK that transforms MDX files into type-safe objects with frontmatter validation), Stripe (Payment processor handling subscription billing, webhook events, and customer portal), Editor.js (Block-style rich text editor that outputs structured JSON instead of HTML), and 2 more. A focused set of dependencies that keeps the build manageable.
What system dynamics does taxonomy have?
taxonomy exhibits 3 data pools (Database, Generated Content), 2 feedback loops, 4 control points, 2 delays. The feedback loops handle auto-scale and polling. These runtime behaviors shape how the system responds to load, failures, and configuration changes.
What design patterns does taxonomy use?
4 design patterns detected: Route Groups, Server Component Data Fetching, Parallel Loading States, Progressive Enhancement.
Analyzed on April 20, 2026 by CodeSea. Written by Karolina Sarna.