如果是一个数据的各种枚举的中文映射的场景。是后端不讲理，建议后端按照约定的 schema 一次返回。

如果是两组数据。

如果有多个前端（不是程序员，是客户端），应该更倾向于听后端的。因为不是专门伺候你。
如果仅一个前端，可以以前端开发为主（后端开发是生产者，前端开发是消费者），谁离业务更近，谁说了算，谁责任大。别说帮忙合并数据面向页面提供接口，前端要求后端直接返回渲染好的 html 都行。
但具体实践中大部分要看习惯和交情。


具体情况具体分析吧。




从 op 描述来看。
op 更想省事，后端理由正当合理。



我们要判断争论点是把复杂度和锅（我可以听你的这么做，但是出问题你负责）从谁转移到谁。
争夺复杂度和锅的争论，推脱复杂度但是不甩锅的争论，大部分都是好同志。
推脱复杂度同时也不背锅的争论，我们可以直接理解为队伍里出现了不合适的人。


另外多说一句：
技术团队的技术争论，
如果有人不「站在 “整体”的位置上，看“现在”和“将来”，」
还争个热火朝天，
如果不是公司薪资水平不行。那要么是菜，要么是坏。

做个解密。不给钱只给一部分看。然后给钱下载。

直接不暴露源 IP 。扫都扫不出的那种，比如源站用其他域名，非白名单 ip 不可 tcp 连接之类的。
服务不重要的话，遇到攻击直接间歇性佛系自闭。

重要的服务。隐藏的真实的源 => 隐藏的 cdn 源（节点多一些） => 提供服务的 cdn （节点多多的）。节点被攻击就直接黑洞。ttl 搞短点，让 dns+cdn 去自动平衡流量。不知道这个思路行不行。dns 的东西忘完了，不确定。


他搞分布式攻击，你就搞分布式服务。被攻击的节点直接自闭，也产生不了多少流量费用。🤣

感觉面试官卡在这个问题很久了。

你接了单然后再转给货运公司？

看下来感觉 op 是想后端尽可能少写代码，前后端尽可能少的重复劳动。所以一开始朝着 lowcode 方向走了。
我做过几乎一样的事情。

但是后来发现。真正的业务逻辑千奇百怪，很难做到「不写代码」，哪怕是有 lowcode 平台能实现这些复杂业务逻辑，那配置的过程就相当于「写代码」了。可能要做一些取舍。不能沉迷于全部自动实现。😂


我的实现大概是这样：

1. 定义数据结构，包括：字段校验；状态机；筛选、搜索字段、字段变更事件、字段监听事件、持久化方式等。
2. 基于数据结构，自动生成齐备的 curd restful 接口；也可以自定义接口，请求响应的 schema （可引用数据结构）。
3. 可以通过定义的接口直接生成 openapi3.1 的 schema ，进而生成文档。
4. 自动实现路由、参数校验、权限校验等。
5. 任意接口可以自己接管、实现更具体的业务逻辑。
6. 可以自动生成前端请求接口的 sdk 。前端不用调试接口，直接用。
7. 基于接口 schema ，生成描述表单、列表、详情的 jsonschema ，然后前端实现类似 react-form-schema 、amis 的渲染引擎；也实现了前后端不分离的，生成 html 的服务端渲染引擎。

8. 具体的业务逻辑还是手写。在合适的地方引用列表、表单、详情的组件（引擎渲染 jsonschema + sdk 的数据）。

为啥不用 PHP 呢。

不建议 10 天时间去新疆。30 天可以，慢慢玩的那种。

搜一下 api gateway.

考虑一下带宽和磁盘读写。

用 amd 的 u 。
ffmpeg rtsp 抓图。

我不得不怀疑，相当一部分说 3 的，多少有一些不负责任的恶意。


不要只看当前。要看天花板在哪里。
就算 2 、3 到手都一样。在上海你可以翻倍，在老家就很难了。
如果是很年轻刚开始工作。建议提升空间作为第一优先级。


给自己 2 ～ 3 年的时间在上海。可以继续在技术上提升、没事多去更好的公司面试。
都说环境差。其实啊，对摸鱼党来讲，环境是真的差。对优秀的人来讲，虽然差，但是也没那么差。

设计模式看一看，修饰模式。

那我们做一个免费版就是了。

几十万用户推荐三天，298 很划算。
如果 298 很划算，那么 698 就更划算，相当于 298x8 。
如果 298 都让你很爽了，我为了让你更爽，搞了个 698 给你。


如果这里所有数字都是真的。显然会有等式不成立。
也就是说，一定有数字不是真的。

那你觉得哪(个/些)不是真的？

@kaiwenli zpy.com 多少钱。

不知道最后怎么选择的？