What’s Full Stack Software? What are some of the most common architecture out there? How can we understand more about this domain? In this post, we hope to share with everyone the fundamentals and help everyone kickstart their journey.
Disclaimer: this is not an academic post, hence terminology might not be academically “correct”. The Objective is to simplify the process and help everyone understand the topic better
Front End is a software that display information & allow user to interact with the information provided. This could be a Desktop App, a website displayed on a browser, a Mobile App.
Back End is a software processing center that provide the information that user requested via interaction with Front End software.
Full Stack refer to a system consist of Front End and Back End component
Behind the scene
Below is one of the very common scenario on what happening behind the scene when a user open a website (Front End) and retrieve some certain information/document from the server (Back End)
- The Browser will then use the website contents to render a prettified User Interface for user to interact with
- User might then want to interact with the website to retrieve more information. For example, they might want to search and retrieve some documents stored in the system. User will then enter the text they want to use for document in the search bar, then click “Search” button.
- “Web Server” then search through the Database and extract out relevant documents, these information will then return the result to the Web browser.
- Browser will then render the new User Interface based on the new set of data (list of documents) received.
- Website Content and Behaviour is not locally available from the Browser and it need to be downloaded from the internet (e.g Storage Server)
- Web Browser doesn’t need to connect to Back End (Web Server & Database) to render and display basic website data. This mean if the website content doesn’t change overtime, we don’t need the Back End Component. This is applicable for many website out there.
- User doesn’t interact directly with Web Server & Database, all communication need to happen through Front End (Website User Interface)
- Web Server is responsible for supporting Front End to provide the relevant information per User request.
How do we prevent someone else reading or stealing the information between our Users browser and Web Server?
Common Practice #1: Use HTTPS (TLS/SSL and Certificate Authority Network)
- Standard HTTP protocol send data as a plaintext (which can be easily read in transit)
- TLS/SSL protocol encrypt data transfer between User Browser and Web Server. This involves using a set of asymmetric key (Public Key+ Private Key).
- Browser (Front End) will first retrieve the Public Key from the Web Server (Back End)
- Browser (Front End) will then encrypt all the data to send to the Web Server (Back End) using the Public Key
- Once the encrypted data received on the Web Server, it will use the Private Key to decrypt the data.
- Since the private key is something only the server has, no body else in the middle could decode the message.
- However, what happen if someone else attack in-the-middle and pretend to be the Web Server and issue a fake Public Key to User’s browser?
- To prevent this, all the Public Key are issued and reviewed by a network of trusted Certificate Authority (CA). CA are the well trusted companies and agencies that work as the middleman to certify whether the Keys & Certificate used for encryption is valid. This prevents the very common Man-in-the-Middle attack where the attacker impersonating the user’s Web Browser or the Web Server.
- In Figure 5, we can check that the website is using a valid Certificated issued by “Baltimore CyberTrust” (Root CA) and is distributed by “Cloudfare Inc” (Intermediate CA)
Common Practice #2: Reduce number of communication point
This is also referred to as the Firewall approach. The Firewall will sit in front of the Web Server or the Network to monitors and controls incoming and outgoing network traffic.
- In figure 6, we can see that this Firewall will only allow HTTPS connection from external network (where the User’s Web Browser are from). The Database has no external communication with the outside world.
Common Practice #3: Authentication
We have discussed about how to encrypt data between one user and the system. How about between our users in the system? How do we differentiate our users and make sure they can only access their own data and not others?
One of the most layman approach (HTTP Basic Auth) is to let Browser (Front End) send over a set of key (Username and password) with every request to Web Server (Back End). This has a few key limitations even if we use TLS/SSL to encrypt the information
- After Web Server decrypting the payload, any Server side logging software might record the raw password in plaintext.
- The password might be stored permanently in the Browser. If the computer is shared with another user, the password could be easily stolen by inspecting the browser.
Nowadays, majority Authentication protocol & framework exchange Username and Password with a Token after first login. Subsequently, the token will be used for user’s authorization and identification. The token might have an expiry date and can be revoked from the system.
Now we understand the design of a simple secured web application. How do we enable more people to use this?
1. Web Front End Scaling
We discussed above that a web-based Front End consists of Website Content (HTML, JS, CSS, Assets) that can be downloaded from a File Storage Server to user’s Browser. Since these website contents are static (not changing), we can make multiple copies of these and distribute from a network of servers.
These network of server to distribute static content are call Content Delivery Network (CDN). By using CDN, our main File Storage Server (origin) doesn’t have to serve every user who would like to load our website.
For more information: https://www.cloudflare.com/en-gb/learning/cdn/what-is-a-cdn/
2. Back End Scaling
There are 2 main ways to scale the web server, either increase server computing power such as #CPU, RAM, Storage (also referred to as Vertical Scaling) or increase the number of server (Horizontal Scaling)
The Vertical Scaling method is easier to do at the beginning, however, it might also hit some certain physical limit where the cost increment is no longer in linear relationship to the number of users the server can serve.
Horizontal Scaling Method is easier to achieve, however, we need to introduce a few more concepts and it should be planned from the design phase.
2.1 Web Server Scaling — Load balancer
- Load balancer is used to distribute the load evenly across different workers (e.g API Server).
2.2 Database Scaling
- For SQL Database, it can be scaled up by sharding (splitting the data storage across different server), and master-slave replication (replicate slave copies for faster reading speed)
- For NoSQL Database, horizontal scaling is supported by default
- In-Memory Database is also used to reduce time needed to query data, as the speed to read from Memory is much faster than reading from a Disk Drive
- SQL Database: MySQL, PostgreSQL
- NoSQL Database: MongoDB, CouchDB, Cassandra
- In-Memory Database: Redis, Ignite, Hazelcast
2.3 File Storage Scaling
- For On-premise setup, Network Attached Storage (NAS) is used to scale-up storage solution
- For Cloud based solution, there are many managed service provided by Cloud Service Provider, such as AWS S3, Azure Blob, Google Storage.
- For self-managed solution, Hadoop and MinIO are also quite famous
Taking all the above concepts into consideration, we have a secured and scalable full-stack software architecture below.
Coming Soon Topics:
- End-to-End Stack — Bringing Hardware into the Fullstack Software World