Чому інтеграція AppSync у мобільний застосунок ламається на реальних навантаженнях
Інтеграція AppSync у мобільний застосунок майже завжди проходить гладко на стенді й починає сипатися в полі.
Причина не в самому сервісі, а в тому, що мобільний клієнт живе в умовах, яких немає в серверного коду: мережа зникає посеред запиту, застосунок згортають у фон, пристрій змінює Wi-Fi на стільникову мережу.
Синхронізація даних у мобільному застосунку — це не один запит, а постійний обмін між локальним кешем, чергою невідправлених змін і сервером.
Перший типовий збій — розсинхронізація локального кешу. Клієнт записав зміну офлайн, відправив її пізніше, а сервер на цей момент уже отримав правку з іншого пристрою.
Без версіонування записів і стратегії розв'язання конфліктів остання відповідь мовчки затирає свіжіші дані, і користувач бачить застарілий стан.
Офлайн-режим мобільного застосунку тримається не на «збереженні в базу», а на строгому порядку застосування мутацій і явному правилі, чия версія запису перемагає.
Другий — дублі підписок у реальному часі. Екран перестворюється при повороті або поверненні з фону, щоразу відкриваючи нове з'єднання, і старі не закриваються. Клієнт отримує ту саму подію двічі-тричі, лічильники подвоюються, а канал тримає зайві сокети й палить батарею.
Лікується прив'язкою підписки до життєвого циклу екрана й єдиною точкою підписки на рівні сховища, а не на рівні окремого віджета.
Третій — деградація при перемиканні мережі. З'єднання рветься, клієнт іде в реконект із наростаючою паузою, і без коректної обробки розриву губляться події, що прийшли в момент переходу. Користувач бачить «застиглий» список, хоча на сервері дані вже оновилися.
Усі три збої проявляються не одразу, а під реальним навантаженням і на слабкій мережі — тому далі розбираємо, як це закривається на рівні архітектури клієнта.
Що дає коректна інтеграція AppSync: режими синхронізації та їхній ефект
Режими синхронізації: що змінюється в цифрах
Режим реального часу тримає відкритий канал до сервісу: зміна на сервері доходить до пристрою за частки секунди, а зворотний запис іде одразу. Це те, що потрібно чатам, трекінгу замовлень і спільним спискам — затримка оновлення даних перестає бути помітною на око.
Ціна — постійне з'єднання й акуратна обробка обривів: без повторної підписки після втрати мережі інтерфейс тихо «замерзає» і показує застарілі дані.
Періодична синхронізація опитує сервер за розкладом і обходиться дешевше за ресурсами, але дає вікно розсинхрону — на повільних каналах воно зростає.
Офлайн-черга змін закриває третій сценарій: правки накопичуються локально й ідуть пакетом при появі мережі, тому застосунок залишається робочим у метро й на складі.
Ключове питання тут — розв'язання конфліктів: стратегія «перемагає останній запис» проста, але втрачає чужі правки, а версійне злиття за полями зберігає обидві сторони.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Реальний час | чати, статуси, спільна робота | потребує стабільної мережі, складніший відкат |
| Періодичне опитування | каталоги, звіти, рідкісні оновлення | вікно розсинхрону зростає з інтервалом |
| Офлайн-черга + злиття | поля, склади, виїзні співробітники | потрібна явна стратегія конфліктів |
На практиці режими комбінують: довідники тягнуться опитуванням, критичні сутності — потоком, а запис завжди йде через чергу з версіонуванням. Такий розклад знімає цілий клас відмов — загублені правки при одночасному редагуванні та «залиплі» екрани після обриву зв'язку.
Ми налаштовуємо це на AWS AppSync, де підписки, офлайн-сховище й правила злиття описуються декларативно.
AWS AppSync
Етапи впровадження: від аудиту схеми даних до передачі документації
Впровадження синхронізації починається не з коду, а з аудиту схеми даних: які типи та поля вже є, як влаштовані зв'язки, де клієнти пишуть безпосередньо в базу, а де читають застарілі зрізи.
На цьому кроці ми фіксуємо карту запитів і підписок, щоб нові операції не дублювали наявні та не тягнули зайві дані на мобільний пристрій.
- Аудит схеми даних і поточних потоків. Звіряємо моделі, права доступу за операціями, розбираємо, які екрани застосунку читають і пишуть які сутності. На виході — список конфліктів і місць, де синхронізація зламає наявну логіку.
- Проєктування цільової схеми. Визначаємо типи, ключі розбиття та сортування, стратегію розв'язання конфліктів при одночасному редагуванні з кількох пристроїв, правила авторизації за власником запису.
- Налаштування синхронізації та офлайн-режиму. Підключаємо локальне сховище на пристрої, налаштовуємо черги відкладених змін і повторне надсилання після відновлення зв'язку, щоб застосунок працював без мережі та не втрачав правки.
- Навантажувальна перевірка мобільного застосунку. Прогоняємо сценарії з великою кількістю одночасних підписок, частими перемиканнями мережі та масовими правками. Дивимося, як поводяться час відгуку, обсяг даних, що передаються, і витрата батареї.
- Оптимізація за результатами замірів. Прибираємо надлишкові поля з відповідей, розбиваємо важкі запити, обмежуємо частоту оновлень там, де інтерфейсу достатньо періодичного опитування.
- Передача документації. Віддаємо опис схеми, правила доступу, сценарії синхронізації та офлайн-поведінки, інструкції з розгортання середовищ і чекліст для команди замовника.
Такий порядок знижує ризик, що синхронізацію доведеться переробляти після перших скарг користувачів на розбіжність даних. Опишіть задачу — повернемося з оцінкою та планом за кожним етапом.
Чим відрізняється офлайн-режим із локальною базою від прямої роботи із сервером?
Пряма робота із сервером означає, що кожен екран застосунку чекає на відповідь мережі. Поки з'єднання є, це виглядає просто: запит пішов, дані прийшли, інтерфейс оновився.
Але щойно зв'язок зник — метро, підвал, роумінг, перевантажена вежа — запити починають висіти, екрани показують порожнечу, а користувач або чекає, або йде. Інтеграція AppSync у мобільний застосунок якраз будується навколо того, щоб цей розрив не був видимий людині.
Офлайн-режим із локальною базою даних перевертає схему: застосунок пише й читає зі сховища на пристрої, а мережа стає фоновим синхронізатором. Користувач працює миттєво, незалежно від якості зв'язку, а зміни йдуть на сервер, коли канал з'явився.
Ціна — шар синхронізації, який потрібно спроєктувати: черга операцій, повторні спроби, порядок застосування.
Розв'язання конфліктів даних — головне, де ці два підходи розходяться за складністю. За прямих запитів до сервера конфлікту майже немає: сервер — єдине джерело правди, останній запис перемагає.
В офлайн-режимі два пристрої могли правити один запис, поки були без мережі, і під час синхронізації потрібно вирішити, чия версія правильна: за часом зміни, за версією запису або через злиття полів.
За обсягом трафіку різниця теж відчутна. Пряма модель тягне дані щоразу, коли відкривається екран — за слабкого каналу це помітно і за швидкістю, і за витратами. Локальна база віддає дані зі сховища, а мережею йдуть лише зміни — дельта-синхронізація замість повної вибірки.
Вибір не бінарний: зазвичай беруть локальну базу для користувацьких даних і прямі запити для того, що зобов'язане бути свіжим — статуси, оплата, права доступу.
Кейс: як ми усунули розсинхронізацію даних у застосунку з тисячами активних користувачів
Клієнт — сервіс доставки із сотнями кур'єрів у зміні та десятками тисяч активних користувачів. Застосунок працював на REST-запитах: статус замовлення підтягувався опитуванням раз на кілька секунд, а зміни з різних пристроїв одного акаунта перетирали одна одну.
На пікових навантаженнях частка конфліктів сягала 18% від усіх змін статусу, а після втрати мережі клієнт показував застарілі дані до ручного перезапуску — відновлення займало хвилини й вимагало дій користувача.
Що переробили в шарі синхронізації
Ми перенесли обмін даними на керований GraphQL-шар із підписками: клієнт більше не опитує сервер, а отримує зміни по каналу.
Кожна мутація проходить через резолвер із перевіркою версії запису — якщо пристрій надсилає дані на основі застарілого стану, сервер відхиляє операцію й повертає актуальну версію, а клієнт застосовує її без участі користувача. Це прибрало клас відмов «останній, хто записав, перемагає», через який губилися правки.
Метрики до і після
| Метрика | До | Після |
|---|---|---|
| Частка конфліктів змін | до 18% | нижче 1% |
| Відновлення після втрати мережі | хвилини, вручну | секунди, автоматично |
| Клас відмов «втрата правок» | регулярний | усунено |
| Навантаження на сервер від опитувань | постійне | лише фактичні зміни |
Окремо налаштували офлайн-чергу: операції, зроблені без мережі, зберігаються локально й застосовуються під час відновлення з'єднання з перевіркою версії. Це закрило сценарій, коли кур'єр вносив статус у підвалі й втрачав його.
AWS AppSync дав керований шар підписок і резолверів без власної інфраструктури реального часу — команда не витрачала час на підтримку серверів з'єднань.
Після переробки частка конфліктів упала більш ніж у двадцять разів, відновлення після втрати мережі перестало вимагати дій користувача, а навантаження від постійних опитувань змінилося потоком лише фактичних змін. Опишіть своє завдання — повернемося з оцінкою та планом робіт.
Технічні сумніви перед стартом: сумісність, міграція, відкат, доступи
Перед стартом інтеграції AppSync замовники найчастіше ставлять одне й те саме запитання: що буде з уже працюючим застосунком та його даними.
Відповідаємо предметно — інтеграція AppSync не вимагає переписувати клієнт повністю: наявні REST-виклики та локальний кеш продовжують працювати паралельно, а GraphQL-шар підключається зверху, у міру готовності екранів.
Міграція даних іде за схемою «подвійний запис → звірка → перемикання читання», тому на кожному кроці є точка повернення.
Що якщо після перемикання виявиться розбіжність у даних?
Відкат змін закладено в саму схему: читання повертається на попереднє джерело однією правкою конфігурації, без релізу застосунку. Подвійний запис при цьому зберігається, тому розбіжність закривається повторною звіркою, а не ручним відновленням.
Доступи та ролі описані окремими політиками — у кожного середовища свій набір прав, прод ізольований від тестових контурів.
Що якщо в команді немає досвіду з AppSync? Передаємо документацію щодо інтеграції: схему типів, приклади запитів і мутацій, розбір авторизації за ролями. Інженери замовника долучаються до роботи на етапі налаштування резолверів, а не після здачі.
Що якщо потрібно змінити провайдера авторизації? Шар доступу винесено окремо від бізнес-логіки — зміна провайдера зачіпає конфігурацію, а не код екранів.
На руки після здачі замовник отримує:
- схему даних і опис типів із прикладами запитів;
- конфігурації середовищ із розподілом прав доступу та ролей;
- регламент міграції даних із точками звірки та умовами відкату;
- інструкцію з відкату змін без релізу застосунку;
- документацію щодо інтеграції для команди замовника;
- набір перевірок для приймання — які сценарії та як тестувати.
Опишіть задачу — повернемося з оцінкою та планом: розберемо поточний стек, визначимо порядок міграції та зафіксуємо точки відкату до початку робіт.
Терміни етапів впровадження: що і в якій послідовності відбувається
Порядок етапів вибудуваний так, щоб кожен наступний крок спирався на перевірений попередній: спочатку фіксуємо модель даних і правила доступу, потім піднімаємо синхронізацію, і тільки після цього переводимо на неї живі екрани.
Такий план інтеграції дозволяє на будь-якому кроці зупинитися і отримати працюючий застосунок, а не набір напівготових модулів.
Етапи 3–5 ідуть з частковим перекриттям: поки один інженер веде синхронізацію, другий готує переведення екранів — так загальний термін впровадження скорочується приблизно на третину без втрати контролю.
Орієнтовні терміни вказані для застосунку середньої складності; на розбір впливає кількість екранів і глибина офлайн-сценаріїв, тому фінальний план ми фіксуємо після першого тижня роботи, коли схема даних уже видна повністю.
Окремо закладаємо етап навантаження та відмови: він показує, як застосунок поводиться при обриві зв'язку і поверненні в мережу, і часто виявляє конфлікти запису, які не видно на тестових даних. За підсумками цього етапу правки в схему вносяться до передачі, а не після виходу в продакшн.
AWS AppSync
