This document explains the RealWorld project's approach to managing its ecosystem of 150+ implementations and community resources. It covers the implementation registry system using CodebaseShow, community-created resources like performance comparisons, specification assets (mobile icons, API collections), and the GitHub Discussions-based community engagement model.
For information about creating new implementations, see Creating New Implementations. For details on issue and PR workflows, see Issue & PR Templates.
The RealWorld project uses CodebaseShow as the central registry for all implementations. This external platform serves as the canonical list of completed implementations across all technology stacks.
Implementation Submission Workflow
| Step | Action | Location | Purpose |
|---|---|---|---|
| 1 | Check for WIPs | GitHub Discussions | Avoid duplicate efforts, find collaborators |
| 2 | Announce WIP | GitHub Discussions | Signal intent, gather feedback |
| 3 | Develop | Local fork of starter kit | Build implementation |
| 4 | Test | Postman collection | Validate API compliance |
| 5 | Submit | CodebaseShow | Add to official registry |
Sources: apps/documentation/src/content/docs/introduction.mdx17-27 apps/documentation/src/content/docs/implementation-creation/introduction.md8-17
The project uses GitHub Discussions to manage implementations under development, preventing duplicate efforts and facilitating collaboration.
WIP Discovery Process
The system encourages checking for existing work-in-progress implementations before starting new ones:
github.com/realworld-apps/realworld/discussions/categories/wip-implementationsSources: apps/documentation/src/content/docs/introduction.mdx27 apps/documentation/src/content/docs/implementation-creation/introduction.md8-9
The RealWorld project has enabled a unique corpus of performance comparison research due to its standardized API specification. Multiple community-created studies compare frontend framework performance using identical functionality.
Available Performance Studies
| Year | Title | Publication | Focus |
|---|---|---|---|
| 2017 | A Real-World Comparison of Front-End Frameworks with Benchmarks | Medium (FreeCodeCamp) | Initial baseline comparison |
| 2018 | A Real-World Comparison of Front-End Frameworks with Benchmarks (2018 Update) | Medium (FreeCodeCamp) | Framework evolution tracking |
| 2019 | A Real-World Comparison of Front-End Frameworks with Benchmarks (2019 Update) | Medium (FreeCodeCamp) | Three-year trend analysis |
| 2020 | A Real-World Comparison of Front-End Frameworks with Benchmarks 2020 | Medium (DailyJS) | Modern framework landscape |
The studies are valuable because:
Sources: apps/documentation/src/content/docs/community/resources.md7-11
The project maintains an open invitation for community members to contribute RealWorld-related content.
To contribute community resources:
apps/documentation/src/content/docs/community/resources.mdSources: apps/documentation/src/content/docs/community/resources.md13-15
The repository includes standardized icon sets for mobile implementations in the spec/mobile_icons directory.
Mobile Specification Approach
Unlike frontend web implementations that share a common Bootstrap 4 theme, mobile implementations use a different approach:
spec/mobile_icons directoryThe spec/mobile_icons directory contains resolution-appropriate icons for both iOS and Android platforms, ensuring consistent branding across mobile implementations.
Sources: apps/documentation/src/content/docs/specifications/mobile-specs/introduction.md5-11
The OpenAPI specification and Postman collection are distributed through multiple channels for maximum accessibility.
Specification Access Patterns
| Use Case | Access Method | File | Purpose |
|---|---|---|---|
| Review API contract | Documentation site | api/openapi.yml | Understand endpoint requirements |
| Test backend | Newman CLI | api/Conduit.postman_collection.json | Automated validation |
| Generate client | OpenAPI tools | api/openapi.yml | Auto-generate API clients |
| Interactive testing | Postman app | api/Conduit.postman_collection.json | Manual API exploration |
The specification files referenced in documentation pages point to the canonical versions in the api/ directory:
Sources: apps/documentation/src/content/docs/specifications/backend/introduction.md5-9 apps/documentation/src/content/docs/specifications/backend/postman.md5-9
The documentation site uses a hierarchical structure defined in astro.config.mjs that organizes content into logical sections.
Sidebar Configuration Mapping
The documentation sidebar is defined in apps/documentation/astro.config.mjs69-173 using the Starlight integration. Key configuration elements:
| Section | Label | Purpose | Pages |
|---|---|---|---|
| Implementation Creation | label: 'Implementation creation' | Guide for building new implementations | Introduction, Features, Expectations |
| Frontend Specifications | label: 'Frontend specifications' | Frontend implementation requirements | Templates, Styles, Routing, API, Tests |
| Backend Specifications | label: 'Backend specifications' | Backend implementation requirements | Introduction, Endpoints, API Response Format, CORS, Error Handling, Postman, Tests |
| Mobile Specifications | label: 'Mobile specifications' | Mobile implementation guidance | Introduction (single page) |
| Community | label: 'Community' | Community resources and acknowledgments | Authors, Resources, Special Thanks |
The structure enables developers to navigate documentation based on their implementation type (frontend, backend, or mobile) while providing shared community resources accessible to all.
Sources: apps/documentation/astro.config.mjs69-173
Developers and users can discover implementations through multiple pathways based on their needs.
Implementation Discovery Pathways
Documentation Site Entry
CodebaseShow Browse
https://codebase.show/projects/realworld?category=frontend or ?category=backendGitHub Discussions Browse
github.com/realworld-apps/realworld/discussions/categories/wip-implementationsAvailable Categories
| Category | Example Technologies | Use Case |
|---|---|---|
| Frontend | React, Angular, Vue, Svelte, Solid | Client-side SPA implementations |
| Backend | Node, Django, Rails, Spring, Phoenix | Server-side API implementations |
| Mobile | iOS, Android, React Native, Flutter | Native mobile applications |
| Fullstack | Next.js, Nuxt, SvelteKit, Remix | Combined frontend/backend frameworks |
Sources: apps/documentation/src/content/docs/introduction.mdx17-27
The project uses GitHub Discussions as the primary community hub, replacing traditional forums or chat platforms.
Discussion Categories and Their Purpose
| Category | Purpose | Typical Content | Outcome |
|---|---|---|---|
| WIP Implementations | Track implementations under development | "Building RealWorld with Rust + Axum" | Prevent duplicates, enable collaboration |
| Community | Share RealWorld-related content | Performance studies, tutorials, videos | Addition to community resources page |
| Q&A | Technical support | API specification questions, testing issues | Community-provided solutions |
| General | Open-ended discussions | Feature requests, ecosystem ideas | Project direction input |
The invitation to join GitHub Discussions appears prominently in the introduction: apps/documentation/src/content/docs/introduction.mdx15
Sources: apps/documentation/src/content/docs/introduction.mdx15 apps/documentation/src/content/docs/community/resources.md14
The decentralized approach using CodebaseShow provides several advantages:
Benefits of External Registry
Trade-offs
| Aspect | Internal Registry | External Registry (Current) |
|---|---|---|
| Control | Full maintainer control | Relies on external platform |
| Automation | Requires custom tooling | Platform-provided features |
| Searchability | Limited by implementation | Rich filtering and search |
| Historical tracking | Git history | Platform-dependent |
| Barrier to entry | Requires PR approval | Self-service submission |
The current model prioritizes ecosystem growth and discoverability over tight centralized control, enabling the project to scale to 150+ implementations without overwhelming the maintainer team.
Sources: apps/documentation/src/content/docs/introduction.mdx17-27 apps/documentation/src/content/docs/implementation-creation/introduction.md17
Refresh this wiki