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

  • 存数据库比较方便管理,也不会有多少性能损失。除了少部分不用登录的接口,都要在参数中携带 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
    
  • ActiveAdmin 定制化实战 at 2020年07月16日

    代码量越少,人的幸福指数越高。 复杂的逻辑都在 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 这颗树上吊死

  • 微服务如何做聚合接口? at 2020年04月10日

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

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

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

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

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