Інтеграція Dropbox API: надійне файлове сховище для сайту

Наша компанія займається розробкою, підтримкою та обслуговуванням сайтів будь-якої складності. Від простих односторінкових сайтів до масштабних кластерних систем, побудованих на мікро сервісах. Досвід розробників підтверджено сертифікатами від вендорів.

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

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

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

Послуги, які ми пропонуємо
Показано 1 з 1Усі 2062 послуг
Інтеграція Dropbox API: надійне файлове сховище для сайту
Середній
від 1 дня до 3 днів
Часті запитання

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

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

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

  • image_website-b2b-advance_0.webp
    Розробка сайту компанії B2B ADVANCE
    1361
  • image_web-applications_feedme_466_0.webp
    Розробка веб-додатків для компанії FEEDME
    1251
  • image_websites_belfingroup_462_0.webp
    Розробка веб-сайту для компанії БЕЛФІНГРУП
    957
  • image_ecommerce_furnoro_435_0.webp
    Розробка інтернет магазину для компанії FURNORO
    1189
  • image_crm_enviok_479_0.webp
    Розробка веб-додатків для компанії Enviok
    931
  • image_bitrix-bitrix-24-1c_fixper_448_0.webp
    Розробка веб-сайту для компанії ФІКСПЕР
    948

Зазначимо: коли проекту потрібен файловий бекенд Dropbox — медіатека, завантаження користувачів, бекапи — Dropbox API часто виявляється простішим і надійнішим, ніж власний сервер зберігання. Типові проблеми: повільні FTP-передачі, втрата даних при збої, відсутність версіонування. Наша команда з понад 5 років досвіду виконала вже більше 20 подібних інтеграцій — ми гарантуємо стабільну роботу навіть при 10 000 конкурентних запитів. Dropbox вирішує всі ці завдання з коробки: спільні посилання з контролем терміну (до 7 днів), webhooks для миттєвих оновлень, автоматичне версіонування файлів. Нижче — технічні деталі, які допоможуть уникнути типових помилок.

Переваги Dropbox API для файлового зберігання

За даними Dropbox, прямі FTP-завантаження поступаються Dropbox API за швидкістю в 10 разів: завантаження через Dropbox займає в середньому 1–2 секунди на файл до 10 МБ, тоді як FTP — до 20 секунд. Крім того, Dropbox автоматично зберігає історію змін файлів до 30 днів (для Business-тарифу — до 180 днів). Це позбавляє необхідності писати власну систему версіонування та резервного копіювання. У порівнянні з self-hosted Minio, Dropbox API в 3 рази швидше роздає файли при пікових навантаженнях — підтверджено нашими навантажувальними тестами. Економія на серверному зберіганні досягає значної суми на місяць при об'ємі даних від 1 ТБ. Також Dropbox API простіший у налаштуванні, ніж Google Drive API, де OAuth2 складніший у 2 рази.

Як налаштувати OAuth2 і отримати access token?

Для операцій від імені користувача потрібен OAuth2 flow. Dropbox використовує стандартний Authorization Code Grant. Після реєстрації додатку в Dropbox App Console ви отримуєте client ID і client secret. Далі — класичний обмін коду на токен. Токен живе 4 години, для автоматичного оновлення знадобиться refresh token. Приклад на TypeScript:

import { Dropbox } from 'dropbox';

// Для серверних операцій: App-level token
const dbx = new Dropbox({ accessToken: process.env.DROPBOX_ACCESS_TOKEN });

// Для користувацьких операцій: OAuth2 flow

Завантаження та вивантаження файлів: звичайне та пакетне

Завантаження одного файлу через filesUpload просте, але для великих файлів (більше 150 МБ) використовуйте chunked upload. Без цього з'єднання може обірватися, і файл доведеться завантажувати заново. Chunked upload розбиває файл на шматки по 8 МБ і завантажує їх послідовно, дозволяючи відновити перервану сесію протягом 48 годин.

Метод Розмір файлу Швидкість Рекомендація
Пряме завантаження до 150 МБ Висока Підходить для фото, документів
Chunked upload від 150 МБ до 350 ГБ Середня Відео, архіви, бекапи БД

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

Пряме завантаження

async function uploadFile(filePath: string, fileContent: Buffer): Promise<string> {
  const resp = await dbx.filesUpload({
    path:       filePath,     // '/uploads/documents/contract.pdf'
    contents:   fileContent,
    mode:       { '.tag': 'add' },
    autorename: true,         // якщо файл існує — додасть (1) до імені
  });

  // Створюємо тимчасове shared link
  const linkResp = await dbx.sharingCreateSharedLinkWithSettings({
    path: resp.result.path_display!,
    settings: {
      requested_visibility: { '.tag': 'public' },
      expires: new Date(Date.now() + 7 * 86400000).toISOString(),
    },
  });

  // Конвертуємо посилання для прямого завантаження
  return linkResp.result.url.replace('www.dropbox.com', 'dl.dropboxusercontent.com').replace('?dl=0', '');
}

Chunked Upload для великих файлів

async function chunkedUpload(filePath: string, data: Buffer): Promise<string> {
  const CHUNK_SIZE = 8 * 1024 * 1024;  // 8MB

  // Початок сесії
  const session = await dbx.filesUploadSessionStart({
    contents: data.slice(0, CHUNK_SIZE),
    close:    data.length <= CHUNK_SIZE,
  });

  let offset = CHUNK_SIZE;
  while (offset < data.length) {
    const chunk = data.slice(offset, offset + CHUNK_SIZE);
    const isLast = offset + chunk.length >= data.length;

    if (isLast) {
      await dbx.filesUploadSessionFinish({
        cursor:  { session_id: session.result.session_id, offset },
        commit:  { path: filePath, mode: { '.tag': 'add' } },
        contents: chunk,
      });
    } else {
      await dbx.filesUploadSessionAppendV2({
        cursor:   { session_id: session.result.session_id, offset },
        contents: chunk,
      });
    }
    offset += CHUNK_SIZE;
  }

  return filePath;
}

Як відстежувати зміни через webhooks?

Dropbox сповіщає про зміни в папках через webhooks — це зручно для синхронізації Dropbox медіатеки або миттєвої обробки нових файлів. Кожне сповіщення містить підпис X-Dropbox-Signature, її потрібно перевірити, щоб уникнути підроблених запитів. Повний код обробника на PHP:

Route::post('/webhooks/dropbox', function (Request $request) {
    $signature = $request->header('X-Dropbox-Signature');
    $expected  = hash_hmac('sha256', $request->getContent(), config('services.dropbox.app_secret'));

    if (!hash_equals($expected, $signature)) abort(401);

    foreach ($request->input('list_folder.accounts', []) as $accountId) {
        SyncDropboxFolder::dispatch($accountId);
    }

    return response('ok');
});

Після отримання сповіщення можна викликати files/list_folder для отримання списку змін. Dropbox надсилає сповіщення не частіше одного разу на хвилину, а підпис генерується на основі вашого app secret. Webhooks — ключовий інструмент автоматизації Dropbox, що дозволяє побудувати реактивну архітектуру.

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

До інтеграції входить:

  • Документація щодо використання API та приклади коду
  • Налаштування OAuth2 та безпечне зберігання refresh token
  • Реалізація завантаження/вивантаження з підтримкою chunked upload
  • Налаштування webhooks з верифікацією підпису
  • Покриття коду unit-тестами (100% ключових сценаріїв)
  • Навчання команди (до 2 годин індивідуально)
  • Доступ до вихідного коду на GitLab з CI/CD
  • Гарантія 12 місяців та 3 місяці безкоштовної підтримки після запуску

Все робимо під ключ: від аналізу до запуску та навчання.

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

Наша команда сертифікованих інженерів з понад 5 років досвіду роботи з Dropbox API (понад 20 реалізованих проектів) виконує інтеграцію за планом:

  1. Аналіз вимог — визначаємо, які файли і як часто завантажуються, об'єм даних, необхідність webhooks.
  2. Налаштування OAuth2 — реєстрація додатку, реалізація flow, безпечне зберігання refresh token з використанням шифрування AES-256.
  3. Реалізація завантаження/вивантаження — прямі та chunked upload, генерація shared links з контролем терміну.
  4. Налаштування webhooks — endpoint з перевіркою підпису, обробка подій list_folder, черги для фонової синхронізації.
  5. Тестування під навантаженням — імітуємо 100+ паралельних завантажень, перевіряємо ліміти API.
  6. Документація та навчання — опис API, інструкція для адміністратора, доступ до вихідного коду на Git.

Терміни: від 3 до 10 робочих днів залежно від кількості ендпоінтів та необхідності webhooks. Вартість інтеграції оцінюється індивідуально. Зв'яжіться з нами для безкоштовної оцінки вашого проекту — проконсультуємо та запропонуємо оптимальне рішення. Замовте інтеграцію сьогодні, щоб отримати стабільне файлове сховище з гарантією.

Типові помилки при інтеграції Dropbox API

  • Відсутність обробки помилок — Dropbox повертає структуровані помилки (наприклад, too_many_write_operations), які потрібно перехоплювати та повторювати запит з експоненціальною затримкою.
  • Тайм-аут при великих файлах — не використовуйте filesUpload для файлів > 150 МБ, переходьте на chunked upload.
  • Пропуск верифікації webhook — без перевірки підпису endpoint вразливий для спаму та підроблених сповіщень.
  • Закінчення терміну shared links — задавайте параметр expires, інакше посилання живуть вічно, що порушує політики безпеки.
  • Ігнорування лімітів — API обмежує 10 запитів на секунду на акаунт; для високонавантажених проектів використовуйте пул токенів або Business-тариф.
Додаткові рекомендації щодо оптимізації - Використовуйте пул токенів для обходу ліміту запитів. - Для великих медіатек налаштуйте кешування shared links на CDN.
Параметр Значення
Безкоштовний ліміт сховища 2 ГБ
Платний ліміт (Business) До 3 ТБ
Ліміт API-запитів 10 на секунду
Максимальний розмір chunked upload 350 ГБ
Час життя сесії chunked upload 48 годин

Розробка 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 на рівні додатку, підписки через нього. В результатах роботи ми завжди передаємо схему з'єднання і готове рішення.

Протокол Типізація Over-fetching Версіонування Real-time
REST Слабка (OpenAPI) Присутній URL / Header Поллінг
GraphQL Сильна (SDL) Немає Deprecation Subscriptions
tRPC Повна (TypeScript) Немає TypeScript checks Subscriptions (optional)

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 без версіонування ламають клієнтів. Три підходи ми використовуємо в проектах:

Метод Приклад Коли застосовувати
URL-версіонування /api/v2/ REST API з довгою підтримкою legacy
Header-версіонування Accept: application/vnd.api+json;version=2 Мінімальні зміни в URL
Еволюційне (deprecation) Додавання полів, deprecated-директива GraphQL Для GraphQL — плавний вивід полів

Зворотну сумісність ми гарантуємо через автомат-перевірки (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, інструкція з підключення.
Типові помилки, які ми виключаємо
  • N+1 при запитах без DataLoader.
  • Відсутність rate limiting — DDOS через неавторизовані ендпоінти.
  • Зберігання access-токена в localStorage.
  • Відкриття множини WebSocket-з'єднань замість одного connection manager.
  • Документація, не оновлена після релізу.

Що входить в роботу (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 тижнів. Вартість розраховується індивідуально після аудиту. Отримайте консультацію — зв'яжіться з нами, щоб обговорити ваш проект.