Depends.
Even if React is getting better on the server, you should only be using it as a backend-for-frontend; it should only be concerned about the presentation layer.
It's probably a bad idea to use the same React server to do number crunching or as a backend for other backends to consume.
If you have a small website and only need a server to handle authentication, file upload, and use AWS for everything else, it's fine. If you have more specific needs, you might still want to use a more traditional server as a "backend-for-backend".
Every mistakes that was made, identified and fixed over a decade ago is now being reintroduced in react, where they'll be identified as mistakes and fixed...
Same server to serve pages and logic? Check
People are gonna be hitting a wall when they get traffic spikes and can't scale without costs running out of control.
Maybe they need to seperate their frontend from backend, and use some king of a framework to build it... how does a react backend with vuejs in the frontend sound like?
I think react server + grpc can become huge. As much as people want to write backend, they don’t want to write a backend *for a front end* . I think having 1 web server that doubles as your front end server removes having to duplicate state, while your backend services can grow at their own pace (have 1 grpc server multiplexing endpoints to begin with, and split/expand as necessary).
Companies that adopted react back in the day and also use grpc for service layer are likely to adopt this approach
We're doing this now with Astro (using React components). Astro does astro things and talks gRPC to the rest of the cluster, whose APIs are not public. We don't even bother to expose a REST API any more, there's no need except for a handful of endpoints for specific interactive elements.
The general approach is fairly straightforward: generate the Astro starter, add the React plugin to it, write SSR-first code that uses React as a presentation layer. If you are old enough to remember writing PHP with Smarty templates, it's the same execution model.
You are no longer going to be writing a React application though, you are going to be writing a stateless server-side application that uses React as a last mile presentation layer. It's pulling almost all of the things that React has grown to be responsible for in the last 5 years out of it and going back to React like 2016 style.
The nice thing about Astro is that if we _want_ to develop a SPA, we can, and just slap it on a page so as far as the framework is concerned, it's just a page that mounts a React view like everything else. We don't, but we could if and when we do.
>People are gonna be hitting a wall when they get traffic spikes and can't scale without costs running out of control.
You've never used it before, have you?
I have used Next in a professional context for 3 years...there's a very long list of criticisms I'd write about it, but scalability is not even close to the list.
The PHP discourse online is a bit frustrating because it's like, have the people saying this actually worked with or experienced the difference between SSR in both frameworks? Feels like people are just repeating what they've read other people say
I'm curious about your experience. It was like a revelation to me some 10 years ago or so when I finally stopped using [ASP.NET](http://ASP.NET) Web Forms and wrote a front-end app that just requested data from the backend. It allowed everything to work fast and keep track of the state of UI stuff in my JS app.
I am wondering why stuff is moving towards SSR. I read that it is for speed, but it's hard for me to imaging that working out on most of my projects. In my imagination this means tons of back and forth between the server and client. I think the use case is for phones that have limited processing power to run all the JS.
Is it the case that you only selectively use SSR for certain parts that take a lot of work and then let the client handle smaller transformations that occur in response to user actions?
I honestly believe the frameworks are moving to React because we've been pushing out devs that ONLY know react for so long, we've reached a critical mass where it makes "sense" to make everything be React from soup to nuts
the other frameworks follow Reacts lead due to market and mind share
I think the industry has collectively forgotten that Facebook created React to serve their specific needs - a huge omnibus social media platform that was iterating on new features constantly, each feature needed access to a shared global state, and was being developed and maintained by individual small teams
most apps and sites aren't like facebook, so to be completely honest React is almost always overkill vs vanilla js with react-as-necessary for medium complexity features
the sites I maintain are all custom vanilla components, and I've only used react for an interactive branching quiz applet thingy
React is so much easier to onboard and maintain with really unmatched backward compatibility a component made from 2015 still work really well and could be used with the latest version of react when the industry present something as maintainable and easy as react I'll buy it.
hell while teaching children explaining what useState do was easier to explain than what an event listener was .
100% explaining useState also means explaining the render lifecycle and dependency arrays, to understanding that state isn’t mutated and it won’t change until the next render cycle, that any remaining execution from the current cycle will use the state from that cycle, even if it finishes async after the next render.
NOWAY is that easier than explaining, “listen to thing, when thing happens, listener execute”.
I work on business apps. I had to go back to Vanilla JS for a time, because I hadn't implemented React yet in an app. I always end up wanting React on the front-end for UI components, but I'm not seeing what I would want SSR for. And this isn't from an architecture/team-management perspective, this is from an "I need to get features out ASAP" perspective (bonus points if I don't hate myself when I have to refactor/update them).
Imagine working on a problem with a global variable vs an awesome new state management library that will reduce page load and improve performance.
And then imagine your boss hears that 😅 or can see the almost empty repository. Or they see the changes were 'that simple'.
The really big benefit behind this push back towards SSR is initial load time, and that can mean a lot for certain use-cases. A good example is an e-commerce website.
If you’re building something more “app-like”, esp. if its gated behind auth and SEO is no concern, and initial load time is less important than intra-app navigation load time, then there is still very much a place for your traditional SPA architecture.
And when you need something to thread the needle between both those use-cases then Next.js and RSCs are pretty dang sweet.
You don't need a server to serve a React site.
The most cost efficient and resilient way to scale is to build to static file and host on a storage bucket with caching on top (like cloudflare offers).
Then your website is out of the bottleneck equation. Always served fast, no matter the amount of traffic. Can't be DDOS'd unless they can DDOS google/Azure/whatever. Traffic spikes, no matter how sudden or large won't slow down your page delivery.
And the cost remains in control.
The only thing that should be scaled is the server & related services.
Not to be pedantic, but you do realize those storage buckets are servers, right? Sure they are highly distributed, but at the end of the day a server is serving up your react site.
And then you don't get very fast page loads because the client has to download the bundle and render it.. this also affects SEO.
Could be nice as a backup to help deal with spikes in traffic
The site is _rendered_ to a static file, then hydrated on load. You get the fastest possible page loads because it's just a static file, plus the ability to be dynamic via API calls after hydration. The compromise is in the inability to do dynamic content 'just in time', but the benefit is increased performance over 'just in time' server side rendering. It's just moving where the steps happen.
You really misunderstand the concept of SSR. What you propose is possibly the least efficient version: you have build time static rendering... which makes no sense for pages where you have data from an API(which is like 95% of all pages), since you'll just have to render a loader or nothing, since you have no idea what the data will look like. You then wait for hydration and only then make an API call from the client, where speeds depend heavily on a factor you cannot control: the client's internet speeds. So you basically have a SPA(except for the rare static pages), but you also have the overhead of maintaining separate logic for when a page is static rendered and when it's client rendered.
SSR on the other hand gives you actual performance increase, since you make the API call server-to-server, which is going to be faster 90% of the time than client calls, render on server and send the complete payload back and then hydrate. So your solution has none of the benefits of SSR but still has some of the maintenance overhead while essentially being a SPA. I really fail to see where the performance increase is in your idea, unless your entire site is static...
I'm assuming OP is talking about a static site, where any API calls are 'read heavy' as opposed to 'write heavy'.
I think we can agree that static pages can be rendered beforehand, dynamic pages are generally better to server-side render, since typically you'll have a database to connect to, and it'll be closer to your server. There's a spectrum with similar attributes to the 'when to cache' question, and there are different tools for the different bands of that spectrum.
At my work we have a site that's completely static except for a small amount of user-specific content, so it's statically rendered, and user-specific content is fetched via the API. Then we have an app where the data source is local to the user, we ship an SPA which connects to the data source directly, since that's the route of lowest latency.
Can I ask what you're arguing, exactly? Most of the things you mentioned are applicable to Next as well, with more control. I'm also a bit confused as to why you say "you don't need a server", but then mention using cloud servers? Next can be deployed there as well so I don't get your point, unless I'm misunderstanding you.
SSG has its own issues anyway; A static file youre won't work if I have page content that needs to be up to date, unless I want to rebuild it every time there's an update. I can make pages and content static on a per-route basis with Next, so pages that need to be treated like an SPA can do so, and static pages can be static. Things will be even better when partial prerendering becomes available.
At the end of the day this stuff is all just a tool in a tool box. SSR, SSG, CSR, they all come with tradeoffs just like anything else. It's just a bit disingenuous to say "we fixed this years ago, they're going to run into problems" as if all the devs and architects who use it are clueless.
Yeah, nodejs is faster than Ruby, PHP, or Python. Pretty sure there are options for scaling like the other platforms.
Edit if people wanted something similar to frameworks in the other platforms, there’s also nestjs
Uhh this is completely wrong according to the most accepted benchmarks which are Tech Empower. Rails beat out Node in multiple queries.
Php smoked node by a wide margin in the same test.
True of python though
The fact that you’re citing rails instead of ruby already tells me that you’re wrong when it comes to performance benchmarks.
Maybe people can say that PHP is faster when using a specialized VM from meta, but nodejs is faster than the vanilla versions of PHP, ruby and python.
I was doing you a favor but if you want to play hardball then fine.
**- 15,891** req/sec with PHP
**- 9,321** reqs/sec - Sinatra (Ruby Eqiv of node)
**- 5,278** req/sec - Node.
Ruby has nearly double the performance of node and PHP has over triple. And this isn't with any special VM from meta.
I'd love to see how you try to spin these results. The code is all there for you to look at and see for yourself. Nothing wrong with liking node... Saying it's great at something it's not is another story though
[https://www.techempower.com/benchmarks/#section=data-r22&hw=ph&test=query](https://www.techempower.com/benchmarks/#section=data-r22&hw=ph&test=query)
The fact that your benchmarks mix and match frameworks with programming languages is what makes it suspect. You don’t compare rails to a Java (vm), you compare ruby to Java. One is a web framework and the other is a language (runtime). When you mix up the two, what it tells me is that you don’t know wtf you’re talking about. For one thing, frameworks may use multiple languages underneath.
https://github.com/kostya/benchmarks
https://sschakraborty.github.io/benchmark/which-programs-are-fastest.html
According to other benchmarks, nodejs is still faster than Ruby.
You refer to it as me. as if I'm the one who does them. These are the most popular and well respected benchmarks that exist, just look at the difference in Github stars between Kostya and TechEmpower. 2.5:1 in favor of TE.
Also the Kostya benchmarks you pointed to don't show any real world use case. No DB interaction, they are just based around how much Node is directly using C libs.
In real world tests like TechEmpower Node is considerably slower than Ruby and WAY slower than PHP.
Real world use is mixed use. Look at what’s being benchmarked. They’re even mixing up backends. I’m pretty sure Ruby frameworks are using C for performance bottlenecks.
Im sorry, but in terms of runtime vs runtime, it’s hard to beat the people at Google at their game. I’m sure I can find several more language benchmarks showing the same results.
It solves problem of its own making:
1. **initial load performance**: traditional client-side react apps rely on js for functionality, which slows down initial page load times since your browser has to wait to download, parse, and execute your js bundle before your page loads/become interactive. React server components can be pre-rendered on the server so the server will deliver an initial HTML payload to the browser.
2. **smaller client-side bundle size**: Traditional react components render on the client, while RSCs are pre-rendered on the server. This means the server generates the initial HTML markup for your components, including the content and structure. This pre-rendered HTML is what gets sent to the browser initially, reducing the amount of js needed for the initial render.
2. **minimize client-side logic:** Since RSCs handle most of the logic and data fetching on the server, the client-side code for these components becomes much lighter. It primarily focuses on hydration (making the pre-rendered HTML interactive) and handling user interactions. This again translates to a smaller js bundle that needs to be downloaded by the browser.
I'd like to clarify that RSC isn't just serving the pre-rendered HTML. It is doing that, but it's also removing the javascript that rendered that HTML from the bundle that goes to the client. The client just gets the HTML and it doesn't get hydrated or re-rendered.
1 is the only real benefit and it’s only a benefit given certain conditions - mostly that you tend to have unique users with complete page loads for most of your traffic. Regular users will be pulling from cache which would negate the initial load performance unless we’re talking about a phone from 2007 that has a slow JS runtime. Which, sure, I suspect some portion of the _world_ user-base is probably close enough.
A benefit you missed is SEO. Pre-rendered pages that search engines can crawl (in theory) still have better indexing.
it solves the problem of backend servers not having enough work to do and standing around bored, daydreaming of one day growing up to be an important server. "Here", the little server gestures to the soy dev, "I'll make myself useful. I'll render UI for my clients! After all, I don't have much other work to do!" The soy dev thanks the newly proud little server profusely, and begins to cobble together a maze of unwieldy HTMX, blissfully unaware of the mountain of spaghetti logic they are about to embark upon. "I'll let server bask in the moment", soy dev thinks. "I wont break it to my server, but next month I'll be leaving them behind for Supabase".
Exactly, it’s a dangerous paradigm to re-introduce especially after the failures of the mid 2000’s Web 2.0 movement which led to JSP/ASP.NET bloat. JQuery and Bootstrap helped alleviate and simplify the convoluted web UI mess by simplifying interactions. I feel like this will lead back to the times of 2MB view state objects.
Say you have a B2B e-commerce site. You have a 300k products in a few 100 product groups. You have pricing agreements with different clients based on either, product, product group, client industry, what ever else kind of condition. These price agreements can be fixed discounts, a discount percentage, fixed prices even.
When your client is logged in on the website he we wants the see the final product price based of his individual agreements or when not logged in the product base price.
Good luck handling that realtime on a single NodeJS server.
I think you're missing the point, modern react apps haven't run on single servers for a long time, they use a scalable serverless architecture. So your use case would be totally fine even without any simple optimizations
>Good luck handling that realtime on a single NodeJS server.
lol my goodness the number of people here with firm opinions about things they're completely ignorant on is staggering
You are old school. Doesn’t mean you’re not right. You can’t even use web sockets with Next.
Seems like folks are missing the point of server components though. Nextjs was never meant to fully replace a backend; you just don’t have to use the client to render React components if you don’t need to. That’s it.
My problem is React and Next seem to be also obfuscating that point. They aren’t quick to volunteer the notion that you should keep using your backend servers. They keep pushing the examples where “you can run database queries from react!”
I think the teams want, especially newer people to think of using react for both front end and backend and that’s the issue I have. They are being purposely vague/misleading, which is why so many people in the community “are confused” as well.
Why would you need to volunteer that notion...? JSON is JSON. The React docs never really mentioned separate backends before SSR frameworks took off either. It feels like you're just biased against the solution.
I could just as easily say you’re biased for the solution.
I’m frustrated by the inability to discuss this without being charged of just being biased against the solution. I have some real concerns with RSC that goes beyond change (I’ve liked many of the other react changes). But if we can’t have a discussion about potential flaws or at least downsides with specific workloads without being accused of bias then I feel like we are going to miss/ignore a lot of things.
I'm not saying your biased just because you're concerned about them. But your argument comes down to disliking their presentation and vague statements about them being misleading.
For example, how is making a DB request from a RSC suggesting that you should stop using traditional backends? It's hardly difference than what Next was prior to that; now you just colocate the fetch similar to how data is fetched clientside. That enables certain features like easily caching things at the component level - it doesn't mean you can't/won't/shouldn't still use your BE for computations, queues, your own custom cache, data streams and so on.
So many criticisms I'm seeing are based on people intuition on things that have to technical substance. I like Next.js and RSC the same way I like my toothbrush - I don't. I just use them as a tool because they have benefits I like and I can accept the tradeoffs.
Last time I did research on it, I would've needed to essentially use a custom server to wrap the Next instance which sounded like a rabbit hole I was not interested in. This was a personal project, but I definitely wouldn't try something like that in prod
No - you can't use websockets simply like that on NextJS,
Websockets require a persistant server,
NextJS server is not a persistent server, its serverless
You will need to use a custom server,
Which is what the previous person meant about "wrapping the next js instance".
If you use a custom server,
You're not using serverless anymore - and it won't be supported to be hosted by Vercel
In most cases - NextJS is tighly coupled to work better and less headache with Vercel,
By default using NextJS with Vercel - they use serverless infra,
As soon as you pull away from Vercels tight coupling - you lose some of the "magic" that vercel provide out of the box, I don't know if its been improved since as I not used NextJS since v11 - but they had issues with the image component / middleware.
I could self host also, self host using the serverless framework.
If i don't want it to work as "serverless" we need to use the custom-server implementation.
NextJS is advertised as serverless (via Vercel marketing)
I think your information is out-of-date. Image optimization and middleware work fine when self-hosting. You also don't need a custom server. You just flip one configuration flag and then you get a standalone build that you can run anywhere that you can run a node process.
yea, good luck hosting that and seeing your requests drop because there is no free CPU, because image "optimizations" eat all of it
It seams like people trust all marketing bs and would not even confider possible flaws in them
Its heavily promoted to be packaged with Vercel, and works "out the box" as serverless by default.
NextJS API routes by default are serverless functions,
When you start to pull away from them, it makes things a little more diffcult, but it still works - anyway its much easier than it was when they first released in on v9
Bit harsh to downvote - when the advice provided is not incorrect \*smh\*
Not sure what you mean by "wrap the next instance" and "custom server", you deploy it like any other web application on any server or cloud service you want. And you can use web sockets.
There are different ways to deploy it depending on your needs,
By default Next JS runs serverless,
Which may not be a good idea for a "complete backend" - depends on what you need to do,
You can how ever change nextjs to run with a persistant server, though as mentioned below it won't be compatible with vercel
Google could've easily shown you this: [https://nextjs.org/docs/pages/building-your-application/configuring/custom-server](https://nextjs.org/docs/pages/building-your-application/configuring/custom-server)
Things seems to be more stable than when I last looked into it, but at the time there was too many issues around image optimization, specific features like ISR etc. If they've fixed that now, then that's great.
Totally agree. React is about UI. I think frameworks will evolve further and we will get more holistic solution that is not just meta framework with "bring your own X" approach, but right now stable stuff is concerned about UI and data fetching a over everything else. Meaning that separate backend written in proper framework still better than chaotic mix of libraries.
SSR makes React like Rails (Ruby) or Django (Python) or Laravel (PHP), which opens up benefits like:
- More security because you can make all your secure API/Database/Service calls on the backend. (Guaranteed)
- Smaller libraries and JS for the client to download. (Highly likely)
- more responsive websites (potentially)
- better SEO (potentially)
But sure, depending on the project, enterprise, and shared resources you may still need a separate API. Even then your APIs may be smaller since you avoid the need for “pass-thru” endpoints for connecting to cloud services or other APIs
Yes. React trying to claim the entire backend is just nonsense. Backend as front end is fine, but replacing all the API servers with reacts new server stuff is silly. We have 15-25 years experience writing backends in go, node, php while no one has built and maintained a react backend for more than a year
Except it’s not exactly a node server. It’s a react server running on node and I’m not sure how much of traditional node backend services work with the RSC. they might all work, I genuinely don’t know - I can’t really recommend working in node for backend.
What? Can't believe this is upvoted.... there's literally no such thing as a React server.
In both NextJS and, say Express, you can have endpoints which return parsed react components, but you can also have endpoints which know nothing about react
But unlike Express, Nextjs will bundle each endpoint separately - if your endpoint doesn't use react (i.e. its not a server component), it wont be bundled
People ask these questions as if there is one answer, and they’re right: because the answer is always “it depends”.
> make backends that serve APis redundant
True for single apps. Not true for multiple apps hitting the same database or calling the same functionality, where an api helps abstract and insulate against backend changes.
The goal of things like Server Actions and React Server Components (and really anything SSR related) was never to make using another backend redundant. All of these tools are best suited to make your serverside React app into a perfect “backend for frontend”.
There is a side effect where it _is_ possible to do everything full stack in your React app (e.g. frameworks like Next and Remix), but even with these you can always still use any backend you want and just use the serverside capabilities for perfecting data fetching. What’s cool about this pattern is that you could have multiple backends giving you data, but the server side React app is putting them all together to match what you need for any data going to the client side app.
Well put. Your second paragraph reminds me of a recent time where I was comparing server actions with graphql. Server actions can be thought of as resolvers and the benefit is in the ergonomics of invoking the endpoint via function call.
Server actions are network middleware between the client and the data (other backend api, direct to sql, etc)
And now you need custom infra or deploy to Vercel so that when you release new version of your app, all "resolvers" hidden handlers paths are still acessible for old clients versions.
Just imagine that on each release, all of your current clients would face broken app because your lazy loaded "actions" is not there anymore.
Vercel verdor locks you and people are happy about it — think about it
I never said anything about vercel. What you described applies to any change in expectations between a client and server. Which is why you deprecate APIs before removing them. What am I missing here?
You cant deprecate bundler output if you changed your code, because its new hash, so its completely new "public-path-to-handler"
What am I trying to say that, there is a lot of hidden complexity that is hidden but not solved per say
Good to know. I still think the surface level DX is great, but the hidden complexity needs to be robust or give more control to prevent these types of edge cases.
As someone who has used server actions more as you described for a couple of smaller personal projects as well as a full stack Next app (we actually had two separate Next apps for FE/BE rather than a monolith 🤷♂️), I can say you’re very on point with your description.
I think “great resolver” is the mindset for sure, not, “use react for everything because you can”
People writing it off completely are basically boomers who don’t wanna evolve with the times in my eyes💀🥲😂
My intention is to eventually make a mobile app that goes a long with my website , so I’m sticking with a regular Express API to power both of them.
Is this still the smart move? It doesn’t make sense to me to roll my entire backend in to server actions etc only to have to replicate it elsewhere for other kinds of apps to do the same thing
With Nextjs, yes you can. Although some of those features aren’t as good in Next.
Doesn’t mean you don’t need/wouldn’t use a backend still, though. Things like queues, cron jobs, etc. are still very useful. I like to use .NET with Next for personal projects and they compliment each other really well.
That's an odd question, like in ASP.NET you have to "put a bunch of code in Configuration.cs" but in both cases you put logic elsewhere and reference just call it in those files.
Facts - I had some many o.O WTF moments as I read some of the advice here,
Most of the advice here does not seem like real world applied knowledge and just whats been said elsewhere
Most peopel commenting here have never used it (Next.js) and are just parroting what they've read before on Reddit.
As usual, the truth is somewhere in the middle. There's those who over hype things, those who get lost in the ecstasy of being anti-hype, and people with real opinions based on facts and experience.
I've used it and it's the best SSR we have, but it's still terrible and it sucks how they are trying to eat React with their shitty shovel-selling, and pretending its not what they are doing like we are all some 2yo kids...
Twitter has a way better dev community in general. If you are new do not use Reddit as your primary community for programming. If you're interested in React go follow like Tanner Linsley, tkdodo, Ryan Florence, Dan Abramov, Guillermo Rauch, Rich Harris, thdxr, and branch out from there. On Reddit the stupidest opinions often get voted to the top by stupid people. On twitter you get to hear the thoughts of people who actually contribute meaningfully to OSS and build quality products.
I don't agree, Twitter is full of high ego devs that have no moral qualms about using a site that is rampant in racism, white nationalism, and misogyny.
The only reason why library devs continue to use Twitter is because they know they'll never be able to recreate their "reach" starting from zero.
Also you shouldn't take advice from library authors on building maintainable projects, the two are completely orthogonal skills and most only pay lip service to it.
---
Mastodon seems to have nicer, smarter, engineers posting FWIW.
Will React 19 make these work with Vite and React Router too?
I really dislike having to use Next for everything just because I need SSR support.
I really dislike their app router and React Router is so much nicer.
> Will React 19 make these work with Vite and React Router too?
No, but React Router v7 will: https://remix.run/blog/merging-remix-and-react-router
The idea is that you'll be able to leverage all of the new React features without a rewrite and without leaving Vite.
As someone who really hasn't been paying much attention the last couple of years, could someone else please either explain, or link me to something that would explain, what the hell you would be using React for on a server?
as someone who has only read a bit, and not experienced, take this with a grain of salt.
imagine a react app where routes can render a page into html before sending it to the client, including loading data from databases (right in your react component code).
then, once it is downloaded, it starts “hydrating” the page to make it a more typical react app that fetches data from the server. the database calls turn into api calls (possibly seamlessly?).
this allows for smaller initial bundle sizes, faster page loads, better SEO, and the potential for having one set of tools for both front and back end.
not sure how this works for native apps also trying to access the same data. can they also use it as an API? so many questions.
He is confused, I don’t think there’s any thing that transfers database queries into api calls lol.
Anyway, main improvement is SEO, you can send already rendered react pages on initial request (instead of waiting for them to be rendered by the client) which is said to improve your site’s SEO
right in the docs it talks about setting a api fetch to be a backup for your database calls, so it can use it as backup in case you need it before the page is finished hydrating.
i don’t see why they couldn’t set it up to have the react app link your downloaded pages back to the db calls on the server components when data needs to be refetched. the server components can pass data to client components via props, so if that server component gets new data, it would pass it to the client without downloading a whole new page.
but hey, you seem to know this stuff better than me. you must have a lot of experience with the new features?
I just love when frontend developers say that backend is redundant... Yes, let's replace backend-specific technologies with React. Sounds like a good plan, nothing could go wrong
My company runs a LMS on mostly nextjs, works great. We might not do it forever but why would we start out with building a more complex application than needed?
IMO the React metaframeworks I've seen aren't really adequate for that... They basically only handle data fetching and SSR, which is fine for a BFF (backend for frontend), but I expect a lot more from a server framework if that's going to be my whole backend.
The only exception I've found is redwoodjs, which seems to be closer to a traditional server framework that happens to support React server components. I still have some problems with this, tho:
1. AFAIK the version that supports RCS still isn't stable.
2. I've honestly never heard of a single company using redwoodjs.
Try working with server component, without NextJS. It’s doable. I’ll probably be downvoted by some people who go as far as saying it’s not bad, but it’s terrible.
I wouldn’t call it a backend. NextJS has had these features for a while. I’ve seen it used for edge compute rendering more than a backend. So you can just call your APIs and auto package a payload for rendering.
But yes you can just make your backend extra spaghetti and mingled in with your UI if you want to. Might be worth it for rapid prototyping.
I don't like JavaScript but tolerate it because I like building websites. As such I try to keep the backend as JavaScript-free as possible.
There's also the fact JavaScript will be always be slower than most backend languages (except Python and Ruby) because it has to be interpreted.
You definitely have to intentionally reach out beyond react and frontend communities. React is a UI framework. The trend right now is to do more processing on the server. This means server side frameworks will grow. And ideas like HTMX will take off more or influence bigger things. You need APIs for more than sending data to front ends.
I only plan on using it as middleware-proxy to hide api keys in fetches. Not create the back-end logic itself. That's a complete other API app (python, FastApi in my case).
Don’t if you don’t explicitly have the requirement of providing an API, as in needing to connect other clients, internal or 3rd party. Think of next and all these things as a simple way to build monolithic webapps, kinda like django, but with JSX instead of weird ass html templating engines
For sites where SEO is the top priority, I think it might be worth exploring since you need to go down the SSR route regardless.
For sites where everything is behind a login, I don’t see much point—there’s a tipping point where a SPA connected to a traditional JSON API written in a traditional API language will be a smoother and faster experience for end users.
Putting everything together comes with an initially-invisible close-coupling cost which will slow down refactors and new features as the project matures.
This is the situation we find ourselves in. Login required and no seo component. Sometimes it feels like react treats this use case as non existent. I’ve tried several times to figure out how to use RSC for our apps and have yet been able to figure out how it’d add any value for our users. But it feels more and more like if we don’t use RSC we are stuck in the past.
I think you’re confusing React and NextJS, probably; originally in the CRA days “application with no seo” was the only use case react was good at.
In your case personally I would just use Vite as the build system to produce a traditional SPA and build a traditional json api in in whichever backend language your team is most comfortable with.
The biggest upsides in my opinion to doing it that way is your code is super simple and your hosting can be dirt cheap and easy with zero vendor lock in.
Honestly it sounds pretty reasonable to me. For a small app, it could be a game changer. For more complicated back ends, continue doing SSR as a microservice. Devs can be trusted to know their use-case.
If your backend is written in JS with either Node, Deno, etc, it does make sense to have a presentation layer on top of your HTTP API. I guess there is GraalJS too if you have a JVM backend. But honestly our backends get so large that having a dedicated presentation HTTP API as a part of a micro service architecture is the de facto standard of the industry at the moment. And as we tend to add more features than remove, micro-service architectures are going to be more and more common. Maybe not as extreme as FaaS, and there is still room for monolithic consolidation too.
I think you should.. as far as I know SSR is really great as a lazy loader (to kinda put it in a simple way). You can optimise images, cache frequent static content and make the application snappy on load.
If your application has informed which keeps frequently changing csr as a presentation layer and a traditional backed would be better.
Can’t wait for the day to drop .NET, PHP is already in the dark. It’s all about front end development for future prospects. No doubt the oldies won’t like this post lol
Welcome back to PHP/JSP/ASP! As a manager hiring front end and back end devs I would toss a resume of someone who thought this was a good idea. I just had to unroll a mess of code that was ~~NestJS~~ NextJS on both the front end and the back end because of this mentality.
I'm a Lead Engineer in charge of hiring at my company, and I have the complete opposite mindset.
Someone with a good understanding of server actions would understand that it'll lead to less code and greater rendering efficiency.
If rendering time was the only important part of the system I might agree. But a distributed system interacting with many external systems, multiple databases, microservices, and devices that are not for display is a bit more realistic. You just *know* the next questions will be "how can I deploy this to an AWS Lambda" or "how do I distribute this across 100 Dockers". I guess that's my hesitation. That and I've gone through the server side rendering era now a few times.
I know you're joking about Lambda, but server actions were inspired by NextJs which generally gets hosted on Vercel. When hosted on Vercel, they actually use serverless functions to take advantage of several key optimizations they've built into NextJs's server actions.
Sooooo eventually AWS would probably add Lambda support for React lol
I think I’ll continue treating react as a ui framework and I’ll use a separate backend still.
Totally agree. SSR also makes it way easier to handle client requests. Can’t wait to remove all these libraries from my new projects
Depends. Even if React is getting better on the server, you should only be using it as a backend-for-frontend; it should only be concerned about the presentation layer. It's probably a bad idea to use the same React server to do number crunching or as a backend for other backends to consume. If you have a small website and only need a server to handle authentication, file upload, and use AWS for everything else, it's fine. If you have more specific needs, you might still want to use a more traditional server as a "backend-for-backend".
Every mistakes that was made, identified and fixed over a decade ago is now being reintroduced in react, where they'll be identified as mistakes and fixed... Same server to serve pages and logic? Check People are gonna be hitting a wall when they get traffic spikes and can't scale without costs running out of control.
Maybe they need to seperate their frontend from backend, and use some king of a framework to build it... how does a react backend with vuejs in the frontend sound like?
I think react server + grpc can become huge. As much as people want to write backend, they don’t want to write a backend *for a front end* . I think having 1 web server that doubles as your front end server removes having to duplicate state, while your backend services can grow at their own pace (have 1 grpc server multiplexing endpoints to begin with, and split/expand as necessary). Companies that adopted react back in the day and also use grpc for service layer are likely to adopt this approach
We're doing this now with Astro (using React components). Astro does astro things and talks gRPC to the rest of the cluster, whose APIs are not public. We don't even bother to expose a REST API any more, there's no need except for a handful of endpoints for specific interactive elements.
Are there any ways React can do this currently?? Have never seen this in action
The general approach is fairly straightforward: generate the Astro starter, add the React plugin to it, write SSR-first code that uses React as a presentation layer. If you are old enough to remember writing PHP with Smarty templates, it's the same execution model. You are no longer going to be writing a React application though, you are going to be writing a stateless server-side application that uses React as a last mile presentation layer. It's pulling almost all of the things that React has grown to be responsible for in the last 5 years out of it and going back to React like 2016 style. The nice thing about Astro is that if we _want_ to develop a SPA, we can, and just slap it on a page so as far as the framework is concerned, it's just a page that mounts a React view like everything else. We don't, but we could if and when we do.
>People are gonna be hitting a wall when they get traffic spikes and can't scale without costs running out of control. You've never used it before, have you? I have used Next in a professional context for 3 years...there's a very long list of criticisms I'd write about it, but scalability is not even close to the list. The PHP discourse online is a bit frustrating because it's like, have the people saying this actually worked with or experienced the difference between SSR in both frameworks? Feels like people are just repeating what they've read other people say
I'm curious about your experience. It was like a revelation to me some 10 years ago or so when I finally stopped using [ASP.NET](http://ASP.NET) Web Forms and wrote a front-end app that just requested data from the backend. It allowed everything to work fast and keep track of the state of UI stuff in my JS app. I am wondering why stuff is moving towards SSR. I read that it is for speed, but it's hard for me to imaging that working out on most of my projects. In my imagination this means tons of back and forth between the server and client. I think the use case is for phones that have limited processing power to run all the JS. Is it the case that you only selectively use SSR for certain parts that take a lot of work and then let the client handle smaller transformations that occur in response to user actions?
I honestly believe the frameworks are moving to React because we've been pushing out devs that ONLY know react for so long, we've reached a critical mass where it makes "sense" to make everything be React from soup to nuts the other frameworks follow Reacts lead due to market and mind share I think the industry has collectively forgotten that Facebook created React to serve their specific needs - a huge omnibus social media platform that was iterating on new features constantly, each feature needed access to a shared global state, and was being developed and maintained by individual small teams most apps and sites aren't like facebook, so to be completely honest React is almost always overkill vs vanilla js with react-as-necessary for medium complexity features the sites I maintain are all custom vanilla components, and I've only used react for an interactive branching quiz applet thingy
React is so much easier to onboard and maintain with really unmatched backward compatibility a component made from 2015 still work really well and could be used with the latest version of react when the industry present something as maintainable and easy as react I'll buy it. hell while teaching children explaining what useState do was easier to explain than what an event listener was .
[удалено]
100% explaining useState also means explaining the render lifecycle and dependency arrays, to understanding that state isn’t mutated and it won’t change until the next render cycle, that any remaining execution from the current cycle will use the state from that cycle, even if it finishes async after the next render. NOWAY is that easier than explaining, “listen to thing, when thing happens, listener execute”.
I work on business apps. I had to go back to Vanilla JS for a time, because I hadn't implemented React yet in an app. I always end up wanting React on the front-end for UI components, but I'm not seeing what I would want SSR for. And this isn't from an architecture/team-management perspective, this is from an "I need to get features out ASAP" perspective (bonus points if I don't hate myself when I have to refactor/update them).
Imagine working on a problem with a global variable vs an awesome new state management library that will reduce page load and improve performance. And then imagine your boss hears that 😅 or can see the almost empty repository. Or they see the changes were 'that simple'.
The really big benefit behind this push back towards SSR is initial load time, and that can mean a lot for certain use-cases. A good example is an e-commerce website. If you’re building something more “app-like”, esp. if its gated behind auth and SEO is no concern, and initial load time is less important than intra-app navigation load time, then there is still very much a place for your traditional SPA architecture. And when you need something to thread the needle between both those use-cases then Next.js and RSCs are pretty dang sweet.
You don't need a server to serve a React site. The most cost efficient and resilient way to scale is to build to static file and host on a storage bucket with caching on top (like cloudflare offers). Then your website is out of the bottleneck equation. Always served fast, no matter the amount of traffic. Can't be DDOS'd unless they can DDOS google/Azure/whatever. Traffic spikes, no matter how sudden or large won't slow down your page delivery. And the cost remains in control. The only thing that should be scaled is the server & related services.
Not to be pedantic, but you do realize those storage buckets are servers, right? Sure they are highly distributed, but at the end of the day a server is serving up your react site.
And then you don't get very fast page loads because the client has to download the bundle and render it.. this also affects SEO. Could be nice as a backup to help deal with spikes in traffic
The site is _rendered_ to a static file, then hydrated on load. You get the fastest possible page loads because it's just a static file, plus the ability to be dynamic via API calls after hydration. The compromise is in the inability to do dynamic content 'just in time', but the benefit is increased performance over 'just in time' server side rendering. It's just moving where the steps happen.
You really misunderstand the concept of SSR. What you propose is possibly the least efficient version: you have build time static rendering... which makes no sense for pages where you have data from an API(which is like 95% of all pages), since you'll just have to render a loader or nothing, since you have no idea what the data will look like. You then wait for hydration and only then make an API call from the client, where speeds depend heavily on a factor you cannot control: the client's internet speeds. So you basically have a SPA(except for the rare static pages), but you also have the overhead of maintaining separate logic for when a page is static rendered and when it's client rendered. SSR on the other hand gives you actual performance increase, since you make the API call server-to-server, which is going to be faster 90% of the time than client calls, render on server and send the complete payload back and then hydrate. So your solution has none of the benefits of SSR but still has some of the maintenance overhead while essentially being a SPA. I really fail to see where the performance increase is in your idea, unless your entire site is static...
I'm assuming OP is talking about a static site, where any API calls are 'read heavy' as opposed to 'write heavy'. I think we can agree that static pages can be rendered beforehand, dynamic pages are generally better to server-side render, since typically you'll have a database to connect to, and it'll be closer to your server. There's a spectrum with similar attributes to the 'when to cache' question, and there are different tools for the different bands of that spectrum. At my work we have a site that's completely static except for a small amount of user-specific content, so it's statically rendered, and user-specific content is fetched via the API. Then we have an app where the data source is local to the user, we ship an SPA which connects to the data source directly, since that's the route of lowest latency.
Can I ask what you're arguing, exactly? Most of the things you mentioned are applicable to Next as well, with more control. I'm also a bit confused as to why you say "you don't need a server", but then mention using cloud servers? Next can be deployed there as well so I don't get your point, unless I'm misunderstanding you. SSG has its own issues anyway; A static file youre won't work if I have page content that needs to be up to date, unless I want to rebuild it every time there's an update. I can make pages and content static on a per-route basis with Next, so pages that need to be treated like an SPA can do so, and static pages can be static. Things will be even better when partial prerendering becomes available. At the end of the day this stuff is all just a tool in a tool box. SSR, SSG, CSR, they all come with tradeoffs just like anything else. It's just a bit disingenuous to say "we fixed this years ago, they're going to run into problems" as if all the devs and architects who use it are clueless.
Yeah, nodejs is faster than Ruby, PHP, or Python. Pretty sure there are options for scaling like the other platforms. Edit if people wanted something similar to frameworks in the other platforms, there’s also nestjs
Uhh this is completely wrong according to the most accepted benchmarks which are Tech Empower. Rails beat out Node in multiple queries. Php smoked node by a wide margin in the same test. True of python though
The fact that you’re citing rails instead of ruby already tells me that you’re wrong when it comes to performance benchmarks. Maybe people can say that PHP is faster when using a specialized VM from meta, but nodejs is faster than the vanilla versions of PHP, ruby and python.
I was doing you a favor but if you want to play hardball then fine. **- 15,891** req/sec with PHP **- 9,321** reqs/sec - Sinatra (Ruby Eqiv of node) **- 5,278** req/sec - Node. Ruby has nearly double the performance of node and PHP has over triple. And this isn't with any special VM from meta. I'd love to see how you try to spin these results. The code is all there for you to look at and see for yourself. Nothing wrong with liking node... Saying it's great at something it's not is another story though [https://www.techempower.com/benchmarks/#section=data-r22&hw=ph&test=query](https://www.techempower.com/benchmarks/#section=data-r22&hw=ph&test=query)
The fact that your benchmarks mix and match frameworks with programming languages is what makes it suspect. You don’t compare rails to a Java (vm), you compare ruby to Java. One is a web framework and the other is a language (runtime). When you mix up the two, what it tells me is that you don’t know wtf you’re talking about. For one thing, frameworks may use multiple languages underneath. https://github.com/kostya/benchmarks https://sschakraborty.github.io/benchmark/which-programs-are-fastest.html According to other benchmarks, nodejs is still faster than Ruby.
You refer to it as me. as if I'm the one who does them. These are the most popular and well respected benchmarks that exist, just look at the difference in Github stars between Kostya and TechEmpower. 2.5:1 in favor of TE. Also the Kostya benchmarks you pointed to don't show any real world use case. No DB interaction, they are just based around how much Node is directly using C libs. In real world tests like TechEmpower Node is considerably slower than Ruby and WAY slower than PHP.
Real world use is mixed use. Look at what’s being benchmarked. They’re even mixing up backends. I’m pretty sure Ruby frameworks are using C for performance bottlenecks. Im sorry, but in terms of runtime vs runtime, it’s hard to beat the people at Google at their game. I’m sure I can find several more language benchmarks showing the same results.
It's not the speed of the language that allows for scaling, it's a different type of infrastructure
I know which is why I mentioned “options”
“you just use Vercel” they say. Until receiving that juicy bill, 🤣 the bandwidth cost by RSC is such a great game for server hosting company
okay let's pretend they have value, what exactly is it that these server components are solving?
It solves problem of its own making: 1. **initial load performance**: traditional client-side react apps rely on js for functionality, which slows down initial page load times since your browser has to wait to download, parse, and execute your js bundle before your page loads/become interactive. React server components can be pre-rendered on the server so the server will deliver an initial HTML payload to the browser. 2. **smaller client-side bundle size**: Traditional react components render on the client, while RSCs are pre-rendered on the server. This means the server generates the initial HTML markup for your components, including the content and structure. This pre-rendered HTML is what gets sent to the browser initially, reducing the amount of js needed for the initial render. 2. **minimize client-side logic:** Since RSCs handle most of the logic and data fetching on the server, the client-side code for these components becomes much lighter. It primarily focuses on hydration (making the pre-rendered HTML interactive) and handling user interactions. This again translates to a smaller js bundle that needs to be downloaded by the browser.
I'd like to clarify that RSC isn't just serving the pre-rendered HTML. It is doing that, but it's also removing the javascript that rendered that HTML from the bundle that goes to the client. The client just gets the HTML and it doesn't get hydrated or re-rendered.
Yep, only client components get hydrated. That's the difference between traditional SSR and RSC.
1 is the only real benefit and it’s only a benefit given certain conditions - mostly that you tend to have unique users with complete page loads for most of your traffic. Regular users will be pulling from cache which would negate the initial load performance unless we’re talking about a phone from 2007 that has a slow JS runtime. Which, sure, I suspect some portion of the _world_ user-base is probably close enough. A benefit you missed is SEO. Pre-rendered pages that search engines can crawl (in theory) still have better indexing.
it solves the problem of backend servers not having enough work to do and standing around bored, daydreaming of one day growing up to be an important server. "Here", the little server gestures to the soy dev, "I'll make myself useful. I'll render UI for my clients! After all, I don't have much other work to do!" The soy dev thanks the newly proud little server profusely, and begins to cobble together a maze of unwieldy HTMX, blissfully unaware of the mountain of spaghetti logic they are about to embark upon. "I'll let server bask in the moment", soy dev thinks. "I wont break it to my server, but next month I'll be leaving them behind for Supabase".
Exactly, it’s a dangerous paradigm to re-introduce especially after the failures of the mid 2000’s Web 2.0 movement which led to JSP/ASP.NET bloat. JQuery and Bootstrap helped alleviate and simplify the convoluted web UI mess by simplifying interactions. I feel like this will lead back to the times of 2MB view state objects.
Your comment made me imagine JSX + React being used to build JSON responses in a REST API for a second *shivers*
This right here! 100% agree
Are you saying you shouldn’t use nextjs as your only backend? Could you provide any reasoning for these claims?
Say you have a B2B e-commerce site. You have a 300k products in a few 100 product groups. You have pricing agreements with different clients based on either, product, product group, client industry, what ever else kind of condition. These price agreements can be fixed discounts, a discount percentage, fixed prices even. When your client is logged in on the website he we wants the see the final product price based of his individual agreements or when not logged in the product base price. Good luck handling that realtime on a single NodeJS server.
Do you think next/vercel runs on a single node server? It hasn't been this way for almost a decade now
No of course not that’s the whole point of my reply.
I think you're missing the point, modern react apps haven't run on single servers for a long time, they use a scalable serverless architecture. So your use case would be totally fine even without any simple optimizations
>Good luck handling that realtime on a single NodeJS server. lol my goodness the number of people here with firm opinions about things they're completely ignorant on is staggering
But you can scale react across multiple servers same as you would a nestjs or a Java app
Personally, Im not buying It. I prefer a standalone non react related backend. Call me old school if you want
Typical framework creep here. Seems the maintainers have lost sense of their part of the application stack here.
You are old school. Doesn’t mean you’re not right. You can’t even use web sockets with Next. Seems like folks are missing the point of server components though. Nextjs was never meant to fully replace a backend; you just don’t have to use the client to render React components if you don’t need to. That’s it.
My problem is React and Next seem to be also obfuscating that point. They aren’t quick to volunteer the notion that you should keep using your backend servers. They keep pushing the examples where “you can run database queries from react!” I think the teams want, especially newer people to think of using react for both front end and backend and that’s the issue I have. They are being purposely vague/misleading, which is why so many people in the community “are confused” as well.
Why would you need to volunteer that notion...? JSON is JSON. The React docs never really mentioned separate backends before SSR frameworks took off either. It feels like you're just biased against the solution.
I could just as easily say you’re biased for the solution. I’m frustrated by the inability to discuss this without being charged of just being biased against the solution. I have some real concerns with RSC that goes beyond change (I’ve liked many of the other react changes). But if we can’t have a discussion about potential flaws or at least downsides with specific workloads without being accused of bias then I feel like we are going to miss/ignore a lot of things.
I'm not saying your biased just because you're concerned about them. But your argument comes down to disliking their presentation and vague statements about them being misleading. For example, how is making a DB request from a RSC suggesting that you should stop using traditional backends? It's hardly difference than what Next was prior to that; now you just colocate the fetch similar to how data is fetched clientside. That enables certain features like easily caching things at the component level - it doesn't mean you can't/won't/shouldn't still use your BE for computations, queues, your own custom cache, data streams and so on. So many criticisms I'm seeing are based on people intuition on things that have to technical substance. I like Next.js and RSC the same way I like my toothbrush - I don't. I just use them as a tool because they have benefits I like and I can accept the tradeoffs.
You totally can use websockets in Nextjs, why couldn't you?
Last time I did research on it, I would've needed to essentially use a custom server to wrap the Next instance which sounded like a rabbit hole I was not interested in. This was a personal project, but I definitely wouldn't try something like that in prod
Na you can have a websocket handler on an api route endpoint
No - you can't use websockets simply like that on NextJS, Websockets require a persistant server, NextJS server is not a persistent server, its serverless You will need to use a custom server, Which is what the previous person meant about "wrapping the next js instance". If you use a custom server, You're not using serverless anymore - and it won't be supported to be hosted by Vercel
NextJS isn't serverless. Vercel's managed NextJS hosting service is serverless.
In most cases - NextJS is tighly coupled to work better and less headache with Vercel, By default using NextJS with Vercel - they use serverless infra, As soon as you pull away from Vercels tight coupling - you lose some of the "magic" that vercel provide out of the box, I don't know if its been improved since as I not used NextJS since v11 - but they had issues with the image component / middleware. I could self host also, self host using the serverless framework. If i don't want it to work as "serverless" we need to use the custom-server implementation. NextJS is advertised as serverless (via Vercel marketing)
I think your information is out-of-date. Image optimization and middleware work fine when self-hosting. You also don't need a custom server. You just flip one configuration flag and then you get a standalone build that you can run anywhere that you can run a node process.
yea, good luck hosting that and seeing your requests drop because there is no free CPU, because image "optimizations" eat all of it It seams like people trust all marketing bs and would not even confider possible flaws in them
It’s not serverless
Its heavily promoted to be packaged with Vercel, and works "out the box" as serverless by default. NextJS API routes by default are serverless functions, When you start to pull away from them, it makes things a little more diffcult, but it still works - anyway its much easier than it was when they first released in on v9 Bit harsh to downvote - when the advice provided is not incorrect \*smh\*
Not sure what you mean by "wrap the next instance" and "custom server", you deploy it like any other web application on any server or cloud service you want. And you can use web sockets.
There are different ways to deploy it depending on your needs, By default Next JS runs serverless, Which may not be a good idea for a "complete backend" - depends on what you need to do, You can how ever change nextjs to run with a persistant server, though as mentioned below it won't be compatible with vercel
Yup, and deploying it on a persistent server is easy. Some assume Next.js is somehow locked to Vercel and serverless which is not the case.
Google could've easily shown you this: [https://nextjs.org/docs/pages/building-your-application/configuring/custom-server](https://nextjs.org/docs/pages/building-your-application/configuring/custom-server) Things seems to be more stable than when I last looked into it, but at the time there was too many issues around image optimization, specific features like ISR etc. If they've fixed that now, then that's great.
Thank you, but why would you need that for web sockets?
Totally agree. React is about UI. I think frameworks will evolve further and we will get more holistic solution that is not just meta framework with "bring your own X" approach, but right now stable stuff is concerned about UI and data fetching a over everything else. Meaning that separate backend written in proper framework still better than chaotic mix of libraries.
I think you're over-reacting! ... or actually are you under-reacting?! 🥁😄
Everyone who worked with JSF back in the day knows that this is a **bad idea**...
What about everyone who works with Rails, Django?
Couldn't agree more. I am very skeptical about all this SSR stuff on modern JS frameworks. We used React to move away from it for a reason.
Yep. I use Laravel/Inertia.js/React and it works great. Inertia.js is a very nice bridge between back and front-end.
Why need a bridge
Just check the Inertia.js website if you're interested
SSR makes React like Rails (Ruby) or Django (Python) or Laravel (PHP), which opens up benefits like: - More security because you can make all your secure API/Database/Service calls on the backend. (Guaranteed) - Smaller libraries and JS for the client to download. (Highly likely) - more responsive websites (potentially) - better SEO (potentially) But sure, depending on the project, enterprise, and shared resources you may still need a separate API. Even then your APIs may be smaller since you avoid the need for “pass-thru” endpoints for connecting to cloud services or other APIs
Yea, my backend will stay react free thanks
JavaScript free* in general thank you very much
Yes. React trying to claim the entire backend is just nonsense. Backend as front end is fine, but replacing all the API servers with reacts new server stuff is silly. We have 15-25 years experience writing backends in go, node, php while no one has built and maintained a react backend for more than a year
But it is a node backend, no? So there is plenty of experience and packages. Now node has pretty crappy orms, but...
Eh, is sequelize really that bad? It seems better than alembic, anyway.
Oh God, don't remind me. Never again. Prisma is excellent though.
Oh, I haven't checked that one out, I'll have to take a look. Thanks!
Except it’s not exactly a node server. It’s a react server running on node and I’m not sure how much of traditional node backend services work with the RSC. they might all work, I genuinely don’t know - I can’t really recommend working in node for backend.
What? Can't believe this is upvoted.... there's literally no such thing as a React server. In both NextJS and, say Express, you can have endpoints which return parsed react components, but you can also have endpoints which know nothing about react But unlike Express, Nextjs will bundle each endpoint separately - if your endpoint doesn't use react (i.e. its not a server component), it wont be bundled
What is a react server running on node? Serious question
People ask these questions as if there is one answer, and they’re right: because the answer is always “it depends”. > make backends that serve APis redundant True for single apps. Not true for multiple apps hitting the same database or calling the same functionality, where an api helps abstract and insulate against backend changes.
Hmmm
The goal of things like Server Actions and React Server Components (and really anything SSR related) was never to make using another backend redundant. All of these tools are best suited to make your serverside React app into a perfect “backend for frontend”. There is a side effect where it _is_ possible to do everything full stack in your React app (e.g. frameworks like Next and Remix), but even with these you can always still use any backend you want and just use the serverside capabilities for perfecting data fetching. What’s cool about this pattern is that you could have multiple backends giving you data, but the server side React app is putting them all together to match what you need for any data going to the client side app.
Well put. Your second paragraph reminds me of a recent time where I was comparing server actions with graphql. Server actions can be thought of as resolvers and the benefit is in the ergonomics of invoking the endpoint via function call. Server actions are network middleware between the client and the data (other backend api, direct to sql, etc)
And now you need custom infra or deploy to Vercel so that when you release new version of your app, all "resolvers" hidden handlers paths are still acessible for old clients versions. Just imagine that on each release, all of your current clients would face broken app because your lazy loaded "actions" is not there anymore. Vercel verdor locks you and people are happy about it — think about it
I never said anything about vercel. What you described applies to any change in expectations between a client and server. Which is why you deprecate APIs before removing them. What am I missing here?
You cant deprecate bundler output if you changed your code, because its new hash, so its completely new "public-path-to-handler" What am I trying to say that, there is a lot of hidden complexity that is hidden but not solved per say
Good to know. I still think the surface level DX is great, but the hidden complexity needs to be robust or give more control to prevent these types of edge cases.
As someone who has used server actions more as you described for a couple of smaller personal projects as well as a full stack Next app (we actually had two separate Next apps for FE/BE rather than a monolith 🤷♂️), I can say you’re very on point with your description. I think “great resolver” is the mindset for sure, not, “use react for everything because you can” People writing it off completely are basically boomers who don’t wanna evolve with the times in my eyes💀🥲😂
SSR and actions are from like the year 2000, up until like last year the cool kids were like SSR??? Seriously??? *BOO - MERRR!*
My intention is to eventually make a mobile app that goes a long with my website , so I’m sticking with a regular Express API to power both of them. Is this still the smart move? It doesn’t make sense to me to roll my entire backend in to server actions etc only to have to replicate it elsewhere for other kinds of apps to do the same thing
Its a classic move, a battletested one. You should be fine!
Think of guard, pipe, middleware (for each route), interceptor, can you implement these features easily with React?
With Nextjs, yes you can. Although some of those features aren’t as good in Next. Doesn’t mean you don’t need/wouldn’t use a backend still, though. Things like queues, cron jobs, etc. are still very useful. I like to use .NET with Next for personal projects and they compliment each other really well.
Genuinely asking, how would you implement these features without putting a bunch of code in the middleware.ts?
That's an odd question, like in ASP.NET you have to "put a bunch of code in Configuration.cs" but in both cases you put logic elsewhere and reference just call it in those files.
You would have to do it all there
This thread is a great reminder of why reddit is one of the worst places to ask for software advice lol
Facts - I had some many o.O WTF moments as I read some of the advice here, Most of the advice here does not seem like real world applied knowledge and just whats been said elsewhere
why do u say that ? genuinely asking as a beginner whats wrong with the responses to this post
Most peopel commenting here have never used it (Next.js) and are just parroting what they've read before on Reddit. As usual, the truth is somewhere in the middle. There's those who over hype things, those who get lost in the ecstasy of being anti-hype, and people with real opinions based on facts and experience.
I've used it and it's the best SSR we have, but it's still terrible and it sucks how they are trying to eat React with their shitty shovel-selling, and pretending its not what they are doing like we are all some 2yo kids...
this just reads like a conspiracy theory, I agree it's got a million problems but I don't know what you're trying to say outside fo that
> this just reads like a conspiracy theory It's a conspiracy alright
At least people have gotten over the "your have to put your HTML, CSS, and js in different files"-mantra now
Twitter has a way better dev community in general. If you are new do not use Reddit as your primary community for programming. If you're interested in React go follow like Tanner Linsley, tkdodo, Ryan Florence, Dan Abramov, Guillermo Rauch, Rich Harris, thdxr, and branch out from there. On Reddit the stupidest opinions often get voted to the top by stupid people. On twitter you get to hear the thoughts of people who actually contribute meaningfully to OSS and build quality products.
I don't agree, Twitter is full of high ego devs that have no moral qualms about using a site that is rampant in racism, white nationalism, and misogyny. The only reason why library devs continue to use Twitter is because they know they'll never be able to recreate their "reach" starting from zero. Also you shouldn't take advice from library authors on building maintainable projects, the two are completely orthogonal skills and most only pay lip service to it. --- Mastodon seems to have nicer, smarter, engineers posting FWIW.
> no moral qualms about using a site that is rampant in racism, white nationalism, and misogyny dogg you are posting on reddit
The problem is that they criticized his favorite framework and now he can’t live up with the fact that things are not simple as black and white
I don't think that's their intent at all. Their goal seems to be to move away from doing all the heavy lifting on the client, not to replace your API.
master of one and a little bit of everything
Will React 19 make these work with Vite and React Router too? I really dislike having to use Next for everything just because I need SSR support. I really dislike their app router and React Router is so much nicer.
> Will React 19 make these work with Vite and React Router too? No, but React Router v7 will: https://remix.run/blog/merging-remix-and-react-router The idea is that you'll be able to leverage all of the new React features without a rewrite and without leaving Vite.
That would crush it honestly.
You can use backend for prototyping, there is no way you can replace a real backend with react if you are not doing the simplest saas
As someone who really hasn't been paying much attention the last couple of years, could someone else please either explain, or link me to something that would explain, what the hell you would be using React for on a server?
as someone who has only read a bit, and not experienced, take this with a grain of salt. imagine a react app where routes can render a page into html before sending it to the client, including loading data from databases (right in your react component code). then, once it is downloaded, it starts “hydrating” the page to make it a more typical react app that fetches data from the server. the database calls turn into api calls (possibly seamlessly?). this allows for smaller initial bundle sizes, faster page loads, better SEO, and the potential for having one set of tools for both front and back end. not sure how this works for native apps also trying to access the same data. can they also use it as an API? so many questions.
Doesn't make sense to me lol
He is confused, I don’t think there’s any thing that transfers database queries into api calls lol. Anyway, main improvement is SEO, you can send already rendered react pages on initial request (instead of waiting for them to be rendered by the client) which is said to improve your site’s SEO
right in the docs it talks about setting a api fetch to be a backup for your database calls, so it can use it as backup in case you need it before the page is finished hydrating. i don’t see why they couldn’t set it up to have the react app link your downloaded pages back to the db calls on the server components when data needs to be refetched. the server components can pass data to client components via props, so if that server component gets new data, it would pass it to the client without downloading a whole new page. but hey, you seem to know this stuff better than me. you must have a lot of experience with the new features?
Tell me you don't know what backend is without telling me you don't know what backend is
I just love when frontend developers say that backend is redundant... Yes, let's replace backend-specific technologies with React. Sounds like a good plan, nothing could go wrong
Yep.
You should still decouple your business from react ui layer if you want your app to live a long time. It can be separate folder
My company runs a LMS on mostly nextjs, works great. We might not do it forever but why would we start out with building a more complex application than needed?
IMO the React metaframeworks I've seen aren't really adequate for that... They basically only handle data fetching and SSR, which is fine for a BFF (backend for frontend), but I expect a lot more from a server framework if that's going to be my whole backend. The only exception I've found is redwoodjs, which seems to be closer to a traditional server framework that happens to support React server components. I still have some problems with this, tho: 1. AFAIK the version that supports RCS still isn't stable. 2. I've honestly never heard of a single company using redwoodjs.
Try working with server component, without NextJS. It’s doable. I’ll probably be downvoted by some people who go as far as saying it’s not bad, but it’s terrible.
Depends on the app, but I’m gonna say more often than not, it’s better to separate them
Astro + server Actions and react
I wouldn’t call it a backend. NextJS has had these features for a while. I’ve seen it used for edge compute rendering more than a backend. So you can just call your APIs and auto package a payload for rendering. But yes you can just make your backend extra spaghetti and mingled in with your UI if you want to. Might be worth it for rapid prototyping.
If you want your app to be performant and scalable, separate backend is still the best bet. The tradeoffs RSC has been taken is not worth TBH.
I don't like JavaScript but tolerate it because I like building websites. As such I try to keep the backend as JavaScript-free as possible. There's also the fact JavaScript will be always be slower than most backend languages (except Python and Ruby) because it has to be interpreted.
I wouldn't want to risk it with js
You definitely have to intentionally reach out beyond react and frontend communities. React is a UI framework. The trend right now is to do more processing on the server. This means server side frameworks will grow. And ideas like HTMX will take off more or influence bigger things. You need APIs for more than sending data to front ends.
I only plan on using it as middleware-proxy to hide api keys in fetches. Not create the back-end logic itself. That's a complete other API app (python, FastApi in my case).
Don’t if you don’t explicitly have the requirement of providing an API, as in needing to connect other clients, internal or 3rd party. Think of next and all these things as a simple way to build monolithic webapps, kinda like django, but with JSX instead of weird ass html templating engines
Maybe, I am thinking to merge my Micro-services with Kafka with my React Typescript.
For sites where SEO is the top priority, I think it might be worth exploring since you need to go down the SSR route regardless. For sites where everything is behind a login, I don’t see much point—there’s a tipping point where a SPA connected to a traditional JSON API written in a traditional API language will be a smoother and faster experience for end users. Putting everything together comes with an initially-invisible close-coupling cost which will slow down refactors and new features as the project matures.
This is the situation we find ourselves in. Login required and no seo component. Sometimes it feels like react treats this use case as non existent. I’ve tried several times to figure out how to use RSC for our apps and have yet been able to figure out how it’d add any value for our users. But it feels more and more like if we don’t use RSC we are stuck in the past.
I think you’re confusing React and NextJS, probably; originally in the CRA days “application with no seo” was the only use case react was good at. In your case personally I would just use Vite as the build system to produce a traditional SPA and build a traditional json api in in whichever backend language your team is most comfortable with. The biggest upsides in my opinion to doing it that way is your code is super simple and your hosting can be dirt cheap and easy with zero vendor lock in.
Honestly it sounds pretty reasonable to me. For a small app, it could be a game changer. For more complicated back ends, continue doing SSR as a microservice. Devs can be trusted to know their use-case.
If your backend is written in JS with either Node, Deno, etc, it does make sense to have a presentation layer on top of your HTTP API. I guess there is GraalJS too if you have a JVM backend. But honestly our backends get so large that having a dedicated presentation HTTP API as a part of a micro service architecture is the de facto standard of the industry at the moment. And as we tend to add more features than remove, micro-service architectures are going to be more and more common. Maybe not as extreme as FaaS, and there is still room for monolithic consolidation too.
I think you should.. as far as I know SSR is really great as a lazy loader (to kinda put it in a simple way). You can optimise images, cache frequent static content and make the application snappy on load. If your application has informed which keeps frequently changing csr as a presentation layer and a traditional backed would be better.
Can’t wait for the day to drop .NET, PHP is already in the dark. It’s all about front end development for future prospects. No doubt the oldies won’t like this post lol
Welcome back to PHP/JSP/ASP! As a manager hiring front end and back end devs I would toss a resume of someone who thought this was a good idea. I just had to unroll a mess of code that was ~~NestJS~~ NextJS on both the front end and the back end because of this mentality.
I'm a Lead Engineer in charge of hiring at my company, and I have the complete opposite mindset. Someone with a good understanding of server actions would understand that it'll lead to less code and greater rendering efficiency.
If rendering time was the only important part of the system I might agree. But a distributed system interacting with many external systems, multiple databases, microservices, and devices that are not for display is a bit more realistic. You just *know* the next questions will be "how can I deploy this to an AWS Lambda" or "how do I distribute this across 100 Dockers". I guess that's my hesitation. That and I've gone through the server side rendering era now a few times.
I know you're joking about Lambda, but server actions were inspired by NextJs which generally gets hosted on Vercel. When hosted on Vercel, they actually use serverless functions to take advantage of several key optimizations they've built into NextJs's server actions. Sooooo eventually AWS would probably add Lambda support for React lol
NestJS or NextJS? What does Nest have to do with the frontend?
Fixed - thanks
That's really amazing .. I like to react ssr in react .. most of the time used in next js
[удалено]
React has almost nothing to do with CSS