How I created CloudMonitor.dk

Search for a command to run...

No comments yet. Be the first to comment.
In Laravel, Eloquent ORM facilitates defining relationships between models, such as a Post belonging to an Author. Typically, if a Post's Author is missing, accessing the author results in an error. Default models address this issue. By implementing ...

Welcome to the world of cloud infrastructure, where ease of deployment and scalability are paramount. Today, we're going to walk through setting up a Droplet (a virtual server) on DigitalOcean, one of the most user-friendly cloud platforms. Our focus...
Getting started with Terraform on DigitalOcean can be an exciting journey for developers and DevOps engineers looking to manage infrastructure as code. In this blog post, we'll guide you through the basics of using Terraform with DigitalOcean, helpin...

In the world of software development, testing is a crucial aspect of ensuring the reliability and functionality of your applications. One common challenge in testing is generating realistic and diverse sets of data for your test cases. This is where ...

Translate model attributes (table columns) easily into any number of languages.
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 stack I have used to create this project is:
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.
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:
| Instance | Price 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.
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.
There are many underlying techniques I have been tackling in this project, so I will just cover a few here.
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.
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: