Client Side versus Server Side Rendering
In week 9, we discovered a Python framework called Flask.
While taking the course, something didn't seem right to me.
I couldn't understand why we were working with HTML on the server.
Since I started learning to program, I had always used a frontend application to build the user interface and a separate backend application to connect requests from the frontend to the database.
I kept wondering, "Why is the UI being generated on the server?"
This confusion resulted from my previous exposure being limited to Client Side Rendering development (CSR) and pushed me to explore the difference between those 2 approaches.
Client Side Rendering: We typically use a separate application to build the frontend.
Data exchanged between the frontend and backend is in JSON format.
For example, if I send a request to the backend to list all people matching specific criteria, the backend will return JSON data (perhaps an array of objects).
My frontend then processes this JSON and builds the UI in the browser using the frontend application's mechanisms.
Server Side Rendering: We typically have a single application handling both frontend and backend. The frontend is created on the server and served directly to the browser.
Traditional SSR (PHP, Ruby on Rails, etc.) renders static content, meaning if you want to update something on the page, you need to send a request to the server and receive a completely new page.
Modern SSR (Next.js, Nuxt.js) can update parts of the page without rendering the whole page again. They combine characteristics of both SSR and CSR.
It's SSR because the initial user interface is created on the server, but once loaded in the browser, it behaves like a CSR application.
To summarize:
CSR = JSON comes from the server → The browser builds the UI
SSR (Traditional) = HTML comes from the server → The server builds the UI
SSR (Modern) = Application is built on the server and sent to the browser; once in the browser, the application sends and receives JSON to and from the server.
Another interesting topic and a fundamental we saw in this week is user authorization.
What is user authorization?
After a user successfully authenticates by providing the correct username and password, authorization is a mechanism that allows a user to access the different services of an application without having to authenticate anymore.Authorization is like getting a stamp on your wrist after being accepted in a club, to be able to get back in faster.
There are 2 kinds of authorization : sessions based and token based authorizations.
Sessions
In sessions, the session data is stored on the server and a session ID is sent to the client and stored in a cookie.
Sessions are stateful meaning the client is coupled to a specific server.
In distributed systems where the application is running on multiple servers, all the server needs access to the same session data which adds latency as each server needs to make a request to the session store.
Sessions offer a more flexible way to invalidate the access to the server.
Tokens
A token is sent to the client containing all necessary information for authorization. The token is sent with every request and uses asymetric keys.
Tokens are stateless meaning the client is decoupled from the server which makes it a better choice for distributed systems.
