Именно здесь и начинает свой путь задумка проекта LifeLines – освещать все мировые события в максимально объективном и непредвзятом ключе, давая читателю возможность формировать свою точку зрения на происходящее.
Ясно-понятно, вы и ноду знаете на уровне джуна. Читайте
For a high-traffic website in production, the best way to put compression in place is to implement it at a reverse proxy level (see Use a reverse proxy). In that case, you do not need to use compression middleware. For details on enabling gzip compression in Nginx, see Module ngx_http_gzip_module in the Nginx documentation.
С Go похожая ситуация, ибо насколько бы эффективно это бы не делало приложение (неважно на каком языке) иебсервер это сделает быстрее и без оверхеда. Это best practices.
Кроме того, вы так и не показали хотя бы на пальцах, как обеспечить защиту статики для пользователей, исходя из их полномочий. Полномочий могут быть сотни, вы их в куки не запихаете. Как решать будете?
В куки полномочия, серьезно, еще наверное plaintext? :) Токен и/или сикрет и по нему уже проверять, поразительно что это не очевидно, примеры проверки токена я уже приводил выше.
Т.е. если бы PHP был бы веб-сервером и мог бы делать это эффективно, то можно было бы отдавать файлы прям из PHP-приложения? :)
Вопрос из разряда если бы у бабки было причинное место.
В PHP нет встроенного веб-сервера.
Я вам в самом начале показал, что есть.
PHP не может эффективно отдавать статику.
Так же эффективно как Nginx/Apache - конечно, и не будет никогда т.к. есть вебсерверы специально для этого предназначенные (в который раз я это пишу, в 5-й?).
Да, я считаю, это плохо.
Ваше право.
И не только я, среди наших сеньёров PHP тоже есть такие, кто так считает
В приложении есть методы, один и тот же метод обрабатывает запрос:
GET /some/{some-id}/some-other/{some-other-id}
some-id и some-other-id -- разные, но метод один, и приложение знает что это один метод, и метрики успешных, ошибочных и т.д. запросов собирает для одного метода, не важно это запрос на файл, или АПИ
Nginx ничего этого не знает, с разными параметрами это будут совершенно разные URL для него. Он не может собрать статистику хитов, ошибок, гистограмму выполнения и т.д. по методу.
На nginx эта задача не выполнима.
Все правильно, на Nginx эта задача невыполнима, наверное потому, что это всего лишь вебсервер и его задача просто передать запрос, что собственно и сделаем:
Собираем в приложении статистику хитов, ошибок и чего угодно.
Но PHP файлы не отдают, поэтому всё что можно костылится на nginx-ах.
На PHP не отдают статику т.к. в этом нет никакого смысла, и это делает далеко не только PHP а любой скриптовый и не только язык т.к. это контрпродуктивно. Поэтому node.js, питон, go и многие другие "костылят" это на Nginx и только .NET все прогоняет сквозь себя :)
Более того, сервис на .NET-е используется в одном проекте на Python, выступая в роли API-гейта и статики со сложными политиками доступа к файлам. Новости у меня хорошие, это работает отлично :)
Good for you. Жду ссылку на гитхаб
Ну вот кейс, PHP плохо справляется с отдачей статики.
Я уже не знаю как объяснить еще более доступно... Статику отдает вебсервер, потому что это статика и потому что PHP не вебсервер. И повторюсь, так поступает по озвученым выше причинам далеко не он один, и вэтом нет никакой проблемы от слова совсем. Проблему пытаетесь найти вы, но до сих пор тщетно, поэтому не сдавайтесь, пишите, вы один против всей индустрии веб фреймворков, cms и всего такого :)
Вы можете заниматься софистикой сколько угодно, провоцировать на ответ фразами "вы не ответили на вопрос потому что он не равится" и все в этом духе, не утруждайтесь, правда. Мне ваших 2-х перлов про то, что "нанимать нужно не разработчика со знанием фреймворка, а просто PHP разработчика" и вред конкуренции хватило сполна.
Наличие большого количества конкурирующих фреймворков -- это плохо для индустрии.
Да, я понял, вы просто решили преплюнуть свою прошлую глупость. Я не могу сколько либо серьезно отвечать на такие вбросы, всерьез заявлять, что конкуренция это плохо может либо жирнющий тролль, либо школьник у которого пока отсутствуют ввиду возраста базовые знания об экономике.
GET user/123/service/44/info GET user/333/service/55/info
Для nginx это совершенно разные запросы, которые нельзя консолидировать.
Приложение знает, что это запрос одного и того же метода, но с разными параметрами.
Разница между уровнем и детализации наблюдений -- разная. Это крайне очевидно.
Вы много написали, но не указали самого главного - проблему, собственно из-за этого все что выше лишено смысла.
Это то и значит. Может вы всё остальное приложение в nginx перенесёте? Или что значит "хочу"? )) Значит применять логику при отдаче контента.
Тоже самое, опять читаю это как "хочу" т.к. не раскрыта проблема.
Во-первых, возможности крайне ограничены. И придётся подстраиваться.
Ограничены для чего? Для описаной вами задачи - достаточно.
Во-вторых, это костыли.
Я понял, у вас везде где что-то незнакомое - "костыли". Это модуль для Nginx от самого Nginx(F5). Я так понимаю, что вам там в .NET запихали все и сразу, нужно это или не нужно не спрашивают. Практически во всех хоть сколько-либо серьезных приложения/сервисах для Linux (и не только) используется модульный подход, т.е. при необходимости определенного функционала вы подключаете модуль/библиотеку, а не тащите все в рантайм, чтоб оно расходовало ресурсы зазря.
Генерирование на лету, проблема в том, что файлы начинают отдаваться из PHP, а это уже проблема.
Вижу 2 слова "проблема", но как и выше нет самой проблемы.
Приложение отдаст её или из кеша, или сгенерирует (допустим виде уменьшенной фотки) и положит в кеш. Без всяких костылей и прокладок.
Приложению вообще не нужно ничего ложить самому в кеш, фотка будет там уже после первого запроса. Вот как-то так:
GET /product/123/banner -- отдаём баннер товара, какой именно зависит от региона, правил, да и параметров самого пользователя
Все в томже духе, задача простая и довольно распространенная, если вы думаете, что эффективно с этим справится только .NET - у меня для вас плохие новости :)
Другими словами. Вам не нужно ходить на природу, ведь есть телевизор и National Geographic. Это хоть какой-то выход для человека с ограниченными возможностями.
Ваше невежество можно понять, вы видимо долго и безвылазно сидите на .NET и даже не пытаетесь вникнуть как оно там в других окружениях, а тут еще на конфах бравые докладчики рассказывают что "там" все криво, через костыли и велосипеды а у нас православно и круто.
хочу снимать метрики обращений к статике точно таким же образом, как и к любым другим ендпоинтам -- единый код, единый подход, единая точка наблюдения
А это и так одна точка наблюдения - логи Nginx, что для статики, что для динамики. А если вы хоть сколько-либо претендуете на хайлоад то ваша статика живет на CDN.
хочу рулить отдачей контента программно, в одном месте, а не размазывать по конфигам nginx-а
Что такое "рулить отдачей контента программно"? Конфиг Nginx это не программно? Нужно обоснование, что конкретно вы хотите и какие цели преследуете, а не просто "хочу".
хочу иметь возможность управлять доступом к статике программно, смотреть на юзера и решать, отдавать статику или нет, точно таким же образом, как к любому другому ендпоинту -- единый код, единое место
Nginx + Secure link module
хочу иметь возможность генерировать статику на лету, программно определять как именно, и где хранить, как отдавать
Ну генерируйте на PHP, в чем проблема?
хочу иметь возможность хранить статику как удобно, а пути делать любыми, такими как нужно бизнесу, программно
Rewrite rules
хочу иметь возможность легко и безболезненно менять логику размещения статики, сегодня на диске, завтра в S3, без каких-либо ковыряний конфигурации серверов
Ради бога, деплой конфига того же nginx прям из приложения
Вот собрал я образ с приложением, и ему ничего больше не нужно, он просто работает. С PHP пока так не получается. Приседаний выше крыши.
Ничего страшного, это нормально, имея познания PHP и его инфраструктуры на уровне джуна все кажется сложным, с опытом все прийдет
И, если быть честным, "зачем отдавать PHP статику", а почему бы и нет? Но нет. Понятно, что удобно всегда дать простой ответ: "да вам это не нужно" :)
Для любой задачи должно быть обоснование, а не просто "хочу"
Я вот давно задавался вопросом, а почему из PHP никто не отдаёт файлы, статику? Это максимально перекладывается на внешний веб-сервер, или внешние микро-сервисы.
Попробуйте задаться другим вопросом. Зачем из PHP отдавать статику?
Вот собственно, я почему и задаюсь вопросом. Я вижу как с этим всем больно, буквально на каждом шагу в PHP.
В чем боль то? Или это что-то ваше личное на уровне ощущений и поэтому вы это не можете описать?
Это и значит, что в php нет своего веб-сервера. Значит для запуска веб-приложения в продакшене нужно что-то ещё. И это не очень хорошо, как показывает практика.
Что в этом плохого? Какая практика, ваша?
Продолжая сравнение с .NET, веб-приложение содержит в себе полноценный веб-сервер, как часть самого приложения. Более того, оно может работать в режиме прокси, ощутимо не уступая в производительности nginx-у.
Веб-сервер как часть самого приложения это минус, как это масштабировать? То есть в каждую ноду с приложением мне тащить кроме него самого еще и веб сервер? Страшно представить, как до сих пор живут без своего веб сервера perl, node.js, go и прочие.
Это неправильное предположение. Не понял, на чём оно базируется.
Базируется оно на том, что я до сих пор не видел ничего хоть отдаленно претендующего на энтерпрайз решение где в качестве микросервиса/модуля для php используется .NET(C#). У вас есть что-то чтоб переубедить?
Например, gRPC Server, без прокладок на Go никак, и в режиме бесконечного полнодуплексного бесконечного стриминга -- нужны очень серьёзные приседания и высокие скилы. Т.е. оно как-то решается, но плохо.
Поддержка OpenTelemetry, в глубочайшей альфе и по сути всё делать надо руками, никакой поддержки прозрачной трассировки. Даже метрики негде хранить, кроме как прикручивать какой-нибудь Redis, а это уже влияние, недопустимое для счётчиков производительности.
Ну не в "глубокой альфе" а в бете, особенно учитывая то, что платформе всего несколько лет и это "непрофильная" для php задача.
Асинхронные IO операции, без удержания рабочих процессов и потоков. Тут всё плохо.
Все там нормально с этим, особенно в последние годы.
Разработка игр, мобильных приложений, десктопных приложений, веб-приложений, работающих в браузере -- нет, от слова совсем.
Вот вы пишете такую чушь а потом удивляетесь, откуда минусы. Игры, мобильные приложения... напомню, что php разрабатывался и продолжает разрабатываться в первую очередь как язык для веб приложений.
Какое-то очередное заблуждение. При чём ультимативное, "все...", "никто..", ну да, ну да. Не понятно на чём основано.
Основано на опыте. Ну и как писал выше - разубедите меня, покажите проекты где с php бок о бок работает хоть с чем-то на .NET.
Если на PHP нет ни одной задачи, которую бы он решал лучше, быстрее или оптимальнее чем на том же .NET, и отвечая риторически на вопрос топика, стоит ли учить PHP?
Учитывая то, что PHP это в первую очередь разработка под WEB - конечно стоит. И очевидно, что решает задачи не хуже .NET, т.к. на данный момент в сфере бэкенд фреймворков он занимает лидирующие позиции, в отличии от .NET доля которого несоизмеримо мала.
Но если вот эту часть отбросить и посмотреть взглядом инженера. Зачем?
Низкий порог вхождения, тонны учебного материала, огромная кодовая база, язык развивается в правильном направлении
Про php -S вы это серьёзно? А зачем тогда "есть Nginx, Apache и др."? Я не очень понимаю вашу логику :)
Это было опровержение ваших слов про то, что в php нет веб-сервера, никто конечно не будет это использовать в продакшене т.к. есть тот же PHP FPM. И никто не будет писать веб-сервер для php т.к. как я писал выше есть Nginx и другие.
По поводу "никому в голову не взбредёт", опыт такой есть, именно написание микросервисов на .NET, и именно для проектов на PHP.
Ну ктож вам запретит велосипедостроение, я говорю про энтерпрайз решения, а там если микросервис то скорей всего Go, если модуль - Си или набирающий обороты Rust. На C# вероятнее всего будет писать какой-нибудь горе-интегратор, зашедший в проект с php и не имея в штате специалистов нужного профиля, но это лишь предположение.
Ну опять же, я сделал наверное достаточно провокационное заявление. Что есть задачи, которые, например, тот же .NET решает лучше чем PHP, а есть задачи, которые PHP просто не способен решать, но решаются на .NET. А вот наоборот, задач, которые можно решать лучше на PHP, чем на .NET, я не знаю. Это не вопрос чьё кунфу лучше или хуже. Вполне себе практический.
Во-первых, озвучьте пожалуйста задачу, которую PHP не способен решить, а .NET способен, т.к. судя по вашим прошлым комментариям ваши познания в php и его инфраструктуре у вас на уровне IT менеджера среднего звена. Ну и во-вторых, если мы берем абстрактную задачу с метрикой "кто быстрее" то очевидно, что компилируемый язык как C# сделает это быстрее интерпретируемого PHP (но это не точно), ну и опять же, если нужна производительность никто не пойдет делать это на .NET и возьмет тот же Rust.
Пока считаю, что минусы, которые мне насыпали, обусловлены исключительно эмоциями. Опять дескать кто-то набрасывает на наш любимый язык, но это вовсе не так. Мои суждения могут быть ошибочны, хотелось бы послушать контраргументы, а не холиворить попусту.
Минусы вам насыпали за накидывание на вентилятор без аргументов и полное незнание инфраструктуры php, ну и конечно, сравнение компилируемого и интерпретируемого языков это моветон.
Но нет ни одной задачи, которую бы PHP решал лучше, чем например .NET, с другой стороны есть огромное число задач, которые .NET решает лучше, или PHP в принципе не способен их решать без прокладок и костылей на C/Go/etc.
Как мило, вы сравниваете мягкое с теплым, платформу и язык. Даже если взять C# - это компилируемый ЯП, когда PHP интерпретируемый. Про "костыли" это вы хорошо тоже отметили, бред опять же, на Си сам php и написан как и практически все его модули, на Go есть конечно какие-то микросервисы, но что примечательно, никому и в голову не взбредет писать модуль или микросервис для php на том же C#.
О чём говорить, у PHP до сих пор нет собственного веб-сервера. До сих пор. Ему нужны прокладки в виде PHP-FPM, RR, Swoole, Supervisor. Он сам по себе не в состоянии даже тупо запуститься. :)
Очевидно, что вы совсем не понимаете о чем пишете, вот вам встроеный веб-сервер:
php -S 127.0.0.1:8000 app.php
PHP FPM который вы называете "прокладкой" это тоже один из модулей php, для которого никто не пишет свой веб-сервер т.к. есть Nginx, Apache и др.
У вас извращенное понимание того, что выбирает крупный бизнес. Не " что-то модное и стильное ", это вам к различного рода стартаперам и другим любителям смузи, корпорации берут то, что проверено годами и имеет качественную поддежку, да, конечно Java (Spring итп), но и Symfony с Laravel не далеко ушли.
Манипуляция чем? Мнением, согласно вашей теории в которое превратились факты?
То есть когда фактов становится больше одного они перестают быть фактами?
Ну с тем, что вывод консоли скриншотом тут не поспоришь, а вот что не так с png?
Серьезно?
Нет конечно, я написал пример конкретно под ваш кейс. Обычно все запросы просто идут в роутер, примерно так
Ясно-понятно, вы и ноду знаете на уровне джуна. Читайте
С Go похожая ситуация, ибо насколько бы эффективно это бы не делало приложение (неважно на каком языке) иебсервер это сделает быстрее и без оверхеда. Это best practices.
В куки полномочия, серьезно, еще наверное plaintext? :) Токен и/или сикрет и по нему уже проверять, поразительно что это не очевидно, примеры проверки токена я уже приводил выше.
Вопрос из разряда если бы у бабки было причинное место.
Я вам в самом начале показал, что есть.
Так же эффективно как Nginx/Apache - конечно, и не будет никогда т.к. есть вебсерверы специально для этого предназначенные (в который раз я это пишу, в 5-й?).
Ваше право.
А у меня 25 сантиметров в холодной воде
Все правильно, на Nginx эта задача невыполнима, наверное потому, что это всего лишь вебсервер и его задача просто передать запрос, что собственно и сделаем:
Собираем в приложении статистику хитов, ошибок и чего угодно.
На PHP не отдают статику т.к. в этом нет никакого смысла, и это делает далеко не только PHP а любой скриптовый и не только язык т.к. это контрпродуктивно. Поэтому node.js, питон, go и многие другие "костылят" это на Nginx и только .NET все прогоняет сквозь себя :)
Good for you. Жду ссылку на гитхаб
Я уже не знаю как объяснить еще более доступно... Статику отдает вебсервер, потому что это статика и потому что PHP не вебсервер. И повторюсь, так поступает по озвученым выше причинам далеко не он один, и вэтом нет никакой проблемы от слова совсем. Проблему пытаетесь найти вы, но до сих пор тщетно, поэтому не сдавайтесь, пишите, вы один против всей индустрии веб фреймворков, cms и всего такого :)
Вы можете заниматься софистикой сколько угодно, провоцировать на ответ фразами "вы не ответили на вопрос потому что он не равится" и все в этом духе, не утруждайтесь, правда. Мне ваших 2-х перлов про то, что "нанимать нужно не разработчика со знанием фреймворка, а просто PHP разработчика" и вред конкуренции хватило сполна.
Да, я понял, вы просто решили преплюнуть свою прошлую глупость. Я не могу сколько либо серьезно отвечать на такие вбросы, всерьез заявлять, что конкуренция это плохо может либо жирнющий тролль, либо школьник у которого пока отсутствуют ввиду возраста базовые знания об экономике.
Вы много написали, но не указали самого главного - проблему, собственно из-за этого все что выше лишено смысла.
Тоже самое, опять читаю это как "хочу" т.к. не раскрыта проблема.
Ограничены для чего? Для описаной вами задачи - достаточно.
Я понял, у вас везде где что-то незнакомое - "костыли". Это модуль для Nginx от самого Nginx(F5). Я так понимаю, что вам там в .NET запихали все и сразу, нужно это или не нужно не спрашивают. Практически во всех хоть сколько-либо серьезных приложения/сервисах для Linux (и не только) используется модульный подход, т.е. при необходимости определенного функционала вы подключаете модуль/библиотеку, а не тащите все в рантайм, чтоб оно расходовало ресурсы зазря.
Вижу 2 слова "проблема", но как и выше нет самой проблемы.
Приложению вообще не нужно ничего ложить самому в кеш, фотка будет там уже после первого запроса. Вот как-то так:
Без лишнего оверхеда запросами в приложение - прямиком из Nginx.
Все в томже духе, задача простая и довольно распространенная, если вы думаете, что эффективно с этим справится только .NET - у меня для вас плохие новости :)
Ваше невежество можно понять, вы видимо долго и безвылазно сидите на .NET и даже не пытаетесь вникнуть как оно там в других окружениях, а тут еще на конфах бравые докладчики рассказывают что "там" все криво, через костыли и велосипеды а у нас православно и круто.
Это прям жирно вы набросили, правда. Вас не смущает что так вся индустрия работает и не только в IT.
А это и так одна точка наблюдения - логи Nginx, что для статики, что для динамики. А если вы хоть сколько-либо претендуете на хайлоад то ваша статика живет на CDN.
Что такое "рулить отдачей контента программно"? Конфиг Nginx это не программно? Нужно обоснование, что конкретно вы хотите и какие цели преследуете, а не просто "хочу".
Nginx + Secure link module
Ну генерируйте на PHP, в чем проблема?
Rewrite rules
Ради бога, деплой конфига того же nginx прям из приложения
Ничего страшного, это нормально, имея познания PHP и его инфраструктуры на уровне джуна все кажется сложным, с опытом все прийдет
Для любой задачи должно быть обоснование, а не просто "хочу"
Попробуйте задаться другим вопросом. Зачем из PHP отдавать статику?
В чем боль то? Или это что-то ваше личное на уровне ощущений и поэтому вы это не можете описать?
Что в этом плохого? Какая практика, ваша?
Веб-сервер как часть самого приложения это минус, как это масштабировать? То есть в каждую ноду с приложением мне тащить кроме него самого еще и веб сервер? Страшно представить, как до сих пор живут без своего веб сервера perl, node.js, go и прочие.
Базируется оно на том, что я до сих пор не видел ничего хоть отдаленно претендующего на энтерпрайз решение где в качестве микросервиса/модуля для php используется .NET(C#). У вас есть что-то чтоб переубедить?
Опять мимо
Полным полно
Ну не в "глубокой альфе" а в бете, особенно учитывая то, что платформе всего несколько лет и это "непрофильная" для php задача.
Все там нормально с этим, особенно в последние годы.
Вот вы пишете такую чушь а потом удивляетесь, откуда минусы. Игры, мобильные приложения... напомню, что php разрабатывался и продолжает разрабатываться в первую очередь как язык для веб приложений.
Основано на опыте. Ну и как писал выше - разубедите меня, покажите проекты где с php бок о бок работает хоть с чем-то на .NET.
Учитывая то, что PHP это в первую очередь разработка под WEB - конечно стоит. И очевидно, что решает задачи не хуже .NET, т.к. на данный момент в сфере бэкенд фреймворков он занимает лидирующие позиции, в отличии от .NET доля которого несоизмеримо мала.
Низкий порог вхождения, тонны учебного материала, огромная кодовая база, язык развивается в правильном направлении
Хорошо, если за платформу взять фреймворк, Symfony, какие у вас к ней претензии?
Это было опровержение ваших слов про то, что в php нет веб-сервера, никто конечно не будет это использовать в продакшене т.к. есть тот же PHP FPM. И никто не будет писать веб-сервер для php т.к. как я писал выше есть Nginx и другие.
Ну ктож вам запретит велосипедостроение, я говорю про энтерпрайз решения, а там если микросервис то скорей всего Go, если модуль - Си или набирающий обороты Rust. На C# вероятнее всего будет писать какой-нибудь горе-интегратор, зашедший в проект с php и не имея в штате специалистов нужного профиля, но это лишь предположение.
Во-первых, озвучьте пожалуйста задачу, которую PHP не способен решить, а .NET способен, т.к. судя по вашим прошлым комментариям ваши познания в php и его инфраструктуре у вас на уровне IT менеджера среднего звена. Ну и во-вторых, если мы берем абстрактную задачу с метрикой "кто быстрее" то очевидно, что компилируемый язык как C# сделает это быстрее интерпретируемого PHP (но это не точно), ну и опять же, если нужна производительность никто не пойдет делать это на .NET и возьмет тот же Rust.
Минусы вам насыпали за накидывание на вентилятор без аргументов и полное незнание инфраструктуры php, ну и конечно, сравнение компилируемого и интерпретируемого языков это моветон.
Как мило, вы сравниваете мягкое с теплым, платформу и язык. Даже если взять C# - это компилируемый ЯП, когда PHP интерпретируемый. Про "костыли" это вы хорошо тоже отметили, бред опять же, на Си сам php и написан как и практически все его модули, на Go есть конечно какие-то микросервисы, но что примечательно, никому и в голову не взбредет писать модуль или микросервис для php на том же C#.
Очевидно, что вы совсем не понимаете о чем пишете, вот вам встроеный веб-сервер:
PHP FPM который вы называете "прокладкой" это тоже один из модулей php, для которого никто не пишет свой веб-сервер т.к. есть Nginx, Apache и др.
Вы предлагаете деградировать? Спасибо, не надо
У вас извращенное понимание того, что выбирает крупный бизнес. Не " что-то модное и стильное ", это вам к различного рода стартаперам и другим любителям смузи, корпорации берут то, что проверено годами и имеет качественную поддежку, да, конечно Java (Spring итп), но и Symfony с Laravel не далеко ушли.
Ты очевидно спутал хабр с каким-то ватным лепрозорием. Накинул, да так жирно... Липов?
Вы вертитесь прям как уж на сковородке, пытаясь доказать свою абсурдную теорию. В итоге получается бред, типа такого
На меня как минимум потратится большее кол-во электроэнергии, увеличится износ самого трамвая и рельсового полотна.