A web application (web app or website) or a mobile device application (mobile app) is composed of three main parts: front-end, back-end and database. The front-end part of any application is what displays the information to the viewer and runs on the client (browser or mobile device). The back-end processes information and runs on a server that is remote from the user’s device. The database is also located remotely and stores all the data necessary for the application to run (user logins, user information, etc.).
Mobile applications also have a front-end. The front-end in this case is the application code you download to your device. The code used to display the user’s view is different per device type. For Apple devices this code is Objective-C or Swift. For Android devices this code is Java. In the web app world, such languages are mostly used for the server side. That is, the browser does not understand Java itself and will not display the desired results. Mobile devices are built differently than the web browser and understand different types of code.
Why can’t an application be fully contained on the user’s device, like a phone or a tablet? It can, but with limited functionality. The reason the processing of such information has been set aside for the server rather than left for the device itself is two fold. One, a lot of the time the device does not host enough processing power to compute the information as it is developed to specialize in other types of processing specific to the device. Two, for any data that is stored in a remote database, the information needs to be retrieved by a middle party and pass it onto the front-end for display.
Consider the ability for users to log into their account on a common application. If there was no common server for each user to query for the purpose of verifying their username and password, each device would have to have it’s own storage located straight on the device itself. Each time a user creates an account, provided that other devices need to have knowledge of this user (for example for sake of communication), each device would have to be updated. Can you imagine not only how much data would have to be stored on your device, but also how many updates per day, nay per second, would be happening on your device. The device would be rendered unusable.
In my previous example I specifically did not include the browser as a possible application without a server. This example is even less probable. You can have a web application that runs only on your local computer, and many developers do while they are developing a site, however it will not be accessible to anyone else. If there is no means of accessing your website by anyone else but you, there will be no point for your site. However, you can serve the site from your own computer and open it up for access to the world, but in this case your own computer becomes the remote host; server.
The database is a simple repository for your data. In an example of user logins it stores user names, emails, passwords (hopefully encrypted), and other user data that the application will need to retrieve and use throughout its lifetime. There are many configurations for databases. A common ideology in databases is the idea of relational databases. Relational databases organize data into tables with columns and rows, each row having a unique key. Rows in one table can be link to rows in another table. For example, we can store usernames, passwords and emails in one table called “Members” and more details about each user like address, occupation, user’s website address in another table called “Member_Details” associating the records by a common row ID.
Databases can be stored on the same server as the server/back-end component of your application, however, this practice is not secure and should not be used beyond a simple proof-of-concept for your idea. Read more in Basic Server Security Concepts
Application architectures get much more complicated starting with this simple concept. We can have load balanced servers which are employed to distribute a bigger load between them, CDN networks which work to serve users pages faster depending on their geographical locations, caching layers between all three front-end, back-end, database, CMS systems, firewalls and many many more. For the sake of simplicity, we won’t go into these as they are all very specific to particular type of projects and would be better addressed as the need comes.