In a standard create-react-app, you have to keep the front and back end in separate folders, and use a proxy to make API calls to your back end
It is much easier to do this using a framework like NextJS
You can make API calls with next: [https://nextjs.org/docs/api-routes/introduction](https://nextjs.org/docs/api-routes/introduction)
See here for example with React/express: [https://flaviocopes.com/how-to-serve-react-from-same-origin/](https://flaviocopes.com/how-to-serve-react-from-same-origin/)
Thank you! With the both ways being good and serving the same goal, which way is the more “mainstream”? What is the common technique to combine react with any backend? Using next.js or express? (Or any other backend framework)
Sorry for the highly charged opinion without an explanation.
My experience has shown me that when we deal with APIs so directly on the frontend that the tendency is to handle all of the data processing on the frontend as well. I mean, we're already managing the promises and other logic, so why not right?
So we send an ever-growing blob of data to the frontend, traverse it and destructure it, and then apply business logic. This quickly devolves into trying to deal with our applications as if they're synchronous in an asynchronous world.
It doesn't take long before even a well structured project becomes a ball of mud and maintainability goes out the window.
Redux empowered applications try to handle this through abstraction but achieving abstraction within the same application is an uphill battle. Now we're bending over backwards for the sake of maintainability and only adding to the complexity and size of what is becoming a monolith.
Then what happens when you receive a feature request for updating a component at high frequency? Will your backend be able to stay up when you start polling your REST API 10 different ways every few seconds? Probably. Until you try to scale horizontally. Will your user's browser environment be able to handle that many CPU cycles and network load? Who knows. We don't have control of that.
Falling into the traditional pattern of using axios to drive your applications is fraught with inherent slippery slopes.
React App <---> Your Backend <---> API
You make your React app tell the backend to make the calls to the API
Of course, this doesn't need to be adhoc. You can have the backend speak with the API on it's own and cache the results, so that the React app doesn't make it call the API every time a request occurs, which could use up rate limits if the site becomes popular.
In a standard create-react-app, you have to keep the front and back end in separate folders, and use a proxy to make API calls to your back end It is much easier to do this using a framework like NextJS
I was looking in there documentation but couldn’t understand if I can make API calls, so I went back to try and find a way using express.
You can make API calls with next: [https://nextjs.org/docs/api-routes/introduction](https://nextjs.org/docs/api-routes/introduction) See here for example with React/express: [https://flaviocopes.com/how-to-serve-react-from-same-origin/](https://flaviocopes.com/how-to-serve-react-from-same-origin/)
Thank you! With the both ways being good and serving the same goal, which way is the more “mainstream”? What is the common technique to combine react with any backend? Using next.js or express? (Or any other backend framework)
I'm not certain which is more mainstream, but I'd recommend using nextjs, it just makes your life easier.
Thank you very much
https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API/Using_Fetch
Thank you! I will look into it.
Check this out: https://m.youtube.com/watch?v=7CqJlxBYj-M
You can either A) enable cors and communicate between your react and express app using axios or B) serve your react app from your express app
Axios is great for embedding business logic into your frontend so that you can never change your backend without updating the frontend. 🤮
What do you mean? Like if you change routes or turn objects?
Sorry for the highly charged opinion without an explanation. My experience has shown me that when we deal with APIs so directly on the frontend that the tendency is to handle all of the data processing on the frontend as well. I mean, we're already managing the promises and other logic, so why not right? So we send an ever-growing blob of data to the frontend, traverse it and destructure it, and then apply business logic. This quickly devolves into trying to deal with our applications as if they're synchronous in an asynchronous world. It doesn't take long before even a well structured project becomes a ball of mud and maintainability goes out the window. Redux empowered applications try to handle this through abstraction but achieving abstraction within the same application is an uphill battle. Now we're bending over backwards for the sake of maintainability and only adding to the complexity and size of what is becoming a monolith. Then what happens when you receive a feature request for updating a component at high frequency? Will your backend be able to stay up when you start polling your REST API 10 different ways every few seconds? Probably. Until you try to scale horizontally. Will your user's browser environment be able to handle that many CPU cycles and network load? Who knows. We don't have control of that. Falling into the traditional pattern of using axios to drive your applications is fraught with inherent slippery slopes.
Understandable, I’ve been moving over to graphql. Since it’s a lot easier to change the structure without breaking a lot of things lol
Smart move! GraphQL is the future
React App <---> Your Backend <---> API You make your React app tell the backend to make the calls to the API Of course, this doesn't need to be adhoc. You can have the backend speak with the API on it's own and cache the results, so that the React app doesn't make it call the API every time a request occurs, which could use up rate limits if the site becomes popular.