Front-end, Back-end and database-side – The Structure of an App


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.).


For a website or web app, the front-end part of the application is displayed by the browser: chrome, firefox, IE, opera, safari, etc. The browser itself is just a simple application used for viewing particular types of files build with particular type of markup language called HTML and a dynamic programming language called JavaScript. It’s equivalent to an application like a word processor or excel. The browser understands how to display HTML, however so do certain word processors like Word. The reason they are not used for browsing the internet is that it’s not what they were built for and such uses are not heavily supported by these processors.

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.

In order to display content meant to be shared by multiple clients, the browser or device need to grab the content from someplace. The place where web pages are stored as files is called a remote server. “Remote” because it is not located on the user’s device specifically. To display a page, the browser makes a call to the server specified by the URL the user types in, and retrieves the HTML and JavaScript codes to display.


When the web browser makes a request for the page, there could be some back-end, server-side language associated with the page that needs to be processed first. Consider an example of a blog which has many blog posts stored in a database. A user requests a page that list all blog titles. Before we return the page to the browser, we need locate all the blogs in a specific table of the database, retrieve all the titles and list it on the page in a language that the browser will understand: HTML. The browser is not equipped to process this server-side code, nor does it understand it and that is why it needs to be done by the server. In some instances, JavaScript itself can be used to grab the information straight from the database and display it for view on the browser. Not all browsers support this function, however, nor is it a convention to do so. In most cases it is not considered a secure option. Having a separation between user input, the client side, and the database, the server side, among many things, provides us a layer of security where we can put checks to assure the integrity of input.


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.

Example of a relational database with Employees, Departments, Designations as separate tables relating to each other by IDs.

Example of a relational database with Employees, Departments, Designations as separate tables relating to each other by IDs.

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.

  • Facebook
  • Twitter
  • Delicious
  • Digg
  • StumbleUpon
  • Add to favorites
  • Email
  • RSS

One thought on “Front-end, Back-end and database-side – The Structure of an App

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>