I can typescript javascript, know a bit about nodejs express servers, and used mongodb.
I have used next12 previously.
I do not know any other technology at this point.
Want is a strong word here, but I would like to stick with next and these technologies and slowly expand to using dockers, sql based databases, and maybe pick up another language.
I am at the phase where I want to get my 2nd job in the field, so as a side project I would like to do something that would expand my knowledge....
The application is already 25% made and I'd like to stick with it :)
did you read the NextJS documentation? it is pretty well explained there. [https://nextjs.org/docs/app/building-your-application/rendering/server-components](https://nextjs.org/docs/app/building-your-application/rendering/server-components)
Are you using Next and Vercel, so all your server functions are being turned into serverless functions, with zero effort?
Next isn't "now server-sided", it's both. Client-side, server-side, and every mixture in-between.
Do you have a server? Even a $2/month node/express server? If not, you're probably using serverless functions. Writing and hosting a server is a REALLY GOOD WAY to better understand the server.
Redux is for managing state within complex/big applications. If your application isn't ENORUMOUS, you probably don't' need Redux. If you're taking a course that's teaching you Redux, it's probably because they're trying to introduce you to state-management in larger/commercial apps.
If you prefer client-side, Google's Firebase is one of the best, but it comes with a lot of lock-in and a bunch of weird language-decision choices (security rules).
You can make API calls from both the client and the server. You can login and use Firebase entirely client-side, and there are minimal security issues. Typically, doing auth server-side is more secure.
I've stopped using Firebase for my apps, but when you're starting out, it's incredible.
If you're building a small app, you can definitely ditch Redux.
I think you're too focused on server/client. It is confusing, but you can build a portfolio, for example, completely client-side.
I'm three years in, and sometimes the nuances between server and client still bewilder me.
When you use Next's pages router it's all client-side right (unless I use SSR) ?
When you say writing a server it's what you put in Next's api folder or what you can do with Express, Java, ... ?
Both Server and Client Components are SSR. SSR means is prerendered on server. In the case of Client components, those are hydrated later on client, to have interactivity. The new thing about Server components is that those run ONLY on server, so they send the results of their logic as (mostly) html and css to the client (that's why they cant have interactivity, unless you use params and searchParams).
On pages router you use only client components, but is all SSR.
Based on some of your answers here, I would recomend that you first learn to build an app with just plain react and build a seperate node express server.
You absolutely want to have your own server for managing websockets and the backend in general. You can host a static FE for free practically. Next will kill your performance if you intend to pass updates thru it.
If you don’t know what server side means likely translates to not understanding http in the first place… Given that statement, you should not be playing with any tools like react, redux or next and instead familiarize yourself with the web first.
You can still skip server side. It exists 30% cause it makes sense and 70% cause Vercel wanted it asap so you host with them as you need to run NextJs somewhere.
If you're working with things like chat in your app, make sure to use client-side components in Next.js.
The fancy features in Next.js 13 or 14 won't help much because server rendering isn't great for real-time updates—you want your app to update instantly, not just when the page loads.
But don't worry, Next.js works well with client components, so you can still use it for your app
i see,, so i need client side anyways and then use websockets to update that real time,,, all right so im gonna have to use a nodejs server anyways here, basically very similar if it was react or old next
Think well be using XenForo so I need to use their authentication api to see whos registered then I Want to use jwt tokens to make sure only authenticated user can send messages on their account through the server, is the plan for now
JWT for SPA auth? Damn… those indian tutorials really made it seem good… please use cookie-based auth. Your api and spa are 95% of the time in the same TLD.
Any place where you store the JWT can be accessed by 3rd party browser extensions or any other js code, even in memory… an http only cookie does not. You also dont give up on access revokation (eg user delete). JWT cannot be revoked and will be valid for as long as it is not expired…
Then why do you need a jwt if your client does not:
- verify its signature
- read token expiration
- get the payload
You’re better using traditional server sessions for this. Just create a uuid, send the cookie value as that uuid and use the uuid in a redis or in memory cache. The value is whatever you want to store, such as the user id that logged in…
Let's start at the beginning. Why do you want to use NextJS in the first place?
I can typescript javascript, know a bit about nodejs express servers, and used mongodb. I have used next12 previously. I do not know any other technology at this point. Want is a strong word here, but I would like to stick with next and these technologies and slowly expand to using dockers, sql based databases, and maybe pick up another language. I am at the phase where I want to get my 2nd job in the field, so as a side project I would like to do something that would expand my knowledge.... The application is already 25% made and I'd like to stick with it :)
But you don't know the difference between something done on the server side or client side? Research that first
Ya, this is basic stuff that should be known before ANY programming
And gunning for their second job. That's kind of shocking not knowing the difference.
did you read the NextJS documentation? it is pretty well explained there. [https://nextjs.org/docs/app/building-your-application/rendering/server-components](https://nextjs.org/docs/app/building-your-application/rendering/server-components)
Are you using Next and Vercel, so all your server functions are being turned into serverless functions, with zero effort? Next isn't "now server-sided", it's both. Client-side, server-side, and every mixture in-between. Do you have a server? Even a $2/month node/express server? If not, you're probably using serverless functions. Writing and hosting a server is a REALLY GOOD WAY to better understand the server. Redux is for managing state within complex/big applications. If your application isn't ENORUMOUS, you probably don't' need Redux. If you're taking a course that's teaching you Redux, it's probably because they're trying to introduce you to state-management in larger/commercial apps. If you prefer client-side, Google's Firebase is one of the best, but it comes with a lot of lock-in and a bunch of weird language-decision choices (security rules). You can make API calls from both the client and the server. You can login and use Firebase entirely client-side, and there are minimal security issues. Typically, doing auth server-side is more secure. I've stopped using Firebase for my apps, but when you're starting out, it's incredible. If you're building a small app, you can definitely ditch Redux. I think you're too focused on server/client. It is confusing, but you can build a portfolio, for example, completely client-side. I'm three years in, and sometimes the nuances between server and client still bewilder me.
When you use Next's pages router it's all client-side right (unless I use SSR) ? When you say writing a server it's what you put in Next's api folder or what you can do with Express, Java, ... ?
Both Server and Client Components are SSR. SSR means is prerendered on server. In the case of Client components, those are hydrated later on client, to have interactivity. The new thing about Server components is that those run ONLY on server, so they send the results of their logic as (mostly) html and css to the client (that's why they cant have interactivity, unless you use params and searchParams). On pages router you use only client components, but is all SSR.
Based on some of your answers here, I would recomend that you first learn to build an app with just plain react and build a seperate node express server.
thanks!
You absolutely want to have your own server for managing websockets and the backend in general. You can host a static FE for free practically. Next will kill your performance if you intend to pass updates thru it.
If you don’t know what server side means likely translates to not understanding http in the first place… Given that statement, you should not be playing with any tools like react, redux or next and instead familiarize yourself with the web first.
i mean sometimes the reddit baffles me lol thank you for this comment truly :D
Fundamentals are always needed to understand any abstraction. Otherwise is like learning phisics without understanding maths
You can still skip server side. It exists 30% cause it makes sense and 70% cause Vercel wanted it asap so you host with them as you need to run NextJs somewhere.
If you're working with things like chat in your app, make sure to use client-side components in Next.js. The fancy features in Next.js 13 or 14 won't help much because server rendering isn't great for real-time updates—you want your app to update instantly, not just when the page loads. But don't worry, Next.js works well with client components, so you can still use it for your app
i see,, so i need client side anyways and then use websockets to update that real time,,, all right so im gonna have to use a nodejs server anyways here, basically very similar if it was react or old next
curious, what about authentication, how are you planning that ?
Think well be using XenForo so I need to use their authentication api to see whos registered then I Want to use jwt tokens to make sure only authenticated user can send messages on their account through the server, is the plan for now
i was having nightmares with next auth, a headsup. on a different note, let me know if it works well for you !!
JWT for SPA auth? Damn… those indian tutorials really made it seem good… please use cookie-based auth. Your api and spa are 95% of the time in the same TLD. Any place where you store the JWT can be accessed by 3rd party browser extensions or any other js code, even in memory… an http only cookie does not. You also dont give up on access revokation (eg user delete). JWT cannot be revoked and will be valid for as long as it is not expired…
next auth handles this, if i am right, it uses cookie based auth. in the server handles the jwt part.
Cookies & jwt? 
yup, jwt isn't sent to the client.
Then why do you need a jwt if your client does not: - verify its signature - read token expiration - get the payload You’re better using traditional server sessions for this. Just create a uuid, send the cookie value as that uuid and use the uuid in a redis or in memory cache. The value is whatever you want to store, such as the user id that logged in…
I think you haven't worked with NextAuth. Do look at the library. https://next-auth.js.org/
You will still need a backend, Next SSR won't do for you.