Next.JS 会议上的一张照片，描述了最新的Server Action功能，可以在前端代码里写SQL了，这张照片上有很多不好的镜头。
SQL 注入通过“sql”调用进行保护。
如果您不喜欢内联 SQL，可以通过调用函数或端点来抽象它。
如果您认为这是“混合关注点”，那么关注点是书签组件。
9C2095EA-3FCA-462B-BA90-E9006823AB9B.jpeg
这个功能引起了很多争议，这会不会造成一种维护困局？
有人认为这又是倒退到php了
是的，这是一件好事。PHP 的核心问题是，如果我们想要客户端交互性，我们必须声明单独的客户端模板。
使用 React，我们可以创建一次 JSX 并在客户端和服务器上运行它。
有人认为这打破了组件的概念
不，这打破了组件的整个概念
如果设计上的组件是可嵌入到任何地方的部分，则此部分绑定到数据库中的特定表。因此，使用同一表的任何其他组件都不知道这种隐藏的依赖关系。
这并不能解释如何处理隐藏的依赖项。当此组件添加书签时，必须有一个组件来读取书签。它们之间唯一的连接点是数据库。
对数据库结构的任何更改都可能在任何地方使应用程序崩溃
有人认为这是一个Game Changer级别的功能
当 GraphQL 第一次出现时，这个东西就是它的卖点。
不知道为什么人们认为这有什么不同。这是一个游戏规则的改变者
有人从可维护性的角度做出了反对
它不能正确扩展，很快就会变得无法维护。后端涉及几个关键的规范和良好实践（例如负载均衡、可扩展性、吞吐量控制），而这些规范和实践无法通过将后端责任放在 Next 的服务器端代码上来正确完成。
在我看来，回到单体架构没有任何好处，一个大项目会很快变得无法维护和脆弱，因为混合了这些担忧。
不管怎样，发布的原因只有一个，那就是一个卖点。特定于Next.JS的东西，并且只能在其付费的专有服务器上工作
安全性问题是如何解决的
打包的时候前后端分离，所以这部分逻辑不会暴露到客户端
