ИИтог

Разработчик выпустил коммерческий веб-сервис на C и CGI, без фреймворков

инструментыРедакция ИИтогHacker News🔥56Рейтинг ИИтог56Влияние20Новизна30Релевантность65Неожиданность50Участники5Достоверность70

В 1994 году динамический сайт означал программу на C в каталоге cgi-bin, которую Apache запускал на каждый запрос. Автор текста пишет, что спустя тридцать два года выпустил коммерческий веб-продукт на фундаментально той же технологии. Это marketyour.games: сервис с учётными записями пользователей, панелью поиска для создателей контента, папками для их организации, платежами через Stripe и транзакционными письмами через Postmark. Сервис следует принципу прогрессивного улучшения и не требует JavaScript. Центральный тезис автора: упадок CGI был оправдан в 2004 году, но в 2026-м это уже не так, а современное веб-приложение вполне можно написать на C.

Стек называется BCHS: OpenBSD, C, httpd и SQLite. Фреймворка нет: программа на C читает переменные окружения CGI и формирует ответ. Шаблонизатора нет: C-код выводит HTML напрямую. Отдельного сервера базы данных нет: файл SQLite открывается через C API. Контейнера нет: статически собранный бинарник кладут в папку. Всё приложение, каталог C-файлов и Makefile. Зависимостей три, но реальных зависимостей сборки две, libcurl и libsodium; обе включены в проект (vendored) и собираются вместе с ним. Чистая сборка занимает несколько секунд, пересборка, менее полусекунды. Вместо раздачи статических файлов httpd направляет весь трафик на CGI-бинарник: все ресурсы вкомпилированы в исполняемый файл и отдаются из памяти.

Эксплуатация устроена так: каждый запрос порождает новый процесс, поэтому выкладка новой версии, это замена одного файла, без перезапуска сервера и простоя. OpenBSD, по словам автора, даёт разумные настройки по умолчанию и инструменты pledge и unveil для защиты программы на C, а httpd по умолчанию работает из chroot, так что CGI-бинарник изолирован в своём уголке файловой системы. Отладка тоже проще: приложение, обычная программа, которую можно запустить из оболочки, подать ей запрос, смотреть stderr и пройтись по ней в gdb. Автор сравнивает CGI с serverless-архитектурой: супервизор вызывает код на каждый запрос, передаёт набор переменных окружения и забирает результат.

Отдельный довод, зависимости. В типичных стеках граф зависимостей разрастается: одна-две прямые тянут сотни косвенных. Цепочка поставок автора, компилятор C и три библиотеки; чтобы её скомпрометировать, пришлось бы взломать libcurl, за которым следит весь интернет, а не пакет с одиннадцатью скачиваниями в неделю и владельцем, ушедшим в 2019 году. Редактор у автора, классический Vim без плагинов (без LSP, автодополнения, форматтеров и ИИ): стек достаточно прост для обычного редактора. Когда инструменты нужны, под рукой sanitizers, valgrind, gdb, ctags, cscope. Писать весь фронтенд на C оказалось не так мучительно, как автор опасался. Вместо Postgres с серверным процессом и частыми обновлениями, SQLite без процесса и настройки.

Есть и минусы: CGI, это лишь интерфейс между веб-сервером и приложением, из коробки почти ничего нет, и нужные утилиты приходится писать самому. Автор сделал свои в одном заголовочном файле cgi.h, но не уверен, что это правильное решение: библиотеки вроде kcgi существуют, но их использование означает принять их API и модель безопасности. Автор хотел бы видеть набор общих утилит, которые можно подключать как библиотеки stb, и допускает, что опубликует cgi.h как начало. Итог: большинство причин, по которым от CGI отказались в начале 2000-х, сегодня не работают, форк процесса далеко не так дорог, как раньше, ведь современные ядра его сильно оптимизируют, а если цена форка станет проблемой, FastCGI, достаточно простой апгрейд. По словам автора, в этом стеке меньше подвижных частей, чем в чём-либо, что он выпускал раньше, и он будет брать его снова.

Ключевые факты

  • Автор выпустил коммерческий веб-продукт marketyour.games целиком на C и раздаёт его через CGI; стек назван BCHS: OpenBSD, C, httpd, SQLite.
  • Сервис современный по функциям: учётные записи, панель поиска, папки, платежи через Stripe, письма через Postmark, работа без JavaScript.
  • Один бинарник, файл SQLite и три библиотеки (реальных зависимостей сборки две: libcurl и libsodium, обе вендорены); чистая сборка занимает несколько секунд, пересборка, менее полусекунды.
  • Каждый запрос, новый процесс, выкладка, замена одного файла без простоя; OpenBSD даёт pledge и unveil, httpd работает из chroot.
  • Главная цена выбора, собственные утилиты для CGI: автор написал cgi.h, но не уверен, что это лучшее решение.

Почему это важно

Материал не про ИИ, но показательно спорит с привычной картиной веба: автор утверждает, что технология 1990-х, которую давно считали устаревшей, в 2026 году пригодна для настоящего коммерческого продукта. Довод строится на том, что причины отказа от CGI в начале 2000-х потеряли силу: форк процесса стал дешевле, спецификация CGI 1.1 с 2004 года не менялась, а число движущихся частей минимально. Отдельный акцент, на угрозу цепочке поставок: автор прямо связывает минимум зависимостей с ростом числа автономных агентов и регулярными атаками на репозитории пакетов.

Кому это важно

Прежде всего разработчикам, которых утомили разросшиеся стеки с пакетными менеджерами и сотнями косвенных зависимостей, и тем, кто выбирает простой способ вести небольшой коммерческий продукт в одиночку. Интересен он и тем, кто работает на C или хочет понять, как устроен CGI: по словам автора, если понимаешь HTTP, то понимаешь и CGI, а знания эти не стареют.

Как это применить

Автор описывает конкретную схему. Приложение, программа на C, которая читает переменные окружения CGI и пишет HTML напрямую; база, файл SQLite, открываемый через C API; на выходе статически собранный бинарник. httpd на OpenBSD направляет весь трафик на этот бинарник, а ресурсы вкомпилированы в него и отдаются из памяти. Обновление, замена одного файла. Для отладки подойдут gdb, valgrind, sanitizers, ctags и cscope; Vim поддерживает ctags и cscope и имеет графический интерфейс к gdb (:h Termdebug). Если цена форка когда-нибудь станет проблемой, автор советует перейти на FastCGI. Для типовых задач CGI придётся либо писать свои утилиты, либо взять библиотеку вроде kcgi, приняв её API и модель безопасности.

Можно ли доверять

Это личный рассказ автора о собственном продукте, а не независимая проверка. Он убедителен как свидетельство «так сделано и работает», но в тексте нет замеров задержки, пропускной способности или стоимости форка: утверждение о дешёвом форке качественное. Нет и данных о трафике, числе пользователей или выручке marketyour.games, не упомянут аудит безопасности. Автор в тексте не назван, дата публикации не указана. Оценки вроде «меньше подвижных частей, чем в чём-либо раньше», субъективные.

Риски и подводные камни

По признанию самого автора, CGI даёт из коробки очень мало: нужные утилиты нужно писать самому, и собственный cgi.h он не считает бесспорным решением. Готовые библиотеки вроде kcgi требуют принять их API и модель безопасности. Выкладка через замену файла и отсутствие простоя опираются на запуск нового процесса на каждый запрос, и именно стоимость форка автор называет возможной проблемой, для которой есть путь к FastCGI, хотя самому ему он не понадобился. Надёжность защиты в тексте связана с возможностями OpenBSD (pledge, unveil, chroot в httpd): это описание конкретного окружения автора, а не общий рецепт.

«CGI, это serverless за вычетом вендора (и неожиданных счетов).»

— автор текста