The Method Explained

In previous articles, I have explained to you what a full-stack software developer is and what challenges you will encounter when starting. I said that the only way to learn properly and speedily is to follow a plan, a well-designed method. One that will take you by the hand and teach you, step by step, what you need to know about each topic.

Using the diagram below, I will show you what this method must cover to succeed in its goal.

This is a diagram of the components that make up a typical modern web application. This diagram is by no means exhaustive but gives us a good place to start. The app has two sides to it; the front end (also called the client side) and the back end (also called the server side). The client interacts with the front end via a mobile device, desktop, or laptop, hence the client side. The back end is running on big powerful computers called servers, hence the server side.

These back-end servers can reside in the server room of an organization or the cloud. The cloud is simply a third-party organization where, instead of managing your servers, you can rent servers and services. A typical example of the cloud is AWS (Amazon Web Services) and Microsoft Azure. Many organizations use a hybrid of on-site and off-site servers.

Let us now have a look at the types of front-end and back-end apps that we need to be able to build to call ourselves full-stack programmers. But first, let's have a look at the data flow, that is the way data moves through the system.

Data Flow

Interaction usually starts with a user using one of the client-side apps. It can be a phone, tablet, workstation, or laptop. For example, one of the first interactions will be to supply your user credentials (username and password) via the login page so the app can authenticate you. Authentication is a process whereby the app makes sure that you are who you say you are. In our diagram above, any one of the client-side devices can be used.

Once the login button is clicked, the client-side app sends an authentication request to the Web App that is hosted on the Web Server. The Web Server may in return pass the request on to the Business App on the Application Server that will in turn contact the Database on the Database Server to see if it can find a match for the supplied user credentials.

If a match is found in the Database, the Business App will send a successful authentication response back to the Web App that will be passed back to the browser. At the same time, the Business App may also call the REST API Service to log the new user session. In our example, this REST API service is hosted on a different server in the same organization (don’t worry about the terms REST and API for now).

The user has now been authenticated. Let's say that this is an insurance system, and the user opens a specific motor vehicle policy and requests a quotation from a third-party rating engine. Again, once the submit button is clicked, the Web App receives the quotation request and passes it on to the Business App. First, the Business App will authorize the user. Authorization is the process whereby the app determines if the authenticated user is allowed to perform a specific function, like requesting a quotation in this instance.

Once authorized, the Business App will send a quotation request to a SOAP API Service located somewhere in the cloud (don’t worry about the terms SOAP and API for now). The location of this SOAP API Service is of no importance to the Business App. Once the quotation response is returned, the new premium is presented to the user and updated against the policy in the database.

As you can see, all the pieces work together as a whole to support the business requirements of the organization.

Let us now look at the types of apps required to make all this happen. We will start with the server-side apps.

Server-Side Apps

Databases

The database is typically the source of truth in the organization. It holds all business transactions that took place in that organization, and without that data, the organization will not be able to do record-keeping, analysis, or accounting for tax purposes for example. The organization will also break several laws depending on the country in which it resides.

So, it is obvious that we need to know how to design and build databases and how to manage and manipulate the data that goes in and out of them.

Web Applications

These apps rule the web! We need to allow users to load new data and read and update existing data. Management needs to be able to generate reports for decision-making, prediction, and legal purposes. This is where web apps come into play. Depending on the architecture, these apps are installed on single servers or spread over several servers (Web Server and Application Server for example). These apps do all the number crunching and communicate with databases and other services.

When an app receives thousands of requests per second, the app gets installed on multiple servers and a load balancer manages the requests to the different app instances.

Services

A service is an app that has no graphical user interface (or GUI for short) to interact with. These apps usually have an API (Application Programming Interface) that other apps interact with. An app that is calling another app is called the Client. The app being called is called the Service. When a Service calls another Service, the calling Service is called a client as well. Programmers love to have fun with these names and stuff.

These services can be hosted locally on the organization's servers or off-site in the cloud on somebody else's server. These services are running the world as we know it. For example, once you place an order at Amazon, the shipping department is informed via a service to get your order ready for shipping. You, the customer, receive an email via another service confirming your order. Once the order is ready for shipment, yet another service informs the courier to collect. Once collected, you, the customer, receive an ‘On its way’ notification via yet another service. You get the picture. It's services all the way!

Client-Side Apps

Desktop Applications

A few years back, we all installed apps on our PCs. Come to think of it, we still do. These apps are called Desktop apps and have GUIs (graphical user interfaces). Examples are Microsoft Word and Adobe Photoshop. In many organizations, these are still the primary apps in use.

Browser Applications

Originally, the Internet presented us with websites. A website is a collection of web pages with hyperlinks to navigate between them. But then the Internet grew up and the browser became a force to be reckoned with and many of these desktop apps moved online to become what we now call web apps.

Originally, the content on these web pages was static, meaning the content did not change irrespective of how often they were served. Once web applications became a thing, we could make these web pages dynamic, thus allowing them to change based on certain requests. For example, looking for a specific book on Amazon presents us with a different result page than if we were to look for another book. So, instead of presenting us with a static page, these pages are rendered dynamically behind the scenes.

This dynamic rendering of web pages can happen either on the server side or the client side (the browser). And we built these apps differently depending on where the rendering happens.

Mobile Applications

Finally, mobile devices grew up as well and they needed apps as well. Originally, most phone brands had different operating systems, but much of that has been sorted by now and building mobile apps has become substantially easier. These days there are roughly three ways to build mobile apps; a web app that runs on all devices, a native app specific to the operating system of the device, or a hybrid app which is sort of a combination of the two. More on this much later. For now, all you need to know is that each of these app types requires a different set of skills and technologies.

In Conclusion

In this article, I pointed out the different components that make up a software solution. Each of these components requires a specific set of skills and technology stacks.

In the next article, I will show you what courses are making up The Becoming a Programmer Series. You will see that each course is designed to teach you how to build one of the components mentioned in this article. See you there!