Я створив додаток для миттєвих месенджерів на @Cloudflare. Це зайняло 1 день, 3 файли, 4 ресурси... І він готовий масштабуватися від 0 до мільйонів. Worker → аутентифікації та маршрутизації База даних D1 → зберігати користувача/пропуск Профіль користувача DO → та друзі Розмова: ОБОВ'ЯЗКОВО → повідомлення Напишіть блог у відповідь, але короткий тизер тут: Бібліотека cloudflare/actors зробила це дуже простим завдяки властивостям збереження, легкому керуванню з'єднанням через веб-сокети та надсилання повідомлень усім слухачам. Але що робила кожна деталь? Автентифікація та маршрутизація (Працівник + D1) Усі запити надходять через працівника, або автентифікований, або ні. Якщо не автентифіковано, доступні дії — це вход або реєстрація. Після автентифікації він може передати запит будь-якому з наших Довготривалих Об'єктів (користувача або розмови) для встановлення з'єднання веб-сокета. Вся інформація про автентифікацію користувачів зберігається в базі даних D1 (для цього прикладу я зберіг усе CF). Сервіс користувача (Довготривалий об'єкт) Наш перегляд списку друзів підключається безпосередньо до нашого користувача Durable Object через веб-сокет. Коли ми оновлюємо статус, ми надсилаємо повідомлення нашому індивідуальному DO, яке потім може транслювати через RPC до наших друзів і визначати, чи вони онлайн, щоб надіслати їм повідомлення у веб-сокеті для оновлення в реальному часі. Тут ми також зберігаємо наш список друзів у базі даних SQLite, орієнтованій на користувача. Сервіс розмови (довготривалий предмет) Кожна окрема розмова між двома користувачами має власний DO-інстанс. Його єдина відповідальність — зберігати повідомлення, надсилати сповіщення (через сокети) при надсилання нових повідомлень і надсилати сповіщення, коли користувач починає друкувати, щоб ми могли побачити «Особа друкує...» Коротко; Створювати додатки для розваги заради ностальгічних дитячих спогадів — це... Того варте.