How I created CloudMonitor.dk

Subscribe to my newsletter and never miss my upcoming articles

In my previous article Bug Management for Laravel I explained what CloudMonitor is. In this article I want to let you in on how I created it in terms of technologies and techniques. Later I will dig into some of the topics mentioned here to cover theme in deep. Feel free to request one.

The tech stack

The stack I have used to create this project is:

  • DigitalOcean
  • Laravel 7
  • Vue 2
  • MySQL
  • Bootstrap

These are all applications, platforms and frameworks I have been using extensively for years, thus I have a vast experience. However there was obstacles on the way and this was also intended. I wanted to challenge myself and to both learn new techniques but also show off what I can do.

DigitalOcean

Is used to tackle all the infrastructure, from a Ubuntu server (Droplet) with Apache2, firewall, nameservers, cloud backup (Spaces) and managed database (MySQL). The great thing about thing about DigitalOcean is that it's very cost effective to get started as a startup. The only peak in my setup is the managed database, but that could easily be hosted on another Droplet (self-managed) or even the same Droplet as your Apache2/webhost, though the last option is not recommended for production.

For instance if you want to setup similar to mine with webserver, database and backup:

InstancePrice per month
Droplet$5
Spaces$5
Managed Database$30
Per month$40

What I love about DigitalOcean is their straight forward, and cheap, prices, where AWS has a lot of running costs that can be hard to calculate. DigitalOcean for instance offers free nameservers, where that has a small price for AWS.

If you want to try DigitalOcean you can use my link: DigitalOcean - it's an offer for both us:

Everyone you refer gets $100 in credit over 60 days. Once they’ve spent $25 with us, you'll get $25.

Laravel, Vue and Bootstrap

As this is a tool to help Laravel, it only made sense, that the tool itself is written in Laravel. The idea of the package for you install in your application to communicate with the server is to work out of the box, with a very minimum of configuration.

Where Laravel is the backend serverside language, written in PHP, serving all the logic in the background, Vue is a Javascript framework and therefor handles all the dynamic content in the interface.

The styling and layout is handled by Bootstrap which allows for a streamlined standardised layout. A great tool I have found along the way is bootstrap.build where you can style all its components online and refer to a CDN, before you download the modified files, this better ensures for strictly following Bootstraps guidelines while customising the look.

Underlying techniques

There are many underlying techniques I have been tackling in this project, so I will just cover a few here.

Package development

Key / secret

As the platforms purpose is reporting errors on other applications, I naturally had to create a client package that can report these incidents. So it was not just one, the main, application, but two. This would not work without some sort of communication between them and since fragments of code is to be sent in order for better debugging I felt it was needed to encrypt this communication. I ended up using a key/secret approach. The idea is the whole message on the client is encrypted using the secret, which the server also stores and is not transmitted at all. The key is sent along the encrypted message to tell the server which key to lookup to find the unlock secret. The server keeps a throttle limit so too many failed requests will result in a block to avoid brute force.

Testing

One of the biggest issues I had for a long time before I found a solution was to test the client package. One thing is to develop a client for your main application, but often the errors happens when something goes wrong with the communication to the server. I implemented a few steps to tackle that:

  • Versioning, ensuring that client and server a tracking on the same versions, and if breaking changes must be added, the server can handle requests based on the clients version.
  • Communication, I added methods for sending test incidents through the system, so I could force an error to see everything is working before releasing either the server or the client update including debugging information both back to the client and stored on the server.

CloudMonitor.dk

No Comments Yet