0x00 前言
本文是 Django 全栈开发教程的第二篇
目录在这里，已经更新的文章如下
本文需要完成两件事情：
- 第一件事情，回答一个问题：为什么要选择博客系统作为教程而不是别的？
- 第二件事情，简单说说 YaDjangoBlog 的前后端设计。
0x01 为什么是博客系统
在目录评论区，有个读者问：
为什么选择博客系统？而不是别的系统？
一言以蔽之：因为合适。
为什么说合适？
- 第一点：代码量相对合适，业务逻辑大家都很清楚，博客系统说简单也简单，说复杂也复杂，待会我们就可以谈到。简单的例子反而是入门和深入了解 Django 技术栈（而不是设计一个优秀的程序）的最佳案例。
- 第二点：言简意赅，知识点覆盖全面，注意，我们要学习的 Django 技术栈，Django 技术栈，Django 技术栈。不是学高可用架构设计，不是超级复杂系统的设计，不是业务逻辑设计。
- 第三点：日常开发都是见招拆招，依据业务逻辑来，作为开发者，总不能直接把公司的业务代码上传的 Github 上吧？
不妨想想，其实写个博客系统压根就不需要这么麻烦的使用各种组件来给自己的博客系统贴金。那么，我为何还是要『为赋新词强说愁』呢？
答案是『醉翁之意不在酒，在乎山水之间』。通过这个简单的博客，来带大家过一遍 Django 技术栈，具体能学的多好，看个人努力。
当然，借此也吐槽一下，有的人认为，博客系统简单，不就是 Blog / Category / Tag / Comment，有啥可练手的？
其实不然，设计一个博客系统完全可以按照复杂系统的高标准来设计，举例来说：
- ORM 设计：如果我想把 Category/Tags/Comment 变成通用的，即可以对 Blog 进行分类 / 标签 / 评论，对新建的 Product 模型 也可以进行分类 / 标签 / 评论。
- 数据库设计：Category 可能有三到四级子分类怎么办？ Comment 支持评论区互相回复评论。这里的不但要通用，还要用树形结构实现放在一张表里面。
- 全文搜索：Blog 的 content 字段是长文对吧？这个总不能每次搜索都是 like 查询吧？Elasticsearch 怎么搞。
- 缓存和定时任务：PV 和 UV 量总不能每次访问都更新一次数据库吧？为什么不用 Redis 呢？用上了 Redis, 为什么不加上定时任务呢帮忙把 PV/UV 以及点赞数量啥的定期更新到数据库中？
- Celery ：定时任务为啥不用神器 Celery 呢？
- 其他问题：如何对某个接口进行 profile? 如果逻辑比较复杂，是不是要补上单元测试。Django 单实例如何使用多域名？如果加上社交软件认证呢？
那一套太祖长拳从宋兵甲手里使出来，不过是威力平平；
如果是从那乔峰手里使出来，那威力如何？
0x02 前后端分离
前后端分离的必要性
为什么前后端分离？
- 一是需求：简简单单的套模板已经不够了，还要富交互，代码量上去了。
- 二是技术条件成熟：NodeJS 横空出世，使得 JS 成了不仅仅可以在浏览器中运行的语言，成了一门和 Java,Python,Ruby 一样的客户端语言。
- 三是生态：轮子多，这车轱辘如你所愿。
前端的职责变重，代码量则上来了，相应的，模块化工具就自然出来了。
PS: 前后端分离也不是啥新概念，当年开发客户端的不也是前后端分离？ 当然，这里的前后端分离指的是浏览器与服务器的前后端分离。
前后端分离之后，依旧是前端发送请求，后端返回对应的数据。
那么，哪里变了？我认为，主要有两点：
- 前后端流程可以并行开发，即前后端可以同时干活。并且责任明确。
- JS 可以干客户端语言干的事情。
以前，我们都是由美工设计页面，前端开发模板，后端开发 API, 前端再套 API, 再交给后端，后端接过前端的页面套模板。一切看起来是那么的和谐。
但是，就是这么一个看起来一个简单的套模板 / 开发 API，就是一个时间黑洞。
比如说：
- 小美（美工）设计好设计稿，交给小钱（前端）
- 小钱完成前端页面的设计，
- 小侯（后端）开发 API,
- 小钱套 API 后，完成页面设计，并将这个页面交给小侯
- 小侯要做的事情，把小钱的前端页面切分成模板引擎里面的语法，从数据库里面取数据，交给模板引擎渲染，完成套前端页面流程。
接着，产品经理跳出来，指出页面设计中有两个地方需要优化，于是：
大家面临的选择就只有两个：
- 合起伙来，解决掉产品经理
- 大家在反反复复，迂迂回回的需求变更、BUG 解决、调试中，浪费了一些不应该浪费的时间。
那么前后端分离了，前后端的开发就如同客户端开发和服务端开发一样：
- 前端 / 客户端 负责路由，负责什么时候请求什么 API, 该去优化性能就去优化性能。
- 后端 / 服务端 负责折腾后端组件，优化性能。
- 如果调页面，直接找前端去就好了。
- 如果是数据或者 API 有问题，直接找后端就好了。
这么一分，其实职责就好界定了很多，由于修改与优化不会引发两个工种的交叉合作（前端改完，后端套模板）,BUG 率就减少了很多。
PS: 其实职责好界定很多，但不能避免推锅。
由于本博客只关注 Django 技术栈，而所谓使用 JavaScript 前后端通吃的『大前端』, 则不在我们的讨论范围之内。
比起使用一门语言前后端通吃，笔者还是比较倾向于『见人说人话，见鬼说鬼话』, 即使用多种语言，去处理合适的问题的。
前后端分离的成本
前后端分离并不是没有代价的。
对于前端：
- 首次页面 Loading 速度
- JWT 认证请求
- 在特定场景下，有些看起来在多页面开发过程中比较简单的事情，反而比较复杂。
- 需要注意内存的使用率。
对于后端：
- JWT 认证响应，以前是 session 认证，而且 Django 都给你实现好了。现在变了，往往大家使用的都是 JWT 作为认证。
但这些成本相比与节省的开发时间相比都是微不足道的。
当然，我会在本系列的后面抽出一篇教程来专门讲解 Django 内置用户的扩展和前后端分离的登录认证。
0x03 博客系统设计
这个博客最初要解决的问题是：
- hexo 用腻了，想自己写一个简单的博客系统。
- 这个博客要可以导入文章，我不需要编辑器功能，在本地编辑完毕之后，导入数据库就好。
页面构成
- 首页
- 博客列表页
- 博客存档页
- 博客历史页
- 博客详情页
- 关于我页面
模型构成
首先 M 模型层
- PostgreSQL : 博文 / 博文类型 / 博文标签
- Elasticsearch : 博文
- Redis : 每篇博文的阅读量，点赞量
这里需要注意的是：
- 第一：博文类型-博文：1 对多，博文标签-博文：多对多
- 第二：博文中的 content 为文章内容，即可以在 Elasticsearch 中作为全文搜索的字段。具体降到 Elasticsearch 的时候我们会详细说明。
- 第三：博文中的 阅读量和点赞量放在 Redis 里面，由 Celery 的定时任务定期刷到内存中。
再考虑 VT 视图模板层，VT 层，会根据情况 DjangorestFramework 来进行序列化和反序列化。
在设计模型的时候，尽量将涉及到模型的操作放在模型内。
关于如何设计更好的模型，在以后的文章将会讲解，先挖个坑。
架构图
理想环境中，我们的架构图如下：
哦，不好意思，放错图了，是这样的。
但这样的架构应该有专门的人来维护。
于是在人力有限的情况下，本项目的架构图是这样的。
哦，不好意思，放错图了，是这样的。
0xEE. 参考链接
还犹豫啥，Django 前后端分离最佳实践，点赞后，快上车吧
ChangeLog:
- 2018-02-22 开启本文
- 2018-02-27 发布
