未使用DRF的Django API与Next.js集成的疑问及潜在问题咨询

1. 是否需要同时运行Django与Next.js服务器？ #

是的，必须同时运行两个服务器才能让完整项目正常工作。Django作为后端API服务器，负责处理数据逻辑、数据库交互等核心业务；Next.js作为前端服务器，负责页面渲染、前端路由处理和用户交互。前端通过HTTP请求调用后端API获取数据，两者各司其职，缺一不可。

如果是生产环境，你可以将Next.js构建为静态资源或服务端渲染产物，部署到静态托管服务或Node.js服务器，同时将Django后端部署到Nginx+Gunicorn这类组合的服务器上，但依然需要确保后端API服务和前端服务都处于正常运行状态。

2. 除CSRF令牌问题外，不使用DRF还会面临哪些挑战？ #

• 序列化与反序列化繁琐：DRF的序列化器（Serializer）能自动完成模型实例与JSON数据的双向转换，还内置数据校验逻辑。不用DRF的话，你得手动在视图里把模型对象转成字典结构，还要自行编写数据校验代码，不仅重复工作量大，还容易出现格式错误。
• API标准化实现成本高：DRF自带RESTful API的标准功能，比如分页、过滤、排序，以及标准化的HTTP状态码返回（如400参数错误、404资源不存在等）。不用DRF的话，这些功能都得从零实现，比如分页要手动计算偏移量、构造分页响应结构；状态码也得手动对应场景返回，增加前端对接的复杂度。
• 身份验证与授权逻辑复杂：DRF提供了Token认证、Session认证、JWT等多种开箱即用的身份验证方式，还有成熟的权限控制类。不用DRF的话，你得自己手动处理Token生成与校验、会话验证，权限判断逻辑也得从头编写，容易出现安全漏洞。
• API文档维护困难：DRF可通过swagger、redoc等工具自动生成API文档，包含接口参数、返回格式等信息。不用DRF的话，你得手动编写并维护文档，不仅成本高，还容易出现文档与实际代码不一致的情况。
• 请求解析需手动处理：DRF能自动解析JSON、表单等多种格式的请求体。不用DRF的话，你得手动从request.body中读取数据，自行解析成可用格式，还要处理编码错误、格式不兼容等问题。
• 异常处理缺乏统一机制：DRF有统一的异常处理流程，能将后端错误转换为标准化的JSON响应返回给前端。不用DRF的话，你得在视图里手动捕获各类异常，构造合适的错误响应，否则前端可能收到模糊的服务器错误信息，难以调试。

内容的提问来源于stack exchange，提问作者Praise Olusomiji