Investory

Core Stack / Tools

Technical

• Frontend – NodeJS
• Backend – NodeJS
• Database – MySQL
• Source – BitBucket

Deployment

• Server – AWS EC2 (Windows)
• Routing – NGINX
• Deployment – Powershell Script Driven

Other

• Design – Figma
• Project Planning – Jira

Key Learnings

Here are some of the key learnings from the project.

NGINX and Blue / Green Deployments

Maybe this say’s something about my future career prospects, but hands down my favourite part of this project was setting up my own blue/green deployment system. I’ve seen it in use at one of my previous employers, but I’ve never actually set it up myself.

For this project, I implemented my own automated deployment system with both a staging and production environment, so that we could test code in both development, a hosted staging environment and finally push it to the production environment – based on branches created on the repository.

When pushing a code change from staging to production, I made a system that launched a fallback server for NGINX to route traffic to whilst the main servers source code was being updated.

NodeJS is not as bad as I thought

I’ve always wanted to make projects in NodeJS but for some reason have been scared off by the NPM package manager and not knowing how to install or debug things, I assumed it would be complex to setup on my PC so always stuck to Python Flask as my framework of choice. When forced to use and learn NodeJS, it became very clear how easy it is to use and how looking back, I would’ve used it for a lot more personal projects!

Setting up SSL also isn’t awful

I was frankly scared about sorting out the SSL for our hosted domains, but I came to learn that using win-acme to generate certificates is not actually that hard (now I don’t know the in’s and out’s of how secure the generated SSL certs are, but I know that the padlock icon showed in the browser when our project was deployed…). Pointing NGINX at the certs was also a breeze.

Prioritising based on strengths

Given the timeframe, my team quickly realised we had to prioritise based on peoples strengths. I was the only person going into the project with prior programming experience, so after the brief 1.5 weeks of general programming training was up, we had to prioritise based on our strengths.

The team structure was as follows:

Me (Team Lead / Lead Developer): Led team standups and prioritised team members responsibilities based on strengths, whilst also having the final say on technical decisions.

Team Member (UI/UX Design): Absolutely saved the team as none of us knew how to design the frontend. Worked to create all of the UI designs in Figma and then export these to HTML templates.

Team Member (Full Stack): Worked with myself both pair and mob-programming on various aspects of the website. Helped with early prototypes to present in our mock stakeholder meetings. Worked to get the HTML templates provided from Figma working and more accurate (as there where some small issues that the conversion software missed out)

Team Member (Backend / Finance): This team member had experience in finance so they took the lead on all finance related calculations, and worked with myself to get these calculations working correctly in the backend API’s.

To Work On

Given a more reasonable amount of time to work on this project, I probably would’ve focussed on the following things:

Handling Cash Balance:

The website currently has no support for representing cash, e.g. when you sell a stock, it looks like your portfolio has gone down in value because that money just disappears – in reality the money still is there, it just isn’t invested in a share. A mechanism to add/remove cash likely wouldn’t be too complex to implement.

Currency Handling

Currently the portfolio only handles US stocks because the concept of currency adds a lot of complexities. For example, the mechanism for calculating the stocks portfolio performance already seems quite complex and compute heavy, however to add currency management on top would mean having to get the conversion rates for all asset currencies for every single day the portfolio has been active, to then calculate the return for that given day in the users preferred currency – something we absolutely did not have time to account for.

Better Deployment System

To the outside the deployment system worked flawlessly, no downtime on deploys and around a minute after pushing to either the staging or production branch, and the change was live. However underneath, the whole system was powered by PowerShell scripts that polled the Bitbucket repository – not ideal. In future, I would be setting up a system that uses Docker to handle the deploys.

Furthermore, we had a Bitbucket pipeline setup to run tests before allowing you to merge into the staging or production branch. This is great, except we had no unit tests given the time constraints. Given more time, these would have been crucial.

A Login System

Last but definitely not least, the system was exposed to the web with no form of login or authentication. This absolutely needs to be added if the website was going to be made public, in-fact someone in a different team found out our domain before the presentation, and joked about adding random tickers to the portfolio. I knew they wouldn’t have done this, but it highlighted how crucial a login system is.