最新

一个不受欢迎的观点：为了在代理自主性和人类参与之间保持平衡，我认为谷歌不应该修改其核心搜索基础设施以适应代理。这样做，无论是从质量还是信任的角度来看，都会导致崩溃。它们目前的状态，足以让它们维持业务。

在过去的几个月里，我一直在开发 Yulin，这是一个 Node.js 的 AWS 模拟器。它在与您的测试相同的单个进程中模拟 AWS 服务和状态，并且还可以通过 localhost 为本地开发提供模拟服务。它的概念与 LocalStack 类似，但采取了截然不同的方法，避免使用容器，将所有内容保留在一个进程中，您可以在调试器中单步调试。

我喜欢复古开发中的限制。在用 PICO-8 构建游戏时，我开始对它如何将数据打包到虚拟卡带中的方式产生了兴趣。我深入研究了隐写术，并开始思考：我能否将同样的逻辑应用于内容管理系统？我们真的需要所有这些臃肿的东西来托管一个微型博客吗？ Minilith 是一个无数据库的 CMS，其整个状态（文章、页面和设置）被压缩并直接存储在一个 256x256 的 PNG 文件的像素中。 Minilith 零依赖。没有 Node，没有打包器，也没有外部数据库。它完全依赖浏览器 API 来压缩、保护和直接从图像渲染网站。 Minilith 架构生命周期 与传统的后端和数据库不同，流程如下： 1. **载荷创建**：编辑器数据（JSON）使用私钥签名，并使用浏览器原生的 deflate 算法进行压缩。 2. **注入**：使用隐写术将压缩后的比特注入图像的 RGB 通道。在 IEND 标记之前注入一个原始的 tEXt 块来封装提取脚本，将图像变成一个可执行的 polyglot。 3. **分发**：结果是一个单一的图像文件。它可以直接推送到 Cloudflare KV，也可以本地下载。 4. **提取与渲染**：客户端加载器获取图像，将其绘制到隐藏的画布上，提取比特，验证签名和视觉指纹，然后运行解压缩后的载荷。 由于整个数据库只是一个图片，部署和可移植性极其简单： * **Cloudflare Edge**：直接从编辑器发布到 Cloudflare KV，覆盖单个键值对即可实现即时更新。 * **自托管**：从编辑器生成一个 .zip 存档，并在任何基本 Web 服务器上托管。 * **离线可移植性**：编辑器使用服务工作线程。一旦您访问过编辑器一次，它就会被缓存。您可以完全离线地查看、编辑和生成新图像。 明显的缺点是激进的图像处理和优化会破坏 polyglot 逻辑和数据。（不过有趣的事实是：通过 iMessage 发送原始图像可以保留载荷） 代码是实验性的，链接的文章是我对该过程的架构分解。我很乐意收到反馈，并听取您的想法和建议。