Throughout this book, we are going to go through different components and aspects of web development and embedded systems. These are all going to be held together by our central goal of making an entire web application capable of sensing and displaying the surrounding temperature and humidity.

In order to make a properly functioning system, we have to first build the individual parts. More difficult still is making sure all the parts work well together. Keeping this in mind, let's take a look at the different components of our technology stack and the problems that each of them solves:

The sensor is what connects our otherwise isolated application to the outside world. The sensor will be connected to the GPIO pins of the Raspberry Pi. We can interface with the sensor through various different native libraries, which we will be looking into in the later chapters.

This is the starting point of our data. It is where all the data that is used by our application is created. If you think about it, every other component of our technology stack exists only to manage, manipulate, and display the data collected from the sensor.

Data is the name we give to raw information, which is information that we cannot easily aggregate or understand. Without a way to store and meaningfully process and retrieve this data, it will always remain data and never information, which is what we actually want.

If we just hook up a sensor and display whatever data it reads, we are missing out on a lot of additional information. Let's take the example of temperature: what if we wanted to find out how the temperature was changing over time? What if we wanted to find the maximum and minimum temperatures for a particular day, or a particular week, or even within a custom duration of time? What if we wanted to see temperature variation across locations? There is no way we could do any of this with only the sensor. We also need some sort of persistence and structure to our data, and this is exactly what the database provides for us.

If we structure our data correctly, getting the answers to these questions is just a matter of a simple database query.

The user interface is the layer that connects our application to the end user. One of the most challenging aspects of software development is making information meaningful and understandable to regular users of our application.

The UI layer serves exactly this purpose: it takes relevant information and shows it in such a way that it is easily understandable to humans. How do we achieve such a level of understandability with such a large amount of data? We use visual aids, such as colors, charts, and diagrams (just like how the diagrams in this book make the information easier to understand).

An important thing for any developer to understand is that your end user actually doesn't care about any of the backend stuff. The only thing that matters to them is a good experience. Of course, all the other components serve to make the users experience better, but it's really the user facing interface that leaves the first impression, and that's why it's so important to do it well.

This layer consists of the actual server-side code we are going to write in order to get the application running. It is also called middleware. In addition to being in the exact center of the architecture diagram, this layer also acts as the controller and middle-man for the other layers.

The HTML pages that form the UI are served through this layer. All the database queries that we were talking about earlier are made here. The code that runs in this layer is responsible for retrieving the sensor readings from our external pins and storing the data in our database. As you will see in later chapters, the middleware can also be further broken down into individual components, each with its own function.