Forem: Kevin

Create and deploy your Telegram bot HERE entirely free!

Kevin — Fri, 02 Sep 2022 07:52:39 +0000

In this tutorial, I will be showing you how you can deploy your telegram bot and keep it running 24/7 entirely for free.

For telegram bot development, there are generally 2 methods used: polling and webhooks. Many tutorials out there make use of polling using a NodeJS or Python server, that listens to any messages received by the bot. This means that in order to deploy it, we would need a server running 24/7 that keeps polling for updates. There aren’t many free options available to keep a server running (the most common one would be Heroku, but once the server sleeps, there isn’t a good way to get it up again to continue responding to messages)

Today, we will explore the options of webhooks. Setting a webhook for your telegram bot means that whenever your bot receives a new message, telegram will send that update to your pre-defined webhook endpoint. From our custom endpoint, we are then free to do whatever we want with this knowledge that our bot has received a message, and we can respond to it.

For example, when our bot receives a message from a user, telegram will send a POST request with a payload containing information about that message (the user, message text, time, etc) to our pre-defined endpoint. Our endpoint will receive that POST request with the payload, and with that, we can respond to the user.

But does this mean we will also need a server to accept these POST requests? Yes, but we do not need the server to be running 24/7. Instead, we will use serverless functions. There are many free serverless function options available: Cloudflare Workers, Vercel Serverless functions, etc.

In this tutorial, we will utilise Cloudflare Workers to create a POST endpoint which we will set up as our webhook for our Telegram bot.

1. Creating a new Cloudflare Worker

Navigate to dash.cloudflare.com and login (or sign up)
On the sidebar, click on ‘Workers’
Click on ‘Create a service’ to create your new worker
Enter a name for your new worker and select the ‘HTTP handler’ as the starter, and click on ‘Create service’

Once your service has been created, click on ‘Quick Edit’ to edit your worker directly in the browser

Now, in your editor, you should be seeing the default code for a new Cloudflare worker.

addEventListener("fetch", event => {
  event.respondWith(handleRequest(event.request))
})
async function handleRequest(request) {
  return new Response("Hello world")
}

The logic of how we are going to handle the incoming request will be done in the handleRequest function.

At this point, it is good to know what is the payload that Telegram will be sending to us.

{
  "update_id": 1140,
  "message": {
    "message_id": 73,
    "from": {
      "id": "id of user",
      "is_bot": false,
      "first_name": "name of user",
      "username": "username of user",
      "language_code": "en"
    },
    "chat": {
      "id": id of chat,
      "first_name": "name of user",
      "username": "username of user",
      "type": "private"
    },
    "date": 1662102031,
    "text": "hi"
  }
}

From the payload, we are able to tell who the user is, what is the chat that the user is sending (important for group chats) and what is the message text. As a start, lets make our bot echo the user’s message, but add an ‘over’ at the end of the message.

async function handleRequest(request) {
  if (request.method === "POST") {
    const payload = await request.json() 
    // Getting the POST request JSON payload
    if ('message' in payload) { 
      // Checking if the payload comes from Telegram
      const chatId = payload.message.chat.id
      const text = payload.message.text + " over"
      const url = `https://api.telegram.org/bot${API_KEY}/sendMessage?chat_id=${chatId}&text=${text}`
      const data = await fetch(url).then(resp => resp.json()) 
      // Calling the API endpoint to send a telegram message
    }
  }
  return new Response("OK") // Doesn't really matter
}

In this code snippet, we check if the incoming request is a POST, and whether the payload contains the important information from Telegram. We get the chatId and text from the payload, and we generate a unique URL which we will call GET to, which will send a message via our bot programatically. One thing is still missing, which is the ${API_KEY}. This is where the bot API token will be substituted into, and we can set this value via the Cloudflare Workers settings.

Go back to the your worker’s dashboard by clicking on ‘Save & Deploy’ and then exiting out of the editor.
Under the settings panel, click on variables. Here you can set the environment variable for the worker.

Click on ‘Add variable’ and input the variable name as API_KEY and the value as the bot’s API token and save your settings.

2. Setting webhooks for our bot

Now, with our endpoint ready, all that is left to do is to set the webhook of our bot to our custom endpoint.

With our bot API token, and the URL of our new worker (which should be ending with workers.dev), substitute the values into this URL and simply copy and paste it into your browser and enter

https://api.telegram.org/bot<replace with bot api token>/setWebhook?url=<replace with our worker url>

If you see this as a response, you’re all set!

{"ok":true,"result":true,"description":"Webhook was set"}

Wasn’t that easy?

So now you have set up your telegram bot which is able to run 24/7 entirely for free! You can customise this code to make your bot do anything you want. In a future tutorial, I will be showing you how to use Cloudflare KV to setup a simple database for your bot, to retain user data and enhance the capabilites of your bot! It’s really simple too, so like this tutorial if you want to see more!

Improve Your Team's Productivity with Vercel's Preview Deployments

Kevin — Sun, 27 Mar 2022 17:37:58 +0000

It's no secret that I love using Vercel. Not only does it provide me with free hosting and serverless functions, it also helps me to improve my productivity through CI/CD as a web developer. In this article, I will show you how your team can improve productivity using Vercel's free preview deployments.

What are preview deployments? In short, they are deployments for your branches that aren't your 'main' branch, and they have a unique URL so that you or your code reviewers do not have to switch branches or clone to preview the changes.

For example, you have a project hosted on Vercel with the domain myverycoolproject.vercel.app, and it is linked to your 'main' branch on GitHub. If you have another branch, and made a PR, Vercel automatically detects this, and deploys your changes to a separate URL, perhaps like myverycoolproject-f9n834234.vercel.app. With this preview URL, it allows you to immediately deploy the changes in that PR, without affecting your main deployment. Your team can preview the changes of the PR in a matter of seconds, and review the PR. Once the PR is approved and merged, the main deployment will then be updated with the changes.

To me, this saves a lot of time as I do not have to manually change branches and run the project on my device (or sometimes even clone the project). It makes code reviews a breeze, which improves the reliability and code quality of your project. I feel that this is such an important feature which should be in every CI/CD pipeline for a web development project, so try it out now!

To learn how to integrate Vercel into your projects, check out my other articles here:
Continuous Deployment for NodeJS Projects using Vercel
How to setup Continuous Integration for your NodeJS project

Continuous Deployment for NodeJS Projects using Vercel

Kevin — Fri, 23 Oct 2020 17:49:50 +0000

What is Continuous Deployment?

Continuous Deployment (CD) is a software release process, automating the deployment of code to production. It is an extension of Continuous Integration, where the new changes added into the main branch will be released into production. This process is ideal for teams who want to get their new features or bug fixes out to the public as quickly as possible.

In order to minimise the risk to deploying problematic code, a robust and comprehensive set of automated tests need to be in place. This ensures that new code being merged into the main branch (and subsequently deployed) is deployment ready and bug-free. In doing so, software development teams can automate their workflow processes, and do away with the need of manual deployment. This makes it easy for teams to release their new builds to production, encouraging small and incremental builds, rather than all at once, thus reducing the risk of each deployment.

However, if a team requires approval by higher authority, an alternative would be Continuous Delivery. Continuous Delivery is similar to Continuous Deployment, but without automatically deploying the changes to production. Although the deployment to production is done manually, the Continuous Delivery pipeline ensures that once the authorisation is given to release the build, the build is production ready and can be released at any time.

There are many tools available to facilitate this workflow, like Jenkins, TeamCity and GitLab, but in this tutorial, I will be showing you a free alternative where you can have CD for your web applications and have them hosted in their domain for free.

Why Vercel?

Vercel allows you to:

Host your frontend project in their domain (vercel.app)
Integrate with GitHub to enable CD on your projects
Free!!!

Setting up CD in Vercel

For this tutorial, I will be setting up hosting and CD for a blank Create-React-Application in my GitHub repository.

Once you have linked your GitHub account with Vercel, you will be greeted with the dashboard page.

Click on the 'Import Project' button on the right.

Depending on what you want, you can either import from your Git repository, or use one of their boilerplate template to get your project started. In this tutorial we will be importing from Git. Click on the blue continue button and enter the URL to your Git repository.

Once the project has been imported, you can name your vercel project. This name will be used to host your project <PROJECT NAME>.vercel.app.

There are many framework presets that Vercel provides. It usually automatically detects the type of project that you have imported and recommends the preset according. This preset will set the defaults for the build command and output directory in the 'Build and Output Settings' section, but you can override it depending on your project.

You can also provide any environment variables that the project requires like API keys in the 'Environment Variables' section.

Lastly, if the Git repository that you imported does not have the frontend files in the root directory, you can set the correct directory on the 'Select root directory' at the top of the dialog.

Once you are satisfied with the settings, click on deploy and sit back and relax!

When Vercel has successfully deployed your application, your Git repo is now also configured for Continuous Deployment. Whenever a new PR is made, Vercel will automatically build the application and provide a live build of that version of the application. From these builds, you can test out the features of the new PR, while maintaining the production build in the main link. If you are satisfied, you can merge the PR and Vercel will update the production version of your application with the new changes, and viola! Your new changes have been deployed to production in a click of a button.

There are many CI/CD tools available but Vercel is my favourite. It is so easy to setup, the layout of their website is clean and simple to use, and once you set up your project in Vercel, it does everything by itself and you don't have to worry about deployments anymore!

How to setup Continuous Integration for your NodeJS project

Kevin — Fri, 23 Oct 2020 17:34:44 +0000

Continuous Integration (CI) is a software development practice of merging your code with the main branch frequently. This aims to help developers catch bugs early, and also to prevent a developer's worst nightmare, known as 'merge hell'. Merge hell happens when you are about to merge with the main branch, but you are met with a long list of merge conflicts. Imagine after working for on a feature for months and you're finally done, but now you have to untangle this mess of merge conflicts.

CI aims to help solve this issue by having developers merge their code with the main branch once or multiple times a day. The principle is: if it hurts, do it often, then it will not hurt so much. By merging code multiple times a day, this means that even if there is a merge conflict, it would be a relatively small one, since the changes is only up till the previous day at most. This makes the merge conflict easy to resolve, and developers can easily get on with their day. It also allows developers to catch issues and solve them early.

With developers merging more frequently, sometimes the code being merged could be half written code, or code that have not been tested extensively. That is why another important aspect of CI is the use of automated testing. Automated testing ensures that the code being merged does not contain any bugs or breaking changes that would affect the work of other developers. This ensures that problems are resolved before they are merged into the main branch.

In this tutorial, I will be sharing how you can setup CI for your project by implementing automated testing into your NodeJS project. For more information about writing test cases for NodeJS, I recommend reading the following articles:

How to Unit Test with NodeJS?: https://medium.com/serverlessguru/how-to-unit-test-with-nodejs-76967019ba56
Testing in Node.js Using Mocha and Chai: https://medium.com/better-programming/testing-in-node-js-using-mocha-and-chai-part-1-d5a9e91f4b06

Implementing automated testing in GitHub for your NodeJS project

Pre-requisites:

Your project should be on GitHub
Your project should be able to run tests locally using the 'npm test' command

Go to Travis CI and login with your GitHub account.

Click on the '+' on the left sidebar, next to the 'My Repositories' tab.

Search for the repository you want to use, and click on the toggle button on the right.

Travis is now enabled for your project! Whenever a new push is made, Travis will try to build it. However, Travis doesn't know what exactly to do yet, and we need to tell it what to do by using the '.travis.yml' file.

In the root directory of your project, create a new .travis.yml file and enter this into the file:

language: node_js
node_js:
 - "stable"

Now simply add this .travis.yml file into your github repository, and make a new PR and viola! You should see a yellow dot next to your PR, indicating that a Travis build is running, and a green dot if it passes all test cases, or a red cross if it fails your test cases.