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.
Looking back with a lot more experience, I think I can answer this question.
What confused me was that developers go through all the hassle of back-end libraries to write complex APIs, when the same code can be run in the front-end. It seemed like a very roundabout way to build websites.
To understand why developers do this, you have to have a fundamental understanding of the back-end and front-end, which are, at a primitive level, the same thing.
In the web, people host URLs — addresses for servers. These URLs, when visited, send requests to a specified server. The server executes code according to its programming, and sends a response back. Web frameworks just allow developers to do this more efficiently/easily.
When you go to a URL and receive a response from the server, that response is the server's message, "packaged" by a framework. This means that everything from the entirety of Google, to unformatted JSON, is essentially plain text with some additional info (headers) that tells your browser how to handle the response.
When front-end frameworks "package" a response, they take your code and translate it into an HTML response that is sent to your users.
Any and all programming logic included in your front-end code, is run within the HTML using script
(JavaScript) tags. Although you may not be using JavaScript, all front-end frameworks ultimately compile to vanilla JavaScript. The code in these script
tags, is called client-side code.
The problem with client-side code though, is that your end-users (clients) shouldn't necessarily have access to server operations.
If you are trying to say, insert a document into your database, process a payment, or run any sort of sensitive code, doing so on the front-end would cause a myriad of problems (safety and efficiency chief among them).
Instead, what you can do is run back-end (server-side) code. While front-end frameworks take the code you write and serve it to the world by "packaging" it, server-side code, is simply code that runs before (or alongside) the packaging.
When you send a request to a server, server-side code executes locally on the server. Then, the server sends a response based on what the local code evaluates.
This solves the problem of running sensitive/time consuming/resource intensive code, because the code runs on the server (not the client), before the evaluation is returned to the user.
While both back-end and front-end libraries are, at a primitive level, packaging systems, back-end libraries can (importantly) run server-side code.
Back-end and front-end libraries are usually separate, simply because of conveinence (with frameworks like NextJS being the exception). Sending code as user-friendly HTML, often presents different challenges than sending it as plain text or JSON. Frameworks just make it easier to do what you need to do with each.
Frameworks like Next.js often blur the line between server and client side, but the two have their place.
Although the back-end and front-end are, at a primitive level, the same, the main difference is where they run code.
The front-end can run code in the "background" (client-side, browser), but it usually shouldn't for security and efficiency reasons.