А що, Cloudflare це не тільки для того щоб HTTPS налаштовувати?

💡 Усі статті, обговорення, новини про DevOps — в одному місці. Приєднуйтесь до DevOps спільноти!

Вітаю, спільното! Я Артем, і я вже декілька років працюю з маленьким і середнім бізнесом, щоб давати їм максимальну користь у вигляді розроблених продуктів у ролі CTO аутсорсингової компанії Inc-Dev. Ця стаття може бути корисна як технічним лідерам і DevOps, так і розробникам, або навіть людям, що не мають прямого відношення до розробки і просто хотіли б краще зрозуміти IT-Landscape

Як і багато моїх колег, друзів і знайомих, я вже давно не можу уявити простого і спокійного життя без Cloudflare. Думаю всі хоч раз отримували цей простий і безкоштовний TLS-сертифікат, згадували часи коли за це треба було ще й гроші платили, лагідно посміхались і йшли далі робити свою роботу.

Компанія Cloudflare і в правду спростила усім доступ до безкоштовного і простого налаштування не просто DNS з TLS-сертифікатом, а цілої мережі CDN з кешуванням і захистом від потенційних атак.

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

«А для чого ж ще?»

— у відповідь на запитання поставлене в заголовку може поставити пересічний читач

Перед вами коротенький список того, які саме сервіси ми сьогодні розглянемо:

  • R2
  • Turnstile
  • Workers/Pages
  • Бази даних KV і D1
  • Durable Objects

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

R2

Ходять чутки що над неймінгом цього сервісу працювали найкращі розуми-випускники MIT.

R2 — це S3-compatible сховище від Cloudflare. Порівняно з S3, надзвичайно простий в налаштуванні, так ще й безкоштовний для невеликих проєктів, а для великих часто дешевший за S3.

Коли я думаю про R2, одразу згадується історія про товариша, який витратив дві години часу щоб знайти пустий S3-бакет в AWS між регіонами, а в кінці кінців так і не знайшов. А думаю я про R2, тому що одразу після цього ми почали використовувати R2 і такої проблеми більше ніколи не виникало.

Звісно, якщо ваш проєкт використовує AWS як головний спосіб розгорнути додаток, питання вибору R2 або S3 навіть не стоятиме, але для проєктів, які не потребують запуску саме на серверах від Amazon, моїм вибором завжди залишається

Спойлер: про те, що ми використовуємо замість AWS для розгортання своїх додатків і додатків наших клієнтів і як ми економимо на DevOps за рахунок цього я розповім в іншій публікації

Найголовніше для мене в R2 — простота і швидкість налаштування. Для реєстрації в Cloudflare потрібна тільки пошта, а для створення свого першого бакету треба тільки додати дані для оплати і натиснути декілька кнопок. Так само просто приєднати бакет до свого домену, що менеджиться Cloudflare. Додатковим позитивним ефектом в такому разі є те, що ви автоматично отримуєте кешування і CDN на всій мережі, з додатковими оптимізаціями за рахунок того, що все це розміщується в одних і тих самих дата-центрах.

Turnstile

Свою версію CAPTCHA від Cloudflare ви скоріш за все бачили і точно не один раз (і точно не два). Як і найвідоміша reCAPTCHA від Google, Turnstile підтримує як звичайний режим, коли користувачу треба вручну натиснути галочку, так і в невидимому режимі, коли користувач навіть не бачить, що вона інтегрована. Окрім цих двох режимів, також є мій улюблений режим — non-interactive, при якому користувач бачить віджет, але не повинен обовʼязково з ним взаємодіяти щоб пройти перевірку.

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

А ще Turnstile ніколи не питає вибрати всі велосипеди які ви бачите на картинці!

Workers/Pages

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

До якогось моменту платформи Workers і Pages були розділені, з особливістю Pages у тому, що вона дозволяла розміщувати не тільки javascript-код що буде виконуватись у мережі Cloudflare, а й статичні файли, як HTML, CSS, клієнтський JS, і т.д. Але, починаючи з квітня 2025 року, жовта компанія додала підтримку статичних асетів і у Workers і наразі саме вони є рекомендованим способом створювати нові додатки (порівняння в підтримці функцій можна побачити тут developers.cloudflare.com/...​ges/#compatibility-matrix). Тож, хоч мій досвід буде включати як Pages, так і Workers, на даний момент це все більше стосується Cloudflare Workers

Так для чого ж ця платформа? Якщо коротко — для всього. На ній можна розгорнути як маленький бекенд, так і середній бекенд (з великими бекендами більш проблематично, бо існує ліміт по розміру коду для одного воркеру), з єдиним обмеженням в тому, що його неможливо поставити у приватну мережу з базою даних або іншими серверами, але при використанні екосистеми Cloudflare це питання закривається (наприклад, бази даних Cloudflare D1 або KV, про які пізніше в цій статті)

Окрім того, на відміну від того ж Vercel, всі ці фічі доступні повністю за безкоштовно, а subscription-план починається з 5$/місяць без ліміту на кількість людей в організації.

Додатковими приємними «плюшками» є:

  • Preview-деплойменти — для кожного бранча можна створити окремий деплоймент, без додаткового косту
  • Wrangler — CLI, що включає в себе як development environment, так і утиліти для деплою та отримання інформації з Cloudflare без інтерфейсу
  • Прямий доступ до екосистеми інших сервісів Cloudflare — все інтегровано і конфігурується надзвичайно швидко
  • Автоматично налаштовані метрики — підтримується як стандартна аналітика для воркерів, так і додаткова аналітика для веб-сайтів за допомогою Cloudflare Web Analytics
  • Розміщення на всій мережі Cloudflare — один з найбільших плюсів, особливо для фронтенд-застосунків, що означає що код буде виконуватись найближче до користувача, скорочуючи витрати часу на world-wide нетворкінг і покращуючи швидкість отримання статичних асетів

Якщо ви знаєте ще фічі, що підтримуються в Cloudflare Workers, пишіть в коментарях 🤗

Це все круто, але які ж справжні юзкейси?

  • Фронтенди — надзвичайно простий, швидкий і здебільшого безкоштовний деплой як SPA, так і SSR фронт-ендів. Не збрешу, якщо скажу, що 95% усіх фронт-ендів, що були мною розгорнуті протягом останніх 2х років були розгорнуті саме на платформі Pages/Workers
  • Обробники вебхуків і інтеграції — ситуативні скрипти, які не потребують постійного виконання на сервері (хоча більш довге виконання можна зробити за допомогою Workflows), а тригеряться при виконанні HTTP-ендпоїнтів. Приклади включають: інтеграції з сторонніми сервісами, що відправляють вебхуки; чат-боти
  • Сервісні скрипти — неодноразово спостерігав як платформа використовуються для таких речей як: рейт-лімітінг, кешування, reverse-proxy, а також інші скрипти, що стоять між основним бекенд- або фронтенд-додатком і кінцевим користувачем

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

Бази даних KV і D1

Як KV, так і D1 є базами даних, з особливістю в тому, що вони розміщуються на всій мережі Cloudflare, що у комбінації з воркерами може бути використано для створення простих і швидких edge-застосунків.

Так в чому ж різниця і навіщо їх дві?

  • KV — база даних типу ключ-значення, що може бути надзвичайно корисною для розробки шарів кешування, а також задачі рейт-лімітінгу
  • D1 — реляційна база даних, що працює на основі SQLite. Повністю підтримує відповідний функціонал SQLite, розміщується на усій мережі Cloudflare і дозволяє зберігати більш складні дані, що дозволяє будувати повноцінні бекенд-застосунки у комбінації з платформою Workers.
    • Окремою перевагою D1 є підхід до бекапів — технологія Time Travel дозволяє відновлювати бекапи з точністю до хвилин за період останніх 30 днів, без додаткового косту. І якщо 30 днів — недостатній для вас період, то будь-який бекап можна зберегти у R2 для більш довготривалого зберігання. Додатковою опцією є можливість створити fork бази даних напряму з будь-якого бекапу, що дозволяє легко створювати бази даних для тестування локальних фічей, репродюсу помилок або створення staging-environment

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

Durable Objects

Якщо всі інші сервіси хоч і трохи пахнуть магією, але є ± звичними для середньостатистичного розробника, бо так чи інакше використовуються всіма нами незалежно від того, чи користуємось ми Cloudflare чи ні, то Durable Objects це набагато більш унікальна історія.

Що ж це взагалі таке? Якщо коротко, Durable Object прописується у вигляді javascript-класу, після чого після деплою в мережу можна створювати «інстанси» цього класу і гарантується, що в рамках усієї мережі один такий інстанс буде запущений тільки 1 раз в 1 потоці, незалежно від кількості клієнтів. Кожен такий обʼєкт має доступ до власної SQLite бази даних та KV бази даних, дані ізольовані між інстансами.

Окрім того, в рамках Durable Objects є API для обробки, зберігання і надсилання відповіді по websocket-зʼєднанням, без необхідності тримати сам код постійно запущеним. Таким чином, Durable Objects можна використовувати навіть без зберігання якихось даних персистентно в рамках сховища, а просто задля створення шару комунікації між декількома websocket-клієнтами.

Комунікація і розгортання обʼєктів напряму не є молживим і доступне тільки за допомогою платформи Workers (всередині це відбувається за рахунок RPC-викликів). Так само неможливо напряму достучатись до будь-якого Durable Object-а, тільки через Workers.

Тобто, якщо скоротити по максимуму, то Durable Object — це обʼєкт класу, що, коли потрібно, запускається в мережі, але незалежно від кількості клієнтів що намагаються паралельно з ним комунікувати, в мережі він буде тільки 1.

Перше, що прийшло мені в голову, коли я побачив як виглядають Durable Objects — блін це реально схоже на solidity смарт-контракти.

«Так і нафіга воно треба?». Перше, що приходить в голову — це чати. Розробка системи чатів, на яку можна розраховувати з точки зору скейлінгу і відказостійкості зазвичай задача набагато складніше, ніж здається на перший погляд. В свою чергу, ми можемо скористатись цим сервісом від Cloudflare, щоб вирішити найскладніші задачі: синхронне оновлення інформації у всіх клієнтів, консистетність відображення повідомлень та можливість запускати код на декількох машинах одразу (це відбуватиметься автоматично).

Інший приклад — багатоступенева форма реєстрації. Коли клієнт ще не зареєстрований в платформі до кінця, а дані про те, які етапи він пройшов зберігати вже десь потрібно, так як вони можуть бути використані для маркетингу або для оптимізації процесів. За допомогою цієї платформи можна репрезентувати процес реєстрації одного клієнта як 1 Durable Object і зберігати відповідні дані, заповнені користувачем в рамках його власного storage-шару. Після закінчення усіх ступенів ці дані можуть бути направлені вже на реальний бекенд, в рамках якого не треба буде думати про те, як саме користувач заповнив ці дані.

Загалом, застосувань може бути нескінченна кількість, головне питання, яке є сенс ставити собі при виборі чи користуватись Durable Objects чи ні для того, щоб щось написати — «чи виграю я щось від того, що використаю Durable Objects, а не просто реляційну модель зберігання даних у одній великій базі даних?»

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

Але, не зважаючи на це, Durable Objects точно зможуть допомогти вам вирішити деякі задачі швидше, ефективніше і, найголовніше, надійніше з точки зору розгортання, а можливо в додаток ще й повністю безкоштовно.

Outro

Як я вже зазначав раніше, це тільки основні претенденти на цікавість технологій, що надає компанія Cloudflare. Насправді таких технологій набагато більше, і, хоч Cloudflare-стек і не такий «хайповий», як використання чогось по типу Vercel + Next.js + Supabase, я вважаю його набагато більш потужнішим і продуктивнішим з точки зору cost-effectiveness, що може бути особливо важливим для маленьких компаній, стартапів, пет-проєктів, або просто проєктів, на які використовуються раз на рік.

Якщо вам було б цікаво подивитись на реальне застосування технологій, перелічених вище, пишіть про це в коментарях, і, якщо набереться достатньо бажаючих, я зроблю ще одну статтю з розробкою повноцінного додатку на Cloudflare-стеку з використанням максимальної кількості перелічених вище технологій

Окрім того, буду радий будь-яким відгукам, як з приводу статті, так і з приводу Cloudflare взагалом в коментарях

Дякую усім хто дочитав до самого кінця, ви бусінки 🤗

P.S. Представники Cloudflare, якщо вдруг захочете дати мені грошей за цю прекрасну статтю, пишіть мені на email на профілі DOU (будь ласка) 😉

👍ПодобаєтьсяСподобалось10
До обраногоВ обраному7
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Артеме, дякую за статтю!
Ви вірно підмітили — Cloudflare вже давно не тільки про DNS та CDN :)

Ви просили навести більше реальних юзкейсів Workers в коментарях, та і їх справді безліч.

Головна ідея, яку я завжди раджу тримати в голові: ваша аплікація деплоїться не десь в одному дата-центрі у Франкфурті, а одразу на 330+ локаціях Cloudflare по всьому світу, що робить затримку з боку юзера мінімальною. І це ще не кажучи про відсутність холодних стартів та нульову вартість вихідного трафіку з R2.

Від себе додам, що зараз ми активно рухаємося у напрямку розробки, деплою та захисту AI-застосунків. Наша глобальна мережа ідеально підходить для завдань, що потребують низької затримки, як-от AI inference. За допомогою таких інструментів, як AI Gateway, ми допомагаємо керувати та захищати LLM-моделі, контролюючи, які дані до них потрапляють, і запобігаючи витокам.

P.S. Не зміг знайти вашу пошту у профілі, тож виходить грошей не буде :(
На більш серйозній ноті, якщо будуть будь-які запитання — буду радий допомогти, моя пошта [email protected]

Не бачу причини не юзати для pet проєктів. Тим більше, що все можна швидко і дешево піднімати через terraform registry.terraform.io/...​re/cloudflare/latest/docs
Ціни на сервіси можна подивитися у директорії developers.cloudflare.com/directory

Підписатись на коментарі