0

So I'm currently playing around with web development as a project, and I've been looking at React recently. My current issue is that I'm having trouble distinguishing between front and back end seperation.

From my understanding, the front end is the UI that the client interacts with, and the back end is the server itself.

My current goal is to develop a quick note-taking application. To do this, I currently have two different approaches floating in my head.

In the first approach, I'd have only a single directory which stores the project. The first approach is to use React to generate a UI, and then have a component in the UI call a function to write the data into a text file, and store that file somewhere in the front end directory. With this approach, it doesn't really seem like a back-end is necessary, as the front end is handling all of it?

In the second approach, where things are seperated into 2 different directories (one for the front and one for the back), I'd have the front end communicate with the back end, and have the back end write the data into a database somewhere.

Additionally, is it considered bad practice to have the front end handle stuff like writing into files?

1
  • Always. Even if you have "only the frontend", that HTML, JS and CSS is being served to your clients from somewhere. There are more options for hosting that static content because it's very simple, but it still needs hosting. Also it's not clear where you think "the front end directory" is - your React code runs in your users' browsers.
    – jonrsharpe
    May 19, 2020 at 6:44

3 Answers 3

4

From my understanding, the front end is the UI that the client interacts with, and the back end is the server itself.

This is essentially correct. The front end commonly refers to the code that is executed in the user's browser, while the back end is the code that is executed on the server.

The first approach is to use React to generate a UI, and then have a component in the UI call a function to write the data into a text file, and store that file somewhere in the front end directory.

In theory this would be possible. In practice it's not, because of the security model of web browsers. Web browsers prevent you from accessing files on the user's machine. However, you could use local storage or cookies to save the data on the users's machine. This has the drawback that the data is lost when the user clears their cookies/local storage.

Note that in this case you still have a back end because you need a server in order to transmit your page content (i.e. your front end) to your users.

In the second approach, where things are seperated into 2 different directories (one for the front and one for the back), I'd have the front end communicate with the back end, and have the back end write the data into a database somewhere.

This is what you would usually do. It can be misleading to think of front end and back end as "different directories" (though they can be). Note again that the back end must send the front end code to the user, so you will always have a back end in that sense.

The advantage of your second approach is that the user data is stored centrally, and can therefore be accessed from anywhere (well, any place that has a web browser capable of running react). It can also make it easier to protect the data, for example the user can't delete it accidentally.

1

The first approach is to use React to generate a UI, and then have a component in the UI call a function to write the data into a text file, and store that file somewhere in the front end directory.

You seem to have a fundamental misunderstanding of "front" and "back" end. The front end and back end describe execution environments not folders that store files. All of the files in your project must be deployed to a web server, so web browsers can download those files. The HTML, CSS and JavaScript files are then executed on the front end — the user's web browser. As soon as you attempt to save data back to the web server, as you mention in option #1, then the execution environment changes to the back end — the web server where the data is being stored.

Even in approach #1 you have a "front end" and a "back end." Saving text files to the same directory on the server where the HTML, CSS and JavaScript files are stored is not the front end. It is the back end, because it is not the user's web browser. Basically, web server = back end and web browser = front end in a web application.

Vincent's answer is still correct. You should probably store the data in a database of some sort. This will likely be a separate folder on the web server that contains this application logic, which may or may not be written in JavaScript. The data on the front end would be sent via regular HTTP requests to the back end. This could be a form POST, which would not be very React-like, or by using AJAX requests.

Your question just seemed to be confusing the concepts of the front and back ends of a web application. Both options you describe have a front end and back end, but option #2 would be the more common, best practice. Option #1 is technically impossible by executing code in the user's browser. Whether you save to the database or a text file on the web server, you will need application logic in the back end to do the saving.

-2

Front end stuff is what the user normally sees. The back end is usually server side stuff. If I we're in your position I would have it store the notes in something like dynamo dB because it is very static content. With using a service like AWS you can easily distinguish what is back end and what is front end.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.