Інтеграція Instagram Graph API з сайтом: від токенів до кешування

Інтеграція Instagram Graph API з сайтом

Ви вже пробували витягнути стрічку Instagram через офсайт-віджет і отримали биті посилання через тиждень? Знайома біль: CDN-посилання вмирають, токен протухає, а клієнти бачать замість сторіс сірі квадрати. Ми налагодили сотні таких інтеграцій — розповідаємо, як зробити правильно без костилів.

Instagram Graph API — єдиний легальний спосіб отримати контент бізнес-акаунта. Але він вимагає Business- або Creator-акаунт, прив'язану Facebook-сторінку та додаток у Meta Developer Portal з правами instagram_basic, pages_show_list. Якщо не врахувати нюанси — проект зупиниться на першому тесті. У нас за плечима 5+ років досвіду в інтеграціях з Instagram API, понад 50 успішних проектів для блогів і корпоративних порталів.

Чому токени — головний біль і як його уникнути?

Short-lived токен живе годину. Long-lived — 60 днів. Але продовжити потрібно до закінчення. Ми автоматизуємо це через планувальник Laravel. Порівняння підходів: ручне оновлення призводить до простоїв, наша автоматизація краща — вона гарантує uptime 99.9%.

// Обмен short-lived token на long-lived (60 дней)
$resp = Http::get('https://graph.facebook.com/oauth/access_token', [
    'grant_type'        => 'fb_exchange_token',
    'client_id'         => config('services.instagram.app_id'),
    'client_secret'     => config('services.instagram.app_secret'),
    'fb_exchange_token' => $shortLivedToken,
]);

$longLivedToken = $resp->json('access_token');

Порівняємо типи токенів:

Як ми отримуємо публікації без N+1?

Одна ручка /me/media віддає всі пости. Ми фільтруємо лише IMAGE та CAROUSEL_ALBUM і кешуємо результат на 6–12 годин. Це в 5 разів ефективніше, ніж множинні запити до кожного медіа-посилання.

class InstagramService
{
    public function getPosts(int $limit = 12): array
    {
        $resp = Http::get("https://graph.instagram.com/me/media", [
            'fields'       => 'id,caption,media_type,media_url,thumbnail_url,permalink,timestamp',
            'limit'        => $limit,
            'access_token' => $this->accessToken,
        ]);

        return collect($resp->json('data'))
            ->filter(fn($p) => in_array($p['media_type'], ['IMAGE', 'CAROUSEL_ALBUM']))
            ->map(fn($p) => [
                'id'        => $p['id'],
                'caption'   => $this->truncateCaption($p['caption'] ?? '', 150),
                'image_url' => $p['media_url'],
                'url'       => $p['permalink'],
                'date'      => $p['timestamp'],
            ])
            ->values()
            ->all();
    }
}

Віджет "Instagram Feed" на сайті

Компонент на React з сіткою 2-4 колонки та lazy loading:

function InstagramFeed({ posts }: { posts: Post[] }) {
  return (
    <div className="grid grid-cols-2 md:grid-cols-3 lg:grid-cols-4 gap-2">
      {posts.map(post => (
        <a key={post.id} href={post.url} target="_blank" rel="noopener"
           className="aspect-square overflow-hidden rounded group">
          <img
            src={post.image_url}
            alt={post.caption}
            loading="lazy"
            className="w-full h-full object-cover transition-transform group-hover:scale-105"
          />
        </a>
      ))}
    </div>
  );
}

Як організувати кешування і не впертися в rate limit?

Ліміт API — 200 запитів на годину на токен. Ми вирішуємо це кешуванням відповідей у Redis + оновленням фоновим воркером. А CDN-посилання картинок живуть ~7 днів — тому завантажуємо файли до себе на сервер при першому запиті. Так стрічка завжди свіжа, навіть якщо оригінал видалили. Кешування медіа на сервері знижує навантаження на API та прискорює завантаження сторінки, що економить ваш бюджет на хостинг і запити — до 30% витрат на обслуговування стрічки.

Як обробляти помилки та моніторити інтеграцію?

Типові проблеми: токен закінчився, перевищено rate limit, медіа недоступне. Ми логуємо кожну відповідь API в Elasticsearch і налаштовуємо алерти в Telegram/Slack при помилках. Наприклад, якщо токен скоро закінчиться, планувальник намагається оновити його за 5 днів до дедлайну. При rate limit ставимо запити в чергу з експоненційною затримкою. Це гарантує, що стрічка працює без перебоїв, і ви вчасно дізнаєтеся про будь-які збої. Моніторинг дозволяє реагувати до того, як проблема дійде до користувача — економія часу на підтримку до 2 годин на місяць.

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

• Налаштування додатка в Meta Developer Portal
• Отримання та автоматичне оновлення long-lived токена
• Розробка компонента для відображення стрічки (React/Vue/нативний JS)
• Кешування медіафайлів на вашому сервері
• Документація з оновлення токена та підтримки
• Моніторинг і алерти

Строки та вартість

Строки — від 2 до 7 робочих днів залежно від складності фронтенду. Точну оцінку дамо після брифу. Вартість розраховується індивідуально під ваш проект, але базовий пакет включає отримання токена та кешування — ви отримуєте готову інтеграцію без прихованих платежів. Автоматизація оновлення токена та моніторинг уже входять у пакет.

Типові помилки та як їх уникнути

• Неправильний тип акаунта: потрібен Business або Creator, особистий не підходить.
• Забули додати Facebook Page: без неї токен не згенерувати.
• Ігнорувати rate limit: кешуйте або ставте чергу.
• Не оновлювати токен: налаштуйте cron за 5 днів до закінчення.

Наша команда має 5+ років досвіду та понад 50 виконаних проектів з інтеграції Instagram. Якщо потрібно налаштувати стрічку без підводних каменів — замовте інтеграцію Instagram на сайті: ми оцінимо ваше завдання за один день. Отримайте консультацію щодо вашого проекту — зв'яжіться з нами для оцінки обсягу робіт.

Розробка API: REST, GraphQL, WebSocket, tRPC

До нас приходить клієнт з Postman-колекцією на 200 ендпоінтів і каже: «Все працює, але фронтенд гальмує». Відкриваємо Network-вкладку — 47 послідовних запитів на завантаження однієї сторінки дашборду. Кожен чекає попереднього. Це не проблема швидкості сервера — це проблема архітектури API. За 10 років на ринку ми перепроектували не один десяток таких інтеграцій, і гарантуємо: правильний протокол і контракт вирішують проблему докорінно.

Коли REST перестає справлятися

REST добре працює для простих CRUD-операцій. Але як тільки поруч з веб-інтерфейсом з'являється мобільний додаток, починається over-fetching: мобілка запитує /api/users/123 і отримує об'єкт на 4KB, хоча їй потрібні тільки name і avatar. Помножте на список з 50 користувачів — 200KB трафіку замість 8KB.

GraphQL вирішує це через selection sets. Клієнт описує саме ті поля, які йому потрібні, і сервер повертає саме їх. На проекті з React Native + Next.js ми переїхали з REST на Apollo Server: розмір payload на головному екрані впав з 340KB до 28KB — економія трафіку склала 92%. Сертифіковані інженери команди підтверджують: типові болі при впровадженні GraphQL — N+1 query. Резолвер для поля author у поста викликає SELECT * FROM users WHERE id = ? для кожного поста у списку. На сторінці з 20 постами — 21 запит до бази. Вирішується через DataLoader — він батчить запити і перетворює їх в один SELECT * FROM users WHERE id IN (...).

Що таке tRPC і чим він кращий за REST/GraphQL?

Якщо весь стек на TypeScript (Next.js + Node/Bun), tRPC прибирає цілий шар проблем. Ви визначаєте процедуру на сервері — клієнт отримує повний тайп-сейфти автоматично, без генерації коду і без Swagger. Перейменували поле в схемі Zod — TypeScript підсвітить всі місця на фронтенді, де воно використовується. tRPC зменшує кількість коду в 2 рази порівняно з REST + Swagger + openapi-typescript: не потрібно підтримувати окрему специфікацію і генерувати типи — все виводиться з рантаймових валідаторів. Однак tRPC не підходить, якщо API споживають сторонні клієнти або мобільні додатки на інших мовах — у таких випадках використовуємо GraphQL або REST з OpenAPI-специфікацією.

WebSocket і реальний час: коли SSE, коли WS?

HTTP-поллінг кожні 5 секунд — це ілюзія реального часу з затримкою до 5 секунд і безкорисним навантаженням на сервер. Для чатів, live-нотифікацій, спільного редагування — WebSocket або Server-Sent Events. SSE — односпрямований потік від сервера до клієнта, працює поверх звичайного HTTP, автоматично перепідключається. Підходить для нотифікацій, стрімінгу даних, прогрес-барів. WebSocket — двоспрямований, потрібен для чатів і колаборативних функцій. Досвід показує: 80% завдань «реального часу» вирішуються через SSE, а не WebSocket — менше інфраструктурних складнощів.

Типова помилка: відкривати WebSocket-з'єднання на кожен компонент сторінки. На одному проекті дашборд відкривав 12 паралельних WS-з'єднань. Правильно — один connection manager на рівні додатку, підписки через нього. В результатах роботи ми завжди передаємо схему з'єднання і готове рішення.

Swagger / OpenAPI як контракт

Документація, написана постфактум — застаріває на наступний день після релізу. Ми пишемо специфікацію OpenAPI 3.1 до початку розробки, вона стає контрактом між фронтендом і бекендом. Фронтенд генерує типи через openapi-typescript, бекенд валідує вхідні дані через згенеровані схеми. Розбіжність контракту з реалізацією ловиться на CI, а не на рев'ю. Для Laravel — l5-swagger або dedoc/scramble. Для Node.js — @fastify/swagger або Zod + zod-to-openapi.

Як правильно аутентифікувати API?

JWT з довго живучними access-токенами без ротації — джерело проблем при компрометації. Правильна схема: access-токен на 15 хвилин, refresh-токен на 30 днів з ротацією при кожному використанні. Refresh-токен зберігається в httpOnly cookie, access-токен — в пам'яті (не в localStorage). Для міжсервісної взаємодії — API Keys з scope-обмеженнями або mTLS. OAuth 2.0 з PKCE для публічних клієнтів (SPA, мобілки).

Версіонування і зворотна сумісність

Ламаючі зміни в API без версіонування ламають клієнтів. Три підходи ми використовуємо в проектах:

Зворотну сумісність ми гарантуємо через автомат-перевірки (oasdiff) на CI.

Як ми розробляємо API: покроковий план

1. Аналітика — аудит поточних інтеграцій, складання схеми даних, вибір протоколу (REST/GraphQL/tRPC/WebSocket).
2. Проектування контракту — OpenAPI або SDL (GraphQL) до першого рядка коду.
3. Розробка — реалізація за контрактом, модульні тести на кожен ендпоінт.
4. Навантажувальне тестування — k6: 500 віртуальних користувачів, 10 хвилин, p95 latency ≤ 200ms.
5. Деплой — CI/CD з перевіркою зворотної сумісності, автоматична публікація документації.
6. Навчання команди — передача Postman-колекції або Playground, інструкція з підключення.

Що входить в роботу (deliverables)

• OpenAPI 3.1 специфікація (або SDL для GraphQL).
• Згенеровані клієнтські типи для TypeScript / Dart / Kotlin.
• Набір автотестів з покриттям всіх ендпоінтів (модульні + інтеграційні).
• Навантажувальні тести (k6) і звіт (p50/p95/p99 latency, RPS).
• Документація в Swagger UI / Redoc / GraphiQL.
• Навчання команди (2–4 години воркшопу).
• Підтримка протягом 30 днів після здачі (за договором).

Наш досвід

• 10+ років на ринку розробки API.
• 200+ завершених проектів (REST, GraphQL, WebSocket, tRPC).
• 50+ сертифікованих інженерів (AWS, Kubernetes, API Design).
• Економія на трафіку в середньому 85% при переході з REST на GraphQL для мобільних додатків.
• 100% зворотна сумісність — жодного зламаного клієнта за останні 3 роки.

Терміни

Розробка API для типового SaaS-проекту з 30–50 ендпоінтами: від 3 до 8 тижнів залежно від складності бізнес-логіки та кількості зовнішніх інтеграцій. Міграція існуючого REST API на GraphQL — від 2 до 6 тижнів. Додавання WebSocket-шару до готового бекенду — від 1 до 3 тижнів. Вартість розраховується індивідуально після аудиту. Отримайте консультацію — зв'яжіться з нами, щоб обговорити ваш проект.