My general idea was that I was going to make a RESTful backend and then in my frontend request and render data by backend spits out. Is this generally how to layout a Node and React Web app? I'm new to front ends, any help is appreciated!
Yes this is how your app should be structured. The front end should make the API calls to your node backend and will just display the data to the user. This allows your front end to be very dynamic. If you ever want to expand your application later it will be completely independent of your backend. If you ever plan to expand to different platforms (mobile,etc) you will then be able to build those out as separate "front ends" to interact with the API as well.
Related
I am developing my own website. So far, I've used React for the frontend and Flask for the backend. I've been doing frontend development for a while now but I'm just starting to get into the backend.
From my limited understanding, frameworks like Flask and ExpressJS create their own servers and host data that the frontend can use. It seems to me that that they automatically create websites to host and receive data. In my website, I route the backend to do what I want and use fetch requests with POST and GET from the frontend to communicate.
Although it works, to me, it seems overly complex. Why does the backend need it's own server? It seems unnecessary to create a proxy for the frontend and fetch data. Why can a website not just run custom code in the background, why does it need a service like Flask or ExpressJS to run in the background for it? These backend frameworks run Python or NodeJS in the background, but wouldn't it be much simpler if the website itself could run Python or NodeJS in the background?
I also see that in frameworks like React, you can import things and use modules— like in NodeJS. While importing some modules works, the require keyword is not allowed and normal NodeJS code will not work. Therefore, the backend will not work. Why is this— why can't you just run backend code natively? Instead you have to go through fetch and specify headers to basically translate information from your frontend to your backend.
Forgive my amateur understanding of web development, but the frontend/backend system seems overly complex to me. Thanks in advance.
Why does the backend need it's own server?
Where will the client store data so that when you open the page again the data will still be there? You can use localStorage but this is locked to that particular browser. What if someone logs in on a different device or uses a different browser?
Where will the client get the application from in the first place? Your application needs to be packaged up in a form that can be easily downloaded, and it needs an address to be loaded from. This is all considered "back end" even if you're using a static hosting service like GitHub Pages.
There's a lot of reasons why a back-end exists and needs its own server. Any application with persistent state which is expected to work across different sessions needs at least one of these.
I have read on couple of articles that when building a website with react either php or nodeJS or something else is required to have a backend to retrieve data and server side rendering
I can manage data retrieving on react without any backend server (based on my experience with react-native).
I am not sure if server-side rendering is necessary for react?
What are the pros/cons, can the website work without server-side rendering?
Something has to render the original page being served for React. However, after that, there's nothing stopping you from doing everything else client side. There are tons of articles out there discussing the benefits and drawbacks of doing full CSR (Client Side Rendering) or full SSR (Server Side Rendering). However, I've found that most agree that there's a middle ground that meets the best of both worlds.
However, if your app is relatively small and unencumbered, going full CSR as you're indicating you want to will probably have little or no impact.
Server side rendering will give you better search engine results and previewing.
You can still use React with server side rendering with a framework like Nextjs. You may just want to initially render on the server side and from then on in use client side rendering.
Really depends on what you're planning to build. Firebase has security permissions for you to experiment to filter out what type of traffic you'd want. However if you are solely dependent on the client then there would be severe consequences for edge cases. What if there was an app breaking bug and someone abuses it, what if someone has an older version of your app and calls bad code? Utilizing nodeJs to call your business side logic is a very important layer of protection since you have one codebase that handles all of this incoming traffic.
So an example of business-side logic that shouldn't be on the client's system:
What if you had an important counter say $ dollars that you've spent on that website and it goes into the database once and feeds you that information and you'd save that into local storage until the end of the session. Are there consequences to this if you had multiple instances (hint: they might not all of the same $ amount if you've manipulated that data on the client's side) ? This would be an example of why you'd definitely want to have a nodeJS backend for your React application.
Is it possible to combine a Vue.js app with a restful API service?
New to Vue but written my first Vue/Typescript app that is a front end that consumes some public APIs, add extra logic and display results. All works – fine. Now I also want to have my own restful API interface.
I know Vue apps are SPAs, so when I ‘change page’ to myapp.com/page2, it is not fetched from the sever but rather the app just re-renders the display. But is it possible for those routes that are not defined, such as myapp.com/api/whatever, to be a restful interface? That is, consumes requests and return responses? And when hoisted, would a user have access to both a front-end and a back-end, even though the app is running client side?
Did start down this route using express.js but ran into issues as if I was trying to combine chalk and cheese. (Not lease, would need to change the node module to ‘commonJs’).
Would using Nuxt help? Know nothing about Nuxt … yet. Or must I go the traditional way, and write a separate back-end and change my front end to consume it.
I am little confuse about how to implement this especially for routing, how i handle routing for backend and front end and how about i using source (css, html , js ) which it will be different between front and back. thank you.
Yes, that can be achieved using MEAN stack application.
Mean stack tutorial guide Click here !!
You Can Choose Angular As your front End Framework to work with user-Interaction that will be user seeing in his/her browser and Node.Js for Backend Interaction to your Angular Application for making API calls and fetching Data that you want not to be shared with users.
In regarding to routing question use Angular Router module that will handle how user move from one component to anthers on your Front-end.
In Back-end you can use Express router module to Handle your routing requests to specific urls.
You can use Angular 2 as Frontend and Node js as your backend.
Furthermore, the routing will be set on frontend to show html pages and to get the data or perform any sql operation or to put your logic you can use node js by creating methods and then calling these methods from angular 2.
We are starting a project at work and we have used sammy.js with handlebars.js to handle the front end rendering. We are moving this new project to node and using express.js. Do we still need to use sammy.js for front end routing? We do not plan to use any front end framework currently.
Sammy.js is a routing framework designed for single page webapps. That is, Sammy is traditionally used for requests that will never leave your browser and are handled by a set of Javascript code running within it.
Express is used for server side routing, or in other words requests that hit your server. In this case, your server would render the page, then hand the rendered response back to the browser.
You can use both of them together, or use one over the other. The question you should really ask while architecting your app is whether your app is better off as a single page webapp or a multi-page app? For that, I'll refer you to this question: Single Page Application: advantages and disadvantages