UNPKG

@lobehub/chat

Version:

Lobe Chat - an open-source, high-performance chatbot framework that supports speech synthesis, multimodal, and extensible Function Call plugin system. Supports one-click free deployment of your private ChatGPT/LLM web application.

github.com/lobehub/lobe-chat

lobehub/lobe-chat

92 lines (81 loc) • 4.9 kB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
# Directory Structure The directory structure of LobeChat is as follows: ```bash src ├── app # Next.js App Router implementation with route groups and API routes ├── components # Reusable UI components ├── config # Application configuration files, including client-side and server-side environment variables ├── features # Function modules related to business functions, such as agent settings, plugin development pop-ups, etc. ├── hooks # Custom utility hooks reused throughout the application ├── layout # Application layout components, such as navigation bars, sidebars, etc. ├── libs # Third-party integrations (analytics, OIDC, etc.) ├── locales # Internationalization language files ├── server # Server-side modules and services ├── services # Encapsulated backend service interfaces, such as HTTP requests ├── store # Zustand store for state management ├── styles # Global styles and CSS-in-JS configurations ├── types # TypeScript type definition files └── utils # Common utility functions ``` ## app The `app` directory follows Next.js 13+ App Router conventions with a sophisticated architecture using [Route Groups](https://nextjs.org/docs/app/building-your-application/routing/route-groups) to organize backend services, platform variants, and application routes: ```bash app ├── (backend)/ # Backend API routes and services │ ├── api/ # REST API endpoints │ │ ├── auth/ # Authentication routes │ │ └── webhooks/ # Webhook handlers │ ├── middleware/ # Request middleware │ ├── oidc/ # OpenID Connect routes │ ├── trpc/ # tRPC API endpoints │ │ ├── async/ # Async tRPC routes │ │ ├── desktop/ # Desktop-specific tRPC routes │ │ ├── edge/ # Edge runtime tRPC routes │ │ ├── lambda/ # Lambda tRPC routes │ │ └── tools/ # Tools tRPC routes │ └── webapi/ # Web API endpoints │ ├── chat/ # Chat-related APIs │ ├── models/ # Model management APIs │ ├── tts/ # Text-to-speech APIs │ └── ... ├── [variants]/ # Platform and device variants │ ├── (auth)/ # Authentication pages │ │ ├── login/ │ │ ├── signup/ │ │ └── next-auth/ │ ├── (main)/ # Main application routes │ │ ├── (mobile)/ # Mobile-specific routes │ │ │ └── me/ # Mobile profile pages │ │ ├── _layout/ # Layout components │ │ ├── chat/ # Chat interface │ │ ├── discover/ # Discovery pages │ │ ├── files/ # File management │ │ ├── image/ # Image generation │ │ ├── profile/ # User profile │ │ ├── repos/ # Repository management │ │ └── settings/ # Application settings │ └── @modal/ # Parallel modal routes │ ├── (.)changelog/ │ └── _layout/ ├── desktop/ # Desktop-specific routes │ └── devtools/ ├── manifest.ts # PWA manifest ├── robots.tsx # Robots.txt generation ├── sitemap.tsx # Sitemap generation └── sw.ts # Service worker ``` ### Architecture Explanation **Route Groups:** - `(backend)` - Contains all server-side API routes, middleware, and backend services - `[variants]` - Dynamic route group handling different platform variants and main application pages - `@modal` - Parallel routes for modal dialogs using Next.js parallel routing **Platform Organization:** - The architecture supports multiple platforms (web, desktop, mobile) through route organization - Desktop-specific routes are in the `desktop/` directory - Mobile-specific routes are organized under `(main)/(mobile)/` - Shared layouts and components are in `_layout/` directories **API Architecture:** - REST APIs in `(backend)/api/` and `(backend)/webapi/` - tRPC endpoints organized by runtime environment (edge, lambda, async, desktop) - Authentication and OIDC handling in dedicated route groups This architecture provides clear separation of concerns while maintaining flexibility for different deployment targets and runtime environments.