Stock Master: Get Rich by Staying on Top of Stock Trends

Bolu Ajibawo
6 min readNov 16, 2017

--

Stock Master is a web app that helps you stay updated with stock trends of the companies; you and friends care about.

Screenshot of Stock Master

When you enter a company stock code, its stock trend for the last 1 year is plotted on the graph.

Adding a Stock

Your actions are also synced across all users in real-time

Real-time syncing across clients

Stock Master simply involves requesting stock data from an API and plotting the graph of the stock data.

I obtain stock data from Quandl API and plot the graph of the stock trend using Highcharts (a library for drawing charts).

Socket.io powers real-time syncing across users.

Stock Master is a full stack JavaScript application built with: Node, Express, Pug and MongoDB.

Source code of Stock Master has an MIT license and is available on GitHub.

The Process

Let's dive into how I built the app.

Stock Master is my version of the FreeCodeCamp Stock Market app.

User Requirements

  1. User Story: I can view a graph displaying the recent trend lines for each added stock.
  2. User Story: I can add new stocks by their symbol name.
  3. User Story: I can remove stocks.
  4. User Story: I can see changes in real-time when any other user adds or removes a stock. For this you will need to use Web Sockets.

In the spirit of experimenting and building applications to production ready status, I decided to deploy ES2015 code and protect the app from security vulnerabilities.

My ToDo List

The first thing I needed to do, was figure out how the app would work. I had questions like:

How would I plot a graph of stock trends?
Where would I get stock data from?

To plot a graph I came across two main libraries: Highcharts and D3.js .
I went with Highcharts because it was simpler to use. I implemented their demo to see how it works.

I also needed an API to retrieve stock data for companies from, Quandl came to my rescue.

At this point, I had a working demo and could proceed into making a proper app.

The process of making the app involved 3 stages:

Stage 1: Functionality
* Setup server and routes
* Research WebSockets
* Implement all user stories
* Ship ES6+ code.

Stage 2
* Style
* Document
* Refactor
* Deploy

Stage 3
* Test online app
* Get feedback and integrate
* Write

STAGE 1
My working demo was a single index.html file which contained all my code: HTML, CSS and JavaScript. This didn't look good at all.

I wanted to use an MVC architecture and make the codebase modular.

In transiting from the demo, my first iteration of the app made requests from the client to the server, and from the server to Quandl API. The server retrieves stock data and passes said data to the client to plot the graph.

The flow of my app looked like this:

Client -> Server -> Quandl API -> Server -> Client

To make the app faster, I decided to make requests directly from the client to Quandl API. Thus we have:

Client -> Quandl -> Client

The flow is now much simpler to reason about.

Building Stock Master involved a lot of iteration and testing things to understand how they work.

XSS Attacks

I used DOMpurify to clean data before sending it off to my database and also before displaying it to the user. DOMpurify sanitizes data in order to prevent XSS (Cross Site Scripting) attacks.

I didn’t have to worry about XSRF (Cross Site Request Forgery) as user authentication was not a feature of the app. Anybody is allowed to make requests to the app, no special profiles, therefore no requests to be forged.

WebSockets

To sync across users in real-time, I used Socket.io which is based on WebSockets.

I built a simple chat application to understand how WebSockets work, and then used my lessons to integrate real-time functionality into Stock Master.

Check this out! I just built the next Whatsapp. Hahaha

Shipping ES6+ Code

Shipping ES6+ code based on Philip Walton's advice was interesting. He makes a strong argument that:

The latest browsers can support ES6+ code, thus developers should ship ES6+ code to users, as the files are smaller in size and offer faster parse times than ES5 code.

The standard workflow of most developers involves transpiling all code to ES5 and then shipping to users.

Philip suggests we build two JS bundles (ES6+ and ES5) and auto-detect which the browser supports before downloading a single JS file.

I created two config files for webpack and built two JavaScript bundles. I was glad to see it work nicely in the latest Chrome and Opera browsers. Some versions of Firefox and Edge don’t fully support the technique. I was willing to sacrifice these browsers because Chrome is the dominant browser in the world right now, and so the exceptions should be beneficial to the average user.

STAGE 2
I added some simple styling to the app to make it visually appealing.

L-R: Before Styling. After Styling

Refactoring my code was a mentally strenuous task as I had to think through my code, how and why it works.

I abstracted long functions into smaller functions and coupled them together. I gave myself code reviews and had to rewrite my code severally. This is hard, working with other developers would definitely make the process simpler.

Struggling to give myself code reviews

I came across an article that suggested I remove comments from my code so as to make it cleaner and understandable.

I followed the advice and it resulted in a better codebase.

I wrote good documentation on Github and added an MIT License. Contributing to the app is highly welcome. My database is on mlab and I deployed the app to Heroku.

STAGE 3
I tested the online version of the app to make sure everything works as expected and fixed bugs I found.

For instance, I had mobile responsive issues and had to fix that.

Writing this article about my process helped me reflect and share my lessons with others.

Lessons Learned

Even though I had a working demo on day 1 of building the app, it still took me an extra 7 days to build the app into something proper. Be patient.

You might not know how to build something, but taking it one step at a time and solving problems as they come, gets the job done. Literally one step at a time.

I stood on the shoulders of giants: Highcharts and Quandl. If these resources were not available, it would have taken me far longer time to build the app.

Building web applications today is way easier because of open source and free resources.

If you liked this article you may like Chingu, my favorite programming community.

--

--