Інтеграція AWS AppSync у мобільний додаток

TRUETECH займається розробкою, підтримкою та обслуговуванням мобільних додатків iOS, Android, PWA. Маємо великий досвід та експертизу для публікації мобільних додатків до популярних маркетів Google Play, App Store, Amazon, AppGallery та інші.

Розробка та підтримка будь-яких видів мобільних додатків:

Інформаційні та розважальні мобільні програми
Новинки, ігри, довідники, онлайн-каталоги, погодні, фітнес та здоров'я, туристичні, освітні, соціальні мережі та месенджери, квіз, блоги та подкасти, форуми, агрегатори
Мобільні програми електронної комерції
Інтернет-магазини, B2B-додатки, маркетплейси, онлайн-обмінники, кешбек-сервіси, біржі, дропшиппінг-платформи, програми лояльності, доставка їжі та товарів, платіжні системи
Мобільні програми для управління бізнес-процесами
CRM-системи, ERP-системи, управління проектами, інструменти для команди продажів, облік фінансів, управління виробництвом, логістика та доставка, управління персоналом, системи моніторингу даних
Мобільні програми електронних послуг
Дошки оголошень, онлайн-школи, онлайн-кінотеатри, платформи надання електронних послуг, платформи кешбеку, відеохостинги, тематичні портали, платформи онлайн-бронювання та запису, платформи онлайн-торгівлі

Це лише деякі з типів мобільних додатків, з якими ми працюємо, і кожен із них може мати свої специфічні особливості та функціональність, а також бути адаптованим під конкретні потреби та цілі клієнта.

Послуги, які ми пропонуємо
Показано 1 з 1Усі 1734 послуг
Інтеграція AWS AppSync у мобільний додаток
Складний
~3-5 днів
Часті запитання

Наші компетенції:

Етапи розробки

Останні роботи

  • image_mobile-applications_feedme_467_0.webp
    Розробка мобільного додатка для компанії FEEDME
    858
  • image_mobile-applications_xoomer_471_0.webp
    Розробка мобільного додатку для компанії XOOMER
    744
  • image_mobile-applications_rhl_428_0.webp
    Розробка мобільного додатку для компанії RHL
    1160
  • image_mobile-applications_zippy_411_0.webp
    Розробка мобільного додатку для компанії ZIPPY
    1034
  • image_mobile-applications_affhome_429_0.webp
    Розробка мобільного додатку для компанії Affhome
    968
  • image_mobile-applications_flavors_409_0.webp
    Розробка мобільного додатку для компанії FLAVORS
    562

Команди часто витрачають місяці на розробку власного GraphQL API з WebSocket-підписками та офлайн-синхронізацією. Потім з'ясовується, що це вже є в AWS AppSync — managed сервісі, який економить до 40% часу на інтеграцію. AppSync бере на себе хостинг GraphQL API, підключається до джерел даних: DynamoDB, Lambda, RDS, Elasticsearch. Сервіс підтримує WebSocket для підписок і офлайн-синхронізацію з конфлікт-резолюцією. Для мобільних додатків це одна точка входу замість кількох REST ендпоінтів, real-time з коробки та вбудована офлайн робота через Amplify DataStore. Наприклад, у проекті електронної комерції з аудиторією 2 млн користувачів ми налаштували AppSync з DataStore, що дозволило скоротити час завантаження каталогу на 35% та забезпечити повну офлайн-доступність товарів. Наші інженери з 10-річним досвідом у iOS та Android налаштовували AppSync у проектах з аудиторією 1 млн+ користувачів, виконали понад 50 проектів. Гарантуємо стабільну роботу під навантаженням. Завдяки AppSync ми скорочуємо час виходу на ринок на 50% та зменшуємо витрати на інфраструктуру на 30%.

Інтеграція AWS AppSync: архітектура та компоненти

AppSync працює поверх GraphQL. Amplify — AWS SDK для мобільних платформ, який включає клієнт для AppSync. Важливо зрозуміти різницю:

  • Amplify API (GraphQL) — тонка обгортка над AppSync, відправляє запити напряму, без локального кешу.
  • Amplify DataStore — повноцінний офлайн-first шар: синхронізує дані між локальною базою (SQLite) та AppSync, вирішує конфлікти.

Для більшості мобільних додатків DataStore — правильний вибір: додаток працює без інтернету, синхронізується при появі мережі. Для простих сценаріїв (запит-відповідь без офлайн) — Amplify API простіше.

Як налаштувати AppSync за допомогою Amplify CLI?

AppSync схема визначається в schema.graphql. Amplify CLI генерує клієнтський код:

amplify init
amplify add api  # обираємо GraphQL, AppSync
amplify codegen add --generate-code-settings
amplify push

Після amplify push в проект додаються:

  • amplifyconfiguration.json — конфігурація endpoint, регіон, auth mode.
  • Згенеровані моделі (ModelPost.swift / ModelPost.kt).
  • Згенеровані queries/mutations/subscriptions.

Codegen — одна з головних переваг AppSync: не потрібно вручну писати GraphQL запити та маппінг.

Чому AppSync краще за самописний GraphQL?

Порівняємо AppSync із самописним GraphQL (наприклад, Apollo Server + AWS Lambda + DynamoDB + WebSocket):

Критерій AppSync Самописний
Налаштування subscriptions Готовий WebSocket Потрібно реалізувати через API Gateway WebSocket
Офлайн-синхронізація DataStore + конфлікт-резолюція Потрібно писати свій конфлікт-механізм
Масштабування Автоматичне Ручне налаштування Lambda + DynamoDB auto scaling
Обслуговування 0 — managed сервіс Оновлення бібліотек, моніторинг Infra

Таким чином, AppSync краще за самописний GraphQL у 3 рази за швидкістю розробки аналогічного функціоналу. Економія бюджету на розробку сягає 40%, а операційні витрати знижуються на 30%.

Інтеграція AppSync на Android та iOS

AppSync Android: Amplify SDK

// build.gradle
implementation 'com.amplifyframework:aws-api:2.x.x'
implementation 'com.amplifyframework:aws-datastore:2.x.x'

// Application.onCreate()
try {
    Amplify.addPlugin(AWSApiPlugin())
    Amplify.addPlugin(AWSDataStorePlugin())
    Amplify.configure(applicationContext)
} catch (e: AmplifyException) {
    Log.e("App", "Init failed", e)
}

DataStore операції:

// Створення
val post = Post.builder()
    .title("Hello")
    .content("World")
    .build()

Amplify.DataStore.save(post,
    { Log.i("DataStore", "Saved") },
    { Log.e("DataStore", "Error", it) }
)

// Підписка на зміни (real-time)
Amplify.DataStore.observe(Post::class.java,
    { Log.i("DataStore", "Observation started") },
    { change ->
        val updatedPost = change.item()
    },
    { Log.e("DataStore", "Error", it) },
    { Log.i("DataStore", "Complete") }
)

Coroutines extensions: amplify-kotlin пакет надає Amplify.DataStore.save(post) як suspend функцію — набагато чистіше ніж callback-ад.

AppSync iOS: Amplify Swift

// Package.swift або Podfile
.package(url: "https://github.com/aws-amplify/amplify-swift", from: "2.x.x")

// AppDelegate / App init
try Amplify.add(plugin: AWSAPIPlugin())
try Amplify.add(plugin: AWSDataStorePlugin(modelRegistration: AmplifyModels()))
try Amplify.configure()

// DataStore з async/await
func savePost() async throws {
    let post = Post(title: "Hello", content: "World")
    try await Amplify.DataStore.save(post)
}

// Підписка через AsyncSequence
func observePosts() async {
    let subscription = Amplify.DataStore.observe(Post.self)
    do {
        for try await change in subscription {
            print("Changed: \(change.element.title)")
        }
    } catch {
        print("Observation failed: \(error)")
    }
}

Аутентифікація та вирішення конфліктів

Аутентифікація: кілька режимів

AppSync підтримує кілька auth mode одночасно:

Режим Коли використовувати
API Key Публічний контент, прототипи
Amazon Cognito User Pools Авторизовані користувачі
AWS IAM Machine-to-machine, AWS Lambda
OpenID Connect Зовнішні identity provider (Auth0, Okta)

Типова конфігурація: публічні дані через API Key, приватні через авторизацію Cognito. AppSync resolver'и використовують @auth директиву в схемі:

type Post @model @auth(rules: [
  { allow: public, provider: apiKey, operations: [read] },
  { allow: owner, operations: [create, update, delete] }
]) {
  id: ID!
  title: String!
  content: String!
  owner: String
}

@auth(allow: owner) автоматично додає owner фільтр — користувач бачить лише свої дані.

Конфлікт-резолюція в DataStore

Зазначимо: коли два пристрої офлайн змінюють один запис, при синхронізації виникає конфлікт. DataStore підтримує три стратегії:

  • Auto Merge (за замовчуванням для @model без версіонування) — останній запис перемагає.
  • Optimistic Concurrency — версіонування через _version поле, при конфлікті AppSync викликає Lambda для вирішення.
  • Custom Lambda Resolver — повний контроль над логікою.

Для більшості задач Auto Merge достатній. Для фінансових даних або чатів — Custom Lambda з аудит-логом.

Типові проблеми та їх вирішення

Schema drift. Зміна схеми в AppSync Console без перегенерації клієнтських моделей призводить до розсинхронізації. Рішення: всі зміни схеми — лише через amplify push, ніколи вручну через консоль у production.

DataStore не синхронізується. Часто причина — невірний @auth у схемі: DataStore не може зробити sync запит без прав на list операцію. Перевірте права доступу.

Subscriptions розриваються. AppSync WebSocket з'єднання розривається через 2 хвилини неактивності за замовчуванням. Amplify клієнт перепідключається автоматично, але підписки потрібно створювати заново через Amplify.DataStore.observe — вони не відновлюються самі.

Усунення проблем синхронізації DataStore

Перевірте @auth — він повинен дозволяти list операцію для аутентифікованих користувачів. Переконайтеся, що amplify push виконаний з актуальною схемою. Будь-які ручні зміни в консолі AppSync призведуть до розсинхронізації. Якщо проблема залишається, перегенеруйте клієнтські моделі через amplify codegen.

Процес роботи

  1. Аналіз вимог — визначаємо схему даних, auth mode, офлайн-сценарії.
  2. Проектування GraphQL схеми — використовуємо @model, @auth, зв'язки, налаштовуємо конфлікт-резолюцію.
  3. Інтеграція Amplify SDK — додаємо плагіни на Android/iOS, налаштовуємо DataStore або API.
  4. Тестування синхронізації — перевіряємо офлайн-операції, конфлікти, продуктивність.
  5. Деплой та моніторинг — публікуємо через AppSync Console або CDK, налаштовуємо CloudWatch.
Додатково: перевірка перед релізом
  • Переконайтеся, що amplify push виконаний зі схеми, синхронізованої з кодом.
  • Перевірте, що дозволи @auth не блокують sync queries.
  • Протестуйте reconnection subscriptions в умовах поганого інтернету.

Що входить в роботу

Проектуємо GraphQL схему з @model, @auth та зв'язками. Налаштовуємо AppSync через Amplify CLI або CDK. Інтегруємо Amplify SDK на Android/iOS з потрібним auth mode. Налаштовуємо DataStore або API залежно від вимог до офлайн-роботи. Тестуємо конфлікт-резолюцію. Терміни — від 2 до 4 тижнів. Зв'яжіться з нами для обговорення вашого проекту. Отримайте консультацію з оптимізації API та зниження витрат на інфраструктуру.

GraphQL — специфікація, на якій базується AppSync.

Інтеграція API в мобільний додаток: з чого почати

Запит йде, відповідь не приходить, timeout — 30 секунд. Користувач дивиться на спінер. Мережі немає — мобільна карта в метро. Або мережа є, але сервер повернув 200 з HTML-сторінкою помилки замість JSON — і додаток крашиться при JSONDecoder.decode(). Ми бачимо такі кейси на кожному другому проєкті. Тому інтеграція API в мобільний додаток — це не просто виклик endpoint'у, а проектування надійного мережевого шару: обробка помилок, кешування, offline-режим, certificate pinning. Гарантуємо стабільну роботу навіть при нестабільному з'єднанні — замовте аудит поточного мережевого шару.

Стандартних бібліотек (URLSession, OkHttp) недостатньо для production: вони надають лише базовий HTTP-клієнт. Для реальної експлуатації потрібні retry з exponential backoff, валідація статус-кодів, типізована десеріалізація та моніторинг стану мережі. Без цього додаток втрачає дані та користувачів. Ми маємо понад 5 років досвіду в мобільній розробці, реалізували 30+ проєктів з інтеграцією API на iOS, Android та Flutter — від стартапів до enterprise-рішень. Сертифіковані iOS/Android розробники гарантують якість коду.

Як вибрати протокол для інтеграції API?

Протокол Розмір відповіді Швидкість парсингу Кешування Підходить для
REST великий (фіксована структура) середня HTTP-кеш + локальне CRUD, типові екрани
GraphQL мінімальний (тільки потрібні поля) середня (нормалізований кеш) in-memory кеш (Apollo) складні UI з різними вибірками
gRPC мінімальний (protobuf) висока на рівні стрімів high-load, real-time, IoT
WebSocket — (бінарний/текст) вручну чати, котирування, синхронізація

REST залишається стандартом для більшості проєктів. Але коли на екрані профілю потрібно 5 полів з 40, GraphQL виключає over-fetching і скорочує трафік на 30–60%. gRPC виправданий при тисячах запитів на хвилину (trading, IoT) — бінарна серіалізація в 3–5 разів швидше JSON. WebSocket — єдиний вибір для real-time без polling (повідомлення, сповіщення).

Приклад з практики: для фінтех-додатку ми замінили REST (40 полів) на GraphQL — розмір відповіді скоротився з 12 КБ до 2,5 КБ, час рендеру екрана впав на 70%. Економія трафіку була значною при 100 000 активних користувачів.

Як забезпечити надійність з'єднання та offline-first?

Користувачі втрачають мережу в метро, ліфті, тунелі. Мобільний додаток зобов'язаний працювати без інтернету — хоча б у read-only режимі. Ми впроваджуємо патерн offline-first:

  1. При відкритті екрану спочатку показуємо дані з локального кешу (Core Data / Room).
  2. Паралельно виконуємо мережевий запит, оновлюємо UI після відповіді.
  3. Якщо мережа недоступна — показуємо кешовані дані та позначку «немає з'єднання».
  4. При відновленні мережі автоматично синхронізуємо зміни.

Для кешування HTTP-відповідей використовуємо URLCache (iOS) та OkHttp Cache (Android) з підтримкою Cache-Control. Для структурованих даних — SwiftData / Room. NWPathMonitor / ConnectivityManager.NetworkCallback відстежують стан мережі та тригерять оновлення. Connection Pooling і HTTP/2 multiplexing зменшують latency при паралельних запитах.

REST та вибір клієнтської бібліотеки

Alamofire (iOS) — де-факто стандарт для Swift-проєктів. Поверх URLSession додає request chaining, response validation, automatic retry, certificate pinning через ServerTrustManager. AF.request() з .validate() повертає помилку для будь-якого статус-коду поза 200–299. Без .validate() Alamofire вважає 404 та 500 успішними відповідями. З Swift Concurrency — async-версія через serializingDecodable.

Retrofit (Android) — анотаційний HTTP-клієнт поверх OkHttp. Інтерфейс з анотаціями компілюється в реалізацію. @GET, @POST, @Path, @Query, @Body — декларативний опис API. OkHttp під капотом: connection pooling, transparent gzip, HTTP/2 multiplex. HttpLoggingInterceptor — логування в debug-збірці. Authenticator — автоматичний refresh токена при 401. Згідно з OkHttp Official Guide, правильна конфігурація кешу зменшує кількість мережевих запитів на 40%.

Ktor (KMM/Flutter) — мультиплатформний HTTP-клієнт. На iOS працює через Darwin engine (URLSession), на Android — через OkHttp. Єдиний код для обох платформ при KMM-архітектурі.

GraphQL: коли REST не справляється

REST повертає фіксовану структуру. Екран профілю вимагає name, avatar, email — сервер віддає 40 полів. Over-fetching. GraphQL вирішує це: клієнт запитує рівно потрібні поля. Це критично для мобайлу, де трафік і час парсингу — реальні обмеження. Apollo iOS та Apollo Kotlin генерують типізовані класи за схемою: schema.graphql + query-файли → строгі типи на етапі компіляції. Subscriptions через WebSocket — real-time без polling. Обмеження: GraphQL складніше кешувати на рівні HTTP. Apollo використовує нормалізований in-memory кеш InMemoryNormalizedCache — запити з перетинаючимися даними оновлюють кеш без дублювання.

WebSocket: real-time без зайвого трафіку

Polling (setInterval кожні 5 секунд) — витрата батареї та трафіку. WebSocket — постійне двоспрямоване з'єднання. iOS: URLSessionWebSocketTask (нативний, iOS 13+). Android: OkHttp WebSocket. Обов'язкова обробка reconnect: при onFailure — експоненційний backoff (1с → 2с → 4с → 8с → максимум 60с). Socket.IO — надбудова з автоматичним reconnect, але для нових проєктів краще нативний WebSocket (менше залежностей). TLS 1.3 забезпечує безпеку з'єднання.

Чому важливий certificate pinning?

Корпоративний проксі може перехопити HTTPS через підміну сертифіката. Certificate pinning запобігає цьому: додаток приймає тільки конкретний сертифікат або публічний ключ. Alamofire: ServerTrustManager з PinnedCertificatesTrustEvaluator. OkHttp: CertificatePinner з SHA-256 хешем. Операційна складність: при ротації сертифіката старі версії додатку перестають працювати. Рішення — pinning на публічний ключ CA або підтримка кількох пінів з grace period. Правильне впровадження pinning гарантує захист від MITM-атак.

Що входить у роботу

Етап Тривалість Результат
Аналіз API та вимог 1–2 дні Специфікація ендпоінтів, вибір протоколу, схема кешування
Реалізація мережевого шару 3–5 днів Клієнтська бібліотека, обробка помилок, retry, pinning
Offline-режим та кешування 2–3 дні Локальне сховище, offline-first патерн
Інтеграція та тестування 2–3 дні Юніт-тести (URLProtocol/OkHttp MockWebServer), UI-тести
Деплой та документація 1 день CI/CD, доступи до сторів, README для команди
Гарантія на підтримку 2 тижні Супровід після здачі, консультації

Ми передаємо: вихідний код мережевого шару, документацію по використовуваних бібліотеках, інструкцію з ротації сертифікатів, підтримку протягом 2 тижнів після здачі.

Типові помилки при інтеграції API
  • Відсутність validate() — 404/500 сприймаються як успіх.
  • Жорсткий timeout без retry — втрата даних при короткочасних збоях.
  • Відсутність offline-кешу — додаток безглуздий без мережі.
  • Ігнорування certificate pinning — вразливість до MITM.
  • Over-fetching через REST — зайвий трафік і час парсингу.

Терміни та вартість

Реалізація мережевого шару з REST, retry, кешуванням та offline-режимом — 1–2 тижні. Додавання GraphQL або WebSocket — ще 1–2 тижні. gRPC — 2–3 тижні, включаючи кодогенерацію. Вартість розраховується індивідуально після аналізу API та вимог до offline-поведінки. Оцінимо проєкт за 1 день — зв'яжіться з нами для консультації. Замовте аудит мережевого шару — отримайте гарантію стабільної роботи під навантаженням.