You have an idea for a web application (a.k.a app or platform), but what does that actually look like? If you think about building a house, you have a foundation, a frame, walls, a roof, plumbing and electrical wiring. All of these things are important to the finished product. You should think about your application in the same way. It's made up of a bunch of different components. Depending on the type of application, these components will be needed to make your product work.
Since, I’m always trying to find ways to explain technical concepts to people with non-technical backgrounds, this article is going to take you through the components of your future product. This will help you to understand what you’re aiming to build. Mobile apps are slightly different, so I’ll look at that in another article.
Here’s a simplified diagram of your web app:
As I started to create this diagram, I realised that there were a lot of things we just take for granted. We turn on our phones, open up a web browser, go to a website and it all just works. It’s obviously a little more complicated than that! So, when I say a “simplified” diagram, it really is! For now though, it’ll suit my purpose for explaining some basic concepts to you.
Some of these explanations may sound obvious, but for the sake of making sure that everyone is on the same page, please bear with me.
Device (hardware and software)
Let’s start at the top of the diagram. The device (your phone or computer) is a physical piece of equipment through which you access your application. This is called “hardware”. When you turn on your phone or your computer, the thing that makes it work is called “software”. Without software, you phone is like a paperweight – it does nothing! The software associated with making the hardware work is called “operating system” (or O/S) software. The individual programs and apps that allow you to do things on your phone or computer (e.g. a web browser) are also called “software” or “applications”.
Software is a collection of programs that provides instructions to do something and it can be written in many different coding languages. Programs themselves are a collection code used to perform a function. The code uses specific terms and formats to instruct the device on what to do - this is dictated by the coding language chosen. I’ll save a review of different programming languages for a different post as there’s a lot to cover there.
Front-End
The “front-end” is composed of all of the things that you see on the screen. It also includes some smarts to help you navigate the app, capture information and trigger activities within your app.
The level of complexity on your front-end will depend on the types of things that will done via the screens. For example, if you’re just displaying information that never changes, then that’s a lot easier than a page showing search results on a map; where you can zoom in and out on the map, select an object and view information about it.
Back-End
The “back-end” refers collectively to the programs and data storage for an application.
Back-end Programs
Back-end programs do the heavy lifting – they allow you to do things like store and retrieve information, make decisions, and perform actions by applying logic to information provided by the front-end. Think of it as the engine behind what you end up seeing on a screen when you make a request for something.
Some examples of back-end programs include:
- Creating an new user account
- Validating a login request
- Retrieving a list of items based on search criteria
- Calculating values for a report
- Making a decision on a customer appliction
As you can see, the back-end is just as important as the front-end. Together, they work with some sort of data storage facility to make your app work.
Data storage (a.k.a. a database)
Information that is captured by your app needs to be stored somewhere so that it can later be retrieved, displayed or processed at a later date. This prevents a person from having to re-enter information over and over again. The data held in the database can also be generated by the app itself. This might include things like the date the information was entered or an internal status for a person’s account.
For web apps, data is usually stored in a centralised database where the information for your app and all of your users is held in a single place.
There are alternatives to a “database” which is why I have termed this “data storage”. For now, the important thing to know is that data for your app will be stored somewhere and programs will be written to access and update it.
Application Programming Interface (API)
So how do the front-end and the back-end talk to each other? This is where APIs come in. An “application programming interface” is a program that allows two applications to talk to each other. Those applications may belong to you or to someone else. APIs take a request from one application and provide it to another application to process. It also provides the response back to the original application. In your case, this conversation will mostly take place over the Internet.
Some APIs are standard – for example if you want to embed a Google map into your app or if you want to add email addresses to a MailChimp list. This allows companies to establish consistent methods for applications wanting to communicate with them. Think of them as a published manual with the available ways to contact an application and the functions you can access. This manual will also tell you how to make the request and the format that is required.
Other APIs, like your application, may require some customised coding to work. However, for most functions, there’s probably already a template that your developers can start with to achieve the required result.
Host (hardware and software)
Your app (front-end, back-end and datastore) has to be loaded onto a piece of hardware to work. Otherwise, they are just letters and numbers on a page. That piece of hardware is called a “server”. It’s a physical device that has the capacity to run programs, manage all of the requests being sent to it, and store data. These machines can range in size and the specifications will depend on the needs of the application and the number of people accessing it. These servers also have software that allow you to monitor their performance and manage the content on them (think uploading and downloading files and programs, and managing security).
As you can imagine, at the beginning, most of us will not be buying and running our own servers, so we’ll use companies that specialise in this. These companies are called “hosts”. They offer services, called “hosting” that provide the hardware (e.g. servers) and the software to run your app.
Hosting and choosing a hosting service deserves a whole article of its own, so I’ll leave it at that for now. Basically, to make your web app work and to make it available to people, you'll need a host.
What does this mean for you?
So, there you have it – the components of a simplified web application. It turns out there’s a lot there!
It’s important that you understand all of these different components so that you have a reference point when a developer starts talking about them. It also helps you to know what you're actually building. Finally, you now have an idea of the types of expertise that you’re looking for when putting together your development team.
If you have any questions or if something about this isn’t clear, please feel to let me know in the comments below.
Do you need some help to make your web application a reality? Send us your details and we'll set you up with 30-minute discovery session to get you on the right track:
* When you sign up for a discovery session, we'll also add you to our mailing list so you can receive emails from us (with your consent). These emails will include news and updates, occasional offers and promotions, and exclusive content and resources to help you on your development journey. You may also receive follow-up emails in relation to this session. We will not spam you. If you don’t wish to hear from us anymore, simply select the unsubscribe option at the bottom of any email that we send to you.To view our privacy policy, click here.