我已经提交了申诉,看看后续如何。
现在有多名管理员经常看版面,垃圾内容应该不会存在超过 24 小时,如果有漏网之鱼可以在评论区 @Rei
ActionCable 有一个 postgres adapter,不过很少人用 https://github.com/rails/rails/blob/main/actioncable/lib/action_cable/subscription_adapter/postgresql.rb
Rails 里面不用定义,ActiveRecord 是动态读取数据库里面的表信息。你需要为外部数据库的表创建 model,并且设置连接信息,不需要 migration。
搜了个例子 https://stackoverflow.com/a/35492504
你可以跟 python 项目约定好命名规则,id 用 id 整数递增,字段名用下划线,这样就可以很大程度兼容 AR 的约定。然后给 Rails 项目开一个只读权限账号,避免 Rails 项目不小心写入。
Rails 可以同时连接多个数据库。如果 python 子系统的数据没什么兼容问题,可以不导入直接读。
caddy 在申请证书前可以访问后端 api 检查的。
现在放在国外,必要时再开国服。
提醒一下 CF proxy 的灵活模式,CF 到你服务器之间的流量没有加密,数据可能会被中间代理记录。建议用完全模式,在 CF Origin Server 管理页生成一个证书配置到 caddy 上。
https://developers.cloudflare.com/ssl/origin-configuration/ssl-modes/full/ https://developers.cloudflare.com/ssl/origin-configuration/origin-ca/
对于二级域名,你需要在 CF 的 DNS 中添加名称 *
A 记录到你的 IP。
还有你先要确定是用 CF 处理证书还是 Caddy 处理证书,你现在是用 CF 处理证书,不需要看那篇 Caddy 的文章。
CF 处理证书,用 CF proxy 模式,添加自定义域名的时候用 CF API 添加。
Caddy 处理证书,用 CF DNS only 模式,没有 CF 防护,添加自定义域名按上面的文章配置自动处理。
是的,好像 Testing View Partials 也是新加的 https://guides.rubyonrails.org/testing.html#testing-view-partials
看你打算在 Cloudflare 还是 Caddy 处理 SSL。
在 Cloudflare 处理需要用它的 API:Cloudflare for SaaS https://developers.cloudflare.com/cloudflare-for-platforms/cloudflare-for-saas/ 。注意 Cloudflare 和 Caddy 之间也要配置证书加密传输。
用 Caddy 处理可以看这篇文章:用 Caddy 自动申请主域名、子域名和自定义域名的 HTTPS 证书 https://geeknote.net/Rei/posts/2386 。
占用我未测过。不过独立出去后,可以方便调整资源,例如 fly.io 可以设置一个容器一段时间没有请求就停止,有请求再启动。
我依赖的库中没有遇到。
我有个文件(emoji data)高达 418 k……
构建机放境外解决大部分网络问题。
可以通过内网 ip 啊,把虚拟机放在 VPC 里。
你如果指 docker 的 service,那是 docker 自己维护的虚拟内网。如果跨主机用 docker 的网络,就等于要用 docker swarm 了。
Host IP。kamal 没有用 docker 的虚拟子网(无法跨主机)。
turbo 不是为了去 js 化,而是把精力用去真正需要 js 的地方。
js 是 DHH 最喜欢的第二语言。
用 IP。
下次再发这种只有标题没有内容的就移到 nopoint 了。
不涉及密钥的配置可以输出到自定义的 <meta>
标签,然后用 js 在前端读。
Note that the second argument populates the array with references to the same object.
第二个参数传的是引用,意味着第一层数组的每一项都指向同一个 array 对象。
可以混用,一部分打包一部分不打包。如果有洁癖想要完全不打包,就把编辑器独立一个项目打包,就好像 trix editor。
取决于 app server 实现,如果是 puma,我没仔细研究,但我看到了线程池,按我理解是复用的。
访问结束后 current 清理了吗?没清理这个 thread 处理的下一个请求就能访问。
Rails 提供了 Current Attributes 可以帮忙每个请求之后清理值。
https://api.rubyonrails.org/classes/ActiveSupport/CurrentAttributes.html
没有。
第一次见这样写的,如果让我 code review 会驳回,写得简单点。
我没有用过 Django,单从文档看,Django 对前端技术不持立场,开发者根据自己的情况选择前端技术;而 Rails 创始人 DHH 强烈推荐全栈开发,默认包括一个叫 hotwire 的从网页到移动端的前端框架,当然如果不想用 hotwire 也可以选择集成其他“主流”的前端技术。
Rails 7.1 发布 Hacker News 上有一些多框架使用者的评论,可以看一下 https://news.ycombinator.com/item?id=37787130
选择无聊的技术 https://boringtechnology.club/
应该部署一个 demo。
我觉得 Ruby on Rails 的开发效率优势来源于:
ORM 只是 Rails 其中一个优势,且不说我不觉得其他语言的 ORM 追上了 Rails,Rails 还有很多优于其他框架的地方。
例如 Turbo Stream Broadcast 是一个杀手锏功能,让我非常容易开发即时更新的功能。要实现这个功能必须整合数据库、消息队列、前后端通信、前端更新这整个技术栈。少数全栈框架,例如 laravel、Phoenix 也有类似的功能。
过去几年前后端分离盛行,能体会全栈开发效率的人变少了。现在 next.js,remix 等框架又开始往全栈方向回摆,因为有些功能就是全栈更有效率。目前这种技术回摆导致了一些混乱,不断有人抱怨 RSC 难以理解。
我很庆幸 Rails 是一个成熟的全栈框架,让我远离这些混乱,只需专心开发应用。所以是的,我认为 Rails 在 2023 年仍然有效率优势。