React's most dangerous feature 

I created an auth decorator that calls the underlying action only if the user is authenticated and authorized to use the endpoint. Maybe you could do the same:- export const SomeAction = isAuthenticated("admin", () => { });

​​@@dough-pizza could you make a npm package or at least a GitHub repo for just the rest of the population like myself? I think it's useful Sir.

So not worth the "cleanness" of the code IMO. I'd way rather prefer writing some boilerplate to keep things explicit so it's really hard to make mistakes like this.

@@smallmoneybigmoney So true. I am working full time on java+angular apps which "share endpoints" using OpenAPI. Everything is automatically generated. Works like TRPC, the only difference is that you have to restart your server and client for changes to be present. And we can use OpenAPI in any language we want...

Unless they also fixed the source map files, the treeshaking is "useless". The source map files are generated BEFORE the treeshaking, so while the final bundle might not have the code, your source map files WILL have it... Meaning you still expose everything if users have access to source map files.

I know its so funny how its like young CTO's and principal types are rediscovering web development from 15+ years ago. People spend so much time on solved problems as well as pursuing paths that are known to lead to doom and gloom. Every generation of young devs thinks they're the first people to encounter every issue that's new to them and god forbid they bother to check with all the search and LLMs and other tools at our disposal these days

100% the truth, they have so many similarities, it’s only flashier here because of React itself.

I've said this in the comments of a different video, but in webdev, time really is a flat circle. Every decade or so something that was deemed Bad™ comes back as the New Amazing Thing™... except that it's really just the so-called Bad™ thing with a slight twist.

One could argue for or against whether it could be considered "security" issue-it depends on the context. The equivalent of this issue is your client includes info about endpoints-either defined manually or through code generation, for example, but are unused. Unless you had some profiling tools that could flag unused endpoints. The counter-intuitive part is that you'd expect the bundler to not include any unused exported actions, just like any other module bundling does tree-shaking. Rhys is just pointing out that it could leak endpoints that you didn't intent in case you thought it was tree-shaked. Vercel fixed this in Next by tree-shaking the unused exported actions as you'd expect. The upside of this is that it's easier to augment unused endpoints through static analysis, compared to a lot of codegen solutions.

“Express middleware” IS middleware lol, its a pattern used in all servers, nothing to reinvent. Also, yes, NextJs should totally do that, because the current “middleware” is not actually a middleware at all, at least not in the user space

next safe actions

No their goal is to "ship fast" "even before it works" in a goal to lock developers into their ecosystem so they can rationalize how an AWS reseller got a multibillion dollar valuation.

@@furycorp you cant say there is no effort being put in to this

Yes, server actions are just functions converted to post endpoints but it acts like an rpc call

@@heunha9269 say I have a use server action in a form at app/dashboard/page.tsx. how can I call it using postman?

Same thought I had. You can move the function you want to test to its own file that does not "use server" and test it from there (this was shown in the video), but that's annoying. Ability to test random things without exporting them is one of the things I miss most working in JS/TS compared to Rust.

Yeah that’s actually one of the benefits of classes. Assuming your using typescript you can mark the method as private but still allow them to be accessible for testing.

and what's your alternative then?

@@martinlesko1521 OpenAPI and real backend with trpc-like feel??

@@martinlesko1521 trpc and client-side components is all you need and far superior. server-side components is like taking a step backward.

it clearly is a react issue. You are adding more and more complexity between the library and the developer. ReactJS went from a library to now having its own compiler.

That's why I keep using API routes in NextJS instead of server actions. Less magic going on.

I totally agree! I tend to use the new stuff without fully understanding the implications of it or sometimes even not understanding the implications at all, but just doing it because it makes things easier 😅

True anyone that has implemented similar things in a proper backend environment with API and stuff will realise that it needs to be protected as it's exposed I don't get it why don't people wrap their heads around this aspect when writing server actions

@@sulavbaral9972 These are frontend devs we are talking about. They don't worry about user input, that's backend guys' problem.

*frontend developers

@@sulavbaral9972 because it's not immediately obvious is basically an HTTP route. That important details isn't well communicated.

@@kylemichaelsullivan Bingo

But what if one endpoint is supposed to be public and the internal function not?

True - which is why it is our job as development leads to create a system in which developers are less likely to make these mistakes, through code organization and composition - as we do in any other backend framework…

React itself is a footgun

Its not a security issue its a skill issue

@@rob6129 most security issues are skill issues. Memory leak in a C code base, skill issue. Still a security issue.

​@@rob6129the issue is actually the fact that this kind of thing should've never come into existence in the first place. Security issues arise from either software problems or, more commonly, anthropic effects. In this, like in many other cases, it's people trying to cut corners and take shortcuts when they really shouldn't.

​@@rob6129 It's called the "separation of concers". And it's the simplest form of it. There is one thing that is sure - human error will occur. We want to minimalize the chance for it as much as we can. Have everyone forgot OpenAPI? You can generate trpc-like endpoints from nearly any backend language without much hussle...

server actions are literally “separated backend api calls”, you are missing the point

Because it's more convenient but convenience is the bane of cleanliness, efficiency, security and basically everything else other than development speed. People care more about putting out garbage quickly than putting out good stuff slowly.

This. Documentation should be like a user manual to a dishwasher, where on the top there are all the dangers listed, and not a novel, where you gotta read it all before you get it.

It is there in the docs

actions are basically running on server, aren't they? if not, they are just js/ts functions..

I like that idea, make it part of the jsDocs or something so it shows up in the intelligence anywhere the function gets used

php is not insecure lol reddit reader spotted

​@@MrManafon Tell me you have no cyber sec experience without telling me you have no cyber sec experience

php isn't insecure. Neither is JS. The problem is always bad developers. You have plenty of those in both communities.

@@fallenpentagon1579 Poorly designed language and frameworks lead to devs making more insecure software. Crap tools = crap software.

@@fallenpentagon1579 You think only bad developers make mistakes? _Every_ developer makes mistakes. The more robust the language, the more safety nets there are to help catch those mistakes. But these languages are also made by humans, so every language can be considered insecure to some extent. But, on the spectrum of languages, I definitely wouldn't put php on the "secure" side

yeah, folks really don’t understand that its just an api, and issues have to be solved through code composition and organization, not by nextjs placing fake guardrails. Same thing happened back when react couldn’t explain to people what dtos are, and ended up implementing a crappy field level sccess control mechanism 😂

​@@MrManafon people don't even understand how to have proper access control and then complain saying it's an issue lmao

MFW people use cookies which are ass to validate in middleware due to how poorly designed middleware's "edge" runtime is.

@@hello19286 MFW people convinced they need globally distributed "serverless" "edge" functions for apps that will never have a lot of users nor a global audience and so they make sweeping compromises on security, architecture, and design decisions to meet this set of requirements that they don't have nor ever will

If by "skill issues" you mean: a completely different specialty and foisting this on them was always going to end in tears

it's too hard

😂

oh boy

You’re all probably expect me

both are terrible decisions

i take that back. i see i commented too fast. this is not authorization but rather obfuscation.

This is the way