Jianzs

@dzdh 好像不是账号第一年，而是你使用这个组件的第一年，之前没用过不算

@Hamao 有问题可以随时交流哈

V 友可以看看 SST

顺带可以看看我不成熟的项目，哈哈哈哈，欢迎提提意见 https://github.com/pluto-lang/pluto

https://juejin.cn/post/7366891840186826771
https://juejin.cn/post/7366084203953881114

第一个项目的源代码： https://github.com/pluto-lang/pluto/tree/main/examples/rag-qa-bot-with-web

连部署一块给你解决了:)

@ZSeptember #12 终于有人肯定啦，不考虑商业化

是这样的，很多个人开发者虚拟机一把梭哈，没有并发的压力，也就不太考虑 Serverless 这一套，所以现在是通过 AWS 的羊毛来吸引用户能上手试试，给点反馈

大佬下次有需求可以试用一下，劳驾点个 star 呗

@ZSeptember #10 感谢大佬反馈

对于你最后提到的核心问题，深表赞同，所以这款工具的定位就是面向个人开发者的，对基础设施也有要求，云化需要做的比较好。

对于大佬前面提到的三个问题，我是这样解决的，可以交流一下：

1. 对于第一点，Pluto 生成的不是最终的 IaC 代码。比如 API Gateway 这类组件，其实用起来还需要 Route 、Trigger 、Stage 、Integration 之类的组件，我们把这些组件组合在一套 SDK 里，封装出一些方法，生成的代码是这套 SDK 方法的调用。一两句话说不清楚，可以看下这篇文档 https://pluto-lang.vercel.app/zh-CN/documentation/how-pluto-works

2. 对于第二点，目前的确灵活性不足，我只支持在全局作用域定义这类特殊变量，最近才支持了环境变量，只能说尽可能覆盖更多的编程行为。

3. 对于第三点，目标是：抽象之下支持完全可扩展性。会在 Router 这类构造器上提供一个 options 参数，通过这种方式对资源进行细粒度的配置。后续也想做插件体系，通过插件的形式对生成的 IaC 代码进行修改。

@ZSeptember 开发者使用 Terraform 的话，需要维护业务代码、基础设施代码两套代码，有上手成本和维护开销。

我这里的话，是用户只需要编写业务代码，然后 Pluto 理解业务代码的资源需求，自动生成 IaC 代码，目标是让开发者不关心基础设施。

业务代码就像平常写的代码一样，这里不是基于模版来实现的，而是通过程序静态分析来实现的

@Mithril 有道理，感谢大佬！现在是基于 Pulumi 实现，后面打算支持 TF ，到时候导出 TF 代码，让开发者确认