Gin-Vue-Admin Development Platform

repository·main·Indexed 12 days ago

https://github.com/flipped-aurora/gin-vue-admin

A full-stack, front-back separated development platform for small to medium-sized projects. It features a layered backend architecture (Model, Service, API, Router, Aggregation, and Plugin layers), JWT authentication, Casbin RBAC, dynamic routing, and automated code generation. The platform includes comprehensive guidelines for frontend implementation using Pinia and Vue, plugin organization, and a structured AI memory layer for managing business requirements and long-term preferences.

Tokens
74.8K
Snippets
155
Records
327
Agent score
98%

What's inside Gin-Vue-Admin

  1. Overview of gin-vue-admin architecture and features

    main

    Project Positioning

    gin-vue-admin is a full-stack management system framework designed with a decoupled frontend and backend architecture. It focuses on providing robust administrative capabilities, including:

    • Permission Control: Built-in RBAC (Role-Based Access Control).
    • Code Generation: Infrastructure for generating code and managing the backend.
    • Extensibility: Support for middleware extensions and a plugin-based structure.
    • API Documentation: Integrated Swagger support.
    • Standardized Communication: Uses a unified response structure for all API calls.

    Technology Stack

    Frontend

    • Core: Vue 3, Vite, Vue Router
    • State Management: Pinia
    • UI Components: Element Plus, UnoCSS
    • Utilities & Data: Axios, ECharts, VueUse

    Backend

    • Core: Go, Gin
    • ORM & Database: GORM, support for multiple databases
    • Security & Auth: Casbin (RBAC), JWT
    • Configuration & Logging: Viper, Zap
    • Caching & Storage: Redis, support for multiple cloud storage providers
  2. Overview of Gin-Vue-Admin Features

    main

    Gin-Vue-Admin is a full-stack development platform based on Vue and Gin. It is designed to accelerate the development of small to medium-sized projects by providing integrated core functionalities:

    • Permission Management: Implemented using jwt and casbin.
    • User & Role Management: Admin can assign roles, permissions, and menu access to users.
    • Dynamic Menus & APIs: Users see different menus and have different API access levels based on their roles.
    • File Management: Supports uploading/downloading to QiniuCloud, Alibaba Cloud, and Tencent Cloud, including chunked uploads for large files.
    • Code & Form Generation: Includes a Form Generator (using @Variant Form) and a Code Generator for basic CRUD logic.
    • Configuration Management: Allows modifying configuration files via the UI (note: this feature is disabled on the online demo site).
    • Pagination: Frontend pagination is encapsulated using mixins for easy reuse.
  3. Overview of Gin-vue-admin

    main

    Gin-vue-admin is a full-stack backstage management system that separates frontend and backend. It is designed to accelerate business development by providing integrated features such as:

    • Authentication: JWT and Casbin-based authority management.
    • Dynamic Routing & Menus: Dynamic menu and API permission configuration.
    • Generators: Form generator and backend CRUD code generator.
    • File Management: Upload/download support for Qiniu, Aliyun, and Tencent Cloud.
    • User/Role Management: Granular control over user roles, permissions, and menus.

    Tech Stack:

    • Frontend: Vue 3, Element Plus.
    • Backend: Gin (Go), GORM.
    • Database: MySQL (5.6.44+) or SQLite.
    • Cache: Redis (used for JWT token recording and multi-login restriction).
    • Config: Viper and fsnotify (YAML based).
    • API Docs: Swagger.
  4. Understand the Frontend-Backend collaboration boundary

    main

    The aiDoc/frontend-backend/ directory serves as the central repository for defining the collaboration boundary between the frontend and backend. It is used to document and enforce standards for:

    • API Ownership & Boundaries: Defining which service owns which endpoints.
    • Request/Response Structures: Standardizing the shape of data exchanged between layers.
    • Field Constraints: Specifying field names and type constraints to ensure consistency.
    • Integration Guidelines: Important notes for debugging and joint testing (联调).
    • Frontend Standards: Rules for code structure, styling, and utility function reuse.

    Developers should consult the specific sub-documents within this directory (such as boundary.md, frontend-rules.md, and component-library.md) to ensure their implementations adhere to the project's architectural constraints.

  5. Understand the server project structure

    main

    The server directory follows a layered architecture designed for scalability and separation of concerns. Key layers include:

    • api: Versioned API endpoints (e.g., api/v1).
    • router: Route definitions and mapping.
    • service: Core business logic implementation.
    • model: Data structures representing database tables, including request (input) and response (output) structs.
    • middleware: Custom Gin middleware.
    • initialize: System initialization logic for components like Redis, GORM, and Validators. Note that functions in initialize/internal are restricted and should only be called by the initialize layer.
    • config: Configuration structures corresponding to config.yaml.
    • core: Initialization of core components like zap (logging), viper (configuration), and the server itself.
    • global: Global objects accessible throughout the application.
    • resource: Static assets, including Excel import/export paths, form generator distributions (page), and code generator templates (template).
    • utils: Utility wrappers, such as timer for scheduled tasks and upload for OSS (Object Storage Service) interactions.
    ├── api
    │   └── v1
    ├── config
    ├── core
    ├── docs
    ├── global
    ├── initialize
    │   └── internal
    ├── middleware
    ├── model
    │   ├── request
    │   └── response
    ├── packfile
    ├── resource
    │   ├── excel
    │   ├── page
    │   └── template
    ├── router
    ├── service
    ├── source
    └── utils
        ├── timer
        └── upload
  6. Understand the web project directory structure

    main

    The web directory follows a standard Vue/Vite structure with specific organization for the gin-vue-admin ecosystem:

    • src/api: API group definitions.
    • src/components: Global reusable components.
    • src/core: Core GVA component package, including config.js (website configuration), gin-vue-admin.js (welcome file registration), and global.js (unified imports).
    • src/permission.js: Route middleware handling permissions.
    • src/pinia: State management using Pinia (replaces Vuex), with modules for dictionary, router, and user.
    • src/router: Route declarations.
    • src/style: Global styles, including element_visiable.scss for overriding element-plus styles.
    • src/utils: Utility libraries such as request.js (API requests), asyncRouter.js (dynamic routing), and dictionary.js (dictionary methods).
    • src/view: Main view components, including layout (page constraints), dashboard, login, and system modules.
    • vite.config.js: Vite configuration file.
  7. Understand the project directory structure

    main

    The repository is organized into several core directories, each with specific responsibilities:

    • server/: Contains all backend code, including routes, APIs, services, models, initialization logic, and plugins.
    • web/: Contains all frontend code, including pages, routing, state management, API encapsulation, utility functions, and plugins.
    • deploy/: Contains deployment assets such as Docker and Kubernetes configurations.
    • docs/: Contains human-readable documentation and design records.
    • aiDoc/: Contains structured context specifically designed for AI collaboration.
  8. Module grouping and naming conventions

    main

    The project organizes capabilities into specific groups. When creating new documentation, use the following naming patterns and group classifications:

    Module Groups

    • system-core: Core project capabilities, primarily located in server/ and web/src/.
    • plugins: Plugin-based capabilities, located in server/plugin/ and web/src/plugin/.
    • deploy: Deployment and runtime capabilities, located in deploy/.

    Naming Suggestions

    Use these filename patterns for new module documentation:

    • system-core.md (for core system updates)
    • plugin-<name>.md (for new plugins)
    • deploy-runtime.md (for deployment/runtime logic)

    Note: Documentation should focus on responsibilities and boundaries rather than implementation details.

  9. Use enter.go to aggregate module entries

    main

    In gin-vue-admin, enter.go files are used to aggregate module entries for a specific layer. This pattern reduces the risk of circular dependencies and provides a unified entry point for other layers to access capabilities via a single group object.

    You should use this pattern when:

    • Adding a new module group.
    • Aggregating multiple Routers, APIs, or Services into a single entry point.
    • Allowing other layers to access current layer capabilities through a GroupApp object.

    Common mistakes to avoid:

    • Importing across layers directly instead of using the enter.go entry point.
    • Declaring the same alias variables in multiple files.
    • Forgetting to register a new module into the Group struct after creating it.
  10. Rules for updating project memory

    main

    To maintain the integrity of the project's structured documentation, follow these rules when updating memory:

    • Business Requirements: When a user proposes a new business requirement, the AI must synchronously update the memory/business/ directory.
    • Granular Updates: When updating memory, only modify the specific memory file and its corresponding index file. Do not rewrite entire summary files, as this avoids the risk of overwriting previous entries.