[Feature] Enhancing GlobalPing Integration with Granular Node Control and BYOK

[hybrid-zz]

Intro
First of all, I want to thank the Bluewave team for all the hard work they have dedicated to Checkmate. I have been following the development closely and was eagerly awaiting the implementation of the distributed uptime check feature. It’s finally here, and although I wasn’t aware of GlobalPing, it appears to be fantastic and far better for my use case than updown. This feature request aims to further enhance the GlobalPing integration.

Feature Request
Currently, it is only possible to select the continent from which you want to monitor. However, GlobalPing offers more capabilities with granular control over which specific node to ping. I hope you will consider allowing users to bring their own API key and gain more granular control over the nodes.

My personal use case is to monitor the uptime and performance of a local or regional website from specific nodes in targeted regions.

Contribution
If needed and allowed, I would love the to help implement this based on the current setup. I am familiar with typescript and would likely use AI to assist in understanding the codebase and in making the implementation as aligned as possible with the existing logic.

I'd love to hear what you guys think. Would you consider this, and would you like my help/time with the implementation?

[gorkem-bwl]

Let's go @hybrid-zz - what do you have in your mind? Since globalping is a fantastic product/opportunity, I am all ears. The first version was more about "hey lets build something small, and working and see if it can scale & can be improved". Now it's time.

[hybrid-zz]

@gorkem-bwl quick response, I like it.

To start, we could introduce a field in the settings view to allow users to add/store their own API key, so that Checkmate can utilize that key and the associated credits.

A first step in providing more granular control would be to enable users to select whether they want to monitor based on continent, country, or city. Technically, we could let Checkmate query the free unauthenticated API endpoint to retrieve a list of probes: https://globalping.io/docs/api.globalping.io#get-/v1/probes. I quickly examined the results of this API call, and the fields for continent, country, or city are populated for all probes. Unfortunately, the state/region field is not available everywhere.

Based on the results, we could parse the location list and enable users to search for and select the available continents, countries, or cities. To make this more concrete, we could allow users to select multiple cities, countries, and continents. Ideally, it would also be beneficial to offer a combination of these categories.

The next step would be to allow probe selection based on a combination of information provided in the location results and the tags given.

There are some edge cases to consider:

1. Credits depleted
2. Rate limit reached (I'm unsure how this is currently managed)
3. No available probes anymore in the selected city, country, or continent

This is just a quick idea on how to implement this. I still wrapping my head around the UI/UX part and whether it's even possible to allow specific combinations.

[gorkem-bwl]

One thing I might want to add on top is that users may not know where to get pings, so in the 2nd phase we can add templates (eg. "Add one country from each continent" or "3 countries from each continent") - Not many, just a few so that it's easy for the user to go with a list of handpicked locations easily. We also need to make sure that users can never exceed (or even approach) limits here: https://globalping.io/docs/api.globalping.io#overview

Once we are done here, we might be interested to think about the following:

• One time ping from N (N being much higher) number of countries, just like the example on https://globalping.io/
• Rethink about the globe UI

[hybrid-zz]

Exactly, that’s a good addition as a "nice to have". However, the only limit checkmate should enforce is that a maximum of 500 probes can be selected per target. The 500-per-hour limit isn't a significant concern, for users that will be using their own API keys, which will be based on their credits. This ties back to the edge case I mentioned regarding depleted credits.

I’m not sure if you currently have the capacity to implement this or would you like me to give it a try and tackle it at a best-effort level?

[ajhollid]

Hi @hybrid-zz!

This is a very interesting feature request, however it needs to be approached very thoughtfully.

Allowing an arbitrary selection of probes potentially leads to a massive explosion in data, depending upon how it is implemented.

Can you share a bit more about your experience with large data sets, NodeJs / MongoDB, and development in general?

This is not a trivial feature and not one I would be comfortable letting AI do the heavy lifting on.

If you do want to just get started though, implementing the API key feature as a first step is a reasonable approach!

[hybrid-zz]

@ajhollid Hi, it's getting busy over here! 😄

Totally agree with you on all points. I might be a bit biased and overly excited about getting this feature implemented, lol.

I have a fair amount of web development experience, though not much with large-scale or complex applications. I’m comfortable with JavaScript/TypeScript and NoSQL databases, and while I'm not as experienced with Node.js, I think I could manage.

I believe that your approach of allowing users to bring their own key part would indeed be a good way for me to familiarize myself with the codebase.

This would also give you guys the time to consider how you would like to approach the granular control aspect.

Either way, I’m totally fine if you prefer to handle it completely.

[ajhollid]

Personally I don't have a ton of time to devote to the feature, but if you'd like to tackle it the first step would be a solid proposal and discussion of the data side of things.

Yep the API key is a great place to start to understand the project and get a feel for conventions, I'd definitely start there!

My suggestion would be a implementing the backend so we can verify functionality, then the frontend in a separate PR so it can be evaluated on its own merit. Thanks!