Skip to content

Prawirdani/hono-react-monorepo

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

5 Commits
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

Hono + React Monorepo with Turborepo 🚀

This is an example fullstack monorepo project powered by Turborepo, combining a Hono API backend and a Vite-React web frontend.

💡 Why Monorepo Approach?

This monorepo setup is designed to maximize developer experience, type safety, and scalability for fullstack TypeScript applications.

1. Clear Project Boundaries

  • apps/api is the backend (can run independently).
  • apps/web is the frontend (can be deployed separately).
  • packages/ contains all shared logic and contracts.

2. Fullstack Type Safety

By centralizing types and schemas in packages/model:

  • Backend and frontend always agree on data shapes.
  • Zod ensures runtime validation, while TypeScript ensures compile-time safety.
  • Fewer bugs due to mismatched API contracts or unexpected input.

3. RPC-Style Simplicity with Hono RPC

Instead of manually handling REST contracts or managing complex API clients:

  • Thanks to Hono RPC, you no longer need to manually write fetch functions.
  • You define input/output schemas once using Zod.
  • Backend automatically exposes type-safe endpoints.
  • The frontend gets an auto-generated client that knows all endpoints, arguments, and return types.

4. Monorepo with Turborepo

Using Turborepo brings:

  • Fast builds and caching — only rebuild what’s changed.
  • Easier code sharing — reuse models, utils, and types between apps.
  • Unified dependency management and development workflow.

Notes

By default, this monorepo is structured so that:

  • When the React app (apps/web) is built, the output is placed to the public/ folder inside the api app.
  • The Hono API is configured to serve files from public/, allowing it to serve both API and SPA.

Benefits of This Approach

  • You only need to deploy the apps/api folder, as it contains:
    • The API logic.
    • The built frontend served from public/.
  • This simplifies deployment to Docker, serverless platforms, or any compute unit — no separate frontend hosting needed. This design offers a smooth development and deployment workflow, especially when you want to ship everything in a single compute unit.

💡 Customizable: While this setup is optimized for monolithic deployment, you can easily adapt it to your infrastructure. For example:

  • Deploy React separately (e.g., on Vercel, Netlify).
  • Serve only the API from apps/api (e.g., via Cloudflare Workers or AWS Lambda).
  • Use CI/CD to control how build outputs are copied and deployed.

🧪 How to Run

This is a minimalistic fullstack example (a dead simple Todo app) using an in-memory array as the data source — no database connection required.

  • pnpm dev
    Runs both the API and React apps in development mode.
  • pnpm build
    Builds the React app and API. The React build output will be placed inside apps/api/public.
  • pnpm start
    Starts the API server, which also serves the built React app.

❗Known Issues

  • Avoid defining path aliases in the api project If you do, type inference in the web app (when using the shared Hono RPC client) may break and fall back to any.

About

No description, website, or topics provided.

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published