The "SQL In React" Drama 

Modeselekting

Nothing wrong with PHP, but this also gives us types and LSP support inside our templates, which is missing in PHP templating languages, my ideal paradigm would be db to html in as least steps as possible + LSP in templates, this is really close, but I would prefer to do it in a BE first framework (GO keeps calling me to learn it), and do the client stuff with vanilla.js, the whole rerendering model is convenient for writing interactive stuff, but its bad in performing, its too much bloat served to the client for our convenience of writing state dependent UI's declaratively.

Well this has actually happened already. So when dealing with dates and server side rendering there is an obvious problem. If you generate a date on server and then try to hydrate it on client then you get two slightly different dates because some time has passed between the two events. This results in a hydration error because the hydration needs the state to be the same between server and client. The proposed fix by react team is to monkey patch the standard Date class which is a horrible idea imo. I'd much prefer if they just gave their own wrapper around Date instead of messing with the standard classes.

@@wlockuz4467 Where can i find out more about this decision by the react team?

100%. No matter how many frameworks people get tricked into supporting, the scaffolding stays the same. If you only know the framework, and not the scaffolding, you have always built a house of cards. Imagine that React has an unresolvable critical security flaw in it, or Primeagen becomes CTO of your company. You have to pull the framework, and 99% of your "engineers" are gone instantly because they know how to framework, not architect. It just takes one such instance and people are back to the old stuff, and the new guys aren't getting paid for that...

I think server side rendering in general is a mistake. The majority of end user devices are very fast at rendering web pages. It leaves all of that compute power entirely unutilized. The last thing I want in my UI is for a backend change to cause a cascading affect throughout my application. In angular we separate out an api mapping layer specifically to handle server communication and map it to a front end contract so when a backend change is made only the mapper layer is affected the majority of the time. I don't want my UI to be exposed to backend complexity. Nothing to do with "separation of concerns." Instead we are isolating and segregating the complexity of the two applications.

method 1: need nothing but when over 10 lines put in own file 🤡

mix php with not composable markup was bad practice ofc HAHA

This is still not the best, because most of the time I'm confused what is client and what is server

You didn’t though this is setting up an rpc. I’m not saying it’s right but get your brain rot out of here

@@amogh708 That's a thing, I hope that with the new tools that comes these months that problem it's settled, you can learn though

It isn't what you used to do with PHP though. It's specifically different, which makes it different.

Yep. Accidentally add some brackets around this and it's vulnerable to injection. Makes it much harder to catch mistakes like this if the "correct" way looks the same at first glance.

@@SwoopWoW I hope the devs have thought of that and calling the sql function with 1 string argument (when template functions requires the 1st argument to be an array, and 2...N args are any type, or they may not exist) will yield an error or something... preferably even before running the code, e.g. highlight it as an error in the IDE.

Doesn't sound like a problem at all. If someone is writing an app using a stack that generates server code, they have more than enough capacity to understand what is happening. New users have to learn all kinds of things. It's not like you could drop this in a random HTML script tags and accidentally nuke your DB. It doesn't point anywhere without the compiler.

Well perhaps we should have "spent years" teaching developers WHY writing SQL with concatenated variables is bad, as opposed to teching them to be afraid of seeing SQL.

@@MrManafon That's not the point. They know why concatenated SQL is bad. That's why it causes issues when you introduce a syntax that looks exactly like concatenated SQL.

Did you watch til the end? You can do exactly what you stated. Separate concerns at will. The first demo was just to show one way of doing it and it was mentioned that this is NOT the recommended way for production projects. But it's a good way to write code when you just want to prototype something quickly.

This is why a strive for less dependencies, which admittedly is very difficult in Node land. The more abstraction you pour on top of everything, the more locked in you usually are.

I understand you and I properly disagree. If you are designing something specifically to be migrated later, just writer it in the language that is its final destination the first time. If someone 20 sprints from now wants to migrate it, it should be never be the dev that gets blamed for the fact there wasn’t a design choice to make it easier to migrate. Do you see what I’m trying to say?

@@airkami changing technologies or refactoring code is quite common, and almost always without foresight. Maybe you have a new customers and therefore new requirements. Or scaling issues. Or maybe a product feature didn’t land well and you need to redesign. One recent example that comes to mind is Uber moving from Postgres to MySql. Ain’t no way 20 sprints ago they said, “alright let’s implement it in Postgres, but ultimately we want MySql”. That’s asinine.

@@airkami No one is designing anything to be migrated later on, its just that in real world changes are bound to happen. You can not always predict the whole product specification and requirements from the first step and you might need to pivot at some point. You pretty much always need to pivot at some point if you have an actively developed product, the question is usually not if but when and how much. The dev should be blamed for not accounting for the possibility of a pivot because any decent dev should know that they are bound to happen but the dev shouldnt be blamed for the lack of a full fledged migration case planning. I really like Theo and his content but those "arbitrary boundaries" are not really that arbitrary, they are there for a reason. I dont suggest going crazy over very strict rules and making a very simple project a fragmanted mess in the name of separation of concerns but striving for those "boundaries" without losing sight of what and when you want to achieve something is the key imo.

People overthink this. Separation of concerns is frequently an exercise in futility. CSS and markup seperation for instance. 50% of the time beneficial and 50% detrimental depending on the project ie Apps vs Information sites. When structuring code, the lines of separation are also very arbitrary. For example, the vast majority of SPA's have a custom endpoint on a custom backen for a specific purpose that is so tightly coupled that it is really only useful from that one place it used in the frontend, but now it is split into two places. I separate based on future anticipated pain points. Sometimes a monolith makes sense. Sometimes a bunch of micro functions make sense.

Thats why I only use assembly

@@deadchannel8431 assembly is magic too, do you really trust an "assembler"? Thats why I only directly write the machine code, just like von Neumann intended (yes, really. Look up his stance on assemblers)

@@RepChrisyou’re using computers? Pathetic, I bang 2 rocks together like my ancestors did in the neolithic period

Just use remix then.

@@Adityacode To me "Just use Remix", for like 99% of people in the small group that actually needs strong SEO, the bloat of Next and it's "magic" will just impede them.

Like old PHP

It has been done since the dawn of programming UIs. It will be done again.

e.g. PHP "templates"

How is it impossible to maintain? If everything is in 1 file you can just modify whatever you need, it's very nice and straightforward And if you need the same logic in multiple places you can always extract it into a common function and call it from whichever file needs it

@@pokefreak2112 You're essentially suggesting a rewrite and at the same time claiming it's maintainable. Do you see the issue?

Kind of remind me the old "runat=server" attribute for asp (?)

solidstart used to have a server function macro which was a lot better in my opinion. they switched over to "use server" not that long ago unfortunately.

Yes, this is what I want to see, authentication and some security mechanics when using this approach.

wait wait why would anyone do that? if something like that is gonna be compiled away anyway to REST endpoint ?

you can access the request header and cookie inside the server action to do authentication and authorization, they basically recommend to treat server action like a public facing api.

It's not the sql call that is transformed, its the call site of the action within client components. The action will be placed in the server bundle, then the call in client components will be transformed to an endpoint (actions are executed based on their ID from the same queue). Your sql call will stay as-is on the server-side.

@@dealloc You just said that I'm both right and wrong..?

Based

Yeah, I've been web developing since the late 90's and can attest that the problems we solve today are not much different from 25 years ago. Back then the tools were much simpler, now web tooling is like a fever dream. But they are all within the same basic paradigm: Read the data storage, template it into html, display. Receive user input, broadcast to server, save to data storage. Over-engineering and the pursuit of 'hip' tooling prevents web development from ever leaving its adolescence.

You will wait for 10 or more seconds because the business wants SPA and all this beautiful interactive stuff. We have a lot of light frameworks of meta frameworks, but businesses are more interested in heavy SPA

this is completely based... web has gotten a lot better, websites got significantly faster in the last years with better UX/UI and easier to build just because of the advance of technologies like react.js,next.js and its competitors

more react code spaghetti that's for sure.

What do you mean? The middleware would just be a function.

You'd probably go api first and someone or team take care of api since api will now have to be documented, maintained and enhanced as requirements dictate and evolve. The api becomes it's own living project with challenges and complexities.

If you are creating a 3rd party API, why you even use Next.js?

@@drosi1994 maybe recency effect and his brain has freshly cashed knowledge on next js backend stuff. Why would you pick and not pick next?

@@drosi1994 We are not yet. I'm evaluating options for a project that we are starting in a few months. I'd like to be able to use RSC because the pattern seems cool and would work well for the first party UI of the application, but the requirement of having the API accessable by 3rd parties is my sticking point

@@Mr_Simmons I think it's going with the api approach and consuming the api is your best option. This is because doing rsc would effectively duplicate data calls. But I believe you can still consume your own api using rsc. You will have to build your api either ways for the consumption of external parties. Dog food the api by consuming it yourself. That way you see also validating the api. But what weighs more in making the project successful? Third parties consuming your api or your internal use?

It looks like another abstraction layer is needed. Theo created only data abstraction layer, but to have per-endpoint authorisation another layer will be needed, like controller/presenter layer, which will check that current user actually has rights to access this resource. So final code will look something like: formAction={async() { "use server"; await UserPresenter.deleteUser(id); }} const UserPresenter = { deleteUser(id) { const currentUser = await getCurrentUser(); if (hasPermissons(currentUser)) { await DL.deleteUser(id); } } }

do these in the server action. Basically your auth your user before the db part is fired. If the user isn't allowed to do the thing you return an error

Yeah, but the EF core framework is specifically to deal with SQL ORM - this is just some straight SQL bang in your react code.

wym? do they use a custom InterpolatedStringHandler?

"a bit" :D :D

Idk I like dotnet a lot. You can also always inspect what kind of queries are ran by LINQ.

the crazy part is when you use "use client" and the component is still rendered on the server initially

A “wrapper” would be describing different compiler behaviors via an import, that sounds much worse to me

Or... you watch the video for long enough to realise he suggested a solution for that: having a data access layer, where you abstract away the DB functions in their own file/folder and call them in your server actions. But better question: Why do you want to understand the API surface of your app anyway? APIs, for us web devs, are just a means to an end, to get DB stuff or Auth to run on the server. It's only so that our UI can work. The only time you'd need to worry about your whole API like you suggest is if you made a public-facing API, but you'd obviously not use this pattern for that.

Most apps are being built to serve some kind of frontend, so if you wana see what the "api surface area" is, just go to where it's being displayed it can't really get any clearer tbh.

Well, if you wanted an API you should really consider building an API. Do you laugh at racing cars because they don't have pickup beds? Do you insist that all buildings should be built from the same materials?

@@chipmo if you're building some website, the API is all publicly available endpoints whether they were designed or not. From both a security and maintenance standpoint, obscuring the API by embedding it in UI components is a complete nightmare

​@@robertlenders8755 The amount of security/DX/UX issues caused by creating an API layer just to serve a frontend is the exact reason these new patterns exist. Having an API doesn't equal good security and maintenance, having a good a setup and good practices ensures that, there's no reason this cant be achieved by "embedding" it in the UI, just abstract the functions to an "API" folder and structure however you like, and you've got the exact setup an API could have, but just without the crappy network code. so much cleaner.

Not really, this just feels too much like magic.

most of the wasm frameworks are based on js frameworks. leptos is a clone of solid/solidstart with colocated server functions. dioxus also has server functions. the main benefit is server side performance, not necessarily dx on the client. although in my opinion, the dx is better but that's subjective.

although that is probably something that can be easily cought by a linter (calling multiple server actions from a client function => fix: turn this into a server action instead)

But whether it's a function or whether it's an api call, you still are running the risk of sending many requests? so to me it doesnt seem any different - other than the fact you dont have to wire up a network call anymore, so long REST/gql :D

​@@jackjsy From what i read in the docs you can just call the server actions as normal functions inside a server function, which means that instead of sending out 20 requests form the client to the server, you would just call the function 20 times serverside Also even if those 20 calls weren't other server functions but actual requests, if those requests are sent to your service infrastructure, sending them from inside the cluster will have almost 0 latency And then there's also ratelimiting which might get triggered with smth like that :D It's not a massive issue, but i think one of the only "fair" criticisms i can come up with for this "pattern"

@@dahahaka Fair points!

React is PHP way. Angular is java way

It always was the PHP way.

It is PHP all the way down. Always.

Is it because things are rendered on server by default? sry if it's dumb I don't use next js Edit : ah mb I continued watching the video

“use strict”

That's the best part, you don't have to use it if you don't like it. It just gives us another option to compose how we want

You seem to think that people care about how you feel about this.

@@lyovson well you seem to be offended, who knows why

Can you elaborated on the standards and norms. I've tried. DotNet a few times and it boggles me to infinity the amount of configuration and intermediate stuff the must be setup just to get some things working. Did DotNet /enterprise become that way because of things like regulations and traceability?

​@@elmalleable Yea, pretty much. It's so traceable that it has a ILogger interface baked into it that you can leverage with any number of "Factory" solutions (NLog, Serilog, etc) It's written that way so you can flip out modules, components, libraries at-will even if very few teams ever make use of that flexibility. --- ... so. .NET implies .NET Framework; which is 4.8.1 and earlier; this is what WinForms and MVC 3/4 were most likely written in. When you see 'dotnet' written out like that it's implying it's dotnet core; so effectively dotnet 5/6/8 (usually whatever the LTS version is at that point in time). .NET Framework = 80% configuration dotnet 8, one file of dependency injection and configuration, the rest is code. At the end of the day dotnet is all about rapid application development on enterprise solutions, so it needs to be durable but also dynamic enough to handle oddities/nuance that business logic dictates. It's meant to be written with "do not repeat yourself" in mind, but "enterprisey" code is also supposed to be written in silos, meaning THIS branch of logic shouldn't effect THAT branch of logic directly. That's why most modern dotnet is going towards CQRS and/or Mediator Patterns where you can just write hot-swappable micro-services that simply move data around to conduct individual pieces of business logic.

@@elmalleable It's more that Microsoft products and their ecosystem are just very well suited to large organisations. Doesn't matter if the dev experience sucks, they're not the ones making the decisions on what to use.

ah, shown at 21:13 - the form has hidden input fields with encrypted data, those values are POST'd in FormData to `/`

🤣

but acktchually php era the Frontend is backend code eh?

🤣

It is

It's separated in functionality, not separated in files/code. Your server needs can live right next to the client needs. However I feel like this just makes things less straight forward to address in the future. I'd rather them be more separate so I can address them separately as needed.

​@@FrostbytedigitalI tend to agree. I have API services that operate as a backend to multiple different clients, and having all of these in React doesn't seem to be a particularly good solution to me. On top of that, this seems like an abstraction over the communication that's actually taking place and that seems like a really easy way to shoot yourself in the foot.

I have to say I’m not big fan of React, it has some usages but for most cases HTMX, Go/Kotlin/Gleam and strong usage of Views are perfect for a lot of web apps that I need to build and maintain.

Do you think the value gets passed in without being sanitized?

@t3dotgg it is not changed in any way,it is not sanitized, it it just passed as a parameter. But it is safe to use, sql injection is prevented by using parameters for sql queries.

Back in the day sanitation meant rejecting strings that contain quotes or backslashes, or stripping those characters. Some even spit more backslashes into the string when accepting HTTP parameters assuming that makes it safe to use, assuming that is how it is done in the used DB, whatever that DB is. These days you don't do any of that. You either generate a proper string literal when the query is generated, or even better if the DB interface allows it, you pass the SQL string with ? for where the parameters go and pass the parameters in a separate array (however that all gets serialized) and let the DB's SQL parser handle the ?s. I assume that this is what is happening in the background here. It's not what was classically understood as sanitizing SQL strings. Maybe the meaning changed nowadays.

@@doofer149 sql`` is a function which sanitizes any parameters passed into it

​@@blenderpanzi It doesn't need to be sanitized. Postgres, at least, prevents SQL injection by parameterization. That is exactly what this template JavaScript module does. I genuinely think this "use server" thing is awful, but it has nothing to do with SQL template literals. In my opinion these are better than most ORMs.

Is that what you see here? 5 languages and 3k LOC? No.

​@@JeremyAndersonBoisebecause this is a trivial example, but we all know that's what ends up happening

Then what's the way?? Also 3000 line components is really bad. Sign of a horrible code. Basically what I do in server component is fetch the data and pass along to other component. That component can be client or server depending on use case. You can always split the component into multiple files. Even if multiple components wants the data just pull out the data call into separate file and use cache functiion, the cache function ensures that it is run only once.

@@jitx2797 Yea I think we completely agree. There needs to be some basic separation. I was just saying in the previous comment that I have seen what having no separation leads to. I have literally seen files in PHP where it starts with html, then some PHP functions, then some SQL, then CSS, then back to html, then javascript functions, etc. And it's sprinkled like that in no order in the entire file switching between 5 languages.

Couldn't agree more. Wasn't some time while back someone exposed the "secrets" in nextjs because of this "use-server" shit ?? I think theo covered it too.

I don't agree. The future lies in server + client combo. The components that do not require client interactivity will be rendered on server and the rest on client. Super slick combo

@@rampandey191your comment is a bit ambiguous.

​@@rampandey191What future lmao. You soydevs are funny trying to spin decade old paradigms as something new that JS is doing.

@@nou4605 The old paradigms of the past only had server side rendering and not client side rendering. For client side rendering they had to use jquery which is a different ecosystem with its own set of problems. While in react everything is react no need to leave the ecosystem. This is very different from the past. Please understand things rather than copy pasting things from twitter.

yeah it's complicated for beginners I agree, but the technology is very cool once you understand it and you can save yourself a bunch of time and build stuff writing a lot less code and boilerplate while maintaining separation of concerns and security

supermaven

@@tefkah awesome, thank you :)

Skew protection is pretty cool :)

I feel like he addresses in multiple parts of the video. He lays out how you can separate concerns

Either edit it in one place, or edit 5 files like we do currently. Not sure why you think this is more work than now when underlying architecture changes. Seems more DRY to me

No. There are middleware and layouts you can run your auth checks in. To be extra safe, you can as double check with within the actions.

Authentication is usually done at the route level (there is frequently a shared file that represents the "root" of a route and set of subroutes. And usually in a server action. Authorization is usually handled in every server action running server code, sprinkled througout by typically a function like checkPermission("note", "rw");

Thanks, I found an example with a middleware.ts file that looks like it would intercept requests on the server-intake side, but I'm still missing the mechanism for how the client calling the use-server function is augmented to pass the authorization token.

@@flufster777 it’s better to store the token using cookies because that can easily be read by server actions.

@@flufster777 there is definitely a bit of hand-wavy black magic that happens under the hood which I think is tripping you up

Maybe you should actually step back a bit and try to understand what this does because i don't think you do 😅 and i say that as someone who themselves doesn't really like using js on the backend

Theo is a react Andy these nerds literally don’t know what their missing on with rails & Hotwire or laravel or phoenix liveview …

why do you think his data layer pattern is that bad compared to a more standard backend? honest question

If you watch carefully, Sebastien's article already mentions that this pattern is best for learning and prototyping only and http api and data access layer is the way if you want to follow otherwise

yes you are not getting it. the idea is that you don't need a bunch of files and a separated BE, you can have the same functionality of a full stack application with a lot less boilerplate and code writing - while maintaining separation of concerns and security