环境变量问题,需要在 config/deploy.yml
设置
env:
clear:
DB_USER: app
secret:
- DB_PASSWORD
这里设置了的环境变量才会 push 到远程服务器。
反向代理问题,单机情况下 kamal_proxy 可以替代 nginx,去掉 nginx。
kaml_proxy 不需要设置就可以满足 rails 需要。
AI 也需要提问的智慧。我很乐意推荐不好好准备提问的人去问 AI。
主要是网络,好的网络体验大不相同。我有次调试 cloudflare 的边缘节点居然是连到英国,绕地球一圈。
看 @RaySong 有无兴趣搬运?
把图片塞到 job 的参数,小心 redis 内存不够用。
job 的参数是 data:image?不建议参数用太大的对象。把对象保存以后传 id。
basecamp 是用独立的 db 做 cache db。用 db 的好处是缓存周期可以设很长。
我现在写博客主要作为自己外部记忆,顺便给别人看看。
是 Rails cache 的一个实现,类似的可以存 memcache,redis,solidcache 是存到数据库。
Rails 8 刚发布,回归好时机。
Rails 8 的前端方案完善,简化部署配置,减少了依赖服务。要入门和回归的话这就是最好的版本。
Ruby 需要更多布道者👏
docker + devcontainer。
大企业前后端分离的,可以用在管理后台。
暂时没遇到,我之后留意一下。
Stimulus 如果进行了 dom 操作,也需要注意历史恢复的状态。相比之下 Lit 只需要 render 简单多了。
我第一份工作还是 2011 年,当时 Rails 是个时髦的技术。我毕业后半年没找工作鼓捣些开源项目,后来觉得还是要找个工作获得收入。于是看招聘信息,当时一位国内有名的 Rails 布道者的公司在招聘,我就写邮件交了份简历,然后就让我去北京入职了。
Web 组件应该对 Hotwire 很友好,具体是遇到什么问题了?
Hotwire 点赞👍
v0 这个版本号一看就很不靠谱 😂
v1 是 2017 年提的,也过去很久了。
Lit 3.0 是 2023 年发布的,这个时候我才开始认真考虑。
最近实际在项目里面用了感觉可以了,最大的吸引力是它跟 Turbo 兼容。
Web component 已经被主流浏览器支持了。我看了下 caniuse,safari 不支持的只是 is 属性,也就是修改内置元素的能力。现在看来不允许修改是有道理的,各个浏览器内部实现不一样,很难说修改内部元素会产生什么问题。但这个特性不影响 web component 应用。
浏览器 API 的演变就是很缓慢的,通常要落后于第三方框架。但一旦成为标准,其他框架就可以精简一大堆内容。例如 jQuery 和 querySelector,曾经有一个庞大的 jQuery 生态,标准演进后就消亡了。
我不是说 react 会消亡,因为现在有很多应用和生态构建于 react。而是当更多开发者了解 Web component,那么基于 Web 标准构建的组件会越来越多。
怎么我觉得这两篇文章都是推 Web Component 的。
Web Component 胜在可交互性,现在 js 框架互相不兼容,用 react 写的组件要用在 react 组件里面。兼容也不是不行,只是要做很多适配器,估计没人这么用。而 Web Component 可以用在 erb,也可以用在 react。
我正在写一篇博客,Rails 开发者应该拥抱 Web Component。
网络问题。
7 默认也不打包了。
Rails 7 可以选择 sprockets 和 propshaft,Rails 8 默认是 propshaft。
对于 sprockets,确认 manifest.js 里面有:
//= link_directory ../stylesheets .css
那么 app/assets/stylesheets
里面的每个 .css 文件都会单独编译和提供。
例如添加一个 app/assets/stylesheets/page.css
,那么就可以使用 page.css
在布局 app/views/layouts/application.html.erb
里面的 head 预留位置:
<head>
...
<%= yield :head %>
</head>
然后在对应页面:
<% content_for :head do %>
<%= stylesheet_link_tag "page" %>
<% end %>
对于 propshaft,默认 app/assets/stylesheets
目录内的文件都会单独提供,从上面布局部分开始做就行。
Propshaft 文档提到了 https://github.com/rails/propshaft?tab=readme-ov-file#bypassing-the-digest-step
所以用 esbuild 处理也可以。区别是一个默认拆分,选择性打包;一个默认打包,选择性拆分。看自己习惯哪种。
又研究了一下,代码分割也可以在 esbuild 这层做
https://esbuild.github.io/api/#external
不知道会不会跟 asset pipeline 的 hash 文件名冲突,做过的可以分享一下。
我不想每次改代码都让 js 缓存整个失效。codemirror 依赖压缩之后有 230 KB,未压缩前是 800 多 KB。
通过 importmap 提供可以让每个依赖单独缓存。
Rails 增加了一个配置在应用层忽略 SSL,让前面的代理处理,避免重定向:
# Assume all access to the app is happening through a SSL-terminating reverse proxy.
# Can be used together with config.force_ssl for Strict-Transport-Security and secure cookies.
# config.assume_ssl = true
Kamal 2 新增了 kamal proxy 处理 SSL,不用 thruster 处理证书(而且它在代理后,处理不了部分证书校验)。不过 thruster 还可以用来处理文件传输之类,所以在 Rails 8 默认的 dockerfile 内。
Kamal 1 部署一个小时应该是 docker 缓存没做好,而且网络有问题。以前我部署一个应用也是 5~6 分钟。
看下 docker 的 log,应该有错误提示。