v0.5.0
Home GitHub

Architecture

Last updated

go-bot keeps each chat platform in its own package under core/; the only thing they share is the reply convention.

System overview

flowchart LR
  App[Your application] -->|New / Reply / Start| TG[core/telegram]
  App -->|New / Reply / Start| DC[core/discord]
  App -->|New / Reply / Start| LN[core/line]
  TG -->|long polling, outbound| TGA[Telegram Bot API<br/>go-telegram/bot v1.20.0]
  DC -->|WebSocket gateway + REST, outbound| DGA[Discord API<br/>bwmarrin/discordgo v0.29.0]
  LNA[LINE Messaging API<br/>line-bot-sdk-go v8.18.0] -->|HTTPS webhook, inbound| LN
  LN -->|reply / push| LNA

Layers

Layer Packages Responsibility
Application your code Registers one ReplyHandler per bot, calls Send* methods
Platform adapter core/telegram, core/discord, core/line Transport lifecycle, event dispatch into Input, sending, media download, interactive state
Platform SDK go-telegram/bot, bwmarrin/discordgo, line-bot-sdk-go/v8/linebot Wire protocol; still reachable through Input.Raw
Shared utility github.com/pardnchiu/go-pkg/utils UUIDs for saved filenames and Discord component IDs

Cross-cutting rules

Rule Effect
No shared internal package Each package declares its own Input, ReplyHandler, Status; identifiers differ (int64 chat IDs on Telegram, string snowflakes on Discord, source IDs on LINE)
One handler, synchronous Reply(handler) replaces any previous handler; a non-empty return is sent back automatically
context.Context on every network call Every Send*, Delete, Save, and status call accepts ctx
Close instead of Stop Matches io.Closer; safe to call more than once
Platform-native interactions Telegram uses inline keyboards and ForceReply, Discord uses components and modals, LINE has none
中文