我正在参加「掘金·启航计划」
最近想锻炼一下自己的项目开发技术，想着写一个个人博客项目，一方面是温习一下自己前两年工作的开发经验，一方面也想学习一下现在新的技术栈。因为工作时对node.js接触的比较多，而且node.js既可以写前端也可以写后端，于是准备用node.js技术栈写我的博客系统。之前工作时用的编程语言基本都是javascript，而在这个项目中我打算用typescript，相当于在开发项目的过程中也熟悉一门新的编程语言。
目标是做一个前后端分离的博客项目。在后端框架方面，我之前工作时使用的是egg.js。记得上半年的时候我看到egg的开发人员说十月份会出egg的新版本egg3.0，全部用typescript重写。鉴于我之前的经验，也希望能继续用egg开发。现在已经十月份了，我满怀期待地去egg的官网看，确实有个egg3，但只是个补丁性质的改进，并没有发现预想中的ts重写的新版本。找了一下相关通告，结果发现跳票了，真正的ts重写的版本被安排在了egg4，据作者说争取在年前发布。
于是只能去找别的支持typescript的框架。去网上找了一下，发现midway.js是一个不错的选择，它和egg一样都是基于koa，而且完美支持typescript，另外它和egg一样都是阿里团队的作品。于是后端框架的选型就确定下来是midway了。
接下来要找一个连接数据库的工具，也就是ORM。之前工作时使用的是sequelize，但它也同样只支持javascript。去网上寻找支持typescript的ORM工具，发现了TypeORM。于是ORM工具也确定了。
后端部分技术选型相对来说确定还是比较顺利的，并且在两天内写完了基本功能的接口。写完后端基本功能后，准备去确定前端的技术选型。
首先，之前工作时也接触过一点点前端项目，是用umi.js写的。但我只是对其中的一小部分进行修修补补，并不了解从头起一个项目怎么搞。因此我一开始的想法是去网上找一个别人写的博客系统，学习它里面的写法。我先去搜索引擎上搜nodejs博客系统，发现出来的结果并不太好。有一个相对比较好的项目叫iBlog，但是已经很久没更新维护了，我尝试运行也因为版本兼容性问题跑不起来。之后我去github搜blog system，并且选择typescript语言，终于找到一个优秀的博客项目Vanblog，是个新项目，功能非常全面，使用文档也十分完善。于是我将Vanblog作为学习样本。但是感觉项目中的配置本身存在问题，而且开发文档也非常简略，我尝试多次后最终也并没有成功地将完整的开发项目跑起来。不过这个项目里面说它的前端和后端都是用的next.js框架写的，这给我留下来一个较深的印象。
尽管上面说的前端选型过程只有一小段，但实际上我搜索项目+了解项目技术栈+尝试运行差不多花了一个下午的时间。我感觉继续找下去也不会有更好的项目，基本上是白费时间，最终兜了一圈回来，还是准备回归umi.js自己写一个出来，毕竟好歹还算是有那么点基础。
之前公司中的umi项目用的是javascript，但最新的版本umi4已经默认支持了typescript。这正好统一了我这个项目的前后端开发语言，但对于原本就不太熟悉前端的我来说，也加大了我的学习成本。我尝试启动一个umi项目，但是由于语言的改变、版本的更新以及记忆的遗忘，里面的很多东西我都完全不认识了，甚至都不知道怎么绑定表单数据到指定对象，怎么发送http请求，怎么绑定按钮事件等等。没办法，只能一点点自己摸索。这时候我发现umi4的官方教程里面刚好有个写一个blog项目的教程，就对着教程学习。我一开始以为这个教程是教我把前端的界面和发送http请求的代码给实现出来，并不涉及后端和数据库功能。但实际上这个教程竟然做出来的是个完整的可以发布文章并存入数据库的系统，这对我的认知产生了颠覆，在我的认知里umi只是个前端框架，是不可能像后端项目那样连上数据库的。我又仔细研究了一下，具体来说，这部分功能umi使用的是一个叫API路由的功能。官网中的解释如下：
我们的整个博客网站由两大部分构成，一半是运行在浏览器内的前端代码，另一半则是运行在 Serverless Function 中的服务端代码。
为什么需要分成两边呢？这是因为有些代码我们不能让他在浏览器内运行，比如说用户鉴权、串接数据库等等的功能，这些必须作为一个服务然后以 API 的形式暴露给前端页面调用，这个部分可以透过 Umi 4 的 API 路由功能来实现。
这里提到的Serverless概念对我来说是个新鲜事物，这也是umi4提供的新功能。
Umi 4 约定 src/api 目录下存放的 Serverless Function 格式的文件即为 API 路由。这部分路由会打包成不同平台支持的 Serverless Function 产物。
于是我又去了解了一下这方面的内容。教程最后开发出来的博客项目被部署到了一个叫vercel的平台，根据我的理解就是一个专门提供serverless服务的平台，只需要部署一些简单的方法/函数/function（这其中应该会用到它自己的一些构建工具，根据我的理解，每个不同的serverless平台都会有自己的一套工具来部署serverless方法。但对于开发者来说，不需要关心这个过程）就能实现原本需要一个后端项目来实现的接口功能。随着我进一步的了解，发现原来上文中提到的next.js就是vercel团队开发的，这也难怪它既能写前端也能写后端了。
另外这个教程里面还用到了一个新的ORM工具，叫做Prisma。于是又去网上查了一下这个工具，发现评价也很高，并且有人说是相比TypeORM和sequelize是更优秀的工具。
这么多新技术简直让我眼花缭乱。我非常想尝试一下用serverless的方法写，但这代表着我之前写的后端接口都作废了。同时我认识到，饭要一口口吃，事要一步一步做，而且我首要的目标是先把系统做出来，之后再考虑使用新技术重写。因此我最终定下了如下的技术选型：
第一版
-
前端
- Umi4的Ant design pro模板项目
-
后端
-
框架：midway.js
-
ORM：TypeORM
-
第二版
只使用一个Umi项目，ORM依旧使用TypeORM，通过serverless的方式部署到vercel
第三版
尝试用next.js重写，ORM使用Prisma，依然是通过serverless的方式部署到vercel
