Files
scrabble-game/pkg
Ilia Denisov e9f836db87
Tests · Go / test (push) Successful in 9s
Tests · Integration / integration (push) Successful in 10s
Tests · UI / test (push) Successful in 20s
Tests · Go / test (pull_request) Successful in 8s
Tests · Integration / integration (pull_request) Successful in 11s
Tests · UI / test (pull_request) Successful in 19s
Stage 15: dual Telegram bots & language-gated variants
Service-agnostic refinement of the owner's idea: the sign-in service returns a
set of supported game languages with the user identity, and the lobby gates the
New Game variant choice by it (en -> English; ru -> Russian + Эрудит).

- Connector hosts two bots in one container (one per service language, each its
  own token + game channel; the same telegram_id spans both). ValidateInitData
  tries each token and returns the validating bot's service_language +
  supported_languages. Per-language config (TELEGRAM_BOT_TOKEN_EN/_RU, channels).
- supported_languages rides the Session (fbs, session-scoped, not persisted); the
  UI offers only the matching variants on New Game — gating only the START of a
  new game (auto-match + friend invite), not accept/open/play; backend does not
  enforce.
- service_language persisted (accounts.service_language, migration 00010, written
  every login, last-login-wins) and routes the user-facing Notify push back
  through the right bot (push-target coalesces with preferred_language).
- Admin SendToUser/SendToGameChannel gain an operator-chosen language selector in
  the console (unrelated to ValidateInitData).
- Non-Telegram logins carry the gateway default set
  (GATEWAY_DEFAULT_SUPPORTED_LANGUAGES, all variants).

Wire (committed regen): ValidateInitDataResponse +service_language
+supported_languages; Session +supported_languages; SendToUser/SendToGameChannel
+language. Docs (ARCHITECTURE/FUNCTIONAL/_ru/READMEs) + PLAN updated; stage marked done.
2026-06-05 09:35:53 +02:00
..

pkg

Shared wire contracts for the Scrabble platform (module scrabble/pkg), imported by both backend and gateway. It carries no logic — only the generated message types and the schemas they come from.

Layout

proto/push/v1/    # backend -> gateway live-event gRPC channel (Push.Subscribe)
                  #   committed generated Go (*.pb.go, *_grpc.pb.go)
fbs/scrabble.fbs  # FlatBuffers edge payloads (one `scrabblefb` namespace)
fbs/scrabblefb/   # committed generated Go for the schema
  • proto/push/v1 is the single gRPC server-stream the backend exposes and the gateway subscribes to (Event{user_id, kind, payload, event_id}); the payload is an opaque FlatBuffers body the gateway forwards verbatim.
  • proto/telegram/v1 is the Telegram connector's RPC contract (Stage 9; Stage 11 added ValidateLoginWidget for the web Login Widget sign-in).
  • fbs holds the client↔gateway request/response and event payloads as FlatBuffers tables. The backend encodes the push payloads from these types; the gateway transcodes the rest to and from the backend's JSON; the UI generates TypeScript from the same .fbs (Stage 7).

Generated code

Committed (CI only builds it); regenerate dev-time after editing the schemas:

make -C pkg tools   # go install protoc-gen-go + protoc-gen-go-grpc
make -C pkg gen     # buf generate (proto) + flatc (fbs)

flatc is pinned to 23.5.26 to match the github.com/google/flatbuffers Go runtime in go.mod; generating with another version is refused.

Workspace wiring

scrabble/pkg is a bare-path module (no dot), so — like scrabble-solver — it cannot be fetched as a versioned dependency. go.work carries use ./pkg and replace scrabble/pkg v0.0.0 => ./pkg; consumers require scrabble/pkg v0.0.0.