NextJS 14 Server Action Controversy!

Learn five system design patterns that you can use with various combinations of server actions, APIs and microservices.

👉 VS Code theme and font? Night Wolf [black] and Operator Mono
👉 Terminal Theme and font? oh-my-posh with powerlevel10k_rainbow and SpaceMono NF

0:00 Introduction
1:27 Short Postgres/ Clerk Setup
4:10 Server Action Direct to DB
7:24 Server Action To Local SQL Module
10:10 API to Local SQL Module
14:02 Application And Microservice
17:38 Application to Microservice Proxied
20:31 Outro

[Dev-Siri]

server actions make progressively enhanced forms in react manageable.
we had been reinventing forms on the front-end before since there was a pretty strong and often awkward boundary that was hard to send form requests over. this is why I appreciate the feature

[jeromesnail]

Server actions + 1 abstraction layer is the best imo.
You could still use the abstraction layer for some API route if really needed.

[tom.watkins]

I lean towards the seperate API for a few reasons:

1. Most of the databases I have to interact with have IP whitelists on them. Its possible get a fixed IP on Vercel but only on their super expensive enterprise plans
2. Puttkng the API layer closer to my database is better for performance on heavy CRUD usage
3. If you have long running server side tasks then you can fall foul of the serverless time limit on Vercel
4. I use a monorepo and tRPC to make it feel like it is still one application and to retain end to end type safety
5. The API is reusable if we want to have extra applications, such as a mobile app

The cons of this approach are as you say, the extra headache of maintenance and CI/CD. Im considering trying SST to deploy Next.js in our AWS environment to get around some of the security issues though.

[liendwin]

I just found out your channel yesterday and the way you teach is fascinating sir, eagerly waiting for your complete Nextjs course!

[srymisclick]

Surprisingly well made and comprehensive video. You knocked it out of the park with the analysis and the showcase of how this can be orchestrated, as well as what server actions actually mean.
One thing I think you could have touched upon more, and a thing that I see lots of people missing, is that server actions - while creating the endpoints and doing the calls for you automatically - expose your server functions as route handlers to the public. This might not be obvious and I foresee a lot of issues because people will not sanitize the function params because they will miss the fact that it's a public request input.

[aftercamp]

5:06 What plugin should I use to highlight my code?

[umarmuhammadzakari]

I really agree with you there's no winner here, it all depends on some factors like type of app, size of team, whether there's gonna be a mobile app or not etc

[VincentFulco]

Marvelous, in the midst of a project and this fills in many gaps. Always thankful.

[anasouardini]

Really simple and straight forwards; I love it.

[jeancolombel]

Great content! Thanks for putting this together. In these times of constantly evolving full-stack frameworks, it’s helpful to see the different possibilities laid out with their pros and cons. As you mentioned, I believe a combination of these patterns is often the best approach, depending on the specific requirements. 🙏🚀

[eulersson]

Great video What is the problem if the Next app speaks directly to the database instead of through microservice? I guess that you would prefer a microservice if you have two different Next apps interacting with the same API?

[gamerclips]

I would use the more simple to maintain, adding too much of extra layers, and abstractions, just make the application very hard to maintain and understand in the long run

[BlueeyesChineseguy]

Great video! Just to clarify, in the client-to-msvc-proxy example, why are the cons of the client-to-mscv no longer relevant? I.e.
- Multiple servers to maintain
- Larger security surface area

If you proxy the request using a local Next server to the microservice, do the above points not still hold?

[tonajki]

For posterity and from the viewpoint of learners: I think it's unfortunate to use slugs in the example, because of the functional use of the word too. It adds an extra layer of complexity imo

[ilkkaouto]

Maybe I'm hung up on details, but it bothers me a bit that the examples out there use the formAction of a button. To me it implies the action would work without a form, but that is ofc not the case. But I guess with a form element the examples would look less cool. I wonder if we'll end up wrapping React components in arbitrary forms, just to have independent buttons replace their actions. And then there's startTransition for calling Server Actions outside forms, but without progressive enhancement. Which and when should we use each is a bit muddy.

[denissorn]

Shouldn't one use parameterized query and ? instead of ${} (interpolation), if one wanted to stay on the safe side? Edit: Figured it out. The framework does make parameterized query out of (sql) tagged template literals.

[appstuff]

after seeing only 2 of your videos around new nextjs zustand and one more around client vs server with approuter method instead of pages. I somehow believe you are quite credible, knowing your stuff. Thanks! I hope someday when these skills i start earning from, i can thank you with a dinner or something someday. Thanks Jack. :D

[virtual]

Approaches 1-4 are great for fullstack, approach 6 is default way for frontend app. But approach 5 looks overly engineered and under performing solution. Why and where would it be better than approach 6?

[jmagrippis]

It’s the classic case where “separation of concerns” is great general advice, but we can’t really agree on what’s an individual concern 😂

The component-based approach that React popularised redefined whether a single component should be “concerned” about the html semantics, “looks” via styling / css, and interactivity via JS. I’d say most agree now that it’s fine for all that to count as a single concern, and often even keep all the related code in the one file (the component itself).

Maybe we’ll see server actions like that in 5 years, with hindsight. I like the idea of the <StripeCheckout /> component, where its “one concern” is getting you through… Stripe checkout!

Great video overall! I like the server actions with extracted “api modules” the most, the second example!.. unless you do indeed have to maintain a dedicated API for a mobile app etc.

If that’s a concern, then it redefines what I consider an appropriate concern for a component 😄

[AndreyDyatlov]

You can create an API when you need it. Having and maintaining API is a burden. And if you don't need it now, don't create it. I realized it when I wrote my first app using Meteor. The absence of an API helps you to move forward up to 10 times faster.