@sy20030260 谢谢，看来可行，得自己搞一个了。
@xwayway 谢谢。
@Casbin 谢谢自荐，我去研究一下。
@wujichao 不是富客户端，是多种客户端调用。

@Sin 感谢补充。这里的问题其实不单单是配置如何管理自动映射，还有不暴露，而且要跨平台。比如我们的 use cases：

1. 使用 Postman 发请求查询第三方接口，绕开我们自己的逻辑进行测试。
2. 使用 serverless 的 function 做一些 jobs 和 checks
3. 一些 Web apps 在 K8S 里面

目前的 secrets 需要分别在三个地方设置使用。如果用 secret manager，由于 serverless 和 K8S 都是一家云服务提供商，可以通过接入 SDK 或者平台自动集成的方式映射。但是 Postman 没法接入，仍然需要获取所有 secrets 配置上去。

其次是安全问题，在开发中需要支持本地就可以跑起来，因此在本地也需要可以用 SDK 拉下来 secrets，然后每个开发者都会知道。

---

目前看了一圈，估计是要实现一个 internal 的 token 校验服务到这个 proxy server，然后一旦通过即可发送请求到第三方。大概架构图如下：


https://blog.approov.io/using-a-reverse-proxy-to-protect-third-party-apis

找到一个相关资料 https://tyk.io/how-to-manage-third-party-api/

@Sin 谢谢回复。目前用的是 Azure key vault，但是还是会比较容易的泄漏，因为启动时应用还是需要拉下来全部的 secrets 。此外，其他应用也需要重复接入 key vault 的 SDK，然后 API wrapper 都要重复实现一遍。

@mincoke 我们目前就有一层 BFF 用来做 GraphQL，也曾经考虑过 serverless，但是前提还是准备好 Node 应用和基础的 Auth 、三方 API Wrapper 才可能迁移。

@taowen RoR 的 Active Record 太好用了，总不能越升级越原始吧。。

@forgottencoast 我去了解一下，谢谢推荐。

@per 也有注意到，也还在调研，感觉有商业公司背景比较靠谱啊。谢谢推荐

@DrakeXiang 暂时不招单纯的前端，不好意思。

@felixin @FrankFang128 @okampfer @tommyzhang @forgottencoast @oatw @BenX @mincoke

感谢各位建议，我也在昨天连夜调研了一下相关框架，同时今天跟同事和老板开会讨论了一下相关问题，在这里做简单的分享。

目前关于 Node 的生态和相关组件的可持续性发展的确是有点不太乐观，Nestjs 的确主要是由个人维护，然后 TypeORM 没有积极的维护而且已经存在 1.5K 个 open issues，另外一个相比成熟的 ORM Sequelize 甚至在 readme 上面寻找开源维护者，800 多个 open issues 也处于没有核心人员负责和维护的情况。相比之下 Rails 的维护性和成熟度要好一点。

但是从开发者和编程语言的流行度（来自 Stackoverflow 报告、Ruby China 论坛活跃度、招聘网站工作机会、采访部分朋友）来看，JS 的开发者和流行程度是在持续增长的，但是 Ruby 好像是在下跌。JS 有广泛度和简单上手的特性，然后由于简单轻量也常常用于 serverless，Python 有 AI 、ML 的大腿，Java 、C# 都是老牌的，Rust 和 Go 都有自己的新使用场景。唯独 Ruby 感觉只靠 Ruby on Rails 撑起来，适合来快速的做 Web App 原型。目前招聘人才是个问题，可以预见的是未来将会越来越难。

但对于 Java 来说，我们目前是一个小公司，新西兰核心开发团队维持在三到四个 Senior 开发人员的规模（外加测试、系统集成开发等），至少这个财年是这样。目前开发均没有 Java 经验，突然转型 Java 可能会比较吃力，之后招聘也有一定的风险，可以预见的是未来几个月内会面临需求交付减缓，团队学习压力大，可能对业务风险会比较大，虽然这是一个比较终极的方案。

所以只能回到 Ruby 和 Node 这上面。RoR 这个不用说，目前所有代码逻辑都在上面，但是也有很多历史债和环境、特殊业务逻辑在，也有一些问题，所以当有很多新 contractors 进来之后，可能会需要一定时间熟悉项目，前期效率也会低一点。长期维护之后更加依赖 RoR，更难以思考是否要迁移或者迁移成本更高，之后更难招 Ruby 开发。

而选择新起 Node 应用，逐步迁移的方案，如果选用 TS，代码质量会高一点，同时跟 Java 等也比较像，既可以扩展招便 Java 的过来开发，也可以招会 JS 的。同时前端用 React.js 等都可以统一成 JS 语言，更加统一一点。而选框架上，express 也支持 TS 了，可以考虑，不过比较稳定了没什么人维护，而且过于灵活。Nest.js 则是借鉴其他语言成熟框架基于上层做的最佳实践，实际上如果我们基于 express 来设计框架，可能做的好的话会变成 Nest.js 、egg.js 等这样，那还不如直接用。目前坑比较大的地方看起来主要在 ORM 上面，我也咨询了下淘宝同事，看起来 sequelize 相对成熟，生产环节中用基本上也没有太大问题。然后 Controller 这些 API 相关的应该比较基础了，问题也应该不大。对于不是很复杂的系统看起来风险还好。至于更细节的坑，的确会有这种风险。总之已经开会反馈给老板了，等他结合业务发展再想想计划然后最终确定什么方向。

@tomtom9 你好，目前新西兰境内招聘 senior 将会作为 core team 和国外的同事合作，所以如果开发经验不多可能会有点悬。如果有以前国内的工作经验等，可以加我微信或者邮件给我内推一下。谢谢。

@Skmgo 感谢建议，我换算了一下看了下，目前收到的简历的期望薪资都比你这个高一些，已经反馈给老板了，他会有个感觉和判断。此外这个跨境转账也的确是个问题，好像有限额没有什么经验，请问你的微信多少？或者可以加我上面 base64 的微信吗？希望咨询一些走账的问题，可能不方便公开讨论。如果不方便就算了，谢谢。

@felixin 感谢分享！

@felixin btw，可以稍微分享一下哪一块你们遇到过问题吗？比如什么第三方辅助项目等？如果不方便公开私聊可以加我微信：SmlhbmdzaHVpLVl1 （ Base64 ）或者邮箱。如果不方便就无视好了，多谢。

@felixin 谢谢建议，我们讨论下

@jatai 问过老板之所以没有明确薪酬范围是因为以下几个原因：

1. 第一次采用这种方式扩招，没有一套公平定价的策略，而且不同国家薪资、开发者水平和预期都不一样，很难确定一个统一的标准。
2. 由于第一条，不希望通过薪资来卡掉一些潜在的优秀面试者。比如印度、东南亚开发者的薪资水平偏低，如果我们以他们的薪资水平来确定我们的预算，可想而知中国以及欧洲的开发者肯定会直接略过，因为在他们眼里薪资水平偏低，都没必要谈。但实际上我们愿意为优秀人才付出更多，都是可以谈的。

然后没看懂这个你的这个例子想表达什么，如果连准备一份 resume 对于你都算浪费时间，只能说明可能这份工作对你的吸引力不够大。

@jeansfish 是的，之前办公室在那边，去年退租了，现在大家都远程办公了。新西兰境内也招的，是正常 full time 的也可以推荐。

@coderluan 只看单方信息，上来就疯狂“傻逼”“傻逼”的，我也觉得你欠楼主一个道歉。

学到三个事情：

1. **单向信息不要先评价**，至少双方信息都看到了再判断和评价，免得反转啥的。
2. 面试之类的**流程还是要注意，通过机制和规则上消除风险**，比如面试前先问问一些问题（有没有 offer 了或者找到工作了），一开始就是直接开视频面试，然后用一些录屏或者录音的方式记录下来。
3. 发帖须谨慎。。