Django应用开发通用惯例：直接访问后端还是调用API完成CRUD操作？

两种主流方案的适用场景 #

• 服务端直接渲染（也就是你说的直接访问后端的方式）：适合交互简单的传统多页面应用，是Django原生支持的标准实现。直接通过视图函数/类视图调用ORM操作数据库，把数据注入HTML模板后直接返回给前端，开发流程短，不需要额外维护接口层，小型工具类项目用这个方案的团队很多。
• 调用API实现CRUD：适合前端交互复杂、有局部刷新/动态加载需求，或者未来有对接多端（小程序、APP等）计划的项目，是目前中大型项目的行业通用惯例。一般配合Django生态的Django REST Framework（DRF）开发RESTful接口，前端通过AJAX请求调用接口完成数据增删改查。

高并发场景的规范选型建议 #

如果你预期项目会承载大量用户访问，优先选择调用API的前后端分离方案，性能和可扩展性优势远高于传统服务端渲染：

• 静态资源和接口可拆分部署，HTML、JS、CSS等静态文件可以直接托管到CDN，源站请求压力可降低60%以上，用户访问延迟也会大幅缩短
• 接口可以单独做精细化缓存优化，针对高频查询类接口用Redis做数据缓存，能够大幅降低数据库的查询压力，缓存粒度比服务端渲染的整页/片段缓存灵活很多
• 后续扩容更方便，接口服务可以单独水平扩容多实例部署，不用和前端渲染逻辑耦合，迭代和运维成本更低

对应方案的规范实现注意事项 #

如果选择API方案：

• 用Django REST Framework做接口开发，是Django生态下的标准API开发工具，序列化、权限校验、限流、分页这些常用能力都有官方封装，不需要重复造轮子
• 接口设计遵循RESTful规范，GET对应查询、POST对应创建、PUT/PATCH对应更新、DELETE对应删除，后续维护和对接成本极低
• 提前配置接口频率限流规则，避免恶意请求或者爬虫打垮服务

如果你的项目确实是交互极少的内容展示类项目，也可以选择服务端渲染方案，需要做好这些优化：

• 启用Django自带的缓存框架，搭配整页缓存、片段缓存减少数据库查询次数
• 静态资源不要走Django本身的静态资源服务，单独托管到CDN

内容的提问来源于stack exchange，提问作者Pedro Kleiz