masudrana430/web-test-masudrana430

1. Monorepo shape

Chirp is a pnpm + Turborepo monorepo with three deployable apps and several shared packages. The major runtime boundaries are: apps/api for backend services, apps/client-user for the consumer UI, and apps/client-admin for moderation/admin UI.

2. Backend core

The API server in apps/api is a gRPC service, not a REST API. Request handling is split into gRPC handlers under src/grpc/handlers and business logic services under src/services. The handlers are the transport boundary; services contain the feature logic.

3. Contract-first service layer

packages/proto is the service contract source of truth. Proto files define services such as auth, users, posts, comments, likes, follows, bookmarks, notifications, search, and admin. Generated proto artifacts are consumed by the API and client-side gRPC code.

4. Client-to-server flow

Both frontends are TanStack Start apps with server functions under src/server/functions. Those server functions act as the app boundary: route components call server functions, and the server functions use packages/grpc-client to talk to the API over gRPC. This keeps browser code off the direct backend boundary.

5. Two separate frontends

apps/client-user is the consumer social app with routes for auth, feed, explore, posts, profiles, bookmarks, notifications, and search. apps/client-admin is a separate admin console focused on moderation, audits, reports, users, and post/comment management. They share the same backend and data model but have different UI and authorization surfaces.

6. Authentication and session boundary

Auth is handled in the API via the auth service and in each client via server-side session helpers. The user app has login/register flows; the admin app has a stronger auth gate and admin-specific server auth logic. Session state is kept at the app/server-function layer rather than in shared client state.

7. Domain services and data flow

The backend service layer is organized by domain: posts, comments, likes, follows, bookmarks, feed, notifications, search, users, mentions, and admin. Typical flows are: user action in client route -> server function -> gRPC client -> API handler -> domain service -> SQLite via Drizzle -> response back through gRPC to the app.

8. Persistence layer

Persistence is SQLite, with schema definitions in packages/db-schema and migrations in db/migrations. The API owns database access through apps/api/src/db, and seed data is in apps/api/src/db/seed.ts. The database tables mirror the product domains: users, posts, comments, likes, follows, bookmarks, notifications, reports, and audit logs.

9. Shared UI and types

packages/ui is a shared design system built with StyleX components such as Button, Card, Input, TextArea, Avatar, and loading primitives. packages/shared-types provides common TypeScript types for API/session data. These packages reduce duplication across both client apps.

10. Feature-specific frontend composition

The user app is organized around reusable feature components like PostCard, CommentCard, FollowButton, NotificationBell, and post/comment forms. Routes are file-based and page-specific, while server functions isolate backend calls per feature. The admin app follows the same pattern but with moderation-oriented routes and layout components such as AdminHeader.

11. Infra and tooling

Styling is managed with StyleX tokens in each app and shared UI package. TypeScript is strict and centralized with shared configs under tooling/typescript. Biome handles linting/formatting. Vitest covers unit tests, Playwright covers end-to-end tests, and GitHub Actions runs the test workflow.

12. Operational boundaries

The README documents three local service endpoints: user app on 3000, admin app on 3002, and API on 3001 with a health check. That separation is important for a diagram: the browsers hit the two TanStack Start apps, and only those apps talk to the API backend and database indirectly through gRPC.