Comments 18
Там присутствует и не валидный html и названия топиков шифруются через AES (якобы защита от ботов) и всякое прочее. В общем минус вам за парсинг регулярками.
Слишком толсто.
И пока пользователь ее заливает, 2 часа этот гигабайт серверной памяти принадлежит только ему?
Я не в курсе, какой из стеков вы используете. Если там нет настройки Request Timeout / Max Request Length / Content Size или что-то подобного, и все настроено так, чтобы принимать реквесты любого размера и длительности, и для вашего приложения это действительно проблема, то я предлагаю вам этот стек поменять на тот, в котором это все есть.
И да, расскажите как это сделать, так как файл (а точнее запрос) начинает записываться на диск еще на стадии декодинга запроса сервером. И никакая бизнес-логика не запускается, пока пользователь свой гигабайт не загрузит (ну, во времена CGI запускалась).
Прошу меня простить, но я не понял в чем заключается вопрос.
Возьмем для примера PHP, хотя описанное справедливо и для 99% остальных языков и технологий. Допустим, мы хотим позволить пользователю загружать картинки на сайт, для этого делаем формочку с полем типа file и…Так работает браузер и HTML, а серверные языки тут не при чём. Реализовать загрузку на файла с прогрессбаром можно уже очень много лет разными способами.
Всё, что вы описали далее, это обычное поведение. Его можно изменить. Например есть такие модули, как nginx-upload-module. И вообще, это скорее относится к протоколу HTTP, чем к языкам, которые его обслуживают.
1) При загрузке файла потоком, его можно никуда не сохранять! Он приходит потоком, который можно и остановить и оборвать, при этом еще раз — это не файл в /tmp, а поток непосредственно с клиентское приложение. Подозреваю, в PHP тоже можно получить именно поток, а не ссылку на уже загруженный файл, просто научитесь его готовить.
2) Про кеширование. Используйте правильные шаблонизаторы, которые умеют кешировать кусочки, а не всю страницу, и если данные куска страницы не поменялись, то он просто возьмется из кеша уже отрендеренный. И да, всю страницу тоже можно. И да, PHP тоже так умеет, просто научитесь его готовить.
3) Какое такое API? Вы о чем? Верстка на всем, что движется доступна в любом современном CSS фреймворке, начиная с bootstrap и заканчивая w3css, просто научитесь его готовить.
В общем — Вам двойка за подготовку домашнего задания.
Когда надо было уместить хотя бы стартовую страницу сайта со всем её содержимым в 20-30 кб? Когда приходилось генерировать на сервере все страницы в десятке вариантов, ибо клиенты были разными, очень разными и dhtml почти никто не умел? Когда… много чего ещё можно перечислить такого, после чего современный веб — сказка наяву.
Автор, похоже, попросту не разобрался с технологиями и у него болит. Но может уже пора повзрослеть? Выйти из детсадовского возраста? (Это отсылка к известному тесту про скамейку, краткое изложение вот тут: bash.im/quote/418579)
Как уже было описано ранее — все «проблемы» или не проблемы или имеют решение. Я не скажу за php, но на .net уж точно :) И файлы без сохранения на диск и с прогрессбаром, и даже с проверкой содержимого до полной загрузки. И кэш на любой вкус и цвет, работающий ровно тогда, когда это надо. И API с внятной структурой и встроенной документацией. Что уж говорить про возможность универсализировано смаппить ajax запрос на запрос к БД, с валидацией, да через кэш, и с прозрачной проверкой прав пользователя…
А может автор так странно изливает недовольство заполонившими веб рукожопами, к которым он сам себя не относит? Тогда почему бы прямо так не сказать?
Содержание всех разделов больше похоже на легкий стёб на тему «Обо всем, что слышал». Если бы в конце были выводы, могла получиться (плохая или хорошая) статья. А так, увы…
Зачем глупости писать о 99% не пользуйте просто допотопные технологии.
Загрузка файлов:
Даже в PHP это уже порешали давно. Нет, не CGI едины. Да, и на PHP можно поднять демона и слушать порт, даже кодеки для сообщений уже написаны. Не хотите поднимать демона и порт слушать, хотите древний-добрый PHP-FPM — да пожалуйста. Просто не пользуйте $_FILES. Просто читайте php://input как поток, определяйте нежелательные файлы (например когда контент не соответствует заголовку) и не принимайте их. А ещё лучше — выбросьте ваш PHP и поставьте Netty. Не надо сохранять что не попадя на диск.
Кеш:
В чём пробема "учитывая современные реалии, когда на странице много динамических элементов"? Технике кеширования и включения частей страницы на Nginx уже лет и лет.
В чём проблема GET /somepage.html?someshit=12345? Кешируйте определённый location в Nginx (если базовых возможностей мало — OpenResty в помощь) и не будет никто при сгенерённом кеше попадать на приложение тем самым тратя драгоценный ресурс.
Далее: "при генерации страницы можно сделать 500 запросов к мемкешеду и за это ничего не будет" — вот это уже ну совсем ни в какие ворота не лезет. Во-первых — не нужно путать кеширование внутри приложения и кеширование страницы/области страницы целиком. Они для разного предназначены и использовать одно вместо другого — нельзя. Во-вторых — любое хождение за данными через порт (особенно синхронное что характерно для memcached через PHP) — очень долго больно и дорого. Не говоря уже о 500 запросах. С memcached тоже нужно уметь работать и, например, предагрегировать данные при сохранении или другие техники применять в зависимости от задачи. Нельзя просто тянуть значение по ключу.
Интерфейсы:
В чём проблема с API? Выучите заголовок Accept уже в конце концов. Читайте Content-type при ответе и игнорируйте то что вы не Accept'ите. Кривое API — не проблема API в целом. Это проблема конкретных поставщиков конкретных данных. Не нравится этот поставщик — выбирайте другого. Благо рынок широк и на рынке найдутся приложения удовлетворяющие форматам если сами данные добыть можно.
"А иногда и вообще, выдачу всех ключей приостанавливают, а обслуживание прекращают, даже на коммерческой основе, такое тоже бывает. Ну и зачем такое API? Мне проще стянуть страничку и распарсить ее регулярками, чем терпеть такое безобразие. Потому я почти никогда не пользуюсь этими вашими API" — то же самое может и со страничкой случиться. Она просто в один прекрасный момент сранет отдавать 404 или 50*. Тоже не проблема API как такового. Да и чем страничка не API если её всё равно регулярками парсить? JSON и XML да какой угодно текст вне зависимости от формата можно регулярками парсить. В чём проблема то?
За что я не люблю современный веб