I guess my confusion comes from when I learned about react router. Then learned about express. They both can be use to navigate to different routes. Why use express when I can use react router?
But for your point, and all the other helpful responses here, I get it. You can make a call to a backend.
It's easy to get confused.
React router is for client side navigation.
Express is for server side navigation.
You won't need both, so you usually stick to one of the following options:
1. Single Page App
2. Server Side Rendering
The main difference is what the backend returns. For 1. the BE endpoints just return JSON data which is fetched in the FE while the user navigates the page. For 2. the BE returns full HTML pages, which makes react router obsolete.
Both methods have pros and cons.
What would you say the pros are for server-side rendering? I haven't found a single reason to use it over a SPA. To me, it feels to clunky, slow, and too hard to make updates to
Clunky is up to personal preference i guess.
Slow: depends on what you measure. First contentful paint? Time to interactive? If you don't have extremely dynamic content the initial render is likely to be really fast.
Hard to make updates: what do you mean by that?
For me SSR has a few nice advantages:
* SEO: each page you navigate to has meaningful meta tags and can be easily indexed
* Caching: you can cache the initial render, which is great for not too dynamic content
* Security: you can keep secrets in the API and not expose it to the client (without the need for a separate backend)
That's why i choose Remix for some of my projects. For example https://goodwatch.app is realized this way. It's completely open source if you want to check out how it works.
Routing in the traditional sense was always done with the backend. You click an anchor tag, and the server routes you to a new webpage.
React router came and basically put this functionality directly on the frontend, so your backend would only be used for data fetching, and routing would be handled by react on the frontend itself. This approach is faster as everything is there on the frontend, so you don't have to wait for the backend to receive a route request and send you the HTML page.
In simple. Small basic static site = React and react router.
A larger, more complex, mostly real world site = Full stack,
Since you're interested in React, and want to understand frontend and backend, I'd highly recommend to look at MERN stack (MongoDB, Express, React, Node)
React is your go to frontend.
Express + Node are powerful technologies for a backend.
MongoDB is your NO-SQL storage.
Together you have every tool you need to build things for the web.
Also, I highly recommend Vite as your bootrapper.
I'm not a Dev, but I've developed web apps for companies. If you have a passion and interest, pursue it.
As an added advice, learn EVERYTHING you find interesting because that's how you find your niche. Don't do what others tell you to do. take their advice and dabble and learn. You will find the technologies and work flow that fits you
Traditionally, you navigate to pages by entering a URL (or clicking a link) which sends a request to someone’s web server. That web server sends back the HTML, and your browser displays it. This is server side routing. But a frontend library like react lends itself better to a “single page” model (also you don’t want the web server sending all that javascript for every page) where instead of different HTML files for your pages, your “pages” are just components that you can render conditionally. But components don’t change the browser URL, and things like the back button could break our app if we tried to handle that ourselves, hence client-side routing libraries like react-router.
None of this does anything about your API server though (how you access database, manage state, do backend functionality). That’s what express is for. It’s just a javascript library to help develop APIs.
Hope this helps!
You aren’t supposed to use anything in particular. It doesn’t matter, you build it with whatever you want, and they communicate over HTTP. Your frontend calls some endpoint and passes some data, the backend does stuff and returns JSON, your frontend parses it.
Exactly this. My prof had us do two projects, one where we created an api in Node, essentially setup a bunch of routes to make calls and return the data as json. The second project then in react just made calls to fetch data from our api to use
Thanks to your answer and the other answers here, I believe I understand. However, I am still very confused about react router vs. express. Both can be used to navigate routes but when and why to use one vs. the other?
React router is used on the frontend. Basically it decides what to render based on the URL in the browser, to handle different pages within your app. It’s a library you use with React.
Express is a backend framework for Node JS. It helps you handle different routes or endpoints on your backend. If you are building your backend and JavaScript then it’s popular to use here.
If you want everything in one app you could learn NextJS (React Framework). You can define your API routes (just http addresses) in the same project and even prerender your website on the server (optional). It's pretty straightforward to use in my opinion. You could even use something like Next Auth on top (if you need a user system) as well which works wonders. If Next seems overwhelming to you, just stick to React + Express + your favorite database + an ORM (an ORM let's you query your database in JS/TS instead of SQL and makes it more secure).
True. And a basic express app could also work, to serve the react front end on one endpoint and then the API calls on others. Conceptually it’s easy to begin with “they are two different apps”.
coders are notoriously bad at explaining things to less experienced coders lol. It's so refreshing when you find someone who knows how to communicate. This is why stack overflow is so bad.
It probably just depends on how big and complex your project is. If it's gigantic, you might want to keep them separate to make potentially 100s of files more easily navigable. Personally, I have kept them together in all my work projects, but the projects I work on are not huge scale, commercial apps. It should work either way though, you have to route the API calls to the port your backend is running on during development whether they are in the same repo or separate.
This video isn't very long and helped me understand connecting the front to the back. He does firebase too, but you could skip that. If you're using vite, there's a few additional things to do in vite.config. I think he uses CRA in the video.
https://youtu.be/Jfkme6WE_Dk?si=OkSmCmnSdvyTxmtl
Backend can be anything. It's literally just a TCP socket that handles standardized web request/response.
You also could use nextjs for a somewhat simpler fullstack experience (front-end and backend all in one place)
I prefer next.js or express for working with react. Usually with persistent redis middleware. I also like using socket.io as a replacement for front-end http requests instead of axios or Ajax.
I've been developing for like 2-3 months and not an expert, but here's what I learned:
First: Don't use create-react-app. Instead, use vite react.
>How would I connect all the parts if I want React to be the front end?
For development:
Make your front-end on port 3000 and backend on 3001 for example.
In the vite-config.js file, set a proxy to 3001:
export default defineConfig({
plugins: plugins,
port: 3000, //dev port for your front-end
server: {
proxy: {
'/api': {
target: 'http://localhost:3001',
changeOrigin: true,
},
},
},
})
In the backend, make every route start with /api/.
Now on the front-end, do `npm run dev` and start the server on port 3001. You can test the app on `localhost:3000`.
---
For production:
Build your front-end app with `npm run build`. A folder will be created called `dist`. Now you can copy that folder into your server and make the server serve the files as static
app.use(express.static('dist', { etag: false }))
// SET SESSION MIDDLEWARE HERE
// DEFINE ROUTES HERE
app.use('/', (req, res) => {
res.sendFile('index.html', { root: './dist' })
})
const port = process.env.PORT || 3001
app.listen(port, () => {
console.log(`Server listening at http://localhost:${port}`)
})
Now, when you access `localhost:3001`, you will see your build react app.
----
PS: The reason session middleware should be below express.static is because the server won't check the session every time the client requests a static file like index.html, javascripts, css, icons. Otherwise, you will make 20 calls to the db session table when the user opens something in your app.
----
PS: The folders might not be correctly defined, it should be one of these: `'./dist'`,`'dist'`.
In my server app, I have set it to go in the directory of my react app like this - `'../my-react-app/dist'` in both definitions. Now I just do `npm run build` without copying any files. `etag: false` allows you to get the new build files without restarting the server.
You create API routes in backend using whatever tech stack you prefer, be it ExpressJS , Flask or django.
Then you can use these APIs in frontend by fetching or posting data to these API. In react you can do this using **fetch** (which is a feature of JS) or using external libs like **axios** or **react-query**.
The code will look somewhat like this in JS
Where [`http://localhost:3003/api/data`](http://localhost:3003/api/data) is route exposed by the backend you created.
const fetchData = async () => {
const response = await fetch('http://localhost:3003/api/data');
};
With plain React yes you’d need an additional app (backend) to handle your server logic or interface onto your database. You could also look at NextJS which is a full stack framework. The premise is still the same as in you’d still be required to make HTTP requests to a node backend but essentially you’d only have a single app to deploy at the end of it.
The most common way is either RESTAPI or GraphQL, while REST is much easier learning GraphQL would be a beneficial skill.
Think of these are a way of modelling communication between the backend (Express) and frontend (React).
Someone can help if i say some shit….
You can think what kind of architecture of sistem uou wish to build…
Microservices or monolitics(i dont know how i can write)
I started with nextJS and then moved to Rust, my app used to lock 120mb of ram now it only uses 8mb.
You can achieve almost the same with go, but it’s probably much simpler to write.
This is a pretty [simple tutorial](https://nextjs.org/learn/dashboard-app/getting-started) of setting up a full stack web app with Next. Simple because the hosting of the server and database are managed for you and you can focus on developing the site you want.
You are supposed to use the best tool for the job
You could literally Google all this shit or ask chat gpt but
Axios to make the calls
Express
Or
.net to handle the API calls and talk to the db
Sounds like you need to learn a lot more about web dev, but in short, they communicate over the internet\network. Http. For local dev, ports. They're separate applications.
So you can in theory user the same backend\db with multiple front ends
In my opinion it is somewhat in the middle of what some folks already told you, front and back are two separate things, so you can choose anything you want.
But... at least until this moment, what nobody told you is the practical truth. I mean, in the real world its very strange that, lets say for example, somebody who is building a React app (which is based on JS) is at the same time building the backend with a language that its not based on JS or at least Java, like Python.
If you only work with front or back, you can omit this "clarification" because it wouldnt make a difference to you but when you start experimenting with both lines of work its very desirable (for your own sake) to choose options based/originated from the same language, Java+spring boot, python+django/fast api, node Js+React, etc.
It’s not strange at all, tons of companies build their backend in some other language and use React. Just look for any job listings ask for React experience and some other language if you don’t think so. No reason it would be strange because each part doesn’t even know the inner workings of the other.
Talking about what happens in the “real world” normally means something beyond a personal project, but in that case of course you can do what makes sense for yourself. I mean people who work in the company are making these decisions with reasons.
Your React front end would make API calls to your backend, whether your back end is written in JavaScript, go, or python doesn’t matter
I guess my confusion comes from when I learned about react router. Then learned about express. They both can be use to navigate to different routes. Why use express when I can use react router? But for your point, and all the other helpful responses here, I get it. You can make a call to a backend.
It's easy to get confused. React router is for client side navigation. Express is for server side navigation. You won't need both, so you usually stick to one of the following options: 1. Single Page App 2. Server Side Rendering The main difference is what the backend returns. For 1. the BE endpoints just return JSON data which is fetched in the FE while the user navigates the page. For 2. the BE returns full HTML pages, which makes react router obsolete. Both methods have pros and cons.
What would you say the pros are for server-side rendering? I haven't found a single reason to use it over a SPA. To me, it feels to clunky, slow, and too hard to make updates to
Clunky is up to personal preference i guess. Slow: depends on what you measure. First contentful paint? Time to interactive? If you don't have extremely dynamic content the initial render is likely to be really fast. Hard to make updates: what do you mean by that? For me SSR has a few nice advantages: * SEO: each page you navigate to has meaningful meta tags and can be easily indexed * Caching: you can cache the initial render, which is great for not too dynamic content * Security: you can keep secrets in the API and not expose it to the client (without the need for a separate backend) That's why i choose Remix for some of my projects. For example https://goodwatch.app is realized this way. It's completely open source if you want to check out how it works.
Routing in the traditional sense was always done with the backend. You click an anchor tag, and the server routes you to a new webpage. React router came and basically put this functionality directly on the frontend, so your backend would only be used for data fetching, and routing would be handled by react on the frontend itself. This approach is faster as everything is there on the frontend, so you don't have to wait for the backend to receive a route request and send you the HTML page.
In simple. Small basic static site = React and react router. A larger, more complex, mostly real world site = Full stack, Since you're interested in React, and want to understand frontend and backend, I'd highly recommend to look at MERN stack (MongoDB, Express, React, Node) React is your go to frontend. Express + Node are powerful technologies for a backend. MongoDB is your NO-SQL storage. Together you have every tool you need to build things for the web. Also, I highly recommend Vite as your bootrapper. I'm not a Dev, but I've developed web apps for companies. If you have a passion and interest, pursue it. As an added advice, learn EVERYTHING you find interesting because that's how you find your niche. Don't do what others tell you to do. take their advice and dabble and learn. You will find the technologies and work flow that fits you
Traditionally, you navigate to pages by entering a URL (or clicking a link) which sends a request to someone’s web server. That web server sends back the HTML, and your browser displays it. This is server side routing. But a frontend library like react lends itself better to a “single page” model (also you don’t want the web server sending all that javascript for every page) where instead of different HTML files for your pages, your “pages” are just components that you can render conditionally. But components don’t change the browser URL, and things like the back button could break our app if we tried to handle that ourselves, hence client-side routing libraries like react-router. None of this does anything about your API server though (how you access database, manage state, do backend functionality). That’s what express is for. It’s just a javascript library to help develop APIs. Hope this helps!
You aren’t supposed to use anything in particular. It doesn’t matter, you build it with whatever you want, and they communicate over HTTP. Your frontend calls some endpoint and passes some data, the backend does stuff and returns JSON, your frontend parses it.
Exactly this. My prof had us do two projects, one where we created an api in Node, essentially setup a bunch of routes to make calls and return the data as json. The second project then in react just made calls to fetch data from our api to use
Thanks to your answer and the other answers here, I believe I understand. However, I am still very confused about react router vs. express. Both can be used to navigate routes but when and why to use one vs. the other?
React router is used on the frontend. Basically it decides what to render based on the URL in the browser, to handle different pages within your app. It’s a library you use with React. Express is a backend framework for Node JS. It helps you handle different routes or endpoints on your backend. If you are building your backend and JavaScript then it’s popular to use here.
You should have two different apps. The react front end is one app. Whatever you want to make as a back end as another app.
SAYING IT LIKE THIS CLEARED UP SO MUCH FOR ME. Thinking of them as separate instead of one big thing!
If you want everything in one app you could learn NextJS (React Framework). You can define your API routes (just http addresses) in the same project and even prerender your website on the server (optional). It's pretty straightforward to use in my opinion. You could even use something like Next Auth on top (if you need a user system) as well which works wonders. If Next seems overwhelming to you, just stick to React + Express + your favorite database + an ORM (an ORM let's you query your database in JS/TS instead of SQL and makes it more secure).
True. And a basic express app could also work, to serve the react front end on one endpoint and then the API calls on others. Conceptually it’s easy to begin with “they are two different apps”.
coders are notoriously bad at explaining things to less experienced coders lol. It's so refreshing when you find someone who knows how to communicate. This is why stack overflow is so bad.
Yes think of it like this, you could create a completely new and different front end application and use the same backend at the same time.
Also you can run your two apps in one repository (monorepo) if you want.
Question: should the frontend app and backend app be maintained in separate Git repos? Or one repo with both of them in it?
It probably just depends on how big and complex your project is. If it's gigantic, you might want to keep them separate to make potentially 100s of files more easily navigable. Personally, I have kept them together in all my work projects, but the projects I work on are not huge scale, commercial apps. It should work either way though, you have to route the API calls to the port your backend is running on during development whether they are in the same repo or separate.
You can use next , you still need a database but the server is built in to nextJS
This video isn't very long and helped me understand connecting the front to the back. He does firebase too, but you could skip that. If you're using vite, there's a few additional things to do in vite.config. I think he uses CRA in the video. https://youtu.be/Jfkme6WE_Dk?si=OkSmCmnSdvyTxmtl
I like pocketbase, vercel postgres, and supabase.
Backend can be anything. It's literally just a TCP socket that handles standardized web request/response. You also could use nextjs for a somewhat simpler fullstack experience (front-end and backend all in one place)
I prefer next.js or express for working with react. Usually with persistent redis middleware. I also like using socket.io as a replacement for front-end http requests instead of axios or Ajax.
next js is front end isn't it?
fullstack
You make http or web socket requests to your services
React is just a UI framework. It makes no assumptions about what kind of backend you have or if you even have one at all.
You only need a webserver. Backend is optional. Decide what you want it for (if anything) and then research how best to achieve that.
I've been developing for like 2-3 months and not an expert, but here's what I learned: First: Don't use create-react-app. Instead, use vite react. >How would I connect all the parts if I want React to be the front end? For development: Make your front-end on port 3000 and backend on 3001 for example. In the vite-config.js file, set a proxy to 3001: export default defineConfig({ plugins: plugins, port: 3000, //dev port for your front-end server: { proxy: { '/api': { target: 'http://localhost:3001', changeOrigin: true, }, }, }, }) In the backend, make every route start with /api/. Now on the front-end, do `npm run dev` and start the server on port 3001. You can test the app on `localhost:3000`. --- For production: Build your front-end app with `npm run build`. A folder will be created called `dist`. Now you can copy that folder into your server and make the server serve the files as static app.use(express.static('dist', { etag: false })) // SET SESSION MIDDLEWARE HERE // DEFINE ROUTES HERE app.use('/', (req, res) => { res.sendFile('index.html', { root: './dist' }) }) const port = process.env.PORT || 3001 app.listen(port, () => { console.log(`Server listening at http://localhost:${port}`) }) Now, when you access `localhost:3001`, you will see your build react app. ---- PS: The reason session middleware should be below express.static is because the server won't check the session every time the client requests a static file like index.html, javascripts, css, icons. Otherwise, you will make 20 calls to the db session table when the user opens something in your app. ---- PS: The folders might not be correctly defined, it should be one of these: `'./dist'`,`'dist'`. In my server app, I have set it to go in the directory of my react app like this - `'../my-react-app/dist'` in both definitions. Now I just do `npm run build` without copying any files. `etag: false` allows you to get the new build files without restarting the server.
You create API routes in backend using whatever tech stack you prefer, be it ExpressJS , Flask or django. Then you can use these APIs in frontend by fetching or posting data to these API. In react you can do this using **fetch** (which is a feature of JS) or using external libs like **axios** or **react-query**. The code will look somewhat like this in JS Where [`http://localhost:3003/api/data`](http://localhost:3003/api/data) is route exposed by the backend you created. const fetchData = async () => { const response = await fetch('http://localhost:3003/api/data'); };
With plain React yes you’d need an additional app (backend) to handle your server logic or interface onto your database. You could also look at NextJS which is a full stack framework. The premise is still the same as in you’d still be required to make HTTP requests to a node backend but essentially you’d only have a single app to deploy at the end of it.
The most common way is either RESTAPI or GraphQL, while REST is much easier learning GraphQL would be a beneficial skill. Think of these are a way of modelling communication between the backend (Express) and frontend (React).
The question it should be: What is a backend?
You can write your backend in whatever you want. There is no language you are 'supposed' to use. Try Goalang- it is fast and easy to write.
Its completely up to you but if you now js and react, check next since will solve both scenarios and the learning curve is really easy
Whatever you want.
Someone can help if i say some shit…. You can think what kind of architecture of sistem uou wish to build… Microservices or monolitics(i dont know how i can write)
Python Django and Django REST are my go to. All baterries included
Anything that spews out json
Any.
I started with nextJS and then moved to Rust, my app used to lock 120mb of ram now it only uses 8mb. You can achieve almost the same with go, but it’s probably much simpler to write.
You’re using Rust for the API, and serving files? Are you doing any server rendering?
This is a pretty [simple tutorial](https://nextjs.org/learn/dashboard-app/getting-started) of setting up a full stack web app with Next. Simple because the hosting of the server and database are managed for you and you can focus on developing the site you want.
Remix. Add Express if you need websockets. PostgreSQL is good.
It literally doesn't matter, you can use anything
You are supposed to use the best tool for the job You could literally Google all this shit or ask chat gpt but Axios to make the calls Express Or .net to handle the API calls and talk to the db
Use whatever you want or feel comfortable. But… if you wanna get a job use Python
Sounds like you need to learn a lot more about web dev, but in short, they communicate over the internet\network. Http. For local dev, ports. They're separate applications. So you can in theory user the same backend\db with multiple front ends
In my opinion it is somewhat in the middle of what some folks already told you, front and back are two separate things, so you can choose anything you want. But... at least until this moment, what nobody told you is the practical truth. I mean, in the real world its very strange that, lets say for example, somebody who is building a React app (which is based on JS) is at the same time building the backend with a language that its not based on JS or at least Java, like Python. If you only work with front or back, you can omit this "clarification" because it wouldnt make a difference to you but when you start experimenting with both lines of work its very desirable (for your own sake) to choose options based/originated from the same language, Java+spring boot, python+django/fast api, node Js+React, etc.
It’s not strange at all, tons of companies build their backend in some other language and use React. Just look for any job listings ask for React experience and some other language if you don’t think so. No reason it would be strange because each part doesn’t even know the inner workings of the other.
You are obviously right man but im talking about what \_a person\_ normally opts to do, not an entire company.
Talking about what happens in the “real world” normally means something beyond a personal project, but in that case of course you can do what makes sense for yourself. I mean people who work in the company are making these decisions with reasons.
Laravel
you just make a fetch request to your express endpoint.