Understanding Our Application Path: Building a Wishlist App
In the previous article, we discussed the pivotal role of Linux in the modern technological landscape and the critical influence it has on the infrastructure of numerous applications. Now, armed with this foundational knowledge, we are ready to push the boundaries of our understanding.
For many getting started in Software Engineering, the question often is, “Where do I start?” The answer lies in building an application from scratch. For this series, we will be focusing on developing a Wishlist application — a simple yet practical way to understand the DevOps workflow.
Building an application from scratch is a great way to learn the DevOps workflow. It allows you to see all of the steps involved in the process, from development to deployment to monitoring. You will also learn about the different tools and technologies that are used in DevOps.
In this series, we will be focusing on developing a Wishlist application. This is a simple yet practical application that will allow you to learn the basics of DevOps. We will not be deep diving into programming, but we will cover the essential concepts and practices.
By the end of this series, you will have a good understanding of the DevOps workflow and you will be able to use this knowledge to build your own applications.
Here are some additional reasons why building an application from scratch is a good way to learn DevOps:
- It gives you a hands-on experience of the entire development process.
- It helps you to understand the different roles and responsibilities involved in DevOps.
- It allows you to learn about the different tools and technologies that are used in DevOps.
- It gives you a concrete project to work on, which can help you to stay motivated.
Breaking Down the Application
Our Wishlist application needs to be straightforward to use. Users should be able to easily add and delete wishes, share their list of wishes, and tag wishes they’re committed to fulfilling.
Take a moment and try to envision the components our application might need. Got it?
At a high level, we need three components:
- UI (User Interface): This could be a web application or a mobile application. This interface is what our users interact with, where they input their wishes and view shared list of wishes.
- Server: This is responsible for all the logic of our application. When a user adds a wish or deletes one, the server processes these actions and sends a response back to the UI.
- Storage: This is where we store all the data related to our wishes. This could be a database where we save wishes, who added them, who’s committed to them, and so on.\
Monolith vs Microservices
Now, we could build our Wishlist application as a simple monolith — a single-tiered application where the UI and the server logic exist within the same system.
The term “monolith” or “monolithic architecture” is used within the software industry to describe a type of software architecture where all the components of the application — from user interface to data processing to data storage — are combined into a single program that runs within a single process.
In a monolithic application, all the functionalities are tightly coupled and run in the same space. This makes it a single indivisible unit, hence the name “monolith.”
However, in the contemporary tech landscape, this monolithic approach is becoming less popular. The trend is leaning more towards separating the UI from the server, each running as a separate service. This approach is part of what’s known as microservice architecture.
But does this mean we should avoid building monoliths altogether? Not at all.
In fact, for many applications, starting as a monolith is the best approach. Monolithic applications are faster to deliver and easier to test, which means you can get feedback from end-users much quicker. Remember, complexity should be avoided where it’s not necessary.
Why We Separate UI from Server
While we’re using two different applications (UI and server) for our Wishlist app, it’s important to note that this is just one of many possible approaches. The primary reason for choosing this method was to provide a concrete, illustrative example of a common real-world scenario. However, it’s not the only way to structure an application, nor is it necessarily the ‘best’ way in every circumstance.
In practice, software architecture can take many different forms, each with its own strengths, weaknesses, and appropriate use cases. Some applications might be best served by a monolithic architecture, while others might benefit from microservices, serverless functions, or any number of other designs.
The key is not to find the one ‘correct’ architecture, but rather to find the architecture that best suits your specific needs. This often involves starting with a simple design, collecting metrics and user feedback, and then iterating and evolving your architecture over time based on your findings.
So while we encourage you to understand and learn from this 3-tier example, also remember that it’s just a starting point. The best architecture for your application will depend on factors like your team’s skills and experience, your application’s specific requirements, and the nature of your user base. Always be open to exploring different approaches, learning new tools, and refining your architecture as you go
As of now, we will use so called 3-Tier Application
Three-Tier Application Overview
In the world of software development, a common architectural pattern is the three-tier application. This design separates an application’s core functions into three interconnected parts: the client, the server, and the database. This separation allows developers to modify or develop each component in isolation, which can help to manage complexity and improve maintainability. Let’s break down these tiers.
- Client: In the context of our application, the frontend serves as the client. The client, often referred to as the “frontend,” is the part of the application that users interact with directly. It provides the user interface and handles user inputs. The client communicates with the server to send and receive data but doesn’t usually have direct access to the database. In the three-tier architecture, the client application isn’t limited to being a web-based frontend. It could also be a mobile application installed directly on a user’s device. Mobile applications serve the same role as the client-side in our architecture, offering an interface for the user to interact with the application. These mobile applications, whether they’re developed for iOS, Android, or cross-platform, handle user inputs and display data to the user. They communicate with the server (backend) to send and receive data. However, just like a web-based frontend, they usually don’t directly interact with the database. Instead, they rely on the server to handle these interactions.
- Server: The application which forms the server, often known as the “backend.” The server handles the business logic of the application. It processes requests from the client, interacts with the database to retrieve or store data, and then sends responses back to the client. The server is a bridge between the client and the database, ensuring smooth data flow and implementing the necessary business rules and security measures.
- Database: The database is the repository that stores all the data that the application needs to function. It could be a SQL database like MySQL or PostgreSQL, a NoSQL database like MongoDB, or even a cloud-based database service. In our case, we’re using PostgreSQL as our database. It’s can be one or many databases, different types of databases and so on.
As we move forward with building our Wishlist application, we’ll delve into more specifics and explain how each component works. By the end, not only will you have a good understanding of how to develop an application in a DevOps environment, but you’ll also have a functioning application to show for it. So let’s start building!
Bonus Thoughts
While the course primarily focuses on the three-tier architecture, it’s always a good idea to familiarize yourself with various application architecture patterns. They can provide different perspectives and solutions to various challenges you may face during development.
One pattern I personally appreciate and recommend you to explore is the modulithic architecture. The modulithic pattern provides a practical balance between the simplicity of a monolithic system and the modularity of microservices. It allows you to structure your code into distinct modules, each responsible for a specific functionality, while still maintaining the convenience of a single deployable unit.
Whether it’s a simple CRUD application or a more complex system, modulith can be a viable option to consider. It’s particularly useful when you want to start with a simpler architecture and evolve towards a more complex one, such as microservices, as your application grows.
Remember, the architecture you choose should be suited to the specific needs and context of your application. Make sure to invest time in understanding these architectural patterns and consider their trade-offs before deciding on the best fit for your project.
