Front-End & Back-End (CSR)

Introduction
Once when I started Programming, I started with simple PHP and then gradually switched to laravel, but I always had this misconception about websites, I thought the backend and frontend have to always be on one server that handles everything (like in the case of Server-Side Rendering frameworks), but after a while I discovered that there's something called "React" which is a re-usable library that is javascript-based and only then did I realize that yes, front end and back end could actually be on seperate servers or shall we say "nodes".
And it did make a lot of sense because it seems to me that it would be a little complicated to maintain a website/system that has tons of features on both the front end and back end respectively.

-We will be discussing Client-Side Rendering (CSR) for the most part in this blog.

-we will not focus that much on deployment so there would be no discussion of specific cloud service providers.

What can we consider as "front end"?
in the context of CSR, there's multiple frameworks in different programming languages,
the most popular in my experience are React, Angular and Vue.
there's multiple purposes these frameworks serve, but mainly those frameworks (when hosted on a "node") are responsible for human interaction with the website (referring to User Interface and User Experience UX/UI) to make it look as smooth as possible for the user.
behind the scenes each interaction from the user with the UI means a certain action should be done (usually by the backend) or some content should be shown (usually a fetch from the backend to get specific data)

What can we consider as "back end"?

what we can consider a backend is usually a codebase that processes requests coming from a front end node for further processing (fetching, execute a certain method etc...)
There are multiple frameworks and languages that actually work well with CSR-based apps since they act just as an API for the front-end to consume:

• for PHP there's Laravel (although PHP has some limits when it comes to processing due to its blocking nature but if the scale of the app is small to medium it's mostly fine to work with)
• ExpressJS is minimalistic so you'd have to add the libraries you want to work with by your own using NPM, it's good for beginners because one will have to be creative to organize their own folder structure, their
• NestJS comes with some features out-of-the-box and also has great support for the Micro-services architecture, however it does use Typescript heavily so that should be considered when choosing the right framework to use.

The Big Picture
Now that we understand what we can consider as back-end and front-end, the most crucial and important part is actually making the front end able to communicate with the back-end and vice versa.
There are many communication styles to achieve that.

• REST API is one of them, it relies on the HTTP Protocol to provide a Request/Response style and it is also the most common.
• GraphQL is a another way to "query" data from the back-end in a more precise way, therefor getting rid of the extra data that might be fetched and immediately discarded in a typical REST API Request. (An example would be fetching an array of users, each user object having: "id", "full name", "age", "username", "password", "email". And then use for example only the "username" and "password" keys, and as in GraphQL we can specifically "query" that we only need the username's and password's)

Besides that, we need a way to keep track of our users, especially if they're "logged In" or not.

API Keys come to the rescue and act like an access card to a guarded building (the back-end), usually on each connection from the user on the Front End, an API Call gets to the Back End (the very first request is usually a login HTTP Request containing the username and password) then the back-end processes that request and if everything went well, the back-end issues a unique API Key for the Front End to store for any more additional requests.

In Most Frameworks that handles the UI, there's always a notion of a "local storage". in Android it's "Shared Preferences", in Desktop it could be an encrypted file storing sensitive data and so on.

in this context of ours it's the same thing, we store the API Key(s) in the available local data store (or any key/value local data store) implementation that is available to us, in React it's "local storage".

API Key Types

There many type of API keys with specific roles , advantages and inconvenient, in this article I Will focus much on JsonWebTokens (JWT) and Classic generate-on-demand keys.

• Classic API Keys: usually a hash generated by the back-end taking into consideration identifiants of the specific user that is logging-in, after that it's stored in the database (a relational one most of the time), and on each request (other than login), the key will be searched for in our database, if it's found then the request is valid, if not (or somehow "expired") then we should return a specific HTTP Code to announce that.

• JWT Token: the same thing, a hash generated by the back-end, however it's not necessarily stored in the database, why? because the back-end can verify if the token is legit and "not expired" without even interacting with the database, because it's more of an algorithm computation than a mere SQL statement, on the back-end when we generate a JWT Token, it wraps auth information (such as username, password) and an expiration date (it could be minutes, hours , days ect..). On receiving the Key on the back-end to do some specific task, the back-end runs a "verify_if_token_is_legit" method which as mentioned before, is just cryptography math and after that the back-end can even access the auth information that was wrapped in there before at the time of the creation of that key.