Learn about the inspiration and tech stack behind Wojciech's creation, Performeter; a tool for performance testing.
Innerworks is coming soon...
This blog was originally published on our previous Cogworks blog page. The Cogworks Blog is in the process of evolving into Innerworks, our new community-driven tech blog. With Innerworks, we aim to provide a space for collaboration, knowledge-sharing, and connection within the wider tech community. Watch this space for Innerworks updates, but don't worry - you'll still be able to access content from the original Cogworks Blog if you want.
Every month, client communication takes a backseat and we get our creative heads on within our teams to solve problems. The two-day internal event includes a hackathon that is dedicated to internal work only. You can read a bit more about what we do, here.
It was over a recent Cogworks Hackathon that I had my idea, plus, the time to execute it!
The inspiration.
Some time ago we had a team discussion about automating lighthouse reports. We wanted to be able to easily spot any performance issues that might appear when certain changes are made, for example, when we deploy to a production environment.
The idea.
I’d had this idea for a tool to help performance for a while. In my head, I visualised a tool that would produce lighthouse reports for our client websites, store them in a database and display the data as charts. From the charts, it would be easy to see where performance is falling down as a result of simple changes like a package update, or a layout change.
The plan.
The goal was to create a client-side application that presents data from Lighthouse stored in a database through a custom backend application with REST API. My requirements were pretty simple. I wanted to do this efficiently and cost-free. I definitely didn’t want to spend any money on hosting, databases or other services.
The stacks I used to build Performeter.
For the client application, the choice was easy. I decided to use Vue.js to build the whole UI! Why? Because the whole team love it, (you may have read in my previous blog, but to sum up, Vue.js is a framework our whole team are experienced at building with).
For styling and design, I used Tailwind and some free components from Tailwind Components. Thanks to the free components, I saved loads of time writing CSS, HTML and thinking about how things should look. For the charts, I used a package created by Dmytro Barylo - Vue Trend Chart, it looks great and has the functionality that I needed.
As I said earlier, I wanted this to be as easy as possible. As a client-hosted application, I used Netlify. Netlify is awesome because it’s easy to configure and allows you to plug in a custom domain, deployment is automatically triggered by GitHub push, plus, we already use it to store static items so getting to grips with it was easy.
For the backend application & rest API I needed something simple. I decided on Express.js to create the REST API that will be responsible for making Lighthouse reports and serving data for the client application. To store data I chose MongoDB hosted on MongoDB Atlas, selecting the shared option (as that is free and has more than I need for this application)
As a hosting for Express application, I choose Heroku. Again, it was the free option, easy to configure, intuitive and allowed the use of Buildpacks. FreecodeCamp.Org describes buildbacks as the scripts that are run when your app is deployed, used to install dependencies for your app and configure your environment.
Heroku Buildpack makes it easy to build with headless chrome which is great because it was the one thing that I considered as a potential challenge or blocker at the start of this side-project! To run the headless Chrome, I used a package called chrome launcher.
Additionally, Heroku has a lot of available add-ons. One of them is Heroku Scheduler which makes it possible to set some regular time-based jobs. This is the add-on I used to trigger Lighthouse reports, automatically every day.
After a few hours, I was done with the whole project, it was working and deployed. I called it Performeter and I’m really happy with the results.
The Performeter works great! (Although it's more of an MVP-type tool for now) Looking back, Heroku was the weakest point of the application. and at some point, the shared machine from the free plan on Heroku will be too slow and running multiple lighthouse reports will become tricky.
I hope this illustrates how quickly you can build an application when you choose the right tech stack for it. And of course, I hope reminds us of the indispensable benefits of having spare time to work on ideas as a developer!
I’m looking forward to using Performeter on our client projects. Please do feel free to shout out any q's on our Twitter or LinkedIn
Wojciech