@Skmgo 节点客户端和主链中其他节点通过 eth p2p 协议通信，钱包客户端（ dapp 前端，指 app/web 等）与节点通信通常是 http/websocket 的[web3 JSON-RPC APIs]( https://geth.ethereum.org/docs/rpc/server), 这个接口和一般的网络应用没有什么太大区别。但是一般成熟应用不一定用自己的节点，可能使用别人的分布式节点服务（ infura/alchemy)。

1. 钱包节点：有 IP，可以被 DDOS ；
2. 如何防护：对节点客户端所暴露的 http/websocket 接口按常规的 DDOS 防御策略进行配置（限流 /限频等）即可；

@no1xsyzy 是的哈

@jhdxr 对的，我不觉得这个可以叫做不用写代码 :)

我觉得宣传可能是有点过，但是思路没太大差错，做 MVP 快速迭代上线很方便，真需要大流量等的时候，业务应该也不差钱了，正常招团队重新迁移就行。
另外 @jhdxr “只能修改自己的”这个需求他们还真用配置就能实现 ：） ，当然还有很多复杂的逻辑是无法实现的，需要用到云函数，就是正常写 js 后端。

先上个健康检查, 出问题了 auto restart. 如果重启一下就能好, 整几个做负载均衡, 谁停了自动重启谁, 业务面可能无感. 听说过有项目生产环境中业务周期崩溃但是能通过自动重启恢复, 上线大半年了才发现有这问题...

确实有这个问题, 恢复出厂后速度会有适量提升, 但也不是特别快

apple 好, 不能玩游戏(指比 windows 少很多) . 不用考虑性能, 最低配的 air, 也轻便.

1. 刚学编程 CPU 应该影响不大吧, 不会直接学底层写受指令集或架构影响的程序吧;
2. 不做机器学习和编写游戏的话应该对显卡毫无要求, 初学者和低龄儿童(数学没有学到位的) AI 课程基本是忽悠吧(最多建立一个体验), 建议核显(独显对价格和重量 /散热上都受影响);
3. 这要看学什么内容了;

可能很多人点进去看到 UI 后就没有兴趣继续查看了. 我觉得楼主非常有激情的把想法实现了并发布出来, 应该值得肯定. 我仔细看了下内容, 有些不成熟的想法.
1. 楼主产生无服务云平台来服务中小企业或者个人开发者的想法, 应该是对的, 目前大厂也都在布局, 应该就是所谓的低代码平台, 由平台来解决 80%的通用问题, 平台用户(开发者)来解决剩余的 20%的特异性问题(通常大部分是前端方面或一些特异化的 API).
2. 但是楼主平台所提供的服务, 像类似静态网站服务 /数据存储服务等, 我觉得方向有些问题, 这些也都是平台应该解决的通用性问题, 但是楼主平台来解决该问题对比大厂来说没有丝毫竞争力, 这部分与大厂提供的 serverless 和各种云服务完全重合, 不说楼主技术水平是否能够做出超越大厂的性能和稳定性等, 就是价格方面可能也打不过大厂(可以参考腾讯 cloudbase 服务, 目前一定使用量下是完全免费的).
3. 楼主平台提供的服务, 我觉得可能不能满足通用性的开发工作. 楼主提供了很多案例, 但是这些案例并非是真正生产级别的应用. 举个例子, 如果我希望使用 fastfullstack 来构建一个内部管理系统(最通用的需求), 那么首先我要能对数据项进行定制化, 例如用户信息中加入工号字段, 这个目前没有在文档中看到如何解决(可能没有看全, 如果有误请楼主指正), 另外 RBAC 权限控制完全没有看到, 这个也是通常构建应用最长使用到的功能之一. 如果这些功能不在楼主平台范围之类, 那么对于开发者的效率提升可能有限, 这样楼主的平台就完全是一个底层云平台, 直接与各大厂云竞争的产品.
4. 我觉得做通用低代码平台可以参考下 strapi 这个产品, 它的定位是一个 headless cms, 可以方便的构建内容数据及关联关系(我不赞同楼主文档中说的「就目前我们做的 10 多个实际案例来说，暂时未碰到关系型数据读写需求」,数据间的关联关系肯定是需要的), 并且有比较完善的权限管理, 而且在各个阶段留出了 hook 点可以让开发者进行定制. 如果能将该产品 SAAS 化, 相信应该会有很多开发者愿意付费使用(strapi 本身是本地部署的). 但是大厂留给大家的时间也不太多了(参考 https://github.com/TencentCloudBase/cloudbase-extension-cms)
5. 建议楼主在 fastfullstack 注册成为开发者时不要收集用户身份证号, 这个是比较隐私的信息, 会挡住很多愿意试用体验的用户(例如我😄, 所以对楼主平台体验不完整, 以上内容可能存在误差)

以上只是我的个人意见, 楼主如果觉得不对尽请忽略 :)

可能总是求而不可得导致的挫败感, 需要能够放下, 但是确实不容易做到, 加油!

strapi 这类 headless cms 只能解决 CRUD 项目的简单基础需求。但是这是非常有意义的。
处理表之间的复杂级联关系和逻辑计算，strapi 的 Shadow CRUD 是不够的，但是 strapi 也明白这个道理，在项目中几乎每个阶段都可以 hook，以增加自己的处理逻辑，甚至可以定制 plugin, 这时 CRUD boy/girl 还需要上场。
权限系统也是如此，通用解决方案不可能实现现实项目中的各种权限，例如 strapi 的 RBAC 颗粒度是针对每个 model （表）中的各个方法（ find/findOne/create/update/delete 等）的权限，但是现实中的项目客户要求的“权限”可能是好几个 model 中方法的组合，甚至还牵扯更多的别的判断，这时的逻辑也需要 CRUD boys or girls 去实现。
还有许多的“现实“需求直接用 strapi 无法完成的,所以 strapi 此类产品能否取代 CURD boy?我觉得不能。但是能取代一部分 CRUD boy 的基础工作，让 CRUD boy 的工作更加轻松一点我认为是可以做到的。
另外性能问题我觉得倒不是非常重要，这类产品的单体性能肯定是比用 springboot 或者其他框架直接写出来的要低，但是本身逻辑与数据分离，数据库可以分布式扩容，strapi 无状态配置后(上传下载文件上云储存，公共 auth 认证)也可以水平扩容做负载均衡，最终计算得失的地方是使用 strapi 减少的人力成本、后期维护费用与云产品（硬件）费用增加的成本之间的关系，然而这个得失结果却是非常难以明确了。

LGTM!

复杂度不会消失,只会转移. 如果你的基础设施封装了大量复杂度且配置少, 方便集成使用, 就会不太灵活, 例如需要对一个问答系统的某一个方面进行一个定制, 可能无法实现, 这样的基础设施功能受限; 如果你的基础设施配置灵活, 各种定制定制接口丰富, 那么复杂度实际还暴露在用户侧, 配置搭建所需要的专业性和时间精力就会大大增加. 这是一个比较棘手的问题. 具体可以参考 No Code 和 Low Code 词条相关背景.

饺子当然是韭菜馅的,哈哈

很棒的学习材料

比较复杂的项目可以参考 Android 的 Repo & Gerrit, 可以满足管理多个 git 仓的需求, 但是本身也引入了复杂度. https://source.android.com/setup/develop#repo