Like I said in the first article of this series, there is no best tool; please know what the requirements for your project are. Well, my project is a series of articles about choices in a software project. My first goal is to start from the very beginning with nothing fancy, nothing more than what I believe is the minimum software that makes sense.
The Coffee Shop.
To contextualize this project, let's describe a fictional company called The Cofee Shop. A great friend of ours owns this company, and what he wants is a simple Web system that will run on a local machine. Multiple users (employees) using different computers can create orders simultaneously. As it is still a small shop, it is not expected that more than three users will be taking orders simultaneously. Also, products sold and used in the shop can be input into the system's stock by the manager.
As the shop owner, he wants to control what users have clearance for each functionality and manage these users. As his shop is about to open, he needs the system to be developed quickly, and he is not willing to spend on licenses or cloud providers.
He would like a broad view of what is ordered, what employees are selling the most, and what time of day and days of the week are the best-selling days.
Based on this information, I'll create a list of requirements and discuss some options for our project.
5 Users using simultaneously
Run on Local Machine
Fast development
No licenses
Levels of clearance (employees, manager, admin)
Create, Update, and Delete (CRUD)
Users (login, name, password, role)
Products (name, description, price)
Orders (date, products, seller, quantity)
Supply (product, price, quantity)
Report
Sales per person
Products Sold
Profit/Loss
Our key choices
You might have noticed we have started with a simple software application as you have gone through the requirements. But choosing the wrong tools can slow us down or make the project unsuitable for our requirements.
Database Management System (DBMS)
We need a proper database to store all the information input. There are a large variety of database engines available; here, I'll discuss two possible choices that, at some point, you will come across one day or the other.
Relational DBMSs (SQL)
By far the most common type of database, that is. There are plenty of different flavors of RDBMSs, some so simple that they are rarely used for multi-user applications like SQLite, others so robust that they are developed to run in distributed environments leveraging replicas and dealing with massive volumes of data like Postgres. There are free-of-charge DBMSs like MySQL and some enterprise-oriented ones like MS SQL Server and Oracle.
RDBMSs require a data scheme beforehand; this makes this choice less suitable for projects with flexible data schemes. Also, there is a performance issue; RDMSs can quickly retrieve data using indexes and different optimized operations like Hash Joins. On the other hand, inserting or updating indexed data can bottleneck performance.
Non Relational DBMSs (NoSQL)
This is by no means something new, but it became mainstream in the last decade or so. Document Databases like MongoDB, Firestore, and Dynamo are ultra-flexible regarding data schemes. One can have no data scheme and still store data in an organized and reliable fashion. This type of database is also suitable for horizontal scaling and distribution. There are also some downsides; whoever is consuming this data must implement the schema's integrity. Also, it can lose its scalability and distribution advantages if ACID transactions are required for that implementation.
Other Types of Databases
Other DBMS types are dedicated to highly related data, such as Neo4j. Time-oriented, like Influx, is used for recording events like sensor readings. Many different types and applications exist, but we will stop discussing databases and pick one already.
Our Choice
Since we have a well-defined schema and need a free-of-charge DBMS, our weapon of choice will be MySQL. Later in this series, I plan to use different databases for different purposes.
Backend Framework
Just like Databases, there are many frameworks to develop a Web Application. Each of them has its advantages, disadvantages, and toolbox. Many variables might influence this choice. The language used by this framework, for example, Django, could be a plausible choice for someone familiar with Python shortening the development time. C# .NET can also be a perfect choice if many people will be developing the project together; the strongly typed language will likely make the project less error-prone. Also, legacy implementations can determine a good choice for your project. Let's say you are dealing with a legacy application written in Java; to reuse the classes and modules, you can use Java Spring Boot.
I'm a little bit traumatized by 3rd party's code, so I prefer strongly typed languages. But for the first part of this series of articles, I'll go against my will and pick the NodeJS Express framework. The reason is that it uses a loosely typed language (JavaScript) that is easier for a first-timer to grasp. Also, this is the very same language running behind our frontend framework. Last but not least, a large community supports it, so many packages are already available and will be helpful throughout this process.
Frontend Framework
You are probably tired of comparisons by now, so I'll cut straight to the point. There are also multiple frameworks for developing frontend applications; they also have different languages and characteristics. We will probably touch on Flutter further during this series of projects, but JavaScript is pretty much the standard. To combine front and backend languages, we will use ReactJS, one of the most popular frameworks.
Conclusion
There are many options for you to develop. Many things must be considered when picking a piece of your developer stack. To summarize, I'll list a couple of questions you may ask yourself before choosing:
Is the project well-defined, or is it likely to change its requirements along the way?
Do I need a reliable source of truth for my data, or can I deal with inconsistency?
Will many teams be working on the project? Do I need enterprise-level technology and support?
Will this project scale? How much?
Is there a legacy project? Do I have to integrate?
What sort of packages or characteristics of a language should I expect?