May 10, 2024
As this month marks the upcoming launch of the entire product, Iâll soon be bidding farewell to the MonitorMe.io team. With that in mind, I figured, why not document the entire experience and journey, detailing each step of my work as a frontend developer?
So, grab yourself a cup of coffee, settle in, and enjoy the read! đ
In early September 2023, my friend Chinmay told me about a opportunity to work at MonitorMe.io and recommended me as a frontend freelancer to join the project. Iâm really thankful to him and Bishakh Gosh â Co-Founder of Pinggy.io as they helped me getting this opportunity.
My journey with the team began on September 15th. On the very first day, the Shuvam and Abhishek walked me through the productâs idea and vision. Understanding this was crucial for me to design UI and experiences that aligned perfectly with their vision. They were incredibly helpful in explaining the product and delving into the nitty-gritty details of the marketâs existing competition.
I quickly learned that in the Uptime Monitoring and Synthetic Monitoring market, UI and UX often take a backseat. Recognizing this, we aimed to prioritize improving the user experience for our MVP. So, throughout the first week, I sketched out basic designs for each frontend route, laying the groundwork for the months to come.
MonitorMe is the platform where business can track their mirco-services, monolith web applications, and host their public status pages.
Our frontend stack is Nextjs and to pace up the process of writing the UI, we choose Mantine UI library â a perfect abstraction of UI components which you need to build B2B or B2C web applications.
While deciding between TypeScript and JavaScript, Abhishek granted me the freedom to make the call, since I would be working on the frontend solo. After thorough research and consideration of the pros and cons of both options, I leaned towards TypeScript for its strong typing system. However, I also weighed the fact that our API endpointsâ responses were not yet fully defined and could change as we progressed with each feature.
Ultimately, I chose JavaScript over TypeScript to avoid type masterbation.
Edited: Reflecting on that decision, I realize there wasnât a clear winner between TypeScript and JavaScript. The only advantage TypeScript would have provided is a well-documented code base for our response data, which could have been beneficial for new developers joining the project.
In the dashboard view, we stumbled upon an opportunity to display live data for each monitor created by the user. There are two possible ways for this implementation
1. using sockets
2. long polling
We settled on long polling for its simplicity and because we werenât certain whether this feature would be a long-term necessity.
At first glance, this feature may seem straightforward â the frontend hits an endpoint to retrieve new data and renders the data again. However, I took it a step further. By predicting the timestamp of the next data point, which we can predict based on monitorâs heartbeat and the last data point received, I optimized our polling strategy. This allowed us to hit the endpoint right after a new data point is being created, enhancing the real-time nature of our data display.
Without delving into socket implementation, I successfully integrated live monitor data, enabling the rendering of each candle, as shown in the image.
Also I made good use of Redux to manage the global state corresponding to this live chart data of each monitor. This setup made frontend development much smoother by keeping the data layer separate from UI components and routes with single source of truth for data.
However, I have to admit, I wasnât a big fan of the boilerplate code required to set up Redux in React using redux-toolkit. Nevertheless, the benefits it brings, like simplifying state management and ensuring consistency across the app, make it all worth it in the end.
Youâve probably seen those branded status pages of companies, displaying the live status of their services â whether theyâre up and running or facing issues, along with a history of past incidents. Since we canât expose our API endpoint publicly so we canât use client-side rendered status pages.
I came up with a solution using Next.jsâs ISR (Incremental Static Regeneration) feature. Itâs pretty cool â it helps us regenerate the page every 15â20 minutes and update the data/prop right on the server itself. This way, our status pages stay fresh without exposing any sensitive endpoints. Plus, as our status pages are static, we donât need to make round trips to the database to render the page. This would have been the case if we have chosen the client side rendered page with exposing the endpoint publicly accessible.
As you can see in the GIF above, weâve incorporated a live chart to display the candles and monitor latency. I opted for ApexChart due to its extensive customization options. Initially, I implemented this feature by referring to the documentation. However, a problem arose: every time a new data point was polled from the backend, the entire graph would rerender (each and every point). This was caused due to I had passed the global state as prop to the LiveChart component, since this state is getting mutate by long-polling mechanism and in actionâs fulfilled callback, I had used shift
operation on array of this live chart data. Since this operation causes array to remove the first index datapoint but with the cost of reindexing all other elements in the array. Due to this rendering of all points was happening in apex chart.
I solved this issue by managing a new local state within the LiveChart component itself. I updated this state by appending new data points and adjusted the view of the graph using the min
and max
range in the xaxis
option provided by ApexChart. This way, whenever a new data point was polled, it was simply added to our local array, and the view was adjusted to display only the last 48 points.
SpCandle
, they suggested using StatusPageCandle
for clarity. This ensures that even new developers can easily understand the code without needing to decipher abbreviations and contextWe built a really great product in the last few months and Iâm really proud of the work and frontend code that I wrote for MonitorMe.io
MonitorMe is great project by Shuvam and Abhishek and both are really passionate to solve the monitoring and testing problem. Despite they are building this project alongside with their daily job, I never felt difference in their energy while in the daily sync up meet. Someday, I aspire to be a developer as dedicated and passionate as them! đ
Thank you đ for reading until now, I hope you enjoyed it.
If you want to connect with me go ahead and hop into my DMs.