Прив’язки до серверу — що ламається при переносі в клієнт
#draft — аналіз залежностей, зіставлений з кодом (агент-аудит chathouse / prime / golden). Рішення ще не прийняте. Фідить питання переносу воркспейсу в Electron з Unification.
Суть
Воркспейс на сервері (Chathouse / Prime) — це сплетіння логік, прив’язаних до серверу. Не одна річ, а мережа:
- Сесія до партнерського API — з неї сервер робить усі per-TU запити (REST / gRPC).
- Партнерський сокет — сервер парсить його події (нове повідомлення, блок, ліміти) → створення тасків, реалтайм в UI.
- In-memory стан ранерів — presence, координація власності TU, атрибуція
auth_code.
Ключове: ці шматки заплетені між собою. Логін — лише вхід у сесію; але на тій самій сесії висять запити тасків, сендери, історія, пінг онлайну, а парсинг сокета годує таск-фабрику. Тому перенести один шматок у клієнт окремо = зламати серверну логіку, що на ньому висить. Це не «міграція логіну», а розплітання всього вузла.
Тримати сесію й сокет у клієнті саме по собі — доведено Golden (там усе партнерське на клієнті, сервер per-TU-викликів не робить). Складність не тут, а в тому, скільки серверної логіки треба перенести разом, щоб нічого не осиротіло.
Де зараз живе сесія
| Проект | Де сесія | Хто ходить у партнерське API per-TU | Реавтентифікація |
|---|---|---|---|
| Golden (еталон) | у клієнті (кука вкладки + окрема REST-сесія) | клієнт | клієнт |
| Chathouse | сервер: Redis token::<ladyId>::operator | сервер (~244 виклики initiatorId у 45 файлах) | сервер сам перелогінюється з креденшелів у LadyModel |
| Prime | сервер: Redis cookie::<ladyId> (tld-token) | сервер (REST + gRPC + WS) | сервер сам re-login на 401 |
Висновок: справжній масштаб — не «перенести логін», а перенести в клієнт усі per-TU виклики до сайту (як у Golden). Логін — лише вхід у цю сесію.
Що зламається (якщо прибрати серверну прив’язку поштучно)
Спільне для Chathouse і Prime:
- Сервер втрачає токен / сесію → усі per-TU REST/gRPC-виклики падають по 401. Авто-релогін теж падає — він і був серверним логіном.
- Реалтайм-таски зникають разом із партнерським сокетом — це єдиний не-polling тригер створення тасків (
MessageSent/Blocked/chat_DialogCreatedу Prime;ApiWs.publicationу Chathouse). - Polling-воркери (60 / 120 / 600с) крутяться, але нічого не роблять — немає сесії для запитів. Наслідок: тасків нема, сендери мовчать, історія / фаворити / онлайн-кеш порожні.
- Втрачаються побічні ефекти логіну: Chathouse — лог балансу на вході, роздача
auth_code, витіснення дубль-оператора; Prime — гард «один оператор на TU». - Пінг «тримати TU онлайн» лишається без тригер-сету — сервер більше не знає, які TU підключені (пінг іде адмін-кредами, але список TU — з ранерів).
- Presence / дашборди / supervisor-в’ю порожніють — вони читають in-memory стан ранерів.
- Chathouse-специфіка: атрибуція
auth_code— статистика мапиться на оператора черезauth_codeлогіну. Клієнт мусить логінитись виданим серверомauth_code, інакше атрибуція ламається (сама аналітика — ні). - Координація власності TU (один оператор на TU) — за природою центральна, лишається на сервері (Golden тримає це в
ElectronConnectionService).
Два шляхи
| A. Реле сесії (низька інвазивність) | B. Повністю клієнт (модель Golden) | |
|---|---|---|
| Логін | у клієнті | у клієнті |
| Сесія | клієнт віддає токен назад на сервер → серверні виклики працюють без змін | лишається тільки в клієнті |
| Per-TU виклики до API | лишаються на сервері | усі переїжджають у клієнт |
| Обсяг рефактору | малий (не чіпаємо сотні call-site) | великий (переносимо всю партнерську логіку) |
| Ціль-архітектура | проміжна, сервер ще залежить від клієнтської сесії | чиста, збігається з Golden |
Обидва аудити (chathouse, prime) незалежно збіглися: A — найдешевший крок, B — справжня ціль. Робочий напрям: A як міграційний місток → B як кінцевий стан.
Нові канали клієнт → сервер (потрібні в обох варіантах)
Golden уже має всі ці канали — це і є готовий контракт:
- Хендофф сесії / токена (варіант A) або делегування всіх викликів у клієнт (варіант B).
- Інжест сокет-подій (клієнт → сервер) — заміна партнерського WS; найважливіший новий потік (тримає створення тасків).
- Лайфсайкл логіну TU (клієнт → сервер): «TU залогінена (
auth_code, ulid) / вилогінена» — щоб спрацювали лог балансу, presence, пінг, реконект, атрибуція. - Хартбіт «TU ще онлайн» — або перенос пінга повністю в клієнт.
- Снапшоти діалогів / лімітів / тасків — якщо фетч переїжджає в клієнт.
Golden-контракт як шаблон: pull конфіг / контент + durable source-of-truth; push результатів батчем (syncData 60с, ID-ack + delete-on-confirm); один контрол-сокет на оператора для координації власності TU й стріму супервізору.
Відкриті рішення
- A чи B як цільовий стан (місток → ціль).
auth_code(Chathouse) — підтвердити: серверна роздача лишається, клієнт логіниться виданим кодом.- Тримання TU онлайн — пінг лишається серверним (адмін-креди + інжест-список TU) чи переїжджає в клієнт?
Зв’язки
- Unification · Current State
- Family Blueprint — контракт клієнт↔сервер як частина плану нового Family-беку.