这个论坛程序是前一段时间学习koa2的实践作品，技术栈是“koa2+react+mongodb”，已部署到：http://purebbs.com
已经初步实现的功能：
尚未实现功能：
client： https://github.com/maxyou/purebbs server：https://github.com/maxyou/purebbs-server
出于学习的目的，尽量不使用第三方UI库，所以界面比较原始。头次写论坛程序，不足之处太多，欢迎朋友们提出批评建议。
花了70大洋买了域名，开了nginx代理：http://purebbs.com 虽然不一定继续写。
有个点可以提醒你一下...mongoose定义的model有一些钩子, 比如保存之类的...总之, 你可以在特定的情况下增加或者删除elasticsearch里面的索引 然后头像问题, 关键字: 协商缓存 另外一个建议是后端部分可以看看如果换一个框架, 比如nestjs, 你会怎么写..., 因为koa这个东西本身提供得很少, 容易在router或者model里面写一堆业务逻辑... 本地化我没做过, 优秀!
@medmin 你好，很惭愧，我不太懂后端渲染和seo，所以也就未做任何处理，甚至nginx都没开。 我理解的页面刷新之后的过程是：首先页面从服务器加载，其中有个content组件从url中获取“detail/10003”这个参数，然后据此从服务器获取数据，然后就显示了。
老铁，我有一个疑惑，如果直接打开这个url，也是有内容的http://65.49.193.60:3001/#/detail/10003 我有点不太懂，一般来说，SPA对SEO很不友好，原因就是直接粘贴url到浏览器或者手动刷新页面，会导致报错 所以很困扰我 能否大概说一下，为什么你的页面刷新之后还可以有内容？ 你这是做了后端渲染（ssr）还是设置了nginx？或者其他原因？ 这是SPA常见的问题，我目前解决不了，学艺不精，见谅
@bs32g1038 谢谢指导！头像链接这个，更新时更换地址是业界通行做法吗？我需要好好思考一下。我之前是这么写得，后来改成头像地址不变，是因为那个投票功能需要显示投票人头像，可能投票的有好几十人，这个时候根据id去user表查头像地址是不是成本极为高昂？
首先，我觉得总结挺好的。 其次，作为一个过来人，我也想说说自己得看法（吹吹水）。 1、 在学习nodejs web过程中，尽可能选择生态比较成熟得，轮子多的web框架，虽然koa2也是很棒得框架，但相对express来说，生态和资料方面还是少一点。这样能更快的让自己做成 成品，而自发激励继续学习。无论选那个轮子，其中的web知识是固定的。比如说 session，csrf等，只是在代码的实现方式不同。 2、第三方 ui 库的话，在有一定html，css，js的基础上。平时做 demo 什么的，可用可不用。特别少的项目也可不用。在小中项目，能用就尽量用（预估能减少自己写代码的行数，直接上，不要浪费时间重新造轮子，而且也利于团队开发。）。选取前尽量先调研（其他第三方库 同理）。 3、typescript 用在后端，也使用过，但觉得还是不够完美，因为它只能 在编译阶段检测，运行时无法检测。 这很难估量运行时的问题。 4、头像链接 应该放到 user 表中，通过联合查询，这应该才是正解。头像更新，替换 链接。
@maxyou 直接数据库里 模糊查询吧，你还没到那个量级
不知搜索功能怎样做。看过 elasticsearch，看得头大，比较麻烦，难道数据库每一步操作都要同步到 elastic 数据库？或者不需实时更新，过一定时间更新一次？这点没搞明白，请知情同学介绍一下。
实践问题总结：
1， 出于学习目的，从koa2和egg中选了前者，但直接用koa2需要自己去找中间件，找库，找轮子，比较麻烦且难以最优。比如文件上传，日志，session等等，都找了好几个库来试，也不好把握以后扩展是否可以。所以未来做正式项目还得找比较完善的框架，比如nestjs或eggjs之类。
2， 第三方的ui库，如materail-ui或antd多少比较重，特别是前者，对程序主体影响比较大，所以最好尽量少用，初中期不使用，在后期可以考虑。这样非常灵活，以后可以根据选择不同的ui库。
3， 小项目不要使用大第三方库。比如界面的语言切换，考察过相关的i18n库，几乎看不懂，太完善，太庞大，太麻烦了，最后仍然使用redux.store简单处理。这点也说明使用完善的框架比使用koa2要强太多了。
4， 在项目基本完成之后才把前端代码转换为typescript的，所以不全面，且不太地道。从代码查错说效果还是很不错的，以后考虑常用。可能后端才是应该尽量用typescript，毕竟后端出错的危害要远远大过前端出错。以后尽量一开始就使用，后面再改比较繁琐。
5，有的问题不身临其境就感受不到。比如，更换头像后，头像链接将指向新头像的那个新地址，这个小设计给后续编程造成了极大的麻烦。比如头像链接就无法直接存放在post或comment信息里面，因为用户更换头像后之前的头像链接失效。临时的处置是，数据库先查询post及comment，然后aggregate查询user数据表以获取最新头像链接。vote及lineup也一样麻烦。最后采取的方案是，头像链接地址始终不变，新头像替换旧头像时沿用旧头像的文件名。这可能导致客户端头像不刷新，需要加随机数来帮忙刷新，但最后考虑到这不是高频操作，还是reload客户端更为干净。
6，有的功能细节意外的多，比如匿名功能，需要考虑：post与comment的匿名，我的匿名与他人匿名的差异，oauth登录用户的匿名，投票与接龙的匿名，投票人及接龙人的匿名，所有情况下鼠标在头像上悬停时的不同提示，此外匿名时的隐匿信息不应该传递到客户端，必须在服务端就过滤好。如此这样，这工作量是出奇的多。这里说明编码之前的产品需求与设计是很重要的，可以发现工作量意外大的一环。
