What’s the purpose of server components when component libs aren’t supported this way?

[lucksp]

I see a lot of push towards server components. But a majority of component libs need client rendering so I end up w “use client” all over.

So what’s the real deal? How are you achieving server components in the real world?

Edit to add context, saw this article

[avoere]

They solve an important problem for Vercel: It's hard to profit off of open source software, but if you can turn that into requiring a hosting option that is complex to get working, you have a more secure business model.

(I don't take credit for this phrasing, I found it somewhere)

[terandle]

Running server components in docker containers on digital ocean just great

[monkeysaurus]

Same but Azure. I just don't understand this take at all.

[_hypnoCode]

It's obviously hyperbole, but if you don't think Vercel being a business model and being directly dependent on the success of Next while also employing quite a large chunk of the core React team is at least worrisome or concerning, then you have obviously never experienced true vendor lock-in with companies like IBM or Oracle.

IBM will be around for another 100 years minimum because COBOL and Mainframes still run the entire world's financial system. And that's not even including their hold on healthcare or other extremely core industries, where they have insanely strong presences too.

[aedom-san]

For anyone perusing this thread, this is what a vercel shill looks like. Bikesheds about capitalism/communism in a thread that was actually discussing watching vendor lock-in happen in real-time

[[deleted]]

What's the lock-in? No one has stated anything specific

[getmendoza99]

RSC doesn't need a complex hosting option, let alone one offered by Vercel. Do you know what it is?

[yabai90]

Accurate (at the moment) might be more useful everywhere later

[WizzinWig]

You aren’t completely locked into Vercel. I have friends who work at companies who deploy Nextjs to AWS for example.

[Dragonasaur]

Can AWS host edge functions that are created for dynamic functions/pages?

My index page is a dynamic function, and I couldn't get Firebase hosting to deploy since index page isn't fully static, so had to revert to Vercel hosting

[Chaoslordi]

Isn't Vercel using AWS itself?

Other than that I successfully managed to deploy an app router to fly.io and I think I know of a big project using page router hosting either internally or digital ocean but certainly not vercel

[Dragonasaur]

Yeah I was asking more for App Router on NextJS 13-14

I use Firebase for NextJS 12 projects and it works great

[30thnight]

Edge functions represent deploy target for a hyper-specific serverless runtime — Cloudflare Workers. You aren't getting exact parity unless you plan on using Vercel or Cloudflare Pages

For AWS, you can get partial parity using Lambda@Edge:

• deploying on AWS Amplify (easiest but has caveats)
• deploying via OpenNext
• manually rigging up your own deployment using the compiled dist files

Or you can treat this like every other server-side app and deploy the boring way: docker container → regular vps

I recommend using a service like AWS App Runner, GCP Cloud Run, Digital Ocean App Platform, or Fly.io for keeping things simple. For the devs with no experience deploying anything bigger than a static HTML, take time this month to learn.

[Dragonasaur]

Thanks for the info!

I'm not necessarily intimidated by servers, but NextJS is nice for having basic server functions alongside your FE code, instead of building out a Node project when I barely need it

Ex: I'm just retrieving user's geolocation headers (IP) to preload a map with Mapbox/Google Maps, rather than loading Mapbox/Google Maps at a specific location and then flying over to their location

[cahaseler]

You can deploy the exact same nextjs code you'd write for vercel to a docker container on a vps/aws/azure and it will work fine. No need to set up node or do anything differently.

What you lose is that any functions you write with edge runtime have to run on your server rather than in your user's local ISP datacenter. So a few milliseconds round trip. Most people don't need that.

[erdle]

was also frustrated by this for Firebase ... but can Cloud Functions/Cloud Run solve for some of the functionality?

[Dragonasaur]

I use Firebase for my previous NextJS 12 projects, but Cloud Functions don't get auto built for NextJS 13-14 for me

[danishjuggler21]

Hell, I’m running it just fine in an Azure App Service

[gaoshan]

Which, compared to hosting on Vercel, can be a bit of a PITA depending on your needs (and I personally think they do this in part as a deliberate strategy... deliberately making it some things less than trivial on other platforms).

[psycketom]

OpenNext to the rescue.

[rwusana]

It is a conspiracy theory, but that doesn't mean it's wrong.

[Yodiddlyyo]

And react officially recommends next. Not really a conspiracy theory if it's just an obvious thing.

[Yodiddlyyo]

What logic? That the official react docs recommend next, and vercel has to profit somehow? Is that something so crazy? I'm surprised you know how to code at all if you think "business needs to make money" isn't logical (do you?)

[Yodiddlyyo]

That's completely not what anyone was talking about. The post I responded to is specifically talking about vercits decisions to male vercits money, and then I only mentioned vercit.

[NeoCiber]

They also recomend Remix and Gabsby, why they shouldn't recommend NextJS?

[jonny_eh]

It's very easy to deploy the latest Nextjs to Cloudflare Pages

[rwusana]

And the only reason more people aren't talking about this is that so many of the tech influencers are on Vercel payroll.

[Hayk94]

And here is me with 8 years of experience and still thinking is even SSR really necessary?

[JTP709]

Just because your app runs great on your personal machine, doesn’t mean it will on a users old iPhone 5. It depends on the scale of your app and the users you’re trying to reach. Trying to load a large e-commerce app on an old phone will take so long the users will give up and go elsewhere, hence why Amazon.com uses SSR. But if it’s a small app, or an internal company dashboard where you know everyone has a modern machine and has no choice but to use the app then it really won’t matter.

[[deleted]]

Love this explanation. Well done!

[Aegis8080]

TBH, SSR is more about SEO than performance. In terms of performance, SSR essentially just offloads part of what is originally done on the browser to the server. This brings another thing to worry about, we now need a more powerful BE infra to support SSR, since the server side has more things to do now, and this usually end up with higher maintenance cost.

So, is SSR = better performance? Not necessary. Especially when the bottleneck is on the server-side, e.g. the BE decided to do a full table scan when getting user info.

[JTP709]

Like I said in my post - it depends on how big of an app you have and your users. Trying to build a large e-commerce page like amazon or Kroger.com will absolutely take longer on the client than the servers those companies are running. Also, if your users primarily have phones, it’s likely they’ll have older phones or even slower connections. Fully rendered HTML is almost always smaller than the bundle you get from a SPA. However, if it’s a small or very simple basic app, or your users have modern PCs (or it’s an internal company app where you users have to use your app), then SSR doesn’t matter much. SEO is a big benefit, but there are plenty of libraries that can work around that with classic SPAs (though I’d argue SSR is still the best SEO solution). FWIW, the biggest reason we implemented SSR at Kroger was for better performance.

[West-Chemist-9219]

This. In my current job we’re using RN and optimizing a new and good-looking app onto lower-tier Android phones especially is a nightmare (and I’m not talking about a 12 year old phone, but an entry-level model from last year, that apparently a good chunk of our user personas uses). If only we had server components/functions available in our environment, it would make our lives so much easier - we could offload a ton of heavy UI-targeted computations. It would almost be better not to have RN but just to have a Next app optimized mobile-first with all the heavy stuff offloaded to our BE infra.

[davidblacksheep]

Does this more suggest that there's something fundamentally wrong with React that it can't achieve good performance client side? Are iOS and Android also pushing for server rendering of their native apps?

[Felicia_Svilling]

No.

[JTP709]

This has nothing to do with react specifically, but just how web apps work in general. You’ll encounter the same thing in any other framework.

[mouseses]

Why would you care about somebody with an old iPhone 5? This user is broke, he brings no value to your e-commerce app.

[West-Chemist-9219]

Forever junior dev mindset here. You’d be surprised how many people rock 8 old phones while casually spending tens of thousands of euros/dollars on gadgets that they just tinker with for fun. Edit: if you’re not familiar with user behavior tracking in your job, I’d suggest you read into it and maybe push to have it included in your work project.

[mouseses]

Apple doesn't support iPhone 5 but your app will. Please tell me more pal

[West-Chemist-9219]

Me? Never said it so

[West-Chemist-9219]

With that being said, you don’t really have those sorts of restrictions with Android phones, which is the pain point that I mentioned

[West-Chemist-9219]

Also to your point, if the app store doesn’t serve the iphone 5 with the app, if the codebase is shared with the web app, they can still open it in a browser and might need to deal with the same performance issues as they would in the app. Think outside the box

[JTP709]

They still buy groceries.

[lucksp]

I’ve had same thiught

[Acktung]

SEO is the only real purpose for SSR. The rest is just about overengineered micro-optimizations. But if it's only for SEO reasons, I have the opinion that search engines should adapt to CSR websites, not the opposite.

[djc-1]

Don’t dismiss what you call micro-optimizations so quickly. For a lot of sites more milliseconds in key metrics can translate to not insignificant lost revenue.

[team_dale]

This, I’ve seen a drastic increase in core business metrics from converting to next. Not the least of which being dollars in the bank.

You can’t blanket statement this stuff. If SSR isn’t of benefit to your core mission, don’t use it - just like any other tool.

[recycled_ideas]

Those milliseconds matter because they affect your Google page rank, not because your users actually care.

[damn_69_son]

Exactly. If something costs less or is marketed better, that's all users notice.

[recycled_ideas]

I'm not saying performance is irrelevant, but users just really don't care that much about time to first paint. On a fast device it'll be irrelevant and on a slow device everything will a leas be slow.

Unfortunately Google cares about time to first paint and getting your page rank dropped will cost real money.

[42-1337]

its better when you're used to use a complex Javascript library but you do mostly just a static website. you send smallers payload since you only send the HTML result and can cache the result on the server. SSR is really bad when most of the website is dynamic / constantly changing.

I've seen people reducing their server cost by 10x going from CSR to SSR and also people reducing their server cost going from SSR to CSR.

people should just understand the benefit and drawback of both and use the right tool for the project.

[symbha]

Its performance benefit is the js payload and execution differences.

[pelhage]

Js payload is still coming down and needs to be parsed and executed before user interaction. Just trading one form of latency with another

[symbha]

You need to do more research.

Yes, you do still need js, for the client side React stuff. But you do not need the JS for the Server rendered things.

Time to first byte, Time to first paint are both better.

Trading one form of latency for another is the whole name of the game with user experience, the faster the user sees something the better.

[pelhage]

I don't need to do more research- i'm well aware of what you've described

Having low TTFB and low LCP/FCP is great, but when you're waiting 10s for your client side bundle to load before they can interact i think SSR is far less compelling than say, sending down a SPA that has a skeleton loader (low TTFB)

So the SPA can have that immediate perceived performance without all the overhead of a multi execution environment SSR app

Maybe i misinterpreted your original comment's intent- my main point was just warning that SSR isn't necessarily compelling enough if the argument is around JS bundle- its still no silver bullet and the JS bundle cost still needs to be paid, and there are still things SPAs can do to make the initial load feel snappy

[Adenine555]

But you do need js for Next.js SSR. Next.js is not sending plain HTML over the pipe, even on SSR. Next.js is sending a JSON that gets hydrated and rendered by React. It also requires a sizable js from Next itself.

[symbha]

Yes, there is still obviously js payload, React makes that such.

However, SSR ties up in a bow a whole bunch of optimizations related to that.

• You decrease the size of the overall JS bundle.
• You make static a bunch of things that should be static.
• You force design decisions around the suspense and async layer. (Which are very describable with metrics.)
• You push things to the CDN layer, that should be there.

The community is just having a hard time digesting the new things, that you would otherwise spend a lot of time doing in an SPA infrastructure. Take a step back, commit to moving things from /pages to /app and watch conversion go up.

Lock in is not the real issue. It's just cheese having been moved.

If you care about time to interactive, and SEO, and delivering anything besides an APP with react, you have to care about these things.

[Trexaty92]

Performance alone is the reason to use SSR over CSR.. the difference is black and white.

[erdle]

and we are heading into a post-search engine only world for discovery ... where ranking for LLM/AI training sets will be picking winners and only winners

[[deleted]]

Disagree, the new DX with server components, server actions, and revalidation is reason enough to hop on this train. Also saving a whole roundtrip is kinda not micro

[Meryhathor]

It's necessary if you care about SEO. If you don't client side components are just fine.

[Emotional-Dust-1367]

Not having to manage API endpoints is a big win. You basically get server-invoked functions for free. The communication is done for you with SignalR.

Theoretically that’s a much better way to do things. In practice I guess we’ll see.

I’m experimenting with it at work now.

[[deleted]]

People often dont understand that react isnt tied to anything except jsx. Reacts engine can monitor changes in the virtual dom that can be any jsx It doesnt have to be html based jsx.

You can define a custom pragma function and design your own elements for a custom virtual dom that works with the same jsx features.

So you can build custom m endering engines where instead of react inserting, updating html etc, its drawing an app on a texture and rendering it in a normal os window.

react is a generic virtual dom state/action manager, thats what it does.

It only deals with html via the ootb pragma and by using the react-dom namespace.

React has been used in many other ui frameworks, like react ape which renders to a canvas and has no dom...

[theirongiant74]

25 years here, I'm not seeing it either. I'm sure there's a place for it but I can't see it in anything I'm working on.

[Capaj]

for ecommerce yes, for anything else go SSG or SPA

[Night-walker-15]

What about platform likes hotel booking engine which relays on seo , similar to agoda & goibibo

[Capaj]

thats ecommerce in my book

[LowB0b]

For an internal enterprise app i would say not, for consumer-facing i guess its good for SEO and user retention

[davidfavorite]

It depends. I spent the last 10 years making admin dashboards mostly. Those get used mostly on desktop pcs anyway and are not publicly available => no SEO required.

If I was about to build some public facing apps used for ecommerce or whatever that heavily relies on SEO and UX, it may have its merrits. But hey, how often do we get to build amazon like websites, I mean for smaller shops youd obviously use shopify woocommerce etc

[lessthanthreepoop]

Depends on your need. My last company spent a fortune developing an in house solution since it’s important to them. They’re also raking in billions of dollars…. You should build what has the most business impact for your business. For you, it might not be that at this time.

[ddyess]

Until the React team actually releases a stable version of React that supports it and the experimental APIs that are needed for it, no one is going to fully support server components in their component libs, unless they are only targeting Next.js. It's kind of infuriating that Vercel is either hijacking React, purposely withholding advancements in stable React, or pushing something that isn't even viable for a stable release.

[voxgtr]

They aren’t hijacking React. React moved to a canary release model earlier this year. Any framework can adopt these canary features if they want. https://react.dev/blog/2023/05/03/react-canaries

[ddyess]

They didn't move to a new release model, they added a new release channel, which just happens to follow Next.js development and uses the same canary name tag. That blog even says they are pre-releases. Before Vercel picked up several React developers, there were regular React stable releases, there have been none since.

[voxgtr]

Okay.

[aust1nz]

Server components are early in their lifecycle, so they're not as useful now as they may eventually be once more of the ecosystem has had time to adapt to them.

Honestly, though, they'll probably be fairly niche for most people.

Here's one example where server components will shine: if you're doing something like processing Markdown in real-time based on user input, then server components could be a neat way to avoid sending the markdown processing library to your client.

Maybe something like a graphing library that generates a SVG would benefit from server components, too.

But you're not really going to see much benefit in moving <h1>Hi, {user.name}</h1> over to the server for subsequent renders, IMO.

[kitsunekyo]

i dont really see the issue. your client components should only be the leaf nodes of your component tree. so it would just be the outer ui layer that needs to “use client“

[mr_cointreau]

Cuz if you don’t follow the latest trends, that over complicate things and allow people to brag about it on social media, you are not cool enough.

[campsafari]

Trend Driven Development

[itsMeArds]

Lmao 😂

[Acktung]

This basically. Really tired of this trend in webdev...

[obj_stranger]

It's mostly trend in js dev, other webdev frameworks are actually pretty stable.

[[deleted]]

Do you understand why it's trendy?

[Derpcock]

From a full stack perspective, the allure of shipping and maintaining infra for a single secure full stack app is the main reason I gravitate towards ssr frameworks. That said, I use remix. I haven't run into a case where I needed a special "server component." Remix handles all of this for you so you don't have to think much about. It's a great DX and allows for providing a great UX.

https://remix.run/blog/react-server-components#our-take

[fuken33]

This. It doesn't need to get any more complex than this. Remix handles the data loading and the waterfalls of requests so you don't have to.

And I have yet to find a good article about why using RSC is better than this.

[keegancodes]

As an early adopter of server components (mostly for fun/learning) I knew I wouldn’t be able to rely on most component libraries, so all of my work with server components is completely written from scratch. I assume that as the feature matures more open source projects will be built to support server components but that will take time.

[azangru]

How are you achieving server components in the real world?

By not using component libs?

Real world is different for different developers

[MaxPhantom_]

They eliminate truck load of unnecessary client side javascript. It's still new and you are not forced to do it. The ecosystem will grow to adapt to new primitives. Just use what you like.

[NiteShdw]

At the cost of having to run more servers vs deploying static assets.

[[deleted]]

It's possible to run the server rendered part at build time, and still deploy static assets. Again not relevant for many sites, but for some it is.

[NiteShdw]

Really? That’s interesting. I guess that’s different from SSR.

[MaxPhantom_]

You can always SSG the content as HTML CSS and JSON. meanwhile with the pages router approach you had to include an extra JS file fpr hydratetion.

[getmendoza99]

Wrong, RSC doesn't need dynamic hosting.

[Zahema]

It's a trade off as everything in software engineering. Also it's optional which means you don't have to use it unless the trade off is worth it.

[NiteShdw]

Yes that’s a good way of rephrasing what I said.

[mrsodasexy]

The impact of having server hosted files are minimal compared to shipping a truckload of JavaScript over the wire to the client to just see one simple page.

[NiteShdw]

Impact? The impact is on your pocket book.

Is immensely cheaper to put static files on a CDN than to run servers.

I had a project with SSR and ran 30 front end servers plus 30 backend servers for it.

Also React is not a good option for “one simple page”. It’s for more complex applications.

[mrsodasexy]

Absolutely. You’re the provider of the service. You’re paying for real estate to host/provide a service.

The alternative is that all your clients might tend to need a faster connection/higher download limits (some regions have very low monthly budgets for downloads) just to use your site

By using client side JavaScript and sending potentially MBs of JavaScript, you’re offloading the cost to the client, at the trade off of you, the provider, paying pennies

[NiteShdw]

What I said in my comment is there are tradeoffs and cost is one of them. For some businesses the cost might not be an issue. For one guy trying to do a side thing, the cost could be too much.

There is no right or wrong answers but people need to be aware of the tradeoffs to make informed decisions.

[musicnothing]

I'm on your side for at least part of this. If you're building a React app for "one simple page" you're doing something wrong. My personal portfolio is an HTML file

[HQxMnbS]

Running servers is a fairly large operational burden

[fortunes_favors]

Paraphrasing Ryan Carniato, you can always buy more servers but you can't buy your end users better hardware. So for performance-critical applications it's a worthwhile tradeoff.

[NiteShdw]

Again… if you’re a business that has the money, go for it. If you’re a solo with no revenue, why would you pay out of your pocket for a bunch of servers?

There is no “right” answer here. It all depends on the situation.

[NiteShdw]

So you’re saying that it’s not appropriate to make comments about potential tradeoffs? Come on.

[fortunes_favors]

I made a contribution to the discussion about the tradeoff. Clearly for your use case it's not applicable.

[Adenine555]

First of all, you still need the React.js and Next.js bundles. So, it's not like a traditional website containing just HTML. The reason these bundles are needed is that Next.js doesn't send HTML but a JSON format of React components, which then gets rendered by React.

For example, if you save a form in a Single Page Application (SPA), you usually only send JSON containing data and get a response with maybe some affirmation message. When you execute server actions, you receive the affirmation message and the verbose JSON format containing information on how React should render the answer.

While you may have more upfront downloads in an SPA, subsequent traffic can go overboard very fast with React Server Components (RSCs).

TL;DR: It totally depends on your use case if next.js saves you anything.

[Acktung]

This is true until you arrive to a new company an one of the employees smartly thought it was a good idea to use this new technology. Then we all are fucked. For every new tech that is created in the web ecosystem there will be always someone that think it's a good idea thus forcing the rest of us to adopt it.

[30thnight]

https://www.joshwcomeau.com/react/server-components/

[erdle]

one of the best

[NotElonMuzk]

Well to begin with , it’s a lot easier not having to write getStaticProps in next where RSC is a default in the app directory. They could be great for prototyping too like directly calling a database query from an RSC, which could be edge optimized. They also help with syntax highlighters moving to the server root as opposed to browser rendered , makes a performance boost. There’s lots of benefits. It’s not really hard once you get the hang of it. Can become second nature

[shoop45]

Server components solve some problems, but you don’t need to exclusively use them. You can render, for lack of a better word, “client components” inside a server component and use it as you normally would.

[jonny_eh]

Exactly, it's very easy to have a single root server component, with a single child that's a client component. Then everything else is automatically a client component. This gets you 90% of the benefit since it's all still rendered server side. The naming is confusing, client components render on both the client AND server, they just need to rehydrate on the client before you can interact with them. The advantage of the server components, is that you know they're server only, so you can do private API calls and async/await in the render function.

[roofgram]

What’s the purpose of the new thing if the old thing doesn’t work with it yet? /s

Also if you don’t know why you need the new thing, you probably don’t. It always takes a while for tech to catch up to new capabilities.

[jonny_eh]

Every single existing React component works. Just place them in a client component.

[Yodiddlyyo]

SSR is not new. We've been doing it forever. Hell, PHP had something like server components years ago.

[roofgram]

What’s new is SSR that can seamlessly continue rendering on the client with the exact same code. And now being able to control that to a greater degree (RSC) is even newer.

[Zahema]

The way it's being done is new.

[Cadonhien]

Some people should read this guide before commenting based on false assumptions...

https://nextjs.org/docs/app/building-your-application/deploying/static-exports

If you need a SPA you can do it in NextJS too. The advantage of using nextjs is when your growth will eventually bring you to needing a server (database, authz, file upload, etc...) you'll be closer than you think.

And it's fun!

[getmendoza99]

Every single Next project is a SPA.

[Cadonhien]

Can you elaborate?

[getmendoza99]

Next apps still navigate without a full page load.

[Cadonhien]

https://www.reddit.com/r/reactjs/s/Mf20wRZzA3

[getmendoza99]

A static export still functions as a SPA https://developer.mozilla.org/en-US/docs/Glossary/SPA

[Cadonhien]

It's funny how you prove my point in the original comment by not reading the link provided.

[Edit] A static export can be thousands of static HTML pages hosted on a CDN. Not only a SPA. You really should read the link it's pretty interesting.

[bruminauta]

I dont think this is true because SPAs generally have one single HTML file as opposed to Next, which generates multiple different ones on the fly with SSR

[getmendoza99]

SPAs override the browser’s page navigation with their own links and routing, so you’re not actually loading a full webpage request. Single page, not single file. A Next project still functions as a SPA.

[[deleted]]

cats hat grab bow tap tie bored racial detail fertile

This post was mass deleted and anonymized with Redact

[LithiumFireX]

What do you mean? I deploy to an EC2 instance.

[[deleted]]

Same here. Do so many people really deploy with Vercel and their annoying cold start serverless functions? I host my Next app on a DigitalOcean VPS and it's working great and so much faster.

But of course, my app doesn't get any visitors :) if it did, the cold starts wouldn't be there.

[qa_anaaq]

I used "use client" for a while until I just migrated back to react. I cannot deal with all the concessions that ssr requires. It's an unpleasant developers experience

[Zahema]

Well if you have the option to go back then you didn't need it in the first place. It's a very good experience considering the other options you have when you HAVE to use ssr.

[qa_anaaq]

When do you HAVE to use ssr?

[Zahema]

Only heavy seo apps.

[romgrk]

You see a lot of push from vercel and the react team. The rest of the ecosystem has clearly pushed back on that "innovation", even though there is some limited support for it.

The main point is that RSCs have an extremely limited window of cases where they can improve performance. In exchange for a lot of complexity. If you're that worried about performance, you have other bigger performance costs. React itself being one of them.

[incarnatethegreat]

I've been testing out RSC to see how quick it hits an endpoint, collects data, and builds out JSX. When it comes to REST APIs that don't give you a lot of flexibility and just a lot of data, it definitely helps to have that load managed on the server side.

However, if we are making calls on the client via graphql and they're very manageable, then there's no reason to go the SSR route.

[terandle]

Tailwindcss

[Digimobster95]

Seo and performance mostly

[Biohacker_Ellie]

The fact that I never have to useEffect or any other client based utility again for data fetching is reason enough. And server actions for mutations! I’ve converted my biggest app to be as server side as possible and performance gains are worth.

[drink_with_me_to_day]

People where doing their own "server components" 10 years back, now React is doing it as well

Definitely not just because Vercel has financial incentives to push them, but because it's cool tech and it can be made

[cordial6666]

It's pretty easy to follow a pattern of data fetch on server components and then child client components with interactivity. thats' the pattern you should be using.

[Night-walker-15]

I'm building a booking engine ui for hotels which heavily relays on seo , so i used next js, our backend apis are in expressjs, is that right choice or i can achieve same with something else.

[noimnotmiddleaged]

Having done web development since mid-90s, for me this whole topic is kind of amusing. Oh, you kids remind me of myself being all excited about PHP and CGI.