简单来说，这两天为了做 Assignment，尝试前后端全部部署到 AWS 的服务上。其中前端用 React 编写、以 Vite 作为骨架。这种 SPA（Single-Page App，单页应用）我个人更喜欢使用 Netlify 或者 Cloudflare Pages 这类专用服务来部署，因为这些专用服务提供非常健壮的 CI/CD 服务，基本上可以一键部署、自动更新，省去许多麻烦。
我原本的替代思路是在 AWS 上使用 S3 + CloudFront 的模式手动部署（毕竟只是一次作业），但后来发现 AWS 原来有一个与 Netlify 十分接近的替代品，叫做 Amplify，也是提供 CI/CD 一键部署服务。Amplify 甚至更进一步，将用户目录服务也一同囊括进去，直接调用相关组件就能实现注册登录一把梭。
听上去是挺美好的，但只有用过之后才知道这里面的坑有多深。经过一番资料查阅，我最开始的部署方式是直接把代码上传到 GitHub 之后，在 Amplify 界面点击部署按钮即可。这也是我使用 Netlify 的时候最常用的部署方式。
但是后来我发现有些不对劲。关键在于，使用这种方式部署的 Amplify 应用是没办法直接利用 Amplify 的 UI 组件来访问 Cognito 用户目录服务的。几经查找，找到 Amplify 官方有 Amplify CLI 的初始化指令来在 Amplify 服务中创建一个新的 CI/CD 项目，同时会为你部署诸如 Cognito 的额外资源。
看上去也不是不行，那就这么做吧。然后我发现了一些不对劲。最初的「不对劲」还只是在 AWS 帐户管理层面的：通过 Amplify CLI 部署项目之后，AWS 帐户很快就被一堆「东西」塞满了——之所以「东西」需要打引号，是因为 Amplify 创建了一大堆细碎但完全不知道做什么用的资源，包括但不限于 CloudFormation、IAM 角色等等，甚至连 Cognito 身份池也给我创建了两个——你很难不把它们叫做「垃圾」。而且，其中绝大部分的资源的名称对于人类而言基本是不可能记住、区分的乱码，也没有一个解释或者分组功能告诉你这些东西究竟是在做什么。
如果单纯只是这样的话，听上去也并不影响开发进程，对吧？最大的问题在于，本地调试和生产环境使用的好像并非同一套配置文件，加上我之前清理我的 AWS 帐户中被自动创建的资源的时候不知道动到哪根筋，把生产环境调用 Cognito 用户池的角色给删掉了，导致生产环境死活没办法访问 Amplify 创建的两个用户池，一直在报 400 错误。
在尝试过「部署 - 删除 - 再部署 - 再删除」的几个来回之后，我决定从头重新尝试再找找相关的文档。后来发现，Amplify 有一份 游离于 AWS 自身文档体系之外的文档，这份文档推荐的部署方式是：在 GUI 网页点击部署按钮——对，你没听错，就是我最开始使用的部署方式。
那么，这种方式要如何部署类似于 Cognito 这样的额外组件/服务呢？Amplify 给出的答案是配置文件，只要你在项目根目录创建一个存放配置文件的文件夹，在里面编写对应配置文件，云端读取到之后就能自动在 AWS 中创建你需要的资源。
听上去也蛮合理的对吧？然后你再去找文档里配置文件相关的部分…… 怎么回事？文档内的搜索框怎么找不到？甚至连个配置文件 sample 也找不到！Algolia 索引服务应该不至于这么烂吧？
是不是我的搜索姿势不太正确？我在 Kagi.com 搜索引擎中输入「site:docs.amplify.aws defineAuth」这样的关键词，也搜不到配置文件的示例和相关配置项解释。这下我彻底确信，Amplify 这垃圾文档得负全责。好在 Amplify 框架的 apidoc 写得相当好，至少减轻了我在猜配置文件配置项的时候想要买去美国的机票爆破亚马逊总部的心情……
还有，Amplify 还有一个与其他 AWS 服务完全不一样的、更现代化的 UI。格格不入倒还是小问题，重点是如果你是用（略微过时的）Amplify CLI 来创建项目，如果你想在网页配置它部署的 Cognito 等其他服务的后端，你会进入一个旧版的界面。就是，点进去之后，你看到的就是一个有点丑但十分熟悉的界面，但你又会觉得与刚才的 Amplify 界面十分割裂……
所以，现在我知道为何我之前完全没有听说过 Amplify 这个服务了——真的太难用了。完全整合确实是一个优势，但再是含着金钥匙出生也不能像 Amplify 这么嚯嚯，单纯只是把所有东西揉到一起，然后丢给用户说 it just works。用户一看，你这一大堆东西到底是啥啊，然后你就给他们丢了一本看上去装帧很 fancy 但是信息量无限接近于零的说明书。用户拿着这本天书，翻来覆去完全看不出一点信息量，只好无奈地把这堆东西往身后的历史的垃圾堆里扔了进去。