第二期的问题是
Next
中客户端和服务器如何通信 怎么玩?
第二期的问题是
Next
中客户端和服务器如何通信 怎么玩?
众所周知,作为 SSR
框架来讲,应用层面严格意义上是前后不分离(耦合)的项目。那么如何在 Next
中发起一个网络请求呢?都有哪些方式?我们该怎么做抉择?
这些都是我学习这快内容的疑问点,今天我就带着问题,和大家一起探索~
在 Next 13+
App Router
中提供了两种方式:Route Handler
& Server Actions
,我们先聊怎么做,再讲如何做,最后讲怎么选。
Route Handler
为例route.ts
客户端发起请求:
Server Actions
为例index.ts
客户端发起请求:
总的来讲:两种方式的抽象层次不同,Route Handler
更底层,Server Actions
抽象层次更高。
我在 ProNextjs
社区找到了一篇问答,我个人觉得蛮好的,已经回答的很全面了。
文章地址:https://www.pronextjs.dev/should-i-use-server-actions-or-apis
翻译出自 Chat GPT 3.5
问:我应该使用服务器操作还是API?
答:
这是一个很好的问题!客户端与 NextJS
服务器进行通信有两种不同的方式,App Router
支持这两种方式:API
路由和服务器操作。
API
路由是高度可定制的终点,可以支持所有 HTTP
动词,并以任何类型的有效负载响应。 API的缺点是它们本身不具备类型安全性。
另一方面,当您在 NextJS
应用程序上下文中使用时,服务器操作默认情况下具有类型安全性。服务器操作的问题在于您无法对有效负载格式拥有太多控制权。
我认为决策取决于是否还有外部客户端也要调用这些接口。例如,您可能还要编写一个希望使用NextJS应用程序提供的终点的 React-Native
应用程序。如果是这样,则建议您使用 API
路由,因为您可以控制 API
格式。
React-Native
应用程序可以与服务器操作终点进行通信,它们只是 API
终点。但它必须模仿在客户端上创建的调用类型。这并不理想。如果 NextJS
从版本到版本更改了格式,则会破坏 React-Native
应用程序但不会破坏 NextJS
客户端代码。
关于 NextJS
的好处之一就是你始终可以同时使用这两种机制。因此,在需要时您可以先从 Server Actions
开始然后迁移到或者仅添加所需的 API
终点。
以上便是 Next
中如何进行双端通信的相关知识点了,关于 Route Handler
和 Server Actions
的应用以及取舍相信大家应该有了一个权衡;
我个人更倾向于优先使用 Server Actions
,如果是作为服务给外部提供接口而言,则更适合 Route Handler
.
本期到这里就结束了,我是不换,希望你有收获,我们下期再见👋!