Посоветуйте, на чем наваять веб для обработки данных (документов)

Желательно максимально агностично относительно видов и версий браузеров

Фронтэнд на HTML с декорированием CSS в меру твоей испорченности. Бэкэнд на чём угодно. Раз знаешь python и часть кода уже на python то и бери python. В стандартной библиотеке есть модуль http.server, в принципе и его может хватить

На фронте React. На бэке golang. Деплоить всё в кубернетес.

Как-то недостааточно хайлоадно и прогрессивно, чувствуется что надо ещё чего-то добавить

Чем из перечисленного организовывается загрузка/выгрузка? http.server?

rust не хватает, очевидно

Flask+ python раз уж вы его упомянули

http.server (ты не поверишь) реализует http server. Браузер может послать файлы на http сервер POST запросом. Достаточно трёх html тэгов (form, input и button). Дальше работа для твоего кода, с помощью http.server, принять посланный файл, положить его на диск, обработать его скриптами и отправить обратно. Если обработка быстрая то можно в один запрос всё сделать (вернуть модифицированный файл как результат POST запроса, не уверен что это хорошая практика правда)

jQuery.

а что-то минимальное, что позволит сделать то, что нужно, в чем я разберусь и смогу без проблем и чтения тонны чейнджлогов раз в год подкорректировать

FastAPI и «работать» через swagger ui.

Плюсы:

• вообще не надо думать о фронте
• быстро и легко
• основной кодинг - подключение своих скриптов

Минусы:

• скорее всего одна basic- авторизация на всех

На фронте React. На бэке golang. Деплоить всё в кубернетес.

Кубы доллжны жить строго в виртуалке, иначе никак

На сервер загружается документ(ы), обрабатывается и тут же (без доп. ссылок и подтверждений) отдается клиенту в обработанном виде.

в какой-то момент (из-за нагрузки или еще чего) время обработки документа возрастает, клиенты отваливаются по таймауту.

боль, тоска, уныние, сожаления о принятых когда-то решениях.

В зависимости от требований к суммарному объему документов загружаемых за раз и лимитов на сервере, может потребоваться реализовать загрузку документов чанками с последующей сборкой на сервере исходных файлов из кусочков

Mongo же и грузить туда файлы.

Кубы должны жить в облаке. А что там в облаке - небожителям видней.

Я думаю конкретно в этом случае можно будет переписать легко это дело если вдруг упрётся. Там всего скрипта строк на 20 питона

Mongo, Rust… мелко мылите, не современно. Смотреть на вас противно, как динозавры на космической станции. Тут нужны serverless архитектура с edge computing. Если так уж хочется то можно и на Rust с WebAssembly

Я бы взял python + fastapi. Загрузка файлов там вроде из коробки есть, асинхронно запустить процесс для обработки одна строчка. Можно даже nginx перед ним не ставить.

асинхронно запустить процесс для обработки

FastAPI через ASGI работает (uvicorn), там если и нужна асинхронность, то только для какой-то уж сложной обработки «внутри» эндпойнта, которая вряд ли укладывается в указанную ТС задачу.

Напиши в личку если бюджет есть, у меня много таких проектов. Могу сделать.

Со скриптами все просто, это python и bash

Если есть петон то обязательно есть библиотеки, скорее всего - системные. Врядли у тебя дошло до virtualenv, поэтому это первая проблема.

а что-то минимальное, что позволит сделать то, что нужно,

Ну тогда начни с изучения того что такое multipart, как происходит передача через POST-запрос бинарного файла - уже тут можно охренеть от сложности. Поэтому для реализации наколенного HTTP-сервера для GET запросов хватит 300 строк кода а для POST и multipart - уже 3000.

bottle.py

https://learnbchs.org/

Dancer (Perl) + bootstrap

CGI на языке C с использованием библиотеки kcgi

Смотря что такое документ. Если docx/xslx - лучше сразу оформить подписку на mso, нервы целее будут. Если pdf - смотря какая обработка, если странички порезать это одно, если формы/подписи редактировать то это писец.

Спасибо тебе друг, это настолько запредельный уровень скотства что я обязательно сделаю на него разбор.

Санитары должны звать своих героев.

Скотства? Что не так? Можете объяснить по пунктам? У нас все таки конструктивный диалог

Ну я даже не знаю: CGI в 21м веке в chroot на форке Apache 1.3

OpenBSD’s httpd, httpd(8), inherits from relayd(8) and was recently imported into OpenBSD after an aborted attempt to use nginx instead of the legacy Apache1.3.

Читаю и плачу - вот же у людей проблемы 21века в жизни-то.

serverless архитектура с edge computing

И чтобы работало на кластере арендных электросамокатов.

Openhttpd - не форк Apache. Вы даже цитату, которую вы выписали не прочитали.

CGI имеет преймущество над fastcgi и standalone server: надёжность и простота.

А вы на чем разрабатываете веб сайты?

Openhttpd - не форк Apache. Вы даже цитату, которую вы выписали не прочитали.

Если честно не очень люблю разбираться в родословной - кто именно кого форкнул и зачем. Но вот например абацем выше:

The Apache browser has two basic flavours on BSD: the current version available from the Apache project (Apache2) and the legacy version forked by OpenBSD (Apache1.3).

Я поднимал этот httpd в опенке, там действительно конфиги от старого апача, так что думал Тео его форкнул и дорабатывает.

CGI имеет преймущество над fastcgi и standalone server: надёжность и простота.

Нафиг такая надежность не нужна, которая аж целый процесс порождает на входящий запрос от пользователя. Форк это дорого, порождение процессов с последующим управлением - дорого и не всегда предсказуемо.

Поэтому от концепции CGI и ушли сначала в модули PHP (которые по-факту работали с пулом потоков и уж точно не делали форк) а затем в полностью виртуальные окружения с пулами потоков обработки, где обработчик стал частью самого приложения (Node.js да)

А вы на чем разрабатываете веб сайты?

На всем, начиная с Перла и PHP и до джавы, .NET, петона и Node.js.

Но ТС ведь не сайт нужен, почему-то все тут промолчали про фоновую обработку, которая собственно и делает работу. А это важная часть.

Спасибо за ответ. Изучу вопрос подробней

Я конечно понимаю что кушать все хотят и ипотека сама себя не заплатит, но ведь и совесть иметь надо. Ты сейчас пытаешься убедить ТСа что простейшая задачка на десяток другой строк кода (про которую ему уже все объяснили и он вроде даже понял) это ниипаца рокетсайнс который надо поручить профессионалу (тебе)

Но ТС ведь не сайт нужен, почему-то все тут промолчали про фоновую обработку, которая собственно и делает работу. А это важная часть.

Так скрипты у него вроде как уже написаны. А даже если и нет, про них он ничего не спрашивал. Остаётся только, прости хоспади, «сайт» на полтора эндпоинта

Ты сейчас пытаешься убедить ТСа

Даже не начинал, просто озвучил что такой вариант есть.

простейшая задачка на десяток другой строк кода

Не поверишь какое количество проектов уезжали в голубые дали по срокам и бюджету из-за такого подхода.

Так скрипты у него вроде как уже написаны.

Да ты что? А не думал как например загруженный файл попадет на вход скрипту, который еще и работает в фоне? А как результат работы обратно в веб-интерфейс прокинуть?

А даже если и нет, про них он ничего не спрашивал.

Не поверишь, но именно так и происходит наверное всех заказчиков на всех проектах - обязательно всплывает некий темный подвал с заколоченной дверью и надписью «не входить», который подается как «уже реализованный функционал».

Остаётся только, прости хоспади, «сайт» на полтора эндпоинта

Полтора эндпойнта? А что насчет авторизации, например? Или предлагаешь в век победивших роботов, скрапинга и скама такую штутку публично выставлять?

Да ты что? А не думал как например загруженный файл попадет на вход скрипту, который еще и работает в фоне? А как результат работы обратно в веб-интерфейс прокинуть?

Как-как, через argv и файловую систему. Мы тут прикалываемся про микросервисы и edge computing, а ты не полном серьёзе пытаешься напугать ТСа проблемами хайлоада. Когда и если его поделка упрётся в узкие места архитектуры, тогда и будет их расшивать. Благо размер скрипта достаточно мал чтобы его можно было без проблем переписать на раст. Преждевременная оптимизация так же плоха как преждевременная эякуляция

Или предлагаешь в век победивших роботов, скрапинга и скама..

Чё там скрапить? Кого там скамить? Статическую страничку скрапить или результат POSTа? Рейтлимит nginx-ом добавить на всякий случай и ОК. Дорастёт ТС до того что его будут дудосить по взрослому, тогда и будет разбираться. А если уже дорос, и задаёт такие вопросы, то так ему и надо

Как-как, через argv и файловую систему.

Дай тебе боже здоровья и долгих лет, пока на свете есть такие как ты - у меня всегда будет работа.

Мы тут прикалываемся про микросервисы и edge computing,

Ну ну, примерно как папуасы над самолетом в небе. Папуасам весело а самолету пофиг.

а ты не полном серьёзе пытаешься напугать ТСа проблемами хайлоада. Когда и если его поделка упрётся в узкие места архитектуры, тогда и будет их расшивать.

То что я написал это самая банальная эксплуатация, это вопросы которые задают сисадмины разработчикам при внедрении.

Чтобы с тобой или с ТС обсуждать тут архитектуру, вы для начала чего-то в ней должны понимать. Чего я не заметил.

Чё там скрапить? Кого там скамить?

Проведи простой эксперимент: выстави в интернет статическую страничку с формой отправки, без капчи и авторизации. Аналог гостевой книги. Где-то через пару дней будешь получать автоматические запросы к ней.

Будет валиться спам с рекламой, будут стучаться какие-то отбитые роботы в поисках уязвимостей. Сейчас это все делается массово, через ботнеты, которые тупо сканируют подсети и хостеров и провайдеров и диапазоны компаний и госструктур. Массово и постоянно.

Будет валиться спам с рекламой, будут стучаться какие-то отбитые роботы в поисках уязвимостей. Сейчас это все делается массово, через ботнеты, которые тупо сканируют подсети и хостеров и провайдеров и диапазоны компаний и госструктур. Массово и постоянно.

И чё? Ну будут пытаться сабмитить форму, чё с того? Во-первых такие спамеры смотрят не текстовые поля, файлы они обычно заливать не пытаются. А если и попытаются, то что? Ну обработает их скрипт, ну вернёт результат. Рейтлимит не даст перегрузить сервер. Когда рейтлимита и защиты Неуловимого Джо перестанет хватать, ТС придёт сюда же или на другой форум и ему объяснят что http.server не то чтобы самый лучший вариант, и что временную ссылку лучше всё-таки добавить чтобы браузер по таймауту не отваливался если обработка тормозит, и что запускать скрипт на каждый запрос не лучшая идея, а лучше засунуть обработку в отдельный демон (можно даже назвать это микросервисом) и так далее и тому подобное. Но пока ТС спрашивает про то как ему сделать HTTP аналог хэлоуволда, про это ему и отвечаем

Ну понятно, очередной теоретик.

Вообщем дальше дискутировать смысла нет, повзрослеешь, школу закончишь - приходи.

А пока добро пожаловать в игнор (спасибо авторам ЛОРа за эту фичу).

Вообщем дальше дискутировать смысла нет, повзрослеешь, школу закончишь - приходи.

Грустно глядя на прядь седых волос ну ладно

На личном опыте могу сказать, что боты реально спамят даже неуловимых джо. Только купил VPS, сразу начали боты подбирать пароли, слать мусор в формы и т.д. Без капчи в вебе не выжить

Без капчи в вебе не выжить

Вот теперь про капчу.

Казалось бы все просто - подключил внешний бесплатный сервис и все, спи спокойно.

Но в нынешних реалиях хер его знает что с этим сервисом будет завтра: авторы могут взять и заблокировать сервис для вашей компании или целой страны. Или РКН в охотничьем угаре забанит, что тоже непредсказуемо.

А поднимать свою капчу - внезапно окажется что это не так просто. И вот вы уже сидите и ковыряете сборку какого-нибудь libpng, от которого зависит генерация этой картинки капчи и который сломался при обновлении.

Говорю же: время наколенных решений прошло, теперь куда не плюнь - везде сложности и проблемы.

static html/css + python fastapi

https://habr.com/ru/articles/710376/

Блин, это же не форма для коментов или там заявок каких-то. Ну засабмитит бот твою форму, хотя бы даже догадается прислать файл с вирусом или спамом, ну получит ответ и чё с того? Отожрёт сколько-то ресурсов сервера, не велика беда. Надо не просто «думать о безопасности». Надо понимать модель угроз. Не модель угроз сайта в интернете вообще, а модель угроз конкретно твоего проекта

Статикой HTML + CSS, и nginx. Даже ещё сервака не нужно, файлы по cron обрабатывать, пользователю результат по линку 404 или файл результат. Можно добавить Server Sent Events, как прогресс.