I'm writing my first Node/React/Express/Next app.
I'm uncertain how to execute server side code when a request comes in.
When there's a request, I need to get some data off the server disk. I'm trying to do this from a javascript file in my pages directory, but the 'fs' module is not accessible from here. I guess that's because the browser must be executing the code (which is confusing for me because I thought next.js meant the server was processing the code and exporting the html back).
I've done much googling about this problem and can't seem to find an answer. Which is bizarre, because this must be one of the most basic requirements of a web app. Maybe the solution is so basic and I'm just overlooking the obvious?
Can anyone provide a brief explanation or pointers in the right direction on how to do server-side processing (eg reading a file from the servers disk) from a /pages/xxx.js file in a React/Express/Next app? Or in other words, how or where do I access the 'fs' module?
The error I get is "ModuleNotFoundError: Module not found: Error: Can't resolve 'fs' in /pages
thanks
Your next.js app is split in two pieces, the part running on the client and server (rendering the pages to HTML) and the part running only on the server (finding the pages and exposing them over HTTP).
What you want to do is possible only on the server and usually done in the realm of express, the routing framework. Next.js is designed to make it easy to create SPAs that do not need a backend but want server-side rendering.
However it does allow modifying the server-only component, if you need to. The documentation for that can be found in the "Custom Server and Routing" section of the docs.
You can then add API routes that the front-end can call to request data form the backend, e.g. by returing JSON that the app can store in the React state.
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.
A novice javascript developer here!
A have a basic question on whats the best and secured way to make HTTP calls from a front application to a backend service that needs an authentication. My application is a SPA (using Vue.js) & getting data from Java services. Java services need authentication details and return sensitive user data.
I see there are a few options and I wanted to understand a better approach amongst all 3-
Making direct HTTP calls from javascript code- Concern for using this approach is, as Javascript code can also be viewed via dev tools in browser, wont it be easier for anyone to do an inspect and view all critical authentication details hence making overall integration less secure?
Making an HTTP call using Axios via Vue framework- Seems like Axios is Promise based HTTP client for the browser that lets you easily make HTTP calls without much code overhead. but is this secure? is Javascript code loaded in the browser? Or the front end code sends the request and axios makes the request from backend server where the application is hosted?
Using Node- If front end application has unique routes configured for each API call and in my application if I have a route mapping to use request module and node js backend code to make those HTTP calls, is that going to be a robust and secure way of integration?
Please let me know your thoughts and apologies if this is a dumb question!
Not dumb at all. You're just learning.
My first question to your answer 😅 will be: is your application server-side rendered or it's sap + backend?
If it's server-side rendered then I would say it's secured since Node will be sending pages with all required data. On the dev tool, you will only see static files being loaded.
However, if it's SAP, I am not sure whether there is a way to hide whatsoever you send to the server from the dev tool. The only one thing you will need to do is to make sure you encrypt whatever is sensitive to your application.
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.
Context:
I'm making a React website that draws information from the Google Sheets API and formats specific rows into a data visualization. There are columns I don't want to share because of sensitivity of information, and fortunately there are ways to share only specified columns, but that isn't why I'm asking the following:
Problem:
I want to have a Node API that handles requests from a React front-end, but whose code isn't available on the client's browser (for example, in the bundle.js file created during build).
Clarification: I have noticed that when running most Node-React application examples locally and when building them with webpack, you end up with one bundle.js file that contains Node request-handling code being delivered to the browser on page load.
Proposal:
Do I need to deploy two separate apps (one for Node, the other for React), or can I keep them together without the server code being visible to the client?
EDIT POST ANSWER:
you end up with one bundle.js file that contains Node request-handling code being delivered to the browser on page load.
This was untrue. The code I had assumed to be request-handling code was client side request-calling code.
It is already decoupled. There is nothing you need to do.
Note that the security of your node.js server code depends on your server configuration, not node.js. If you access your server via unencrypted file sharing or FTP then your node server code is still not safe.
Even when using encryption, avoid compromised protocols such as SSL or TLSv1.0 (use TLSv1.3 instead for things like FTPS)
You can add a simple authentication system. There are plenty packages out there for Node already, so no need to implement it yourself.
Specifically, this would prevent the backend from sending sensitive data to a unauthorized request.
EDIT: Just for clarification, code run on a Node.js server is not sent out publicly, it will run on your server and send its output to the frontend.
EDIT 2: Looks like I misunderstood your question.
If your code is not decoupled at the moment it will need to be. All code of a React.js project is sent to the browser. Since there is no backend to handle any kind of access logic, any such logic would have to be in the frontend (React.js), where it could easily be circumvented.
I'm building a web application using node.js, this is my first time working with node. I'm using express framework and I have a question about client side rendering.
All the tutorials that I have found online talk about express and server side rendering. They talk about how you can use jade the express templating engine, to serve rendered templates as reponse to your web application.
My application is going to be client heavy and most of the rendering will be done client side. I want to call server to just get plain JSON response and then render it client side, so server side rendering is not of much use.
In this case, is express a right choice? I really like the way I can write APIS in express but I'm concerned about how to serve my application. If I don't want to use the server side rendering it would mean that I would have to serve static HTML at the first call which seems weird to me.
You might want to try Emberjs if you want most of the work done on the client side. But still, you need to send the data to the client so one way is to build your app totally on the client side just by sending a plain html and working your way up there. You can also precompile jade
What you are describing sounds like you are searching for an javascript MVC(or other) solution.
There are a lot of possibilities. Take the right tools for the right job.
Try the following link to get an nice overview of what is possible.
Helping you select an MV* framework