Расскажи про самую сложную техническую задачу за последний месяц

А, слушай, вот это была задачка, я тебе скажу! Месяц, блядь, с этой фоновой синхронизацией в офлайн-приложении провозился. Чуть с ума не сошёл, ёпта. Представь: юзеры там что-то тыкают без интернета, а потом, когда связь появляется, всё это добро должно на сервер улететь, да ещё и не переругаться, если там уже что-то поменяли.

В чём, собственно, была засада: Ну, типа, люди создают и правят записи в офлайне. Потом интернет появился — всё надо синхронизировать. А если за это время ту же запись и на сервере изменили, и у нас локально — это пиздец, конфликт. Надо его как-то по-умному разрешить, а не просто "ой, всё".

Технический ад, в который я попал:

1. Фоновые задачи, ёб твою мать. Нужно было, чтобы синхронизация сама запускалась, даже когда приложение закрыто. Взял workmanager — он в нативном фоне шуршит. Но настроить его, чтобы не жрал батарею как не в себя и работал стабильно — это отдельная песня, волнение ебать.
2. Очередь операций, которую нельзя потерять. Ну ясно, что всё надо куда-то писать надёжно. sqflite показался тяжеловатым для такой мелочёвки, поэтому взял Isar — легковесный, быстрый. Каждое действие — создать, обновить, удалить — ложил в базу как отдельную операцию с кучей полей: что меняли, когда и какой статус.

   @Collection()
   class SyncOperation {
     Id id = Isar.autoIncrement;
     late String entityId;
     late OperationType type; // enum
     late String localDataJson;
     late DateTime timestamp;
     late SyncStatus status;
   }

   Главное — ничего не проёбывать, а то пользователь полчаса что-то вбивал, а потом — хуй с горы, всё пропало. Доверия ебать ноль будет.

3. Алгоритм разрешения конфликтов — вот где мозг сломал. Просто взять последнее изменение по времени — мало. Для некоторых полей, типа статуса заказа, нужны были свои, ебать, бизнес-правила. Писал эту логику на Dart, сидел, думал, э бошка думай. Получилась функция, которая сначала смотрит, кто новее, а потом уже лезет в конкретные поля и решает по хитрым условиям.

   DataEntity resolveConflict(DataEntity serverData, DataEntity localData) {
     // Базовое правило: берем более новую версию
     if (serverData.updatedAt.isAfter(localData.updatedAt)) {
       return serverData;
     } else {
       return localData;
     }
     // + специальная логика для определенных полей
   }

   Чувствовал себя богом, который решает, чьи правды правдивее. Подозрение ебать чувствую, что где-то косяк зарыт.

4. Консистентность интерфейса — отдельный пиздец. Пользователь должен сразу видеть свои офлайн-изменения, но при этом понимать, что они ещё не на сервере. Использовал Riverpod, сделал провайдер-монстра, который скрещивал данные из локальной БД и кеша с сервера. Чтобы всё гладко было, без дерганий. Терпения ноль ебать, пока отлаживал.

Итог: Вроде победил. Сделал механизм, который овердохуища операций переваривает, юзер в офлайне работает спокойно, а всё что нужно — тихо синхронизируется. И логи, бля, на каждый чих, чтобы если что — сразу понять, где собака, сука, зарылась. Выдохнул только тогда.