undrcrxwn / radzinsky

That one single Telegram bot to replace all the others

  Radzinsky

That one single Telegram bot to replace all the others.

Solution structure

• Radzinsy.Host — ASP.NET Core web application that hosts a Telegram webhook or performs long polling.
• Radzinsy.Endpoints — crystal clean business logic; endpoint here basically means a use case.
• Radzinsy.Framework — boilerplate that makes business logic look crystal clean.
• Radzinsy.Persistence — database contexts, entities, migration, and all that.

Flow

1. The Framework's discovery services scan the Endpoints assembly, collecting IEndpoint implementations with specific attributes.
2. Telegram update comes from Telegram through the Host's WebhookController or in response to a long polling request.
3. It reaches the Framework's UpdateHandler and then gets challenged by the Framework's routers.
4. Each router tries to classify the update using its discovery service and then form a Route based on it.
5. When a matching endpoint is finally found, it gets called. If there is no such endpoint, the update is ignored.
6. Endpoint implementation handles the update in a separate DI scope, given both the Update and the Route.
7. If needed, route type is specified (for example, into RegExRoute) and routing details (such as command's alias and parameters) are obtained.

When running locally

• Be humble and prefer dotnet run over Docker Compose to save time.
• Prefer using long polling over webhook. Otherwise, suffer with ngrok or localtunnel.
• If using ngrok, consider signing in via auth token to get unlimited lifetime for your tunnel.
• To use long polling, just leave the Telegram:WebhookHost configuration null.
• Use .NET user secrets to keep your configuration safe and JSON.
• Give this repo a star.

When deploying to production

• Don't use ngrok or localtunnel. Get a VPS.
• If using ngrok, consider signing in via auth token to get unlimited lifetime for your tunnel.
• Copy .env.example into .env (which is Git-ignored already), then modify the latter. Now run Docker Compose.
• Prefer webhook over long polling by setting TELEGRAM__WEBHOOKHOST.
• Give this repo a star.

Configuration

Using double underscores in the environment variable names makes it possible to use both JSON configuration providers (for example, appsettings.Production.json or .NET user secrets) and environment variables seamlessly. What makes it work this way is Microsoft.Extensions.Configuration, that treats TELEGRAM__TOKEN and Telegram:Token as equivalent keys.

• Telegram:Token — Telegram Bot API token, issued at BotFather.
• Telegram:WebhookHost — null if you want to use long polling, otherwise the hostname of your webhook server; the final webhook URL is built by the following template: {Telegram:WebhookHost}/bot/{Telegram:Token}.
• Google:Token — API key of your Google CSE, see the tutorial.
• Google:Cx — Programmable Search Engine ID, get one from the control panel.

If using .env, see .env.example.

Useful links

• Radzinsky — its majesty.
• Степной ишак — the one writing all this.

radzinsky's Issues

Redundant using of another one method

It's quite hard to understand why did you again using method here:

radzinsky/src/Radzinsky.Application/Extensions/ServiceCollectionExtensions.cs

Line 116 in e41d7a0

? new CommandResources(ParseJObjectFromRelativeLocation(path))

if you already assigned value in variable (through this method) here:

radzinsky/src/Radzinsky.Application/Extensions/ServiceCollectionExtensions.cs

Line 114 in e41d7a0

var data = ParseJObjectFromRelativeLocation(path);

Application and domain layers lack of DTO vs Entity segregation

Redesign resources injection

1. Concrete resources should derive from common resources.
2. Resource loading (which is an I/O sort of work) shouldn't be performed in DI extensions logic, thus needs separation.

Radzinsky's boilerplate should become a separate NuGet package

At the moment, Radzinsky's implementation cobines both in one business logic and infrastructure concerns which seems to become a real issue when it comes to scaling. The boilerplate implementation that also includes such patterns as behavior pipeline and update contexts should be separated from the bot as such and most likely be published as a complete framework wrapper over the Telegram.Bot library.

Ambiguous using of injecting DbContext

Here:

radzinsky/src/Radzinsky.Application/Services/UpdateHandler.cs

Line 74 in a1c4481

var dbContext = scope.ServiceProvider.GetRequiredService<ApplicationDbContext>();

you're just get dbcontext from scope.

But here:

radzinsky/src/Radzinsky.Application/Commands/BioCommand.cs

Line 10 in a14cdf8

private readonly ApplicationDbContext _dbContext;

you're getting dbcontext from di.

In my opinion, you should use only one method to get necessary service.

Early return 200 OK to prevent request duplication for long-running operations

Problem

If it takes too long before the response is sent back to Telegram, it will resend the webhook request causing multiple handling of the same update. This may be experienced in long-running operations and while debugging (e.g. pausing the one thread that is handling a request).

Possible solution

First return 200 OK status code right from the webhook controller and then handle the Telegram update in a separate thread.