Sprint 3 and 4 - Self-Hosted Fullstack Infrastructure Concept

Introduction

During these sprints, I explored an alternative, self-hosted system architecture and the use of Cloudflare Tunnels to make a React JS application hosted on Raspberry Pi publicly accessable the outside world while pointing to a registered domain that I had purchased roughly a year ago while following an optional online course during my internship. 

A strong and robust system architecture requires tools that the developer has complete control over - preferabely open source tools. One vision of mine is to move away from the current design pattern of Microbit Cloud Board to Beebotte MQTT to IFTTT (If This Then That) to a generic MQTT viewer mobile application. These tools are hosted by third party companies which are built for ease-of-use but are severely limited in high-performance applications.

Background

As an IoT student, I would much prefer utilise the technical skills and tooling I had learned over the last four years and demonstrate the viabliity of creating a custom, in-house software pipeline with the goal of streaming heart sensor data with as little latency as possible. From observation of 'Beebotte to IFTTT' implementations carried out by other teams. The low-code technology stack is quite inconsistent with the latency at which analogue input samples are relayed from the microbit to the frontend client. In one instance a sample sent from the microbit may take one second to propogate from the sensing layer to the client and then the next sample might take three seconds.

During my internship in 3rd year, I had taken a course on the developer learning platform Frontend Masters had tought me how to combine all the skills that I had previously learned in college from first year up until third year however at the time, I was lacking the skills to approach the problem of architecting and implementing a solution to combine the knowledge I learned into one single, cohesive project. Once I had completed this course, I had hosted, developed a frontend website, a backend webserver, registered the domain: brokenstack.tech and had pointed this domain to the web application I had developed hosted on the cloud provider: Digital Ocean.

CloudFlare

The skills I had gained over a year ago had proven to be surprisingly useful in this endeavor to deveop a much improved architechture for IoT Apps. Since I still had ownership of the domain: brokenstack.tech, I was able to repurpose it for this module through the use of a service called Cloudflare Tunnels. This service enables a domain to point towards a port running on a webserver on any device - in this case, a Raspberry Pi 4. This essentially maps a locally hosted URL: http://localhost:5173 to a publicly-facing domain URL: https://brokenstack.tech. The following is a screenshot of the Cloudflare console.









FFT Visualiser

Jason had discussed several times if it is possible to minimise the latency / inconsistency of data propogation and the use of a Fast Fourier Transform (FFT) visualiser to represent a beating heart to a client anywhere in the world. In order to achieve such a visualisation in real-time, it is crucial that the technology stack is capable of supporting much faster data throughput and consistency.

FFT visualisers are often used in digital signal processing applications in order to quickly display which frequencies of an analogue wave are most common. Music visualisers are the most common example of an FFT visualiser being used in the world everyday.


The audio visualiser depicted below uses the Fast Fourier Transform algorithm to respond to various frequencies in music.






Proposed Architecture

One alternative, open source solution to Beebotte MQTT is to configure a self-hosted MQTT broker on a Raspberry Pi with Mosquitto MQTT. Mosquito can be can be installed on debian-based distributions of linux by running the command: $ sudo apt install mosquitto

Continuing the python to Mosquitto MQTT exploration from the previous sprint, I had created a boilerplate React application. To this application I had added an external node package called mqtt by running the command in the terminal: $ npm i mqtt

To this react application I created a new react component called MqttDisplay which contained the code to connect to the the self hosted broker over the websockets protocol.


This component can then be called in App.jsx 



The output of the react application hosted on the RPI is dipicted below:

Putting it all together, I have created the following diagram dipicting the proposed architecture which I would like to see materialised over the remaining sprints within this module.






Comments

Popular posts from this blog

Blog 2 - HRV Demo

Week 1: HRV Review

Blog 5 - FFT & HRV