#Vercel

Сьогодні склав цікавий пазл та зробив для блогу збір аналітики по RSS. Колись для цього використовував різні проксі, наприклад, Feedburner. Та вже декілька років я віддаю перевагу RSS стрічці на власному домені, разом з самим блогом. А блог в мене давно розміщений на різних статичних хостингах, останнім часом — на Vercel. Все чудово, але статистику по відвідуваннях стрічок він не надасть. Не дасть її й безплатний план Cloudflare. Так що нарешті додав аналітику власними руками. Ну, точніше, збирає аналітику Plausible, а мені залишається тільки відправляти туди відповідні події.

Щоб відстежити запити до RSS стрічок, я підміняю їх на запити до хмарної функції. Для цього у Vercel є правила перезапису адрес. Функції можна писати прямо на TypeScript. У іншому це звичайні обробники за стандартом ExpressJS. Вони мають доступ до всіх файлів зі збірки проєкту. Звідти функція забирає RSS, згенерований Hugo, та віддає споживачу. Ну й ще робить запит до API Plausible. Класно, що весь проєкт разом можна запускати локально, командою vercel dev.

Нюанс: правило перезапису не може мати таку саму адресу, як і файл зі збірки; точніше, файли мають пріоритет. Тому, щоб перезаписати RSS стрічки, потрібно було перенести їх в інше місце; я приписав до них суфікс-розширення. Ще нюанс: функція не може перевищувати 50 МБ, а за замовчуванням у пакет потрапляють абсолютно всі файли. Проте опцією excludeFiles можна прибрати зайві; я просто прибрав світлини.

Далі, щоб зареєструвати подію, потрібно викликати API Plausible. Раніше цей API був напівприватним, прихованим, а тепер доступний офіційно. Ми його вже використовуємо для аналітики додатка iOS. У випадку з RSS, достатньо одного типу події, з відповідними властивостями. Це, звісно, агент браузера та IP користувача, а також URL стрічки (бо в мене їх декілька).

Тут теж нюанс: заголовок X-Forwarded-For, що містить IP користувача, не передається з CloudFlare через Vercel. Тобто Vercel його затиратиме. Але немає проблем, бо CloudFlare дублює заголовок своїм нестандартним CF-Connecting-IP, а він передається нормально.

Нарешті, агент браузера я також передаю як власну властивість події, тому що мені здається, що великі агрегатори RSS на кшталт Feedly можуть передавати в рядку агента внутрішню кількість підписників. Але це ще подивимось.

Отак. Здається, все просто, але це не враховуючи нюансів.

Нарешті, вчора WeightPlot пішов в маси: ось сторінка в AppStore (готовий поділитися промокодом). Щоб це здійснилось, вчора розробляв сайт.

Бо, як писав минулого разу, сайт мусить бути, це обовʼязкова вимога до всіх застосунків в App Store. Тож, окрім розробника, доведеться попрацювати маркетологом.

Спочатку хотів зробити сайт чисто на HTML. Проте, згадав, що я збираюся накидати туди хоч декілька статей — для розʼяснення та для SEO - то все ж взяв рідний Hugo та зробив на ньому.

Щоб впоратись за день, відшукав готову тему. Зазвичай не люблю брати готові теми, але, оскільки сайт грає другу скрипку, то це має повний сенс. Обрав тему Paige. Вона побудована на Bootstrap, та тому дозволила доробити все, що потрібно — наприклад, табличку функцій.

Проблеми зʼявилися з деплоєм на Vercel. Річ у тім, що теми на Hugo тепер встановлюються як… модулі Go. Що, як на мене, дуже дивно. А на Vercel взагалі з цими модулями відбувається щось дивно, та я за кілька годин так і не зрозумів, що. На щастя, є тупе, але ефективне рішення: будувати сайт локально, комітити, та залишити на Vercel тільки хостинг.

Взагалі, цінуйте роботу відділу маркетингу. Бо без нього все, що інженери наробили, просто нікому буде невідомо та не потрібно.

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

Нюанси починаються з правил перенаправлення. Будь-який сайт стикається рано чи пізно зі зміною адрес. Будь-який чемний сайт підтримуватиме старі адреси через механізм перенаправлень. Він всюди налаштовується за власними правилами — ось, наприклад, Vercel. А ось Cloudflare Pages. Все так, та не зовсім. Доведеться вручну коригувати та перевіряти. Коли перенаправлень сотні (так трапляється після реструктуризації сайту) - це вже ціла пригода.

Деякі хостинги підтримують адреси без слеша на кінці, а інші — ні. Технічно, ніби присутність слеша “правильніша”, оскільки ми віддаємо index.html для директорії — а не файл без розширення. Але те, що адреса сторінки виглядає як директорія, це принаймні дивно. Раніше мене це обурювало, зараз вже змирився та зробив все зі слешами (Звісно, через перенаправлення.) Також не всі хостинги готові взагалі показати index.html (бо це вже не просто “віддавати файли”, авжеж?)

Характер відвантаження файлів на хостинг теж відрізняється. Ось на Vercel примусово потрібно мати репозиторій на GitHub. Що гарно, поки в тебе немає величезних світлин або взагалі — завантажень на гігабайти. На Cloudflare Pages можна відвантажити на пряму, але не можна замінити єдиний файл — тільки все разом. На AWS S3 можна просто оновити окремі файли.

Нарешті, хоч і здається, що статичний хостинг — найшвидше, що може бути в вебі, насправді провайдери, особливо безплатні, не гарантують швидкості. В мене Ahrefs не раз скаржився на повільні сторінки на Vercel. А найшвидше сайт працював на власному сервері — але ж то незрівнянно складніше в підтримці. А ще, на власному сервері буде максимальна кількість особливих умов, та з нього найскладніше буде зʼїхати.

Хотілося закінчити на рекомендації конкретного хостингу, але її в мене немає. Хіба можу порадити не вигадувати власні обмеження (як я зі слешами), а триматися ближче до базової парадигми “сторінка = файл”.

Давно вже обмірковую цей переїзд. Зараз мій сайт і так доступний через Cloudflare, але розміщений на Vercel. Хочеться консолідувати майно; та можливо навіть почати платити за Cloudflare гроші — бо там багато є гарного по аналітиці та по захисту. (Але базовий статичний хостинг що там, що там безплатний.) До Vercel в мене найбільше нарікання — що час від часу Ahrefs скаржиться на повільність сторінок, що для статичного сайту дуже підозріло.

Сьогодні спробував перенести. Власне, сам зміст майже тривіально переноситься, і це сучасне досягнення. Обидва сервіси забирають сайт з GitHub, та обидва здатні викликати Hugo для збірки. Тобто майже без налаштувань зʼявляється нова копія. Єдине, що вилізло — це на CF Pages встановлений Yarn 3 та він чомусь не погоджувався з моїм Yarn 1. Але, оновити собі Yarn справа недовга.

(До речі, також всі схожі сервіси використовують спочатку тестові домени, тому підготувати переїзд можна спокійно на тестовому, а потім перемкнути DNS, коли вже буде впевненість.)

З несподіваного: у CF Pages є обмеження на розмір файлу — до 25 Мб. В мене є пара архівів, що його перебільшують. Але їх можна перенести кудись в S3 чи на його аналог - Cloudflare R2.

А ось де справжня проблема, так це з перенаправленнями. В мене після змін архітектури залишився список з близько 1000 застарілих шляхів. В Cloudflare є зручний файл _redirects, але вони надто примітивні для моїх потреб. Наприклад, у Vercel можна написати /page(/?), а у CF тільки двома правилами /page та /page/. Так я починаю упиратися в обмеження на кількість перенаправлень (2000 + 100 динамічних.)

В мене очевидно надлишковий список, можливо, доведеться його обрізати до реально потрібних. Або взагалі почати з порожнього та спостерігати за 404-ми. (Можна було б, за всі ці роки вже зібрати “живий” список старих посилань, але кому він був потрібний?)

Є ще варіант замінити 404-ту на функцію та обробляти перенаправлення там. Безплатно доступні 100 тисяч викликів функцій, вистачить з головою. Функції в Cloudflare потужні, там і база даних є, тож цікаво випробувати.