[не3доровые_асс0циацыи]

Наш бэкенд классный.
Придумать менять id/primary_key сущности после любой операции обновления - это надо еще постараться. Причем как сама операция правки сущности реализована - отдельная песня. Мы не будем просто менять старые поля, заполняя их новыми значениями. Нет, мы создадим новый элемент, скопируем в него поля из старого, затем обновим актуальными значениями, а старый элемент удалим.

Благо, что и до этого момента я вовсю пользовался временными id(которые сам и генерил на клиенте) для склеивания нескольких мутаций GQL в один запрос (там нужно обеспечить уникальность каждой уезжающей пачки исходных данных, как в этом примере). Так вот, теперь эти временные id пригодились для опознания телрезультатов обращений к бэку.

@темы: горбота, кодерастия

Comments

[Хысь]

То есть эти странные шутки про бэкенд имеют под собой какое-то рациональное зерно?

[не3доровые_асс0циацыи]

2Хысь, Феерически облажаться можно и на клиенте, просто большинство косяков фронтенда становятся заметными сразу же, а косяки бэка, когда он вроде бы и ответил тебе, но немного в неожиданной форме - только спустя некоторое время.

Еще - фактор цепной реакции, когда "немного неточный" ответ запускает правильное, но неуместное поведение на клиенте с последующими raspeedorasilo-class эффектами.

Если ошиблись годно, со знанием дела, то придется долго и болезненно осознавать, прежде чем станет ясно, что ошибка является наведенной.

При должном везении можно даже найти пару спящих багулин или неожиданный путь для оптимизации

[Хысь]

В коде 32 бага, в коде 32 бага, мы пофиксили 4, и теперь... в коде 78 багов, в коде 78 багов.
Простите

[не3доровые_асс0циацыи]

2Хысь, Это - база! Так что ничуть не обидно