在作死的道路上狂奔, 一骑绝尘.

存数据库比较方便管理，也不会有多少性能损失。除了少部分不用登录的接口，都要在参数中携带 login_key，然后在 before_action 中验证 login_key 是否存在。登录相关的接口调用 SessionKey.create_with。

login_key 不必校验唯一性，用 uuid 生成，重复的概率可以忽略不计，省去一次 SQL 查询。数据表里加上 user_id 索引和 login_key 前缀索引，索引长度为 7 应该够用了。

class SessionKey < ApplicationRecord
  attr_accessor :login_key, :user_id

  def self.create_with(user:, relogin_flag: true)
    SessionKey.where(user_id: user.id).delete_all if relogin_flag
    SessionKey.create!(user_id: user.id, login_key: SecureRandom.uuid)
  end
end

代码量越少，人的幸福指数越高。 复杂的逻辑都在 API，对后台的要求只是增删改查，要求上不高。 如果是 ERP 那种重后台系统，倒是可能不会会心一笑。

README 里说了 You must use field method to statement the setting keys, otherwise you can't use it.

不支持动态定义方法，它只是对声明的 key 进行重新赋值

移动端评论列表的间距好大，可以优化下，最新评论高亮的进入退出效果可以去掉，有点视觉障碍

希望后面的版本把 find_by 也去掉，改成 Model.where(field: [condition]).find

这个希望难以实现。find_by 是 rails 4 新增的，可以考虑降级到 rails 3

作为一名菜鸟，千万别在项目里这么写，不然会被打死。rubocop 了解下

楼主是把 docker 当 virtual machine 用了吗？ 反面教材，有大佬出来驳斥一番不。

Crystal 了解一下，不要在 Ruby 这颗树上吊死

增量主要是考虑小程序需要与 APP 保持数据同步, 而 APP 本身又可以离线使用.

聚合接口更多是从性能上考虑的, 由于 APP 进一次首页需要调用 N 个接口, 故他们想要在一个接口里完成这些数据拉取操作. 他们也认为这样编程更容易. 目前已经是 http1.1 的长连接

这个报表服务本身是后台管理系统. 提供了少数接口用来在 APP 里做周报,年报的生成, 实时性要求不高, 且是低频请求. 故不会拖垮整个服务.

还有另外的报表服务面向内部运营人员, 用 Python 的 superset 做数据可视化.

应该会考虑在网关做, 利用原有微服务的接口代码. 如果在报表服务做, 可能就不算微服务了, 好不容易把后台和接口拆分开来