Telebot Template

$ git clone https://github.com/massbots/template .
$ chmod +x init.sh; ./init.sh
NOTE The script will delete itself after the configuration.

Project name: ssvideo
Module path: go.massbots.xyz/ssvideo

Dialect (sqlite3|mysql|postgres): postgres
Driver (github.com/lib/pq):

Overview

A basic telebot.v3 template is used for most of our bots. There are two ways of organizing the root, and this one sticks with this project structure. We prefer to use a simpler layout for simpler apps, without separating on pkg and internal directories, keeping every package in the root. But, in the huge projects, where we may have lots of packages as has to be hidden, as exposed, the separation becomes really useful and much more convenient.

So, this is a good example of structuring your advanced bot, when there is too much code for an ordinary main.go file.

Directories

/

The root package, with the name of the module, usually should contain highly generic information. We store the Bootstrap structure here, which defines the basic dependencies required for a successful application performing. It’s later used in /internal subpackages for proper initializing.

/locales

This directory consists of bot locales in *.yml files respectively to the telebot/layout format. If you don’t need localization in your project, leave a single file and specify its locale code in lt.DefaultLocale("..") call.

/sql

Optional, if you don’t use a relational database. It’s a directory of *.sql files, formatted in a way to use with goose migration tool.

/cmd

Main binaries for the project. The directory name for each application should match the name of the executable you want to have. We use /cmd/bot for the bot’s primary executable. It’s common to have a small main function that imports and invokes the code from the /internal and /pkg directories and nothing else.

/pkg

Library code that’s ok to use by external applications. It’s ok not to use it if your app project is really small and where an extra level of nesting doesn’t add much value.

/internal

Private application and library code. This is the code you don’t want others importing into their applications or libraries. Note that this layout pattern is enforced by the Go compiler itself.

/internal/bot

Obviously, the core of the bot. Imports root’s Bootstrap to initialize itself. It has all the handlers and bot behavior, logically grouped by the files. We also store custom middlewares here in bot/middle subpackage.

For example, imagine your bot has some settings that open as an inline menu on settings command. There are several parameters to be configured, let’s say the user’s name and delivery address. Where you should put this logic? The best place is settings.go file in the bot package with three functions inside, which are responsible for sending settings menu, asking for a new value to update, and actual updating operation of the specific setting. That way we have three ascending actions relying on each other, and it makes them intuitive by gathering in one place.

/internal/database

A wrapper to simplify the communication with your database. If you’re ok with using ORM in your projects, then most likely there is no need for you in this package.

/internal/thread

This becomes useful when you have some background routine to do. One file for each thread logic accordingly. Of course, it’s not about OS threads, just a short representative name for the package that holds background logic.

boot := Bootstrap{...}

go thread.ProcessPayments(boot)
go thread.CollectStatistics(boot)

b.Start()

GitHub

https://github.com/massbots/template