Разработчик запустил коммерческий веб-продукт на C и CGI в 2026 году
A Modern Web App in C
Кори Профитт рассказывает, как создал marketyour.games — коммерческий веб-продукт с аккаунтами, поиском, платежами через Stripe и письмами через Postmark — на чистом C с CGI. Стек BCHS: OpenBSD, C, httpd, SQLite. Один статически слинкованный бинарник, три зависимости, никаких фреймворков и контейнеров. Он объясняет, почему CGI, похороненный в 2000-х, снова актуален, и делится плюсами: минимум цепочки поставок, простая отладка, вся логика в одном файле.
CGI — это serverless, только без вендора (и неожиданных счетов).
- dorongrinstein
Многие инструменты могут достичь того же самого. Я могу написать заметку карандашом, ручкой, мелком и т.д. Открою вам секрет, но никому не говорите: можно написать её и на ассемблере.
- ramses0
Моя любимая малозначительная деталь: у busybox есть встроенная поддержка cgi-bin (и `rclone serve webdav`, кажется, упускает возможность упомянуть это). `https://elixir.bootlin.com/busybox/1.37.0/source/networking/...`
Всё, что упоминается в посте, на 100% правда и хорошо обосновано, особенно с включением pledge/chroot/etc. для сброса привилегий.
Есть два диаметрально противоположных механизма развёртывания:
1) нагромождать башни из слоёв друг на друга, пока вы не запускаете простое `echo "hello world"` поверх docker-контейнера внутри vm на сервере proxmox в составе кластера k8s под гипервизором, работающим на удалённых вычислительных ресурсах...
2) просто запустить `bash -c 'echo "hello world"'` и поставить перед ним CGI (без состояния, один бинарник, бла-бла-бла...)
Взгляните на https://github.com/Domain/bash.cgi ... не то чтобы я предлагаю, что 'bash поверх busybox с использованием cgi-bin' — это "правильная архитектура", скорее попытка проиллюстрировать, что объём кода, который удерживает вас от почти истинной "безфреймворковости", крошечный и легко осмысляемый.
Для некоторых внутренних инструментов, которые я делаю для работы, я склоняюсь к:
some-cmd [--json|--markdown] ...yet-more-args...
Когда вы используете сам процесс и shell-окружение как repl, вы начинаете склоняться к тому, что `[--cgi-bin]` будет "просто" ещё одним типом вывода, а способность (нет: предусмотрительность!) гарантировать, что ваши команды независимы, воспроизводимы и зависят только от своих входных аргументов, ведёт вас прямо к тому, что их можно запускать и в "враждебной" ( […]
- OleksandrC
Для тех, кому интересны странные веб-приложения: я работаю над игровым проектом на C++, где клиент компилируется в WebAssembly с помощью Emscripten, а сервер приложения также реализован на C++ (за nginx).
Это тоже из эпохи до ИИ. Игра в стиле Civ. Движок написан с нуля (включая как 3D-часть, так и всю веб-обработку).
Взгляните: https://statebuilder.com/
- assimpleaspossi
Я основал компанию по веб-разработке 22 года назад после того, как разработал систему онлайн-заказа меню для ресторана, которым владел. Я, а затем и мы, делали практически то же самое, о чём говорится в посте, но использовали fastcgi. Я начал с C, потому что знал C. Это была моя настоящая работа. Всё работало так хорошо, что франшиза купила у меня программное обеспечение — а затем переделала его на всякие Microsoft-решения, и с тех пор проблемы шли одна за другой. Это уже другая история.
Я продолжал делать сайты для других заведений, которым нужен был онлайн-заказ; например, для театральных компаний и ресторанов. Всё на C, fastcgi, FreeBSD, postgresql и h2o-server, потому что он всегда делал то, что мы хотели, не прогибаясь под чужие правила. Это было быстро, и легко было вносить изменения, пока изменения не делались за нас или без нашего согласия. Мы очень преуспели.
- unixholder
Чем глубже погружаешься в сложные веб-технологии и фреймворки, тем очевиднее становится, что простота побеждает.
- benlivengood
Golang также позволяет обслуживать веб-сайт или сервис из одного бинарника. Можно даже избежать линковки с libc, если придерживаться чистого Go (CGO_ENABLED=0), и он поставляется со всеми нужными библиотеками http и tls, чтобы заменить традиционный веб-сервер (nginx, apache, httpd).
Я люблю C и в прошлом писал CGI на C, но не люблю конкурентное программирование на C. Хотя fork и exec могут использовать разделяемый read-only mmap на сегментах .text, .bss и .data потребуют инициализации и копирования; есть неизбежные накладные расходы на запуск, которых избегает многопоточный процесс, а сырые pthreads довольно болезненны. Если всё, что вам нужно, — обслуживать низконагруженный сайт, CGI подойдёт.
Меня больше всего беспокоит, как часто делается резервная копия базы SQLite, потому что в современном мире C-веб-сервер никак не может быть свободен от RCE.
- Levitating
CGI — это здорово. К сожалению, nginx не поддерживает его нативно, в отличие от lighttpd.
Мне нравится этот проект для добавления CGI в nginx: https://github.com/pjincz/nginx-cgi
Есть также способы запускать Rack-приложения напрямую из nginx через passenger[1]. Rack — это CGI-подобный интерфейс для ruby-веб-приложений: https://github.com/rack/rack
Он легко позволяет писать приложения и middleware парой строк на ruby.
[1]: https://www.phusionpassenger.com/documentation/Users%20guide...
- creatonez
CGI-процесс открывает базу данных SQLite на каждый запрос...? Это была бы самая безумная конкуренция за ресурсы.