CASE STUDY / MEDIA PLATFORM
MovieFy
01 / PRODUCT SCOPE
为什么电影应用需要两套体验
MovieFy 同时服务希望发现、观看和评价电影的用户,以及需要维护电影、演员、媒体文件和评论数据的管理员。项目的核心挑战不是单独完成一个电影列表,而是围绕同一套内容模型组织两种信息层级:用户需要流畅的发现与观看体验,管理员则需要能够承载复杂关联字段和文件上传的内容工作台。
- 在同一套电影、演员和评论数据上组织用户端与管理员端体验
- 通过组合式表单处理电影元数据、演员关联和媒体文件上传
- 支持搜索、视频播放、评分评论、相关推荐和多语言展示
- 在明暗主题、移动端布局和复杂后台表格中保持一致的交互体验
02 / MOVIE EXPERIENCE
一部电影如何从内容管理走到用户观看页面
- 01
Discover
首页通过 Hero Carousel、最新上传和按 Genre 的高评分列表帮助用户发现电影。
- 02
Search
用户通过标题搜索电影,Search Context 结合防抖逻辑减少重复请求并展示结果状态。
- 03
Explore
电影详情页集中展示视频、剧情、导演、编剧、演员、类型、语言、上映日期和相关电影。
- 04
Review
登录用户可以提交星级评分,查看电影评论,并编辑或删除自己的评论。
- 05
Operate
管理员通过 Dashboard、Movies、Actors 和 Search 管理电影、演员、海报、视频及内容状态。
03 / ENGINEERING DECISIONS
代码中真实存在的前端与全栈设计
- 01
用组合式表单承载复杂电影数据
实现MovieForm 使用 React Hook Form 和 Zod 管理电影标题、剧情、Genre、标签、导演、编剧、演员、上映日期、语言、状态以及海报和视频文件。
价值把一个容易失控的后台表单拆成可验证的字段和可复用的选择器,让创建与编辑共享同一套交互基础。
- 02
用防抖搜索连接演员关系
实现LiveSearch、LiveSearchCast 以及 DirectorSelector、WriterSelector 为导演、编剧和演员提供实时搜索、键盘导航、多选展示和重复过滤。
价值管理员不需要在长列表中手动查找 ObjectId,可以在内容录入过程中直接建立电影与人物资料的关系。
- 03
将用户端与管理员端作为两种产品体验
实现App 根据认证用户角色切换普通用户路由与 AdminNavigator;用户端围绕发现、播放和评论组织页面,后台则围绕 Dashboard、Movies 和 Actors 组织操作。
价值两类用户拥有不同的信息层级、导航和操作密度,同时共享电影、演员和评论 API。
- 04
把媒体上传纳入内容发布流程
实现后端使用 Multer 接收图片和视频,再通过 Cloudinary 保存 URL、public ID 和响应式海报地址;前端在表单中提供文件类型、大小和上传状态反馈。
价值电影内容不再只是文本 CRUD,而是把海报、视频、CDN 资源和元数据作为一条完整的发布链路处理。
- 05
通过 Context 组织跨页面状态
实现AuthProvider 负责登录状态和 Token 恢复,MoviesProvider 管理电影分页数据,SearchProvider 管理搜索结果,ThemeProvider 持久化明暗主题。
价值将跨页面共享的认证、搜索、电影列表和主题状态集中到明确的边界中,降低导航切换时的重复处理。
- 06
用聚合查询批量计算评分
实现MongoDB 聚合负责平均评分、评论数量、相关推荐和高评分电影;getAverageRatingsMap 将多个电影的评分统计合并为一次查询,避免列表场景中的 N+1 读取。
价值保留 MongoDB 文档模型的灵活性,同时为首页榜单和相关推荐建立更可控的数据访问路径。
04 / CURRENT BOUNDARIES
后端和状态边界仍需继续收敛
前端产品体验和核心内容流程已经形成完整骨架,但认证安全、数据一致性和错误契约仍是下一轮工程化重点。
- 高优先级
JWT 存储和生命周期仍需加强
当前前端将 JWT 保存在 localStorage,后端签发 Token 时没有明显的过期时间、刷新和撤销机制。下一步应评估 HttpOnly Cookie、短期 Access Token 和 Refresh Token Rotation。
- 高优先级
邮箱验证状态尚未真正约束评论接口
项目实现了 OTP 邮箱验证和 isVerified 字段,但评论控制器中验证用户状态的检查仍是注释代码,因此不能将评论描述成已严格限制给验证用户。
- 中优先级
评论与电影引用更新缺少事务边界
新增和删除评论会分别更新 Review 文档与 Movie.reviews 数组,但当前没有 MongoDB Session 事务或唯一索引来兜底并发重复评论和部分失败。
- 中优先级
错误契约和参数状态码仍不统一
部分校验错误以 JSON error 返回但仍使用成功状态码,JWT 校验异常也需要进一步映射为明确的认证错误;前端目前主要通过 Toast 消费字符串错误。
- 中优先级
前端服务端状态和搜索状态仍有简化实现
当前使用多个 Context 和模块级分页、debounce 变量维护状态。数据规模扩大后,可将服务端状态迁移到 React Query,并把搜索和分页状态同步到 URL。
05 / NEXT ITERATION
下一轮应该怎么做
- 01
将 JWT 改为带过期和刷新策略的安全 Cookie 方案,并补齐 Token 撤销能力
- 02
在评论接口真正校验邮箱验证状态,并增加 owner + movie 的唯一约束
- 03
使用 MongoDB Session 事务保证 Review 与 Movie 引用的一致性
- 04
统一 4xx/5xx 错误响应、错误码和前端多语言提示,并补充请求级日志
- 05
将电影、搜索和分页数据迁移到 React Query,增加核心用户与管理员流程的端到端测试