Building an Asset Management Inventory App from Scratch - How we did it
Published: 2023-11-13 06:14:08

In this Post, I'll detail how we moved from idea to execution and have an MVP ready in 3 weeks. 

## Introduction
Our project empowers small companies to effortlessly track, manage, and catalog all their assets in one centralized repository and maintain a comprehensive and up-to-date inventory.

The Asset Requisitions feature simplifies and formalizes the process of requesting and allocating assets within an organization. Employees can submit requests for specific assets through the system, and designated approvers can review, approve, or deny these requests. A designated issuer then assigns assets to employees with approved requisitions. 

This project was a team effort between [Alex Jarabi](https://github.com/Jarabi) and [Myself](https://github.com/devKiratu), where Alex built out the frontend and I worked on the backend

## Inspiration

![inspiration image](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/0oi5dr5d9iu095n0f122.jpg)

Alex and I had partnered in a number of projects, so it was a no-brainer that we would work together on this one. We started brainstorming some cool utopian ideas but couldn't settle on one. It was until Alex shared a pain point in his previous workplace that we found something that we could build. We were excited to use our software development skills to solve an actual problem.

The pain point was that his former workplace used a very manual system for allocating IT assets. Requesting for an asset required one to fill a form that they would need to take to their line manager for approval, after which they would take the approved form to the IT department for asset assignment. The IT department used a book to keep a record of the assets and their users. 

This presented the following problems:
- the process was very manual and relied heavily on paperwork. If the requisition form got lost, one would have to restart the process
- the process required the line manager to be physically present in the office to approve a requisition
- all records were in a book, which in case it got lost or damaged, the records would perish as well. Similarly, searching and generating reports was a nightmare. 

With the above identified problems, we set out to build a system that would address them decisively. 

## Architecture, Technologies and Features

### Architecture
We adopted a client server architecture where we had the frontend and the backend in separate repositories and hosting environments. Alex built the frontend and I built the backend and we wanted everyone to own their part of the project. As for the hosting environments, we used [Netlify](https://www.netlify.com/) for the frontend and the ALX servers for the backend. 

Below is a diagram showing the flow of data between the web client, frontend and backend servers. 


![inventorypro architecture](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/ovf68azuypro6p0rim2e.png)

### Technologies
We used `Reactjs` and `bootstrap` for the frontend and `Nestjs`, `TypeORM` and `MySQL` for the backend. We settled for these technologies as we hadn't used them before and wanted to push ourselves and learn something new through this project. It was a good challenge and we learnt a lot. 

### Features
Below is an overview of the core features of the system:
**1. Assets Inventory** - this feature enables you to keep a record of all company assets. A designated user (admin) can create assets in the system and track their condition and current users
**2. User management** - this feature enables creation of users (usually employees) in the system. A created user can log in and make requisitions, track them, and track the assets they have been allocated.
**3. Asset Requisitions** - A user can make a requisition through the system. A created requisition appears in the line manager's dashboard where they can approve or decline the request. An approved requisition appears in the asset issuer's dashboard where they can assign assets. Meanwhile a user is able to track the status of the requisition they made. 

## Technical Challenges and My Work Around
Choosing the right technology for a project can either propel your team to deliver quickly and quality work or it can be the biggest hindrance for progress. I found myself in this situation. I had planned to use `nodejs` and `TypeScript` for the backend since I wanted to build a backend that resemble an enterprise project. 

As you might be aware, nodejs doesn't have a defined architecture and most examples out there are based on opinion. I had a hard time trying to set up a scalable enterprise project while being short on time. 

In my research, I came across [Nestjs](https://nestjs.com/), _'A progressive Node.js framework for building efficient, reliable and scalable server-side applications.'_ While going through their documentation, I read the following lines that described my situation:

> _In recent years, thanks to Node.js, JavaScript has become the “lingua franca” of the web for both front and backend applications ...
...on the server-side, while there are a lot of superb libraries, helpers and tools for Node, none of them effectively solve the main problem - the architecture.
Nest aims to provide an application architecture out of the box which allows for effortless creation of highly testable, scalable, loosely coupled and easily maintainable applications._ 
   
I was totally sold out. I cleared all the files I had initially set up and started work on and installed nestjs. In as much as I had a learning curve, I was pleased at how nestjs has many features out of the box for common functionality such as authentication using `jwt`, RBAC, `TypeORM` integration and above all, a modular and scalable architecture.

The switch to nestjs enabled to iterate quickly and deliver the backend. It remains one of the best decisions I made and I look forward to exploring more of nestjs
 
## Lessons and Takeaways
I have learnt a lot during this period of building the project. What I haven't mentioned is that before the three weeks of building, there was a three-week period of planning. Here we did the following, each taking a week:
- Problem definition - research work on problem to solve, solution to build, shopping for existing solutions, technologies and infrastructure to use, risks and sharing roles.
- MVP specification - Defining the core features of the MVP in detail including user stories, API endpoints, data modelling and overall architecture
- Task Scheduling - Breaking down the MVP specifications into small tasks and mapping them to a Kanban Board (we used [Trello](https://trello.com/)).

The above steps proved to be very crucial as they gave us clarity and direction enabling us to build quickly. My take away from that is that thorough planning is a huge part of software development.

I also learnt how to ship an MVP - it doesn't have to be perfect, it only needs the core features working. Below is a good illustration (borrowed from [ALX Africa](https://www.alxafrica.com/)): 


![MVP](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/tofchi21klnymsjrkc7a.png)

I enjoyed working on the backend and working with `nestjs` and look forward to building more backend projects with it.


## About Me
I am a software engineer currently taking the prestigious and intensive Fullstack Software Engineering Program by [Alx Africa](https://www.alxafrica.com/). You can connect with me on [linkedin](https://www.linkedin.com/in/chris-n-61a4b129b/)

Below are useful links to the project:
- Github link to [frontend app](https://github.com/Jarabi/aim-frontend)
- Github link to [backend project](https://github.com/devKiratu/aim-backend)
- Link to Deployed App [Landing Page](https://aim-pro.netlify.app/) from where you can learn more about the project
- Link to [Youtube Video](https://www.youtube.com/watch?v=Mdd2lXmmoPk) showing a demo of the project.