The first piece of Telescope that lives in the cloud.
There has been one month since the release of Telescope 2.0
In this time, I have been wondering how to solve or at least spend less time fixing problems that frequently happened during the development of the last release.
One of the problems is that we still don’t have Slack integrations. I had been working on this integration in the past. Still, the PRs were not tested or merged before the 2.0 journey started — with all the changes in our project architecture and my decision to design a new user interface, the PRs became incompatible with the project.
So I decided to create a parallel thread to deal with the Slack integration.
Right now, Telescope Watcher can:
- Send messages to a specific channel when one of our servers is down.
- Slack users can trigger actions to check the server's health and receive the live data on Slack. (Slash commands).
- Telescope Watcher also let us know which commit the server is using. We faced this problem more than once when building a new commit, and the build fails, resulting in our stagging server staying behind our master branch.
These features will give us a faster way to respond to this kind of occurrence. Telescope Watcher runs in a test workspace, separated from Telescope's main channel until I finish some details and the tests.
About Telescope Watcher
Telescope Watcher is a Next.js project, it has a front-end where you can check the status of our servers, and the back-end runs a series of continuous checks to ours servers and GitHub. The back-end serves the front-end and Slack.
Telescope Watcher does not live in Telescope machines, it lives in the cloud checking our machines.
Using OOP I was able to store the data from the GitHub repo and our servers in three different objects. All data is parsed into JSON when the app needs to send it to the front-end or Slack.
This approach is a good solution because we don’t need to use a DB to store the data, this is important because we don’t need to worry about more DB accounts and the free tiers constraints.
I’m working on a log engine that may need a DB or not. I’m still considering the options.
My first attempt was to deploy the app in Vercel, but since I’m using a lot of async setIntervals to run the checks, forget Vercel. Your app will start a light sleep that will stop your backend. Vercel is amazing and I will not complain about their services. For this app, they just aren’t the right tool — the place to host it.
I contacted Yuan-Hsi Lee to see what were her thoughts about hosting the app in Microsoft Azure, in the end of the day after a few attempts we figured out that Azure wasn’t the place to host the app too. First, the free tiers do not provide enough resources. And unless you decided to use a VM and set up an entire server and pay for it, the app would have to be 100% refactored to fit into their services. They even have documentation to host Next.js projects there, but just for the front-end and a very basic back-end.
So I hope Azure improve their services.
Amazon AWS ?
AWS Amplify seems to be an option, but since they want my credit card to give me a free tier, the app is still in test, and I don’t want to take the risk of using more resources than the free tier provides. I didn’t go further to check if Amplify would be able to run cron jobs and my periodical checks.
Heroku. I was impressed that I just need to add a simple script (next start -p $PORT) to my app and ok, DONE.
But Heroku sleeps, so I’m using a free service that keeps Heroku alive. During the test period, the app will sleep all days from 00:00 am until 6 am. After the tests, we can use it 24/7.
Telescope Watcher still has an uncertain future because Telescope will be living in the cloud soon too. But until there we have an option to integrate our slack channel, servers and GitHub repo.
I hope to finish the tests in the next week and ship the Telescope Watcher to our main channel.
Thanks for reading.