带着问题学 Next 之双端通信

第二期的问题是 Next 中客户端和服务器如何通信 怎么玩？

问题背景

众所周知，作为 SSR 框架来讲，应用层面严格意义上是前后不分离（耦合）的项目。那么如何在 Next 中发起一个网络请求呢？都有哪些方式？我们该怎么做抉择？

这些都是我学习这块内容的疑问点，今天我就带着问题，和大家一起探索～

解决方案

在 Next 13 App Router 中提供了两种方式：Route Handler & Server Actions，我们先聊怎么做，再讲如何做，最后讲怎么选。

以 Route Handler 为例

代码语言：javascript复制

src/
└── app
    ├── api
    │   └── route.ts

route.ts

代码语言：javascript复制

import { NextResponse } from "next/server";

export async function GET(request: Request) {

    return NextResponse.json({
        data: { title: 'Today is Sunday~' },
        success: true,
    });
}

客户端发起请求：

代码语言：javascript复制

const HomePage = async () => {
    const resData = await fetch('http://localhost:3000/api')
    return <div>{resData.title }</div>
}

以 Server Actions 为例

代码语言：javascript复制

src/
└── app
    ├── actions
    │   └── index.ts

index.ts

代码语言：javascript复制

'use server'

export async function fetchData() {
  // ...
    return new Promise(res => res({ title: "Hello Next" }));
}

客户端发起请求：

代码语言：javascript复制

import { fetchData } from './actions'
const HomePage = async () => {
    const resData = await fetchData();
    return <div>{resData.title }</div>
}

方案差异

总的来讲：两种方式的抽象层次不同，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 .

本期到这里就结束了，我是不换，希望你有收获，我们下期再见