Building a WeChat Mini Program Activity Management Platform from Scratch (Part 1): Architecture Design and Technology Selection

This series consists of 7 articles, fully dissecting the technical implementation of a WeChat Mini Program activity management platform. It covers five major tool modules: event registration, service booking, activity relay, entry/exit registration, and queue number calling. From architecture design to code details, it walks you through the entire process of a complete project.

---

Why Build This Project?

In scenarios such as community operations, educational institutions, property management, and store operations, "information collection" is a high-frequency, essential need. Organizers often face these pain points:

• WeChat group relay messages flood the screen, and statistics rely entirely on manual counting
• Excel files are passed back and forth, leading to version confusion and data loss
• Bookings rely on manual coordination, prone to scheduling conflicts and overbooking
• Entry/exit registration uses paper signatures, with illegible handwriting and no traceability

Although survey tools on the market can solve some problems, their functions are generic and not vertical enough; users still need to jump to other pages to view results after filling them out.

Shubu Booking Registration Assistant is a WeChat Mini Program born to solve these problems — create an activity → generate a QR code → scan to fill in → automatic backend summary, completing information collection for an event in 10 seconds.

---

Five Major Tool Modules

The project revolves around 5 core tools, each corresponding to an independent scenario:

Tool	Scenario	Core Capabilities
Event Registration	Community events, training lectures, team building	Custom form fields, participant limits, whitelist verification, on-site check-in
Service Booking	Clinic appointments, beauty salons, meeting rooms	Time-slot booking, quota limits, date range selection
Activity Relay	Group buying relays, group joining, queued registration	Support for +1 person, custom fields, real-time sorting
Entry/Exit Registration	Community access control, visitor management, attendance	Entry/exit type distinction, approval workflow, QR code registration
Queue Number Calling	Barbershops, government service windows, after-sales service	Real-time number taking, automatic calling, pause/resume

The five tools share the same user system, notification system, and review process, but their respective data models and business logic are completely independent.

---

Technology Stack Selection

Frontend: Native WeChat Mini Program + Vant Weapp

Choosing native development over uni-app or Taro for three reasons:

1. Performance First: The Mini Program itself runs in a constrained environment; native development has no additional compilation layer or runtime overhead.
2. API Follow-up: New WeChat APIs are available immediately, without waiting for framework adaptation.
3. Moderate Project Scale: With 24 pages, native development is fully manageable.

The UI component library chosen is Vant Weapp, which is lightweight, has a unified design specification, and can be introduced on demand without increasing package size.

Backend: Node.js + Express + Sequelize + MySQL

Technology	Version	Selection Reason
Express	4.18	Lightweight and flexible, rich middleware ecosystem
Sequelize	6.37	Mature ORM, supports model-first design
MySQL	8.4	Mature and stable, native support for JSON type
JWT	jsonwebtoken	Stateless authentication, suitable for Mini Program scenarios

Koa or Nest.js were not chosen because the project already has a large accumulation of Express middleware, making Express's learning cost and migration cost lower.

Auxiliary Services

• Redis/ioredis: Cache layer (optional, degrades to in-memory cache)
• sharp: Image compression processing
• multer: File upload
• winston: Log management (daily rotation)
• node-schedule: Scheduled tasks
• nodemailer: Email notifications
• PM2: Process management + daemon

---

Project Directory Structure

Frontend

baomingyuyue/
├── app.js              # App entry, silent login + notification badge
├── app.json            # Page registration + TabBar configuration
├── app.wxss            # Global styles (Tailwind-style utility classes)
├── config.js           # Global constants (BASE_URL, pagination, TabBar index)
│
├── assets/             # Static resources (TabBar icons, tool icons)
├── components/         # Custom components
│   ├── login-popup/    #   Login popup
│   └── privacy-popup/  #   Privacy agreement popup
│
├── pages/              # Page modules
│   ├── index/          #   Home (TabBar #0)
│   ├── manage/         #   Manage (TabBar #1)
│   ├── create-select/  #   Create (TabBar #2)
│   ├── notification/   #   Notifications (TabBar #3)
│   ├── profile/        #   My Profile (TabBar #4)
│   ├── registration/   #   Event Registration (create/detail/register/checkin)
│   ├── booking/        #   Service Booking (create/detail/book)
│   ├── chain/          #   Activity Relay (create/detail/join)
│   ├── entry-exit/     #   Entry/Exit Registration (create/detail/register)
│   ├── queue/          #   Queue Number Calling (create/detail/ticket)
│   ├── admin/          #   Admin Review
│   ├── feedback/       #   Suggestions & Feedback
│   └── templates/      #   WXML reusable templates (field-render)
│
└── utils/              # Utility modules
    ├── request.js      #   HTTP request wrapper
    ├── api.js          #   API function collection (40+ interfaces)
    ├── auth.js         #   Login state management
    └── util.js         #   Utility functions (date, validation, state management)

Backend

src/
├── models/          # Data model layer
├── modules/         # Business modules
│   ├── auth/        #   Authentication module
│   ├── wechat/      #   WeChat related
│   ├── toolkit/     #   Core: 5 major tools + notifications + feedback
│   ├── member/      #   Membership system
│   ├── system/      #   System management
│   └── common/      #   Common services
├── routes/          # Route aggregation
└── shared/          # Shared middleware and utility functions

---

Database Design Overview

Core Idea: Unified Activity Table + JSON Extension Fields

Common fields for the 5 tool types (title, description, status, creator, etc.) are placed in a unified activity table, while tool-specific fields are stored in an extra JSON column. This way, adding a new tool type does not require adding fields or creating new tables.

The core fields of the activity table include: activity ID, tool type (distinguishing the 5 tools), title, description, cover image, status, creator information, extra JSON extension field, and creation and update times.

Example extra content for each tool:

// registration: registration form fields, participant limit, whitelist
{ "fields": [...], "maxParticipants": 50, "accessMode": "whitelist" }

// booking: date range, time slot configuration
{ "start_date": "2026-07-01", "end_date": "2026-07-31", "time_slots": [...] }

// chain: custom fields, deadline
{ "customFields": [...], "deadline": "2026-08-01" }

// entry-exit: registration type, approval switch
{ "registerType": "both", "requireApproval": true }

// queue: number segment prefix, current number
{ "prefix": "A", "currentNumber": 0 }

Participation Record Tables

Each tool has an independent participation record table, linked by activity ID:

Tool	Record Use	Core Information
Event Registration	Registration records	Custom field values (JSON), status, check-in time
Service Booking	Booking records	Date, time slot ID, time slot label
Activity Relay	Relay records	Sort number, +1 count, custom field values (JSON)
Entry/Exit Registration	Entry/exit records	Type (entry/exit), approval status
Queue Number Calling	Queue tickets	Ticket number, queuing status

---

Activity Status Lifecycle

From creation to completion, an activity goes through the following status flow:

draft
  ↓ submit for review
pending_review
  ↓ admin action
  ├── approved → active
  └── rejected → rejected
                   ↓ resubmit after modification
                   pending_review
active
  ├── manually closed → closed → reopen → active
  ├── end time reached → ended → edit and extend → pending_review → active
  └── queue paused → paused → resume → active

Key design point: The ended status is automatically detected by the backend. Each time activity details are requested, the backend checks if an active status activity has passed its end time; if so, it is automatically marked as ended, without the need for scheduled tasks.

---

HTTP Request Wrapper

The frontend has a unified wrapper for wx.request. All API calls go through request.js for unified handling of authentication headers and error codes:

• Automatic Token Injection: Each request automatically reads the Token from local storage and adds it to the Authorization request header.
• Automatic 401 Login State Clearing: Upon receiving a 401 response, the local Token is automatically cleared, guiding the user to log in again.
• Unified Error Prompts: Non-200 responses automatically pop up a Toast with the error message.

On this basis, the API layer defines 40+ business functions, each corresponding to a backend interface. Frontend pages only need to call semantic function names (like submitRegistration, getActivityDetail).

---

Backend Response Specification

The backend uniformly uses a response formatting class to handle all HTTP responses:

// Success response
{ "code": 200, "msg": "Operation successful", "data": { ... } }

// Paginated response
{ "code": 200, "msg": "Query successful", "rows": [...], "total": 42 }

// Failure response
{ "code": 500, "msg": "Error message" }

Combined with a field name conversion middleware, snake_case fields from the backend model layer are automatically converted to camelCase when returned to the frontend, so the frontend does not need to do any key name conversion.

---

Authentication System

The project adopts a dual-role authentication:

Role	Acquisition Method	Applicable Scenario
Admin	Account/password login	Backend management system
Mini Program User	WeChat silent login	Mini Program frontend

The two sets of Tokens use different signing keys and expiration strategies, without interfering with each other.

Login flow on the Mini Program side:

Page onLoad → silentLogin()
  → wx.login() to get code
  → Call backend login interface
  → Backend calls WeChat interface to exchange for openid
  → Automatically create/update user record
  → Return JWT token
  → Store in wx.Storage

The user is unaware; they are logged in as soon as they open the Mini Program.

---

Shubu Booking Registration Assistant Mini Program Screenshots

---

Summary

This article introduced the overall architecture and technology selection of the project. Review of core design decisions:

1. Unified Activity Table + JSON Extension: One table carries 5 tools, with strong extensibility.
2. Native Mini Program Development: Prioritizing performance and flexibility over cross-platform capability.
3. Express + Sequelize: A mature and stable technology stack, reducing maintenance costs.
4. Automatic ended Status Detection: Avoiding the complexity of scheduled tasks.
5. Dual-Role JWT Authentication: Independent token systems for admins and Mini Program users.

The next article will delve into the implementation details of the Event Registration Module, including the design of the dynamic form engine, pitfalls with WeChat checkbox non-responsiveness, whitelist verification, check-in logic, and more.

---

Series Table of Contents:

1. Building a WeChat Mini Program Activity Management Platform from Scratch (Part 1): Architecture Design and Technology Selection (This Article)

1. Building a WeChat Mini Program Activity Management Platform from Scratch (Part 2): Event Registration — Custom Forms, Whitelist, and Check-in (Coming Soon)

2. Building a WeChat Mini Program Activity Management Platform from Scratch (Part 3): Service Booking — Time-Slot Booking Quota Limits and Time Parsing (Coming Soon)

3. Building a WeChat Mini Program Activity Management Platform from Scratch (Part 4): Activity Relay: A Relay System Supporting +1 Person and Custom Fields (Coming Soon)

4. Building a WeChat Mini Program Activity Management Platform from Scratch (Part 5): Entry/Exit Registration and Queue Number Calling: Technical Implementation of Two Real-Time Scenarios (Coming Soon)

5. Building a WeChat Mini Program Activity Management Platform from Scratch (Part 6): Common Capabilities: Dynamic Forms, QR Code Generation, Sharing Mechanisms, and State Management (Coming Soon)

6. Building a WeChat Mini Program Activity Management Platform from Scratch (Part 7): Admin Backend: Review System and Data Management Practices (Coming Soon)

Finally, attached is the finished Mini Program product; you can scan the code to take a look.