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

Summary

This video provides a comprehensive comparison of four different paradigms for handling server-side operations in web development: Server Actions, tRPC (TypeSafe Remote Procedure Calls), GraphQL, and REST. The video analyzes various aspects, including ease of setup, ease of use, handling mutations and queries, type safety, compatibility with other clients, and the ability to work without JavaScript enabled. It offers insights into the advantages and disadvantages of each approach, helping developers choose the most suitable option based on their project's requirements. The video ultimately recommends Server Actions for simple web applications, tRPC for supporting mobile or desktop clients, and GraphQL as a viable choice for internal applications, while cautioning against exposing it to the open internet due to potential denial-of-service vulnerabilities.

Takeaways

• 🔑 Server Actions, tRPC, GraphQL, and REST are four different paradigms for handling client-server communication.
• 🚀 Server Actions are incredibly easy to set up and use in Next.js 14, but lack robust query capabilities.
• 🔐 tRPC and GraphQL excel at handling queries, with tRPC being easier to set up and GraphQL providing better type safety through introspection.
• 📝 Mutations are straightforward with Server Actions, tRPC, and GraphQL, while REST allows more flexibility but lacks standardization.
• 🧩 Server Actions have limited compatibility with non-web clients, while tRPC and GraphQL offer better interoperability.
• 🔌 Only Server Actions can work without JavaScript enabled on the client.
• 🏆 For simple web apps, a combination of Server Actions and React Server Components is recommended.
• 📱 For apps with mobile or desktop clients, tRPC or GraphQL (for internal apps) are better options.
• ⚠️ GraphQL has potential for Denial of Service issues and should be used cautiously on the open internet.
• 🤔 The choice between these paradigms depends on factors like app complexity, client types, and security requirements.

Q & A

What is the purpose of this video script?

The purpose of this video script is to compare different paradigms for server-client communication, such as server actions, tRPC, GraphQL, and REST, and provide insights into which might be the best choice for a particular project.

What are server actions?

Server actions are functions defined on the server side that can be invoked from the client. In Next.js 14, they are defined using the `use server` pragma, and the framework manages the communication between the client and server.

What is tRPC (TypeSafe Remote Procedure Calls)?

tRPC is a protocol that allows defining remote procedure calls that can be exposed by the server. It automatically creates query hooks and handles the marshalling between the API endpoint and the function, sitting on top of HTTP and JSON.

What is GraphQL?

GraphQL is a query language created by Meta (formerly Facebook) that sits on top of HTTP and JSON. It allows specifying queries or mutations using a well-defined syntax, and the server returns the requested data in JSON format.

What is REST (Representational State Transfer)?

REST is an architectural style where entities are defined in a hierarchical structure, but it doesn't have strict standards or formality. It relies on different styles and formats for APIs, with tools like OpenAPI and Swagger providing some standardization.

Which paradigm is the easiest to set up?

According to the script, server actions are the easiest to set up, as they are built into Next.js 14 and require no additional configuration.

Which paradigm is the most type-safe?

The script suggests that GraphQL has an advantage in terms of type safety due to its introspection capability, which allows clients to request the schema from the server and generate types accordingly.

What is the potential issue with GraphQL in terms of queries?

The script mentions that with GraphQL, clients can make up any query against the server, which can lead to a denial of service attack if a malicious API request consumes excessive database or server resources.

Which paradigm is the most compatible with different clients (e.g., mobile, desktop)?

According to the script, GraphQL is the most compatible paradigm due to its standardized format, which allows libraries and clients in different languages and platforms to consume GraphQL APIs efficiently.

What is the recommendation for simple Next.js web applications?

For simple Next.js web applications, the script recommends using a combination of queries on the server in React Server Components and server actions, as it is the easiest way to go.

Outlines

00:00

🤔 Intro to Server Actions, tRPC, GraphQL, and REST

This paragraph introduces the four different paradigms that will be compared: Server Actions, tRPC (Typesafe Remote Procedure Calls), GraphQL, and REST (Representational State Transfer). It provides a brief overview of each paradigm and sets the stage for the subsequent comparison.

05:00

⚖️ Comparing Server Actions, tRPC, GraphQL, and REST

This paragraph compares the four paradigms in terms of ease of setup, ease of use, handling mutations, handling queries, type safety, compatibility across different clients (web, mobile, desktop), and ability to work without JavaScript enabled on the client. It provides a comprehensive analysis of the advantages and disadvantages of each approach, highlighting their strengths and weaknesses in different scenarios.

10:02

💡 Recommendations for Using Server Actions, tRPC, GraphQL, and REST

Based on the comparison in the previous paragraph, this paragraph provides recommendations on when to use each paradigm. For simple web applications, it suggests using a combination of Server Actions and React Server Components. For applications with mobile or desktop clients, it recommends tRPC or GraphQL, depending on whether it's an internal or internet-facing app. It also cautions about the potential denial of service issue with GraphQL on the open internet.

Highlights

Server actions are functions that you define on the server, which can be invoked from the client by just calling that function.

tRPC (typesafe remote procedure calls) allows you to define remote procedure calls exposed by the server, creating handy query hooks and handling marshalling between the API endpoint and your function.

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

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

Server actions are incredibly easy to set up, being built into Next.js 14 out of the box.

tRPC is fairly easy to set up, with good documentation.

GraphQL is difficult to set up, often requiring a code generator to keep it type-safe.

REST is easy to set up in most environments, with a way to create API endpoint routes.

Server actions are incredibly easy to use, as they're just functions called on the client.

Server actions are designed for mutations, making them shine in that area.

Server actions are not as good for queries, as requests are queued, which can be problematic for simultaneous queries.

GraphQL queries can be a security risk, as clients can make up any query, potentially leading to a denial of service.

Server actions and tRPC provide excellent type safety out of the box.

GraphQL allows for introspection against the server, enabling the creation of types from the schema, which is a unique advantage.

Server actions have limited compatibility with other clients, as the API is designed by the framework.

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