Clideo GraphQL

Привет, не успел довести до ума все что хотел прежде чем тебя подключать, все как снежный ком.

Я пока не хочу комитить все наработки, т.к. все еще в сыром виде, и мне легче ориентироваться с нормальным гит статусом. Пока что прикрепляю 2 архива - для бека и фронта. Это просто для ознакомления, завтра созвонимся и решим, будем ли тебя подключать (там вся работа ровным слоем по проекту размазана, не уверен что вдвоем будет удобно) и как именно организовать работу.

Если не работал с графом, пара слов куда смотреть.

По беку - основной функционал весь в ./app/GraphQL и в ./graphql. Ветка основана на свежем релизе, так что старого бека там нет совсем.

./graphql - тут лежит схема графа в SDL формате. Все модели, поля, мутации (все с чем можно будет работать с клиента) объявляются тут. Затем они с помощью @директив мапятся на конкретные реализации в ./app/GraphQL

По клиенту - даже не знаю с чего начать. Это боль.

По первых, у нас теперь есть кодогенерация (см. codegen.yml) типов для API (npm run codegen). Эта команда запросит свежую версию схемы с бека, и скомпилит ее в schema.graphql (для подсказок IDE). Далее возьмет все запросы которые может отправлять клиент (см. graphql-client-service/graphql), наложит на схему и сгенерирует все нужные типы для работы с API - скаляры, типы, мутации, типизированные "документы" (тело запроса), типы для входные-выходных данных и тд.

На текущий момент я написал 90% мапперов для типов бека на типы фронта (в основном енумы). Начал переписывать бекенд-апи-сервис, сейчас на этапе загрузки файлов.

Какие сейчас есть проблемы:

Основное что генерирует больше всего правок - у нас теперь нормализованная структура базы, и у всех треков/трек-элементов есть id и она number а не string. Я посмотрю куда это приведет по ходу дела, но пока вижу что от этого больше вреда чем пользы, возможно сделаю генерацию uuid-like id на основе чисельного id на беке, чтобы избежать переделки большей части клиента, где все завернуто в string.
На беке не хватает пары простых мутаций для обновления track element options и возможно парочки связанных сущностей.
Я не довел до ума реализацию подписок на беке (это graphql поверх websocket, для частичных и realtime обновлений от сервера к клиенту). Оно нам надо для экспорта. Как и саму мутацию экспорта. Я это пока выпилил, потому что без рабочего клиента невозможно провестить, и это создает больше проблем.
Граф плохо умеет в загрузку файлов, и пока нет возможности подписаться на upload progress. Но нам повезло, что Саша переделал дизайн, и теперь все файлы грузятся без указания прогресса загрузки в цифрах (просто индикация что он загружается).
В графе все данные типизированны, и теперь у нас нет возможности пулять туда что нам вздумается, плюс работать с вложенными данными достаточно накладно, так что video/image/audio/text options были немного унифицированы и упрощены. Плюс разнес video и image options на разные типы, т.к. на беке и по наполнению они разные.

И что осталось сделать (на вскидку):

Доделать backend-api-service и все связанные интеракторы. Из головы не могу декомпозировать какие правки потребуются для этого, можем завтра обсудить.
Доделать переход от string к number IDs, либо придумать как симулировать string IDs на сервере, чтобы уйти от этой проблемы совсем. NanoIds/HashIds может?
Доделать мутацию для экспорта и реализацию подписок (websockets) и парочку простых мутаций.