Anatomy of a Website

In case you haven’t realized the internet is a big thing and loads of stuff happens on it. The reason why I’ve decided to write this post is that I have lost count at a number of doctors who have come to me stating that they want to build a website, only to reveal that they know little to nothing about the structure of a website. If you’re one of these people then don’t worry, the anatomy is fairly simple. Even if you have no desire to code the thing yourself, spending 5 minutes reading up on the basics can do wonders. Let’s start from the back to the front:

Database
There’s a range of different databases. Most of them are some form of SQL. These consist of tables. For instance, we can have a user table that has the following fields:

Name
Address
Age
Company

They can link with other tables by foreign keys. For instance, we could have another table called Company. Setting Company as a foreign key in the user table will let us group users together by the company, and save us replicating data and making errors. If we had to enter the company details for each user, it would take a lot longer to make an entry, there would be a higher chance of error, and we would have to store a lot more data. With the foreign key method, we only have to enter the details of the company once. Also, if we had to change the details of the company, it would change for all instances that are linked to that company again saving time.

Backend
When a web page makes a request, the data is pulled from the database. The first port of call is the backend, this is where the data is processed. The backend is a framework that can be coded in a range of languages. I prefer Python but Ruby, C, C++ and many others are used. It’s not just processing data, allocation of data to the views, and allocation of the views to URL addresses are also done in the background alongside the user profile and login functions. If you want the website to send an email, or use a third-party application such as a payment process then it usually gets done here. The data from the backend can be directly injected into the front end, however, this is old fashioned and not recommended.

Front end

When the data is pulled from the backend, it is presented in the front end. There is a range of frameworks that are coded in Javascript that take the data and processes it. Why do this? Why have two frameworks? I mean data processing is being done in the backend right? Well, Javascript frameworks are light weight but dynamic. These can take loads off the server as Javascript is loaded in the browser. When you load a page, the data is rendered using HTML and CSS. Javascript logic can be inserted in the HTML file. Let’s say that you have a decision tree process. Depending on what you enter, different options will come up with different input options. You want to store the users’ final outcome. The logic in the Javascript will process the inputs leading the user to an outcome based on the inputs. When the outcome is decided, the Javascript framework will then push the outcome back to the backend to be further processed and stored. Let’s say there are five steps to calculate an outcome. If you were pushing data from the backend straight to the HTML page, you would have to pull and post data at every step. This means 10 requests to the server. With a Javascript framework, it’s 2 requests. Getting the data at the start, and posting it back at the end.

Arrows are API data routes

Native smartphone apps are also a sort of front end framework. It pulls the data via an API, processes it and presents it in a series of ways, and then posts the outcomes to the backend.

As a side note, there are some people who have issues with the front end framework React, stating that Facebook’s licence behind it could be a problem for start-ups. I’m not a lawyer but if you want to check this out read the following article [link].