多肯定是不多，快乐倒是很快乐

作为一个隔壁的 Elixirist 表示这种语法很 Ruby（能减则减），但清晰度不敢恭维。我现在更看重清晰，因为代码大部分时候是用来读的。

Elixir 版本的例子，匹配都在左边。并且能明确的看到过程中的变量绑定：

def get_user_profile(client) do
  %{id: id} = client.get_json("/current_user")
  %{nick: nick, bio: bio} = client.get_json("/profile", %{id: id})

  %{id: id, nick: nick, bio: bio}
end

个人感觉，如果觉得 pattern 里 %{id: id} 十分繁琐，大可学 JS 弄成 { id } 。Ruby 里面这种语法应该没有歧义。

问一下，Postgres 应该没有 UUID 主键和索引的问题吧？

另外个人感觉迁移主键没有容易的，因为涉及到外键引用，大量迁移关联数据是个挺麻烦的事儿。

我现在一般用 UUID，不用数据库自增长 id 了。自增长 id 容易被猜到临近的资源和数据库实际规模。后期改分布式比较麻烦。优点就是简单和短。UUID v4 方便，但在实际使用中通常觉得太长，尤其是 URL 中使用，而且有些人会有 id 按时间排序的要求。这点应该只有 UUID v5 可以做得到，但它本质上需要开发者自己保证唯一性。

现在互联网应用也很少看到自增长 id，而是用各种字符 id。实际项目中对 ID 一般考虑几点：

1. 是否需要前后端都可以生成
2. 是否需要异构的微服务都方便生成
3. 是否需要中心化的 ID 生成服务，还是每个服务可以自己生成（只要遵循统一的算法）

如果考虑 1，那么只能考虑 JS 也能生成的方式，比如 UUID v4 / NanoID / Hashids 都行。如果考虑 2，那么需要一个有多种主流语言实现的方式，或者雪花算法。这个思路其实很值得学习，基本上是分布式 ID 的通用套路了。另外 MongoDB 的 ID 生成方式也可以考虑。

贴一个 Instagram 的分布式 ID 生成思路。能做到 Postgres 里去，保持数据库生成 ID 的同时效率不低。

喝啥无所谓，关键是喝的时候觉得文思泉涌

然后第二天早上起来把代码删了重写

这就是回表的。因为你有大量索引外的字段。如果只查索引的叫 index only scan。

其实是不是回表无所谓。因为业务拼装的 SQL 可能性很多。一般建立索引是快速缩小范围，然后再回表查。你可以用“哪些字段能让你快速过滤掉大量无关数据”的原则来建立索引。

人在上海或武汉吗？可以加我微信聊聊 (darkbaby123)

呃，团队现在还没到搞办公室政治的规模，等人员多到能拉两个或以上的政党起来，我们再认真研究这个事情……

描述事实而已，这个词成反义词了？

公司也在考虑，可以先聊聊，你加我微信？

是的，上海如果有合适的也招

用是当然用的。只是 Jose 提了一些 更严格的理念 。这些道理放在任何语言都是相通的。

看了这我才知道国外政治正确真不是 B 站玩梗性质的。不过看 原博客 我觉得 Basecamp 做得对，里面说的改变有助于简化组织结构和降低沟通障碍。Jason 提了很多“我们曾经就是 xxx，但后来变成 xxx”这种句式，感觉还是想回到最初那种简单的状态。

explain 的结果不准吧…… 本质上它是 PostgreSQL 为表存储的一套大概统计数据，用来决定 query plan 的。不过这脑洞确实大。

首先我没用过 GraphQL ，但我们团队用过一点点。GraphQL 无法取代 REST，除了它自己有些缺点之外，我觉得还有个原因：它的目标是前端友好，但需要后端买单。相比一个功能完备的 REST API，GraphQL 并没有省多少开发成本。

GraphQL 相对 REST 最大的优点，是一个思考细致涵盖了通用需求的标准，而且因为它受众挺广，各种实现库也很多，不用自己造轮子。但它有些问题是设计决定的，比如前端请求时需要描绘数据的形状，如果前端无法确定数据的形状就很无力（多态或嵌套层级不定的数据）；比如前端对某个资源本来就要获取全部的属性，此时 query 严格定义属性的负担大于好处。

REST 只能算是一种设计风格，具体到复杂的查询，关联数据这些，每个公司都有一套自己的做法（而且不完美）。虽然有一些散乱的 RFC，但都说不上大众标准。更别提库的支持了。但从另一个方面来看，无标准的好处是灵活，你可以结合需求定制适合自己的标准，并且按需添加功能。因为 REST 不强制你必须达到某个最低标准。

REST 对前端的的缺点是太自由了导致没有合适的库。自己写 HTTP 请求，构造数据，解析返回这些都是很重复的事情。要做个通用的 API client 也不是不行，但首先需要定义一个严格的标准。拿返回值解析来说，如果要用一套代码解析出不同类型的数据和关联，那么首先数据结构需要包含资源的类型，哪些属性只是属性，哪些属性是关联，关联的类型是什么……

至于节省数据流量之类的，一般产品上规模的公司才需要操心这些问题。而且嵌套数据无法避免重复 -- 10 个 post 的 author 其实只有 3 人，这种用嵌套就是 10 个 author，把数据拍扁了放在顶层反而更节约。

哦，我知道了。看到备注只有“我是 XX”所以我没加…… 我来加你

你好，是 Ren** 吗？已加

什么叫本质？你自己去试试就知道了。

一种假的 API server，可以通过一些预先编写的规则生成 REST API，这个在前后端约定好接口但还没有具体实现时比较有用。你可以找一些对应的类库，或者用 Postman 和 Swagger 等工具来生成，又或者用 Apiary 这种服务。

想先定义和试用 API 的话，找个 mock server，别这么野路子……

这不是我想表达的重点…… 其实都是两种语言里的不同特性，放一起比较也没什么意义。想了解你可以看看 Elixir。

只拿 Elixir 举例，我个人是觉得函数式的写法更灵活点，最主要的原因是函数不用绑定 this ，所以数据和行为（函数）可以更自由的组合。这也是跟 OO 最大的差别。代价就是因为每次数据和行为组合都要严格指定，代码必然会更多，所谓的更 explicit，比如 user.save() 和 Repo.insert(user) 。

比如有时会碰到“一个数据在不同的业务场景下有不同的关注点” ，在 Rails 里就代表一个 model 有多种不同的功能，它们可以用 concern 实现并混入这个 model，这是一种 mixin 的方式。另一种方式是用 ContextA.do_something(some_model) 的方式来处理，把每个业务场景下的逻辑放在自己的模块里。函数式基本就强制你使用后者了。更复杂的逻辑可能涉及多个函数调用，就可以用 pipe 描述成 params |> ContextA.get_model() |> ContextB.calculate() 这种方式，简化一下函数嵌套。

为什么说链式调用没有 pipe 灵活？因为 obj.do_something 的前置条件就是这个方法必须归属于调用者对象，有时这是一种限制，导致必须用继承或 mixin 来组织代码以达到复用的目的。所有链式调用都可以写成 pipe 的方式，反过来未必成立。

@zzz6519003 @Rei 如果是这样，那确实没有用。反而怎么写都没有 . 简单。从语言层面来说我觉得 Ruby 也没必要关注“给现有功能多一种表达方法”的事情，这就不是语言设计者该做的事情。

@jasl Lisp 据我对 Emacs Lisp 有限的了解，它允许 variable 和 function 用同一个名字，比如变量和方法都叫 foo ，执行再会根据使用场景辨别到底是哪一种。这大概是 Matz 说它们不属于同一个 namespace 的意思。不过这跟 Ruby 有什么关系，以及为什么会影响这个 issue 就不知道了。

语法不管怎么改，含义还是类似 Elixir 的 pipe，把上一个操作的返回值变成下一个操作的某个参数，让代码组合变得更容易。有些场景下 pipe 比链式调用泛用性更高。链式调用的缺点之一是必须把函数混入进某个 object，导致 object 承载多个部分的功能然后变得臃肿。

一开始会，后来…………后来你就习惯了

我过去搞的不太值得学习 (Ruby) ，现在搞的更不值得学习 (Elixir) ，放弃的那个最值得学习 (JavaScript)

倒着看就是最值得学习的语言排行榜？

感觉就是熬夜，饮食不规律，少运动，深夜看手机，并非完全是加班的原因（虽然跟加班肯定有关系）。

我有段时间干一白天，晚上就想熬夜看手机，因为感觉自己累了一天就这么点放松时间还不赶紧利用起来。但其实这样更累。正确的休息方式恰好不是玩手机打游戏。真正让精神放松的方式包括听音乐，冥想，出去散散步（哪怕 10 分钟），小睡一下等。当然这个意识得靠自己慢慢培养了。

首先我更支持平级非嵌套的资源表示方式，即 /animals/:id ，如果要限定 zoo 下的 animals 可以用 /animals?zoo_id=1 。但在有一个唯一标识符 (ID) 的情况下就没必要嵌套了。用户访问他看不到的资源应该通过其他方式来限制。

其次建议 LZ 多了解下 RESTful API 的定义。不是 Rails 的那套 DSL 定义出来路由的才叫 RESTful。嵌套资源也不是所谓的标准风格。理论上只要用统一的 URL 表示资源就可以算是 RESTful 的，就算你用的是 /animals?id=1 。它是一种架构风格但不是规范。而资源有个统一的 URL 的好处是它的常规操作只用修改 method 而不是 URL + method。并且这种统一风格可以让大多数资源受益。

最后说一句，如何设计好的 API 跟内部怎么实现是两码事。

@wootaw 是的，如果按照 LZ 的计算过程描述，其实是有不少中间数据的，比较过程化，这并声明式的 SQL 适合表达的领域。而且如果不考虑存储因素的话化，这个需求本质上就是一个链表计算。因此把计算过程和存储分开思考，解决方案的适用性会广很多。