undrcrxwn / radzinsky

That one single Telegram bot to replace all the others

Bio

Hi! My name is Danil. I'm an 19yo .NET backend developer from Rostov-on-Don, Russia who is curious about software engineering, architecture and system design. Have been studying for my bachelor's degree in computer science at the Don State Technical University since 2022. Dramatically unemployed.

Pets

🥇 Crowd Parlay — a C2C bet aggregation platform on microservices

• languages: C# TypeScript SQL Cypher HTML SCSS
• technologies: 🦄 RabbitMQ MassTransit SignalR gRPC Redis .NET 8 ASP.NET Core React Postgres Neo4j OpenAPI OAuth 2.0 OpenID Connect Docker Kubernetes Istio GitHub Actions
• architecture: Microservices Event-driven Service mesh
• workflow: >5 contributors GitLab CI/CD Kanban Conventional commits Miro

🥈 Hide This Bot — an inline Telegram bot ever used by >10k people worldwide

• languages: Python
• technologies: Aiogram PeeWee

🥉 Radzinsky — a Telegram bot primarily used for chat-management and entertainment

• languages: C#
• technologies: .NET 8 ASP.NET Core EF Core Hangfire Mapster Docker Telegram.Bots

Contacts

• Telegram

radzinsky's Issues

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.

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.

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);

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.

Application and domain layers lack of DTO vs Entity segregation