nginx там и так стоит перед сервисом (если мы про qrenco.de говорим).Я немножко о другом хотел сказать,
я сейчас не говорю о сервисе qrenco.de как таковом, это просто незначительный частный случай, но он интересен поскольку он позволяет сделать наши рассуждения из абстрактных более конкретным.
Вы предложили заменить полноценную имплементацию HTTP-протокола (которая есть в nginx и в стоящим за ним werkzeug) его простой имплементацией поверх xinetd, по большому счёту просто заменить чистым TCP.
Какие минусы и плюсы имеет это решение?
1. (+) Простота, надёжность, отсутствие ошибок, скорость
2. (-) Экспоненциальный рост сложности, изобретение велосипеда (HTTP) при появлении новых требований; требование знания дополнительной информации (пара "хост:порт" в случае TCP, против "хост" в случае HTTP).
То есть, если нас не интересуют дополнительные приятные возможности HTTP, мы вполне можем обойтись одним TCP (xinetd) как простым, надёжным и быстрым решением, но как только мы хотим дополнительных возможностей, мы очень быстро приходим к тому, что нам нужно полноценно работать с HTTP (а не сводить работу с ним к работе с "TCP с фиксированным портом").
Какие возможности HTTP я имею в виду?
1. Стандартное кодирование данных (GET + POST);
2. Шифрование из коробки;
3. Заголовки (например, язык и другие; не так важно в данном сервисе, но в других важно);
4. Content-Type ответа (пример с PNG).
Можно ли это всё реализовать на xinetd? Конечно же да. Просто добавить HTTP-враппер вокруг вашего скрипта, который всё это дело правильно распарсит и представит вашему скрипту, но в конечном итоге вы быстро придёте к реализации nginx с помощью xinetd.
Можно ли всё это реализовать на голом TCP (xinetd + netcat), не переходя на уровень HTTP? Да, можно, но в итоге вы начнёте изобретать свой собственный HTTP, не имеющий своей экосистемы (ни клиентов, ни серверов). То есть, лучше, конечно, использовать HTTP.
В целом считаю ваш подход очень здравым (там где он применим, а именно — где входом сервиса является одна только строка, и выходом тоже одна строка).
Я так же полностью согласен с вами в том, что неоправданное усложнение кода (серверной части) бессмысленно и даже очень вредно. Одна строка на шелле всегда лучше одной страницы кода на питоне или программы на Си (за исключением случаев, где важна производительность или есть другие существенные причины).
Так что предлагаю разделить дискуссию на две:
1. (интерфейс) TCP (netcat) против HTTP (curl) при создании консольных сервисов.
2. (имплементация) Кривизна сервиса qrenco.de и его слабые стороны (например: ненужный форк там где можно использовать библиотечный вызов).
Я считаю, что дискуссия по первой теме представляет значительно больший интерес для сообщества чем вторая (там и так всё понятно; простейшая werkzeug/flask обёртка с очевидными плюсами и минусами; хотя и по второй теме может быть интересно — например, как реализовать аналогичный сервис (не урезанную netcat-замену!) средствами nginx + shell).
В общем, очень интересные темы вы поднимаете
