The Ultimate API Showdown: Server Actions, tRPC, GraphQL, and REST Compared!

Summary

本视频深入探讨了服务器操作与tRPC、GraphQL和REST的比较，旨在帮助观众了解这些技术在项目中的最佳选择。从易于设置、使用便捷性、执行变更操作和查询能力，到类型安全性和兼容性，每种技术的优势和劣势都进行了详尽分析。特别提到，服务器操作在Next.js 14中的引入极大简化了开发流程，但每种技术都有其独特适用场景。视频最后，根据不同需求推荐了适用的技术选择，为开发者提供了宝贵的指导意见。

Takeaways

• 🤖 服务器操作(Server Actions)是Next.js 14内置的,用于在服务器端执行操作的函数。
• 🔑 服务器操作、tRPC、GraphQL和REST是四种不同的范式,各有优缺点。
• ✅ 服务器操作在设置和使用方面非常简单,只需调用一个函数。
• 📝 服务器操作适合执行变更操作,但不太适合查询操作。
• 🦺 tRPC和GraphQL都非常擅长查询,但GraphQL存在潜在的拒绝服务攻击风险。
• 🔐 服务器操作和tRPC具有很好的类型安全性,而GraphQL则通过内省获得类型信息。
• 📱 tRPC和GraphQL在不同平台之间有较好的互操作性,而服务器操作则受框架限制。
• 🌐 只有服务器操作能够在没有JavaScript的情况下工作。
• 💡 对于简单的Web应用程序,结合服务器渲染和服务器操作是最简单的选择。
• 📌 如果需要支持移动端或桌面端,建议使用tRPC或GraphQL(内部使用)。

Q & A

什么是服务器操作（Server Actions）?

服务器操作是在Next.js 14中引入的一种新功能。它们是在服务器端定义的函数,可以通过客户端直接调用,框架会自动处理发送请求到服务器并获取数据的过程。

tRPC(TypeScript Remote Procedure Call)是什么?

tRPC是一种类型安全的远程过程调用方式。你可以在服务器端定义要暴露的远程过程调用,它会自动为你创建查询钩子,并处理API端点和函数之间的数据传输。

GraphQL是什么?

GraphQL是一种由Meta(Facebook)创建的查询语言。它基于HTTP和JSON,但与传统的REST API不同的是,它使用一种特殊的查询语法来指定查询或修改操作。

什么是REST?

REST代表representational state transfer(表现层状态转移)。它是一种架构风格,定义了一组约束条件和原则,但没有严格的标准。REST APIs可以有不同的形状和风格。

从设置难易程度来看,四种范例有何区别?

服务器操作最容易设置,因为它内置在Next.js 14中。tRPC文档较好,相对简单。GraphQL设置较困难,需要配置端点和代码生成器。REST设置通常比较简单。

在易用性方面,四种范例有何区别?

服务器操作最容易使用,因为就像调用函数一样。tRPC和GraphQL使用查询与端点交互,类似于React Query。REST则需要自定义API端点。

在执行数据修改(Mutation)时,四种范例有何优缺点?

服务器操作旨在处理数据修改,表现出色。tRPC和GraphQL也做得不错。REST虽然也容易修改数据,但需要自定义非标准的API,存在一些问题。

在执行数据查询时,四种范例有何优缺点?

tRPC和GraphQL在查询方面表现出色,但GraphQL存在潜在的拒绝服务风险。REST也很适合查询。服务器操作并不是为查询而设计的,在Next.js中可能会遇到队列等待的问题。

从类型安全性来看,四种范例有何优缺点?

服务器操作和GraphQL天生就是类型安全的。GraphQL还可以通过内省从服务器获取模式并生成类型。REST通常缺乏类型安全性,需要一些额外的设置。

在与其他客户端(如移动端、桌面端)的兼容性方面,四种范例有何区别?

由于API由框架定义,服务器操作在跨端兼容性方面表现不佳。tRPC在JavaScript/TypeScript之间可以很好地共享类型。GraphQL作为标准,在各种语言和平台间有很好的兼容性。REST被广泛支持,但缺乏标准化。

Outlines

00:00

🗣️ 介绍服务器操作与其他技术的比较

这一段介绍了将在本视频中比较的四种技术范例:服务器操作、typesafe远程过程调用(trpc)、GraphQL 和 REST。并概述了它们的基本工作原理和特点。同时指出,将比较这些技术在设置、使用、变更、查询、类型安全性、兼容性和无 JavaScript 支持等方面的优缺点,以帮助确定哪种技术最适合您的项目。

05:00

🚀 比较服务器操作、trpc、GraphQL 和 REST

这一段详细比较了服务器操作、trpc、GraphQL 和 REST 在各个方面的优缺点。在设置和变更(例如执行变更)方面,服务器操作相当简单;在查询方面,服务器操作则存在一些限制。类型安全性方面,服务器操作和 GraphQL 更出色。兼容性方面,GraphQL 和 REST 表现较好,但服务器操作则受限于框架的实现。在无需 JavaScript 的情况下,只有服务器操作可以工作。最后,作者根据不同的场景,分别推荐了服务器操作、trpc 和 GraphQL 作为首选。

10:02

🏆 总结与建议

在这一段中,作者总结并给出了自己的建议。对于简单的 Next.js Web 应用程序,使用服务器操作和服务器组件查询是最简单的方式。如果需要支持移动客户端或桌面客户端,推荐使用 trpc。对于需要在服务器和客户端上进行定制查询且不会受到拒绝服务攻击的内部应用程序,则推荐使用 GraphQL。作者还鼓励观众就这些评估发表意见,并呼吁观众点赞和订阅。

Keywords

💡服务器行为

服务器行为是在服务器上定义的函数，可以直接从客户端调用。在视频中，服务器行为是通过使用XJS 14中的use server pragma定义的，并且可以无需额外操作即由客户端调用，这使得它们非常易于使用。这一概念强调了服务器和客户端之间交互的简化，尤其在进行数据请求和更新时。

💡tRPC

tRPC代表类型安全的远程过程调用，允许开发者定义服务器暴露的远程过程调用，并自动创建查询钩子。视频中指出，tRPC基于HTTP和JSON，强调了其对类型安全的支持，并提出即使不使用TypeScript也可以使用tRPC进行RPC请求。

💡GraphQL

GraphQL是由Meta创建的一种查询语言，它基于HTTP和JSON。视频中提到，GraphQL的独特之处在于其请求格式，允许用户定义查询或变更，并且有完整的标准支持。这使得GraphQL在数据查询和更新时非常灵活，尽管设置起来可能相对复杂。

💡REST

REST代表表现层状态转移，是一种架构风格，通过定义层次结构中的实体来交互。视频强调了REST相对缺乏标准化和格式多样性，以及开发者通过OpenAPI和Swagger等工具来规范REST API的尝试。

💡易于设置

视频中讨论了服务器行为、tRPC、GraphQL和REST的设置难易度。服务器行为因为内建于NEX JS 14而得到最高评价，而GraphQL由于需要额外的工具和代码生成器而被认为设置相对困难。这一比较突出了不同技术对开发者友好度的影响。

💡易用性

易用性指的是开发者在实际应用中调用和利用这些技术的难易程度。视频中指出，服务器行为的易用性非常高，因为它们就像在客户端直接调用函数一样简单。这一点在选择技术栈时是一个重要的考量因素。

💡变更操作

变更操作是指对服务器数据的更新或修改。视频中提到，服务器行为、tRPC和GraphQL都很擅长执行变更操作，而REST的变更操作则因其非标准化而显得灵活但可能带来问题。这一讨论强调了在实现数据更新时不同技术的适用性。

💡查询操作

查询操作是从服务器获取数据的过程。视频指出，服务器行为不太适合进行查询操作，因为它们主要设计用于执行服务器端的动作，而tRPC和GraphQL则在查询方面表现出色。这表明不同的技术适用于不同类型的数据交互需求。

💡类型安全

类型安全是指代码中变量的类型是固定的，这有助于防止类型错误。视频中提到，服务器行为和GraphQL在类型安全方面表现优异，特别是GraphQL通过服务器端的自省能力支持强大的类型系统。这强调了类型安全在确保应用稳定性和减少运行时错误方面的重要性。

💡兼容性

兼容性讨论了不同技术与其他客户端（如移动和桌面应用）的交互能力。视频强调了服务器行为在与非框架客户端交互时可能遇到的限制，而tRPC和GraphQL则在不同环境中提供了更好的兼容性。这一点对于跨平台应用的开发尤其重要。

💡无JavaScript环境下的工作能力

这一概念讨论了在客户端禁用JavaScript时，不同技术的工作能力。视频中提到，服务器行为能够以表单提交的形式工作，而这是无需JavaScript支持的。这对于提高网站的可访问性和兼容性具有特别的意义。

Highlights

Server actions are functions that you define on the server, and you can invoke them from the client by just calling that function.

tRPC (typesafe remote procedure calls) allows you to define remote procedure calls that the server exposes, and it automatically creates query hooks for you.

GraphQL is a query language created by Meta, sitting on top of HTTP and JSON, with a standardized request format for queries and mutations.

REST (Representational State Transfer) is an architectural style with defined entities in a hierarchical structure, but without strict formality or standards.

Server actions are incredibly easy to set up and use, as they're built into Next.js 14 and you just call functions on the client.

tRPC is fairly easy to set up, with good documentation, while GraphQL is more difficult due to the need for code generation and type safety setup.

REST is easy to set up in most environments, as they usually have a way to create API endpoint routes.

Server actions are designed for mutations, making them shine in that aspect, while tRPC and GraphQL are also good for mutations.

For queries, server actions are not as great, as requests are queued, while tRPC and GraphQL excel, but GraphQL has a potential denial of service issue.

Server actions and tRPC are highly type-safe out of the box, while GraphQL has an advantage with introspection and generating types from the server schema.

Server actions have compatibility issues with mobile and desktop clients, as the API is defined by the framework, while tRPC and GraphQL are more compatible across platforms.

REST has good compatibility with most clients, as they can make GET or POST requests against the server.

Server actions are the only option that can work without JavaScript being enabled on the client, as they can be accomplished through form posts.

For simple web-only Next.js applications, using server components with queries and server actions is recommended.

For applications with mobile or desktop clients, tRPC or GraphQL (for internal apps) are recommended, with consideration for the potential denial of service issue with GraphQL on the open internet.

Transcripts

whenever the topic of server actions

comes up inevitably folks ask well now

that we have server actions and

something like nextjs do we even need

stuff like trpc graphql or rest and

that's actually a complex question so

what we're going to do in this video is

compare server actions to trpc graphql

and rest and give you some insights into

which might be the best choice for your

project let's get right into

it

all right let's introduce our four

different paradigms starting off we've

got server actions server actions are

functions that you define on the server

in the case of xjs 14 you define them

using the use server pragma and then you

can invoke them from the client by just

calling that function and nextjs or

solid start or quick or whatever

framework you're using manages that

entire flow of making that call for you

next up is trpc or typesafe remote

procedure calls you define the remote

procedure calls that you want to have

exposed by the server it then

automatically creates some handy query

hooks for you and does all of that

marshalling for you between the API

endpoint and your function which is

really cool it sits on top of HTTP and

Json and despite what people may think

you don't have to be using typescript to

use trpc you can make RPC requests from

any language next up is graphql it is a

query language that was created by meta

it sits again on top of HTP and Json

there is nothing exotic about the return

values those are simple Json what is

interesting is the request format which

is a query language and you can specify

either queries or mutations and the

Syntax for that query is well understood

and there's a full standard around that

and then finally there is rest rest

stand stands for representational State

transfer it is an architectural style

where there are entities defined in a

hierarchic structure but beyond that it

it really doesn't have a lot of

formality to it or standards to it and

so you see things like open API and

Swagger as ways to kind of lock down

rest apis but rest apis can have all

kinds of different shapes and flavors

and styles so now let's get into

comparing the various advantag and

disadvantages of using server actions

trpc graphql and rest we'll start off

without easy each one of these is to set

up in terms of setup server actions is

incredibly easy to set up it's actually

built into NEX js14 now so you don't

even have to enable anything all you

have to do is just start using them and

they work out of the box so that's why

I'm giving it three up arrows if it's

three down arrows that would be the

lowest ranking three up arrows is our

highest ranking so how does that compare

to something like trpc well trpc is

fairly easy to set up the docs are

pretty good about how to set this up in

your environment so I'm going to give

that two up arrows graphql is actually

pretty difficult to set up not only you

have to go and set up the API end points

and get those going but you also usually

have to do something like a graphql code

generator to just go and create all of

the stuff like the query Hooks and

everything else to keep it type safe it

is kind of a pain to set up and then

rest is really easy to set up in most of

these environments

nextjs remix they all have a way to

create API endpoint routes all right

what's next ease of use all right well

server actions again are incredibly easy

to use there are just functions all you

got to do is just call these functions

on the client and the client does all of

the work of actually making the request

against the server and getting the data

back it couldn't be easier it looks just

like a function and if you're familiar

with react query trpc is pretty easy to

use as well as our graphql and rest

they're basically just queries against

that endpoint and with react query you

get all those status values and all of

that but let's face it come on use Query

is never going to be as convenient as

just calling a function which is what

you do with server actions our next

category is mutations how easy is it to

do a mutation against a server server

actions were designed to do mutations so

that's one of the places where server

actions are really going to shine of

course they're pretty good across trp C

and graphql as well graphql has specific

types of queries known as mutations

that's all type safe so that's really

easy to use now rest is also really easy

to do mutations with but the thing with

rest is when it comes to these endpoints

you're basically kind of making it up as

you go along you get to define the API

you could use a get to make a mutation

which is not something you'd want to do

you could use a post or a put you get to

define the API that you want and so in

essence you get to define a non-standard

API and that can be a problem all right

what's next well queries so the flip

side of doing a mutation is to do a

query this is actually where server

actions are not so great so server

actions aren't really designed to do

queries they're server actions after all

you're acting against the server you're

not querying against it you're trying to

make some sort of change on the server

and one of the things I've heard

recently about nextjs in particular is

that server action requests are cued so

if you want to go and make multiple

query requests against a server you're

going to have to wait for those to cue

and that's not great when you want to do

queries you're generally going to want

to do multiple queries simultaneously so

that's something to watch out for when

it comes to server actions on nextjs

queries really shine of course on trpc

and graphql but there's a big hidden

gotcha on graphql and that's the fact

that a client can make up any query that

they want against the server and that

can be deadly you can get a denial of

service against your API when someone

makes an AP a malicious API request that

ends up eating a lot of either database

time or server time to accomplish that

request so that's something to watch out

for when it comes to graphql now there

are productss like vunder graph that

allow you to do build time graphql but

runtime rest that avoid that issue so

that's simply something you want to

think about when you think about putting

graphql into production particularly

when you're thinking about high traffic

and then of course rest is phenomenal

for queries all you've got to do is just

create a get endpoint and it's really

easy so another big question is how

types safe are these so server actions

are fantastic they're typees safe right

out of the box you're just calling a

function and so typescript is able to

track those types just as a function now

type safety is one where I'm going to

give an advantage to graphql because

graphql allows for introspection against

the server and that means that a client

whether it be on JavaScript or

typescript or go or rust or whatever

have you you can go and request against

the server to get the schema from the

server and create types off of that so

that is very very handy and it's a

unique advantage of

graphql and then rest is a problem when

it comes to type safety because again

you can make up anything you want when

it comes to rest now you could follow

open API or you could export Swagger and

potentially get types out of rest but

that's a lot of setup and unless you're

in a larger setup most of the time you

are just going and creating your own

types around your own queries and that's

not great for type safety all right

another Vector of comparison is

compatibility so if you are going to

have these endpoints how compatible are

they with other things making those

calls for example you have a mobile

client or you got a desktop client are

those going to interface with these

Technologies well and that's actually

one of the areas where server actions

fall down and that's because server

actions the API is a effectively

designed by the framework so you don't

control what type of query it is if it's

a form post what the actions are the

format of the request you control none

of that so when it comes to a mobile

client if all you have a server actions

they're basically going to have to look

at the wire and see what's going across

the wire and then imitate that to go and

do the equivalent of the server action

which is not a great API trpc is really

good for this you can have the types

that are then imported by a client if

you got JavaScript or typescript on the

other client that's going to be

fantastic when it comes to trpc when it

comes to something like go or rust or

another framework that's not going to be

as good but yeah if you're doing trpc

between two different typescript

applications be it react native and the

web that's going to be great graphql is

fantastic when it comes to

interoperability that's because graphql

is a standard and so you can make

Library liaries that comport to that

standard and therefore you can have you

know IOS and Android libraries that are

fantastic for doing graphql as well as

rust and go it's great rust is pretty

good when it comes to compatibility

pretty much everything you're going to

find is going to be able to do a get or

a post against some server but you're

not going to get that really nice

standardized request like you would with

like a graphql one last area of

comparison that's specific to the web is

whether it can work without JavaScript

being enabled on the client the only on

that's going to be able to do that are

server actions server actions are often

done as a form post that's a basic

function of the web and therefore can be

accomplished without JavaScript and the

only thing that's going to do that of

course is server actions in this case so

if you need that it's going to be server

actions or nothing so my recommendations

as of late 2023 after nextjs 14 has come

out are that for very simple nextjs

applications that are webon using a

combination of queries on the server in

react server components and server

actions is going to be the easiest way

to go if you're looking to support

mobile if you're looking if you also

have mobile clients or desktop clients

then I personally would recommend

probably

trpc if it's an internal app or an

internet app I might also look at

graphql as a possibility nice thing

about graphql is it's really good on the

server and the client and it's really

easy to make customized

queries but on the other hand it's got

that denial of service issue so I

wouldn't want to put it out on the open

internet because it could potentially be

denial of serviced well I hope this

helps you figure out what you want to

use in your applications of course let

me know in the comments do you agree

with my assessments or not in the

meantime of course hit that like button

if you like the video hit the Subscribe

button if you really like the video and

I'll see you on the next Blue Collar

coder