This document explains what was implemented to create an interactive OpenAPI playground using Fumadocs.
fumadocs-openapi: The official Fumadocs OpenAPI integration packageshiki: Syntax highlighting library (required dependency)
- Updated
app/global.cssto include@import 'fumadocs-openapi/css/preset.css' - This provides the necessary styling for the OpenAPI playground components
- Created a server-side OpenAPI instance that loads your
openapi.ymlfile - This instance is used to generate API documentation pages dynamically
components/api-page.tsx: Server component that creates the API page using Fumadocs'createAPIPagefunctioncomponents/api-page.client.tsx: Client component for client-side configuration (currently empty, can be extended later)
- Updated the source loader to use
multiple()to combine:- Your existing MDX docs (
docs.toFumadocsSource()) - OpenAPI-generated pages (
openapiSource())
- Your existing MDX docs (
- Added
openapiPlugin()to the plugins array - This creates virtual pages from your OpenAPI spec under the
/docs/openapi/path
- Added logic to detect OpenAPI pages (
page.data.type === 'openapi') - When an OpenAPI page is detected, it renders the
APIPagecomponent with interactive playground - Regular MDX pages continue to work as before
- Added
APIPageto the MDX components so it can be used in MDX files if needed - This allows you to embed API documentation in regular MDX pages
-
Virtual File Generation: The
openapiSource()function reads youropenapi.ymlfile and generates virtual documentation pages for each API endpoint, organized by tags. -
Interactive Playground: Each API endpoint page includes:
- Endpoint information (method, path, description)
- Interactive request builder with parameter inputs
- Code samples in multiple languages
- Response schemas and examples
- Try-it-out functionality to test API calls
-
Navigation: OpenAPI pages appear in your docs navigation under
/docs/openapi/with the structure based on your OpenAPI tags.
Once you run bun dev, you can access:
- Main docs:
/docs- Your regular documentation - OpenAPI docs:
/docs/openapi/...- Auto-generated API documentation with interactive playground
The OpenAPI pages will be organized by the tags defined in your openapi.yml file (e.g., Authentication, Projects, Toolkits, etc.).
✅ Interactive API playground with try-it-out functionality
✅ Code samples in multiple programming languages
✅ Request/response schema documentation
✅ Parameter documentation with examples
✅ TypeScript type definitions
✅ Server selection (production, staging, local)
✅ Authentication configuration UI
- Run
bun devto start the development server - Navigate to
/docsand look for OpenAPI sections in the navigation - Click on any API endpoint to see the interactive playground
- Test API calls directly from the browser (make sure CORS is configured on your API server)
The slowness you experience is ONLY in development. Users in production will NOT experience it.
See PERFORMANCE_EXPLANATION.md for a detailed explanation.
Why is rendering slow in development?
The slowness is not because it's local - it's due to the size of your OpenAPI spec:
- File Size: 1.1MB (1,155,523 bytes)
- Line Count: 26,323 lines
- Processing: The entire spec must be parsed, validated, and virtual pages generated for all ~77 endpoints
Development (Local):
- First request: 5-15 seconds (processes entire spec)
- Subsequent requests: < 1 second (cached)
- You experience this slowness during development
Production (Cloud):
- Build time: 5-15 seconds (happens once during deployment)
- User requests: < 100ms (serves pre-built static pages)
- Users experience fast page loads!
Your setup uses Static Site Generation (SSG):
- The
generateStaticParams()function pre-generates all pages at build time - All OpenAPI processing happens during
bun build, not at runtime - Users receive pre-built static HTML pages that load instantly
- Development: Accept that first load is slow, but subsequent navigations are fast
- Production: Run
bun build- all processing happens during build, users get fast pages - Large Specs: This is expected behavior. The trade-off is comprehensive documentation vs. build time (not user experience)
You can customize the playground by:
- Editing
components/api-page.client.tsxto add client-side configuration - Modifying
lib/openapi.tsto change how the OpenAPI spec is loaded - Adjusting the
baseDirinlib/source.tsto change the URL path for OpenAPI docs