The 'SQL In React' Drama

I think we can all learn from this. Next/React, server actions, sql, "use server", I get why we're confused. Hopefully this clears up a lot of that confusion.

SOURCES

S/O Ph4se0n3 for the awesome edit 🙏

[jenreiss]

I think at the end of the day the big issue here is that pretending that the boundaries between server and client are completely arbitrary is just a lie. in 99% of situations, the server is on one machine in one physical location, and the client is in a different one, often separated by hundreds of miles and many network hops. This SQL in Component code pretends like the internet is the one giant monolith and that you can access any part of it from anywhere it, which is just patently false. Eventually, no matter how sweet the lie is, somebody is going to run into a use case, or situation where the real fact that there are two separate machines communicating with two separate sets of data and two separate permissions schemes, will conflict, and this giant house of cards will come tumbling down and they'll be stuck with their heads in their hands trying to debug 5+ years of idealistic client developer dreams

[ktxed]

this is not fun, this is just php in new clothes

[HamdiRizal]

We've come full circle back to PHP

[cblanquera]

No methodology approach. There is no server. There is no client. No need to separate. Just put everything in your page file and build up that technical debt.

[dimitrisefstathiadis]

Well. All is fine, but in reality the backend is needed for non trivial projects. If y have 3 resources that Crud cool. But when you have Authentication, Authorization, RBACs, Sessions, Postgres + Caches, Stripe Subscription + Payments, Plans, SMS, Email Scheduling you typically need a robust backend. The problem with tutorials is real..

[nou]

This is what we used to do years ago with PHP and it was considered bad practice. Now you are telling me it's cool?

[okikejiani]

Please tell me this is satire... There is nothing about the example that is shared here that is good clean maintable code.

We did this for years in PHP, eventually realzied it was wrong. History repeating itself.

[lionlike]

These hipsters just can’t help themselves….

[CottidaeSEA]

The reason why I am against things like this is for a single reason. People will make abominations.
I've already worked in multiple codebases where people fetch, mutate and render data in a single file and has made things impossible to maintain.

[AncientSocrates]

Web dev is a joke.
And I dislike frameworks that try to be too smart, and do magic behind the scenes.
This doesn't also teach you anything, because you have no clue what is going on, you are just a tech witch doctor.

[nordern]

My problem with these tag literal functions is that they always *look* like the wrong thing. Like, we have spend years training people to be afraid of exactly this kind of string, and now we make a syntax that makes that OK.
I'm not saying taking the obvious naive solution and just making it work and making it safe is bad, but that it comes build in with disgust and fear around it, and such a reaction to it is perfectly understandable and predictable.
Same might go for the use-server stuff. I have seen beginners in PHP confused why they can't run their PHP code when someone clicks a button. It's a classic beginners trap. So now these people learned "the proper" way this works and when they see code with "use server" that they assume it's just uneducated, or subconciously get mad at it because they had to learn all this other stuff.

[BCRooke]

If you’re building a pet project, separation of concerns is not as big of a deal. But can you imagine migrating to a different technology when there isn’t a nice separation? It’d be so much harder

[rifaldhiaw]

I think the problem is that React used to be a framework with very less magical things, and that is why it's popular.
and now it become hey this mark mean this and this

[filipg]

Couldn't be web devs fighting over syntax instead of solving problems. This industry has done nothing in the past 10 years other than glue together stupid syntax and frameworks in 1000 different ways. It's not SQL in react server actions that is stupid. It's the entire industry, you all need to do some serious grass touching and realize I don't want to wait for 10 seconds for your bullshit code to draw a button. Web would work just fine with 95% less code, you have lost the plot.

[shapelessed]

First thing I would think of when seeing SQL inside of a client-component would be "Oh, nice, they probably use some kind of compiler or what not to replace the sql with a fetch call on the client and generate a corresponding REST endpoint on the server".
The only thing I would be wondering how it's done is authentication in this case, but otherwise it looks really nice. I always found it frustrating to do a bit of frontend, then a bit of backend to check if everything works, debug both and repeat. I hate it when I have to switch between the two, because when you can focus just on a single thing, you get into a deeper state of focus and it just goes faster.

[pushyoch.]

"use server" acts wayyy too much like a magic word/phrase. is there no other more pleasant way to wrap the functionality?

[Zayelion]

Reminds me of linq, but my problem with it is it's not terribly clear where everything is happening. The framework is doing a bit to much work.

[yojou]

there's nothing you can say to me, when i see that "use server" i will ALWAYS cringe

[richardhaddadau]

Supabase capitalises on this a lot. Taking advantage of the server side, feeding into the component.
It's made my most recent projects so much smoother and cleaner when working on them.

[daveism]

Watched the whole video and am even more concerned. Mainly, how can you enforce authentication and per-endpoint authorisation (or even something like Role Based Authorisation)? Also, everything posting back to the root directory of the site seems like an analytics nightmare, no? For example, how would I go about investigating the API surface for issues? Please reply if you have answers.