A Quick Look: The Software Architecture of Common Web App Features
Tags: architecture, webdev, designprinciples, features
Published: 2021-09-29 08:28:33

In this post, I'll walk you through how to implement some of the most common web application features.

For each feature, we'll show the ff. three details:
1. A real-world example as well as a description of the main challenges for the feature
2. A list of components used in the feature
3. Component diagram

Note though that the component list and diagram are not representative of how the real-world examples I provided were actually implemented.

Lastly, the components mentioned here will be abstractions and will therefore not be attached to any specific services/platforms. This will be more of a conceptual overview.

With all of that out of the way, let's start diving in!

## Reporting
![Reporting - Sample](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/cf1msfvygq69zrz2sdp8.png)

The idea of a reporting feature is to display summarized and useful information to users. In most cases, reporting features deal with tons of data. In the above screenshot from Google Analytics, all the data received from websites are summarized and presented using various graphs.

The primary challenge for a reporting feature is ensuring that the summarized data loads quickly. Therefore, the process of summarizing data should be done by a different process separate from the frontend. The frontend's job is to retrieve the summarized data. Nothing more.

### Component Breakdown
- **Data Ingestor.**  This component receives all the data from all possible sources.
- **Data Transformer.** The raw data is then transformed by a separate process.
- **Reporting Database.** Once the data is transformed, it will then be stored in a separate reporting table/cache. This reporting table/cache will then be accessed directly by the frontend.

### Component Diagram
![Reporting](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/4vcrfbndf9ghjzo7z7ob.png)

## Search
![Search - Sample](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/7pctbyy3pgleq6dloa05.png)

For sites with high data volume, providing a search feature is crucial. Search pages should be able to provide results quickly. For more complicated sites, search results are not just ranked by text matching but also by determining search keyword relevance as well.

To achieve this, the searchable items should be indexed beforehand.

### Component Breakdown
- **Search Index.**
- **Middle Man.** This is the one responsible for interacting with the search index and sending over the search results to the frontend. Paginating and counting over the results should be done by this component as well.
- **Cache.** For apps with a really large amount of data, the search results are even cached.

### Component Diagram
![Search](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/zbu6s86w3jxxjihz4psa.png) 

## Social Feed
![Social Feed - Sample](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/ilmtrxo4wg2gv5q32w8f.jpg)

A social feed basically shows a list of items relevant to a user, like text or image posts. The relevancy is usually based on two factors:
- The closeness of the post author to the user
- The amount of interest the user has in the post's topic

To achieve this, feeds should be pre-calculated. Meaning, a separate and ongoing process will determine the posts that will make up a user's feed. This way, the feed items are prepared before the user even visits his/her feed page.

### Component Breakdown
- **User Database.** Will house all the users and their relationships.
- **Post Database.** Will house all the posts created by users. This database should also contain the post's topics as determined by the system.
- **Feed Generator.** The one responsible for determining and compiling the posts relevant to a user. The compiled posts will then be generated as "feed items" and will be stored in a feed database.

### Component Diagram
![Social Feed](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/w8et9oim650lytliaya1.png)

## Images
Images are not technically a full-blown feature but they should be handled properly to deliver a better user experience. 

For example, a user can upload a high-definition image (20MB) and, if there's no post-processing done on this original image, showing it on galleries will be a performance concern. Imagine serving a 20MB file to 1,000 users every minute. I won't do that math, but, that's not really ideal.

### Component Breakdown
- **Image Processor.** This will transform the original image into multiple versions (in different sizes) depending on what's needed by the frontend.

### Component Diagram
In this diagram, it is assumed that the images are displayed on a gallery page showing the small version. Then, on a details page which shows a medium version of the image.

![Images (1)](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/y5o1li220yer0h8swvix.png)

## And now, the end is near...
I hoped you enjoyed reading this article and learned something new from me. I'd be happy to hear your thoughts so be sure to comment down below.

---
### Credits
- Social Feed sample photo by [dole777 from Unsplash](https://unsplash.com/photos/EQSPI11rf68).

Hey, you! Follow me on [Twitter](https://twitter.com/projectkenneth)!