React or Next.js?
Unanswered
Indian mackerel posted this in #help-forum
Indian mackerelOP
I am beginning to work on a day job related project where it is up in the air whether or not we simply use react or try out next.js. We have a backend api partly fleshed out (not written in JS) and we don't want to replace it. Does it even make sense to use next.js? From what I can tell the new paradigm in next.js is "app routing" which appears to require a BE that uses node.js. I am just trying to sort out if we can use next.js for the FE while providing SSR from the existing BE.
Preferably:
1. No node.js on the BE.
2. Using a "modern" next.js approach.
3. Able to use SSR from a standard backend - in this case golang serving part of the page.
Preferably:
1. No node.js on the BE.
2. Using a "modern" next.js approach.
3. Able to use SSR from a standard backend - in this case golang serving part of the page.
105 Replies
@Indian mackerel I am beginning to work on a day job related project where it is up in the air whether or not we simply use react or try out next.js. We have a backend api partly fleshed out (not written in JS) and we don't want to replace it. Does it even make sense to use next.js? From what I can tell the new paradigm in next.js is "app routing" which appears to require a BE that uses node.js. I am just trying to sort out if we can use next.js for the FE while providing SSR from the existing BE.
Preferably:
1. No node.js on the BE.
2. Using a "modern" next.js approach.
3. Able to use SSR from a standard backend - in this case golang serving part of the page.
Firstly, this is a nextjs server so you are bound to get some prejudiced/biased answers.
You dont necessarily need to write your backend in JS but if you need a SSR app, you will have to run a node server. You can directly call your golang api from your node js server which is serving your nextjs. Obviously i will say use nextjs for your frontend just because it provides some neat little opinionated things while also providing some leeway in others.
You dont necessarily need to write your backend in JS but if you need a SSR app, you will have to run a node server. You can directly call your golang api from your node js server which is serving your nextjs. Obviously i will say use nextjs for your frontend just because it provides some neat little opinionated things while also providing some leeway in others.
Barbary Lion
It's a no brainer, just use next, even the official react docs recommends that.
Indian mackerelOP
Well first of all I'm trying to understand if the community is just trying to push JS across both the FE and BE without regard for other BE solutions.
Regardless, are client side requests no longer a thing with Next.js SSR then? Is the BE expected to deliver responses?
You dont need to use JS for the backend and can use it for just frontend if you need
Since you already have a backend api in golang
Indian mackerelOP
But what you are suggesting is Next.js + SSR, where the SSR (rendered by node of course) will talk with the golang api in order to deliver data?
Ok I see how this probably works then.
I had a very unpleasant experience with the Shadow DOM
which is however needed to have "slots"= children in React
but you may want to take a look at Lit new versions, it brought a few improvements, and there are alternate solutions to have slots without shadow DOM
Indian mackerelOP
I'm not familiar with "lit".
It's a framework for web components
basically if you render Go templates and want interactivity
Next.js would be a super overlapping choice
you'd rather want to keep your favorite Go setup
and use a client-side JS library like raw React
but React will not connect well to your golang setyup either
like
the whole UI have to be React
so web components lets you instead have Go templates + islands of interactivity within them, in the form of web comp)onents
the difference is that in React, your components form a tree => they have to be connected and rendered together
with web comps you may have totally independant components
and Lit 3 seems to have brought features that still allow to connect them likewise to React context
Laysan Albatross
I started with Next.js even before I wrote one line of javascript.
You can do it from one or the other side, doesn't matter imo.
You can do it from one or the other side, doesn't matter imo.
@Indian mackerel Well first of all I'm trying to understand if the community is just trying to push JS across both the FE and BE without regard for other BE solutions.
the point of RSCs/Next is the deep integration between the server render and the client render
the client-side can automatically communicate with the BE
React Server Components can be fetched as a JSON payload
so you can have client-side navigation
displaying server-rendered components
the point of Next is hybridization of client and server renders
it will be harder to say load Go rendered components within your client-side JS
I mean you can do it but you are rewriting Next in Go
Indian mackerelOP
I think it would just have to be a go api that returns json for the FE to consume. But I am wondering if FE requests like that even exist anymore in the more modern Next.js approach.
In other words maybe all FE requests are designed to just hit the BE node code...
@Indian mackerel an interesting take: https://twitter.com/rauchg/status/1728459008544272657
this is for PHP but would apply for go too
Indian mackerelOP
So FE -> BE (node) -> BE (go)
Laysan Albatross
The focus on SSR also results in insanely good performance with Search Engines. And even if you have heavy-weight software, you dont have to care if you have a heavy-weight server.
Additionally to that, Next.js has a huge community, thousands of libraries and makes React a better experience for me personally.
Additionally to that, Next.js has a huge community, thousands of libraries and makes React a better experience for me personally.
Indian mackerelOP
It feels ... weird.
@Indian mackerel I think it would just have to be a go api that returns json for the FE to consume. But I am wondering if FE requests like that even exist anymore in the more modern Next.js approach.
you should be carteful about differentiating rendering HTML and getting data
this message is a bit confusing because your post deals with SSR (rendering HTML from data)
and here you seem to talk about client-side data fetching (CSR aka client-side data fetching)
@Indian mackerel So FE -> BE (node) -> BE (go)
sorry this is not super clear, you'll have to specify what is shared between them
you seem to mix up getting data from the Go API and rendering from the Go backend
(or I mix them up in your question)
Laysan Albatross
https://nextjs.org/docs/pages/building-your-application/rendering
Here are all different types listed
Here are all different types listed
oh ups
thats for pages
hold on
Indian mackerelOP
Ahhh perhaps I wasn't clear. My (old) experience would be react + any backend. Where react is an SPA.
Which is how I was thinking about this problem.
Laysan Albatross
So client-side rendering in the resource @Laysan Albatross gently shared
with client-side data fetching
if you are happy with that, give a shot at Vite
the point of Next is bringing SSR and static rendering, you will care about that if your app as some content, if you are building a softwarish app, you may not need it at all
in which case yes, in Next, it's idiomatic to try to get data from Next node (or edge) server as much as possible
via RSCs
though client-side data fetching is also ok
Laysan Albatross
I dont have enough knowledge for that, but I know that React also does something with client components, that require useState hooks etc.
So when you use "use client" it doesn't mean you are rendering the component completely on the client
(As far as I know, please correct if wrong)
So when you use "use client" it doesn't mean you are rendering the component completely on the client
(As far as I know, please correct if wrong)
you'll like that to
@Laysan Albatross I dont have enough knowledge for that, but I know that React also does something with client components, that require useState hooks etc.
So when you use "use client" it doesn't mean you are rendering the component completely on the client
(As far as I know, please correct if wrong)
yes it's prerendered both on server and client
For rendering only on client it's indeed different: https://medium.com/@eric.burel/how-to-get-rid-of-window-is-not-defined-and-hydration-mismatch-errors-in-next-js-567cc51b4a17
I hope you don't mind some reading ^^ I am sure all these resources will help you
Indian mackerelOP
It seems that the "pages" approach, which is old now in next.js, is closer to what I was thinking.
the best one too: https://nextjs.org/learn
@Indian mackerel It seems that the "pages" approach, which is old now in next.js, is closer to what I was thinking.
app router is a generalization of pages
you had getServerSideProps
now you can do the same directly in a React Server Component
at page level
(like getServerSideProps)
but also at layout level, or down at component level, which is the new thing
also RSCs are rendered only on the server this prevents the need to hydrate client-side (makes app a bit faster)
contrary to what most people will say this is an incremental innovation not a paradigm shift
the paradigm shift is in people head because they didn't have time to adapt to SSR in the first place, things moving too fast sadly
@Indian mackerel It seems that the "pages" approach, which is old now in next.js, is closer to what I was thinking.
Laysan Albatross
Wouldn't recommend the pages routing. It surely works fine, but you will have a lot of pain, as the most people are using app
Indian mackerelOP
So, we want to maintain a golang backend that servers only json responses (just data). But someone on the team wants to use next.js. And our app will require "dynamic" routes of course because it is a non-trivial site.... It just feels like Next.js wants everything to be JS.
As for avoiding "pages", given that it isn't the new way, I agree that it probably isn't the best approach.
It just sounds like we are forced to have node BE + golang BE possibly where the node BE is querying the golang BE directly, which, honestly, feels stupid to me. But I guess this is what it is.
As for avoiding "pages", given that it isn't the new way, I agree that it probably isn't the best approach.
It just sounds like we are forced to have node BE + golang BE possibly where the node BE is querying the golang BE directly, which, honestly, feels stupid to me. But I guess this is what it is.
next backend is not a general purpose backend
it's a backend-for-frontend
just enough to empower frontend/fullstack team to process forms or call secure APIs that are not available client-side
keep your go back around
Indian mackerelOP
So are you saying that the node BE + another BE is a common pattern?
yes
Next is all about efficiently using the presence of a Node server to serve frontend needs
either with Route Handlers (= basic API endpoints)
or all the server-rendering features (= SEO and perf optims reducing the burden on the browser)
Indian mackerelOP
Ok. Thanks a bunch. I might have future questions but I will try to keep them to a minimum.
if you want a software app, with zero SSR, maybe just use Vite + your Go backend
and allow the frontend team to have its own space in the backend
like a prefixed route they have all power on
Indian mackerelOP
Gotcha.
this will help implementing things such as agregating data server-side rather than triggering a crapload client-side queries (cascading issue)
the article that defined backend for frontend
funny enough, it was focused on mobile and thought it would'nt work for web
while
it works hella well for web too
@Indian mackerel So, we want to maintain a golang backend that servers only json responses (just data). But someone on the team wants to use next.js. And our app will require "dynamic" routes of course because it is a non-trivial site.... It just feels like Next.js wants everything to be JS.
As for avoiding "pages", given that it isn't the new way, I agree that it probably isn't the best approach.
It just sounds like we are forced to have node BE + golang BE possibly where the node BE is querying the golang BE directly, which, honestly, feels stupid to me. But I guess this is what it is.
Laysan Albatross
wtf hahaha who would use next.js for that, or even react at all.
funny colleagues you got.
I can recommend Svelte if you need a UI.
Works good with Go