The Ultimate API Showdown: Server Actions, tRPC, GraphQL, and REST Compared!
Summary
TLDRThis 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
🤔 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.
⚖️ 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.
💡 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.
Mindmap
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
5.0 / 5 (0 votes)