为什么我从来没有为一个拥有290+计算器的网站 建立一个后端,我运行计算.at,一个拥有290+在线计算器的自由网站 ——按揭支付,BMI,单位转换,百分比,那种东西。
没有账号系统 没有分析像素追逐你 根本没有后端 每一次计算都在浏览器中运行,用你看到的同一页上的平版JavaScript计算.
这听起来就像一个“只是数学”的站点的明显选择, 但这并不是我开始的默认, 从它中产生的一些决定 比我预期的更重要—— 一个是工程, 一个是SEO。
反后端案 "计算平台"的第一个本能是到达API: 验证输入服务器-侧,返回一个JSON结果.
这是大家都知道的规律, 对于像抵押贷款的摊销时间表来说,它甚至听起来是合理的—— 涉及到真正的数学。
但是,走过一个这样的网站 真正能买到的东西: 没有什么可以验证的。
错误输入的最糟糕的结果是用户自己屏幕上的号码错误.
没有共享状态腐败,没有其他用户受到影响,也没有数据保护.
无常取胜.
一个网络来回计算比仅仅计算要慢。
服务器的数学速度不能快于已经拥有两种操作的浏览器.
没有隐私故事可担心。
如果我从未收到这些数字,我就不用去想他们会怎样.
后端的计算器设计通常最终需要在隐私政策中需要"我们不记录您输入"一行;这里没有写,因为没有服务器侧代码路径可以登录.
基础设施的存在纯粹是为了增加延迟和故障模式。
依靠API呼叫的计算器现在有一个停用模式.
是一个标记的计算器没有.
因此网站的每个计算器——从一行百分率公式到全额按揭分期偿还表——都作为普通客户端的JavaScript运行来对抗DOM.
这里大致是它的形状,剥下: 没有框架状态管理,没有服务器往返,没有加载自旋器.
结果更新了输入变化的瞬间.
对于一个其整个价值命题是"快速得到数字"的站点来说,这种响应并不是一个好到有的——这是产品的大部分.
单位转换器的决定,其实是SEO的决定 一个真正有趣的地方是单位转换, 因为自然工程本能与自然SEO本能相抗衡。
工程本能:建立一元件,通过并作道具,再加个小互换按钮.
一个组件,两个使用的案例,DRY。
我实际运出的东西:作为两个单独的静态页面,每个网页都有自己的H1,自己的工作实例,自己的FAQ部分——真正重复的内容结构,而不仅仅是一个共享的组件两次提供.
推理:某人搜索"英里到公里",而某人搜索"公里到英里"则表达了不同的意向,尽管基础数学是一行相乘的任意一种.
一个单一的双向页面必须在两个查询中分割出其相关性信号——它的标题,它的H1,它的默认状态都需要选择一面或套期.
每页两页对一个方向都毫不含糊,这是搜索引擎在决定一个页面的用途时想要看到的.
成本是真实的:要生成的页面是两倍,要写入的工作实例是两倍,如果基础转换因子或演示文稿有变化,要保持FAQ内容的两倍同步.
为~45个单位转换工具,非小乘数.
但这是一次性的诱导成本,而不是持续成本——网站是静态生成的(Astro),因此"翻两页"意味着建设时输出的两倍,而不是运行时复杂度的两倍.
购买的是什么?
购买的成本:零后端 运行、监控或支付即时结果 而不依赖网络 没有隐私政策段落解释我从未收到过的数据会发生什么