是

做 UI 很好啊

https://github.com/hopsoft/stimulus_controllers/tree/master/controllers/src/prefetch_turbolinks_controller 这个？

https://www.intervue.io/ 这个是竞品？

红宝石送分

这位同学是活在上个时代吗

https://github.com/rubyapi/rubyapi tailwind+Stimulusjs+graphql 的开源项目

thin 都不维护了吧 puma 主流了

大部分选型是立场决定的：

打工的我：赶快前后端分离吧，哪有精力做前端？赶紧分出一部分给专业前端！内耗？老板有钱！

自己做项目的我：全家桶真香

并不是针对你...这种做法挺流行的我知道

你这个累加例子量太小，分页都不需要，当然可以这么做了，稍微正常一点的报表（数量>50w）这么做还是明显感觉到慢的

第二个 join 的例子，直接把部门代码和部门名称都入库就没这问题了

第三个例子，经常见到的一个状况就是这种混合查询拖垮数据库，也不一定需要 ETL 那么重，配置个从库，统计类查询使用从库就可以减轻主库的负担，阿里云上点几下就可以的事

是初恋

网页加速器！！谷歌好多年前有这么一个插件

印象中 apollo 只是一个 graphql 客户端工具集和中间件吧 和 hasura 这种 instant graphql server 还是没有太大可比性

「DB 不容易横向扩展」和「应用服务器容易横向扩展」这个前提有道理，但我观察到的现象就是当这个前提被无限放大之后，很多做法就变味了，比如 sql 的 sum 不用，改用应用里 select 之后再 sum；join 不用，改用应用程序自己实现 join；

然而真正对 DB 伤害大的我发现主要是这三个：

• 表结构设计不合理，查询索引设计不合理
• ORM 使用不当，生成效率低的 SQL 和 N+1
• 架构不合理，OLTP 和 OLAP 混用

之前那些例子本质上都对 DB 没什么伤害，而后面的例子才是 DB 的性能杀手，大概就是「以大多数人的努力程度之低，根本轮不到拼天赋」的意思。

我觉得有点危言耸听了

computed columns 的例子其实只是说明 graphile 有这种能力处理，实际上如果你是一个 BaaS 服务，直接接前端，这个是可以前端自己处理的；如果是作为纯后端 API，中间层的 Rails/PHP 是可以处理的...

如果是排序场景，还可以用 pg 12+ 的 stored column

graphile 这类服务并没有鼓励在 DB 里做应用逻辑，一般都是 EventSourcing 架构，记录的更新抛给 serverless 服务，逻辑在 serverless 里处理。DB 里做的只是简单的 query 和 mutation，这个用 Rails 也要执行的，并且可能生成的 sql 更低效

和 Rails 这种比，其实省掉了 App Server 的费用，当然 graphile 之类服务也是有场景限制的，场景适合的话一定比传统架构吞吐量高出几十倍

数据库很难横向扩展也是有条件的，比如大数据和写入密集型，普通的 web 应用主从 + 读写分离就解决了 80% 的问题，然后还有 citusdb、coackroch，yugabyte。我觉得 DB 不能横向扩展已经是伪命题了

学不动了

额 我前段时间一直调研这类，太多了 还有这个：https://github.com/supabase/supabase

最早的鼻祖算是 postgrest 吧，大部分技术原型都来自那个项目...

hasura 那个 migration 你可以理解为就是一个 online 的 rails migration，导出的 JSON/YAML 其实是冗余，他的这些信息都在 db 里存的。当然我觉得最佳的情况是，可以对每个 schema 修改做记录，像 rails 那样方便 rollback 某个迁移，这个 hasura 界面上我是没看到，要自己手动改回去。

rls 和 dsl 就是 graphile 和 hasura 做权限控制和可见控制的两个实现。

https://github.com/dosco/super-graph 这个我觉得和 rails 集成更友好的一个，我其实想做一个类似的，以 rails engine 方式来用，对于 API 项目开发效率会有很大提升。不一定拿来做 BaaS 服务。

有时间可以找个例子来 因为我 js 也不太熟 也不知道 stimulus 的局限在哪里 但我使用下来感觉还没有什么场景是特别复杂的 至于是不是现代前端思维我不太 care 因为这东西只是一个潮流 就像最开始结构表现行为分离是主旋律 现在也没人提了 现在什么 js compoent,css in js,tailwind 这种 css in html 都是打破了之前的思维方式……

好久没关注 graphile 了 但觉得他的思路一直在 db 层面跑到底 这个受众太窄了 能写 pg function 的开发者太少了 rsl 其实没有 hasura 的 dsl 灵活 metadata 独立我觉得是优点 hasura 也同样导出 db 就可以迁移 他的 metadata 也就是普通的 table

列表渲染为什么麻烦 我还没遇到

我是说造轮子 实现一个 db to graphql 的服务

要不要 clone 一个？

用 apply 可以简化一点儿

我以为是因为我 css 水平不行

这里又不会是瓶颈 优化个啥

bootstrap 审美疲劳了

好惨

他们新的不错 还没有投放到社区

这都死多少年了的框架

没备案吧