A few months ago, I decided to build my first solo large project. Having completed 3 years of my Computer Science degree, I felt the need to put my years of study to the test.
Over the six semesters that I had completed I had been introduced to several topics and technologies but could not really delve too deep for the lack of time. I was tired of the several half-completed projects that were made just for the sake of grades on a sheet of paper instead of any substantial work that would stand tall independently.
This led to what became a 4-month revision of everything I had learnt in the past and new learnings that I would carry for the future.
Initial Spark
The origins of the project were based on a quite simple premise. I wanted a portfolio website but with a well-built admin support. My current portfolio website was just a basic Github.io page so any updates to content would result in editing the html and then committing changes.
Brainstorming
With the idea in mind, I had to plot the subject matter of the project. How many moving parts would the project have? How complex could I keep the project? What tech stack would I use? How much time could I allocate to complete the project? were some of the questions I pondered upon.
To start off I decided to make a simple html-based project to decide the structure of the web site. That helped me decide how many parts the site might be composed of.
With any preliminary design, there were issues with this one. The most obvious one being the jarring color scheme.
Clutter vs. Minimalism
One of the things I have observed with each project I make is that cluttering a single page with too many pieces of information as well as too many design components such as rigid borders and strong colours with no relation often puts off the reader.
This is one of the mistakes I made in my initial design.
A person well versed in colour palettes and common design paradigms might be more well versed with making bold design choices look good… but I unfortunately do not fall in that category. So, the easiest fix is to rely on a design framework!
Design Frameworks such as Bootstrap or Material UI provide a mechanism to make sleek components that follow a uniform design language. One has control over the data placed in the component and certain aspects of the design in such a way that one does not completely botch the design by making too many bad decisions. Each design framework has its own subtle characteristics.
I personally always use Material UI which is something used by Google for their web design. More on that soon.
Tech Stacks
A full stack application is composed of the front end, the back end, and the database where the information being communicated can be stored. As of today, there are several tech stacks to choose from which provide a combination of technologies to satisfy the pieces required by the full stack application for example the MERN stack for MongoDB, ReactJs, ExpressJs and NodeJs or MEAN for MongoDB, ExpressJs, Angular, and NodeJs. The tech stack I usually choose is Angular, Spring, and MongoDB.
What impacts the choice of tech stack?
Some factors that might influence the choice of tech stack are
Scale of the application
Complexity of Data
Experience of the individual/team building the application
Type of data
and more.
My choice of tech stack was mostly influenced by my experience. Since the application was at this time just going to be used by me, scale wasn’t much of my concern. However, Spring is a quite scalable framework. I also chose MongoDB since my data was not necessarily well structured. If I were to store information in tables, many columns for a given record may have been null which would result in wasted space.
Design Framework and Tech Stack
In my case, the choice of Material Design as my design framework was influenced by the fact that I used Angular as my frontend. Since both were developed by Google, there would be good compatibility between them.
So, what’s next?
With the barebones decided, I now had to start the main brain racking part which was the implementation of the project. As I can recollect, many things that I initially planned did not come to fruition and many new things appeared which I did not expect. This resulted in the 4-month long journey to complete the application, and this article is but an overview of that journey.
I want to recapitulate and document each of the phases of my project more thoroughly instead of a single rushed article. So, I shall dive deeper into each of the major parts in future posts.
Thanks for reading.