What is full stack development?
Stacks
They are a combination of software applications and components you use to fix a problem or create a project with a certain development focus.
For example, there’s the front end stack that’s mostly focused on the user interface. Developers use different tools and programming languages like HTML, CSS, and JavaScript to build the front end of Web and mobile applications, and together they are the front-end stack.
On the other hand, you build the back end of a Web application which is mainly the apps core with another set of programming languages and tools which include Python, Django, and DRF. And these comprise your back-end stack.
The back-end stack also includes a data management system that consists of database applications to process data.
This is generally referred to as the data stack and is part of the back-end stack.
Back end stack
The back-end stack has everything you need to create the back end of an application’s core that deals with business logic, workflows, and data.
Back-end development includes programming languages like Python or JavaScript, frameworks like Django, and utilities like DRF, and also builds tools, databases, and caching applications.
Front end stack
Let’s shift the focus to the front end, which has two distinct parts web and mobile.
This stack includes everything you need to create a functional user interface of a web or mobile application that can communicate with the back end.
To build the front end of a web application, you need to learn HTML, CSS, and CSS frameworks. You also need to know about client side programming languages like JavaScript or TypeScript and JavaScript frameworks like react.
And lastly, you also have to be familiar with either iOS or Android development tools for both for mobile application development.
Data stack
One of the most crucial parts of every application is the data stack or tools you use to successfully store, process, and retrieve data.
This stack contains SQL or no SQL database engines, caching tools, and everything required to process data. In fact, MySQL, MariaDB, and PostgreSQL are some of the most widely used database engines you can learn to use for data stack.
For caching, Redis is a popular and widely used solution.
Full stack
Finally, let’s discuss the full stack which is the end to end solution for an application. It contains everything you need to create the applications core or the back-end process the data presented by APIs on web or mobile applications. A full stack developer is equally skilled in the back-end, front-end, and database stacks.
Such a developer should have some essential DevOps skills to build and deploy an application to production, staging, and development servers.
To be a full stack developer, you must learn everything that is required to create and deliver a functioning application. And you must also be familiar with a version control system like git for full stack development.
Full stack developer responsibilities
- Understand the complete project and take full ownership
- Select a pro create tools for developing the front-end, back-end, and database
- Create effective user interfaces for web and mobile applications
- Develop APIs
- Develop the back-end of applications
- Store, process, and retrieve data from databases
- Create servers and manage them for development, staging, and production access
- Integrate with the CI/Cd workflows
- Ensure the responsiveness of web applications
- Work together with the graphics team to bring their ideas to life
- Optimize applications for maximum performance
- Make sure applications follow the best security practices
N-tier architecture
When you develop an application, it has different parts. There’s the UI, backend, business logic, and database. These parts need to properly communicate with each other to make an application work.
Layers & Tiers
In application development, you often hear the terms layers and tiers being used interchangeably but there’s a difference between them.
An application can have multiple parts, like the presentation part, the core of the application where the business logic stays, and the database.
When these parts are in different places in the application infrastructure, like on different servers, but they still communicate with each other and function correctly they are called tiers.
Thus, layers are virtual separations of different parts of an application. Tiers are also different parts of an application but they’re physically separated in the application infrastructure.
N-tier architecture
In modern application development, there can be any number of tiers. When an applications architecture is split into multiple tiers, it’s called an N-tier application.
These days, 3-tier architecture is the most commonly used N-tier architecture. Some developers also use a 4-tier architecture when required.
3-tier architecture
Let’s say you developed a web application and the application is split into two distinct parts: the code with business logic that processes the data and the database to store the data.
You host the application code on one server and the database on another. Since they are physically separated into two different servers, you can call them tiers.
In this example, there are two tiers. So where’s the third one?
The third tier is the client computer or mobile, which is used to browse a web application or access the APIs. These clients are completely separate physical machines.
Together, the client machine, your application server, and the database server makeup a 3-tier architecture.
In a 3-tier architecture, the client tier is called a presentation tier. Client machines are also called thin clients because they don’t run business logic. They only communicate with your application and present the data.
The tier that holds the application code or business logic is called the application tier.
Finally, the tier that deals with data is called the data tier.
The 3-tiers are presentation, application and data tiers.
4-tier architecture
The 3-tiers are presentation, application and data tiers. Let’s move on to the 4-tier architecture. In a web application with a 4-tier architecture, a fourth tier is included called the delivery tier.
This delivery tier deals with caching and delivering the front-end assets to the client. For example, like a Content Delivery Network or CDN.
CDN providers have many servers across the world for better content delivery. They store your web applications, HTML, CSS, JavaScript, and images, and deliver them to the client from the nearest server. Because CDN servers are physically separated from your application and data tiers, they’re seen as another tier, the delivery tier.
This is just one example of a 4-tier web application. These applications can be very different from one another depending on their purpose, for example, financial or enterprise applications that have different needs.
Benefits of N-tier architecture
When the application is divided into multiple tiers, it becomes easier to secure and scale the application. Fixing problems or adding new features becomes more manageable because each tier is separate and works independently.
Thus, the application development process becomes more efficient when you use an N-tier architecture for your application.
Recap: What you know about client-server architecture
Introduction
Full stack development includes both a back-end and front-end stack. The back-end, or the core of a web application or an API project, is hosted on a server or serverless platform. In turn, the web application or API is used by clients. So there are two distinct parts: a client and a server, and together they form the client-server architecture.
In this reading, you will learn more about client-server architecture.
The client-server architecture
Every website you browse, the multiplayer mobile games you play and modern home appliances connected to the internet – all of these are applications running on a client-server architecture.
First is the client which is the computer or mobile device used to communicate with the back-end application. When the client devices only communicate with the back-end and just display or present the data and don’t apply the business logic, these devices are called thin clients. If client devices consume data from the API and do heavier data processing on the client side, they are called thick clients.
Second is the server. In a client-server architecture, the server hosts the application’s core that deals with incoming data, applies business logic and saves and processes data in a database. The application’s core is hosted on cloud computing units, on virtual machines, containers, or a dedicated server. Using an N-tier architecture, the application can have different layers spread across multiple physical or virtual servers.
How it works
In a client-server architecture, computers are connected via a network which can be either public or private. The client or the front-end application accepts the user data, does some basic validation, and sends the data to the server.
The server accepts the incoming data and runs through rigorous validation and sanitization processes to ensure the information is valid and doesn’t contain any potentially malicious content. Validation and sanitization are essential parts of every client-server architecture. The rule of thumb is: don’t trust anyone. As the application developer, you must validate and sanitize data no matter how trusted the source of the data is.
The data is then processed by business logic, saved or served from the database, and a response is sent back to the client. Then the client processes the server response data, makes decisions, or simply displays it to the visitor.
In a client-server architecture, the server should be capable of simultaneously handling multiple requests from multiple clients. If the server capacity is insufficient and can’t accept the number of incoming requests then it has to be scaled. You can adjust the server capacity using different scaling techniques you will learn about later in this course.
And, when it comes to communication, you should follow standard communication protocols like HTTP or Websocket to establish communication between the client and the server.
Advantages
One of the most significant benefits of using client-server architecture is the separation of the different layers of your application. The database can be installed and managed in a totally separate layer, and the data stays synced in a centralized location. In this way it allows multiple clients to communicate and use that information at the same time.
Think about the Little Lemon application you have been working on throughout the courses in this program. Without client-server architecture, it wouldn’t be possible to host the restaurant data in a separate server and process it so that whenever something changes, every client sees the fresh and updated data.
Since different application parts are stored in different layers or tiers, scaling, optimizing, and securing the infrastructure and data becomes easier. Backing up and recovering data in case of accidental loss or hardware failure is also easier because you can directly deal with that tier or layer instead of potentially causing problems in the whole application.
Additionally, client-server architecture is cost-effective because you can host it on the cloud with an on-demand pricing model and pay only for what you use. You don’t need to purchase expensive physical computers to host your application. You also don’t need powerful clients to run the business logic. Everything is done on the server, and then the final output is served to the client, which they can display directly or after some minimal processing if required.
Disadvantages
Like every architectural pattern, the client-server computing model also has some disadvantages. The first is management: you have to spend time configuring, managing, and maintaining the servers to keep them in working order. Also, unmonitored or abusive usage of the API provided by your application can cause a spike in monthly bills. Furthermore, security can be a big concern. When a security breach occurs, sensitive user data can leak, and severe financial damage can follow. And, if the server goes down or becomes unresponsive for any reason, the client applications will also stop working.
Conclusion
This reading taught you about the very popular client-server architecture you can use in every full stack application or API project. You also learned about the advantages and disadvantages of client-server architecture.
Additional resources
The following resources will be helpful as additional references in dealing with different concepts related to the topics you have covered in this section.
- Python home page
- Django web framework
- Django REST framework
- JavaScript MDN documentation
- TypeScript home page
- React JavaScript library
- MySQL home page
- MariaDB Server: The open-source relational database
- PostgreSQL open-source relational database
Front-endBack-endFull-stackArchitectureDataweb
Previous one → 7.Securing an API in Django REST framework | Next one → 2.HTML