Российские VPS/VDS-хостинги — рейтинг 2023. Злая версия

С электричеством вообще проблем нет уже лет 20. Максимум пропадает на 2-3 секунды (это решает УПС) и может раза 2-3 за 10 лет пропадало на 5-10 мин.

Интернет ни разу не было за 15 лет, что 2 провайдера одновременно упали.

Hidden text

Кринж-обзор ПМЭФ-2023, а также продолжение истории с запретом торговли на зарубежных биржах

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

Эти заказчики сейчас с вами в одном помещении?

Кринж-обзор ПМЭФ-2023, а также продолжение истории с запретом торговли на зарубежных биржах

С примерами сорян, что-то сегодня нет желания искать аналогичные примеры

Понятно, забежал накинуть на вентилятор

Кринж-обзор ПМЭФ-2023, а также продолжение истории с запретом торговли на зарубежных биржах

О да, где объективность, а где вы со своим размытым до невозможности уточнением "что бы под этим не подразумевалось" и все еще без аргументов (примеров)

Кринж-обзор ПМЭФ-2023, а также продолжение истории с запретом торговли на зарубежных биржах

Даже не знаю, что сказать на столь мощную аргументацию

Вам ответили в вашем же стиле - "если бы у бабки было причинное место"

Кринж-обзор ПМЭФ-2023, а также продолжение истории с запретом торговли на зарубежных биржах

https://ru.wikipedia.org/wiki/Список_заблокированных_в_России_СМИ

Кринж-обзор ПМЭФ-2023, а также продолжение истории с запретом торговли на зарубежных биржах

Манипуляция чем? Мнением, согласно вашей теории в которое превратились факты?

Кринж-обзор ПМЭФ-2023, а также продолжение истории с запретом торговли на зарубежных биржах

То есть когда фактов становится больше одного они перестают быть фактами?

От 3proxy до Nginx forward proxy через боль и страдания (Часть первая 3proxy)

Ну с тем, что вывод консоли скриншотом тут не поспоришь, а вот что не так с png?

Как создавался умный агрегатор новостей LifeLines

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

Серьезно?

Стоит ли учить PHP в 2022 году

Вы предлагаете для каждого метода писать какие-то реврайты на nginx-е? Может и логику уже на Lua туда разместить? ))

Нет конечно, я написал пример конкретно под ваш кейс. Обычно все запросы просто идут в роутер, примерно так

location / {
    try_files $uri /index.php$is_args$args;
}

NodeJS прекрасно статику отдаёт.

Ясно-понятно, вы и ноду знаете на уровне джуна. Читайте

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 тоже есть такие, кто так считает

А у меня 25 сантиметров в холодной воде

Стоит ли учить PHP в 2022 году

В приложении есть методы, один и тот же метод обрабатывает запрос:

GET /some/{some-id}/some-other/{some-other-id}

some-id и some-other-id -- разные, но метод один, и приложение знает что это один метод, и метрики успешных, ошибочных и т.д. запросов собирает для одного метода, не важно это запрос на файл, или АПИ

Nginx ничего этого не знает, с разными параметрами это будут совершенно разные URL для него. Он не может собрать статистику хитов, ошибок, гистограмму выполнения и т.д. по методу.

На nginx эта задача не выполнима.

Все правильно, на Nginx эта задача невыполнима, наверное потому, что это всего лишь вебсервер и его задача просто передать запрос, что собственно и сделаем:

location ~ /some/([^/]+)/some-other/(.+)$ {
    try_files /app.php?some_id=$1&some_other_id=$2 =404;
}

Собираем в приложении статистику хитов, ошибок и чего угодно.

Но PHP файлы не отдают, поэтому всё что можно костылится на nginx-ах.

На PHP не отдают статику т.к. в этом нет никакого смысла, и это делает далеко не только PHP а любой скриптовый и не только язык т.к. это контрпродуктивно. Поэтому node.js, питон, go и многие другие "костылят" это на Nginx и только .NET все прогоняет сквозь себя :)

Более того, сервис на .NET-е используется в одном проекте на Python, выступая в роли API-гейта и статики со сложными политиками доступа к файлам. Новости у меня хорошие, это работает отлично :)

Good for you. Жду ссылку на гитхаб

Ну вот кейс, PHP плохо справляется с отдачей статики.

Я уже не знаю как объяснить еще более доступно... Статику отдает вебсервер, потому что это статика и потому что PHP не вебсервер. И повторюсь, так поступает по озвученым выше причинам далеко не он один, и вэтом нет никакой проблемы от слова совсем. Проблему пытаетесь найти вы, но до сих пор тщетно, поэтому не сдавайтесь, пишите, вы один против всей индустрии веб фреймворков, cms и всего такого :)

Стоит ли учить PHP в 2022 году

Вы можете заниматься софистикой сколько угодно, провоцировать на ответ фразами "вы не ответили на вопрос потому что он не равится" и все в этом духе, не утруждайтесь, правда. Мне ваших 2-х перлов про то, что "нанимать нужно не разработчика со знанием фреймворка, а просто PHP разработчика" и вред конкуренции хватило сполна.

Стоит ли учить PHP в 2022 году

Наличие большого количества конкурирующих фреймворков -- это плохо для индустрии.

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

Стоит ли учить PHP в 2022 году

GET user/123/service/44/info
GET user/333/service/55/info

Для nginx это совершенно разные запросы, которые нельзя консолидировать.

Приложение знает, что это запрос одного и того же метода, но с разными параметрами.

Разница между уровнем и детализации наблюдений -- разная. Это крайне очевидно.

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

Это то и значит. Может вы всё остальное приложение в nginx перенесёте? Или что значит "хочу"? )) Значит применять логику при отдаче контента.

Тоже самое, опять читаю это как "хочу" т.к. не раскрыта проблема.

Во-первых, возможности крайне ограничены. И придётся подстраиваться.

Ограничены для чего? Для описаной вами задачи - достаточно.

Во-вторых, это костыли.

Я понял, у вас везде где что-то незнакомое - "костыли". Это модуль для Nginx от самого Nginx(F5). Я так понимаю, что вам там в .NET запихали все и сразу, нужно это или не нужно не спрашивают. Практически во всех хоть сколько-либо серьезных приложения/сервисах для Linux (и не только) используется модульный подход, т.е. при необходимости определенного функционала вы подключаете модуль/библиотеку, а не тащите все в рантайм, чтоб оно расходовало ресурсы зазря.

Генерирование на лету, проблема в том, что файлы начинают отдаваться из PHP, а это уже проблема.

Вижу 2 слова "проблема", но как и выше нет самой проблемы.

Приложение отдаст её или из кеша, или сгенерирует (допустим виде уменьшенной фотки) и положит в кеш. Без всяких костылей и прокладок.

Приложению вообще не нужно ничего ложить самому в кеш, фотка будет там уже после первого запроса. Вот как-то так:

location ~ /avatar/.+\.(png|jpe?g)$ {
    try_files $uri @app;
}

Без лишнего оверхеда запросами в приложение - прямиком из Nginx.

GET /avatar должен отдавать изображение текущего пользователя.

Покажите rewrite правило. Авторизация определяется либо зашифрованной кукой, либо зашифрованным токеном в заголовке.

location = /avatar {
    set_decode_base32 $session $cookie_auth;
    set_decrypt_session $id $session;
    if ($id = '') {
        return 404;
    }
    try_files $id /avatar.php?id=$id;
}

GET /product/123/banner -- отдаём баннер товара, какой именно зависит от региона, правил, да и параметров самого пользователя

Все в томже духе, задача простая и довольно распространенная, если вы думаете, что эффективно с этим справится только .NET - у меня для вас плохие новости :)

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

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

Стоит ли учить PHP в 2022 году

По сути часто ищут не просто PHP разработчика, а разработчика со знаниями конкретного фреймворка. Это удручает.

Это прям жирно вы набросили, правда. Вас не смущает что так вся индустрия работает и не только в IT.

Стоит ли учить PHP в 2022 году

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

А это и так одна точка наблюдения - логи Nginx, что для статики, что для динамики. А если вы хоть сколько-либо претендуете на хайлоад то ваша статика живет на CDN.

хочу рулить отдачей контента программно, в одном месте, а не размазывать по конфигам nginx-а

Что такое "рулить отдачей контента программно"? Конфиг Nginx это не программно? Нужно обоснование, что конкретно вы хотите и какие цели преследуете, а не просто "хочу".

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

Nginx + Secure link module

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

Ну генерируйте на PHP, в чем проблема?

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

Rewrite rules

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

Ради бога, деплой конфига того же nginx прям из приложения

Вот собрал я образ с приложением, и ему ничего больше не нужно, он просто работает. С PHP пока так не получается. Приседаний выше крыши.

Ничего страшного, это нормально, имея познания PHP и его инфраструктуры на уровне джуна все кажется сложным, с опытом все прийдет

И, если быть честным, "зачем отдавать PHP статику", а почему бы и нет? Но нет. Понятно, что удобно всегда дать простой ответ: "да вам это не нужно" :)

Для любой задачи должно быть обоснование, а не просто "хочу"

Стоит ли учить PHP в 2022 году

Я вот давно задавался вопросом, а почему из PHP никто не отдаёт файлы, статику? Это максимально перекладывается на внешний веб-сервер, или внешние микро-сервисы.

Попробуйте задаться другим вопросом. Зачем из PHP отдавать статику?

Вот собственно, я почему и задаюсь вопросом. Я вижу как с этим всем больно, буквально на каждом шагу в PHP.

В чем боль то? Или это что-то ваше личное на уровне ощущений и поэтому вы это не можете описать?

Стоит ли учить PHP в 2022 году

Это и значит, что в php нет своего веб-сервера. Значит для запуска веб-приложения в продакшене нужно что-то ещё. И это не очень хорошо, как показывает практика.

Что в этом плохого? Какая практика, ваша?

Продолжая сравнение с .NET, веб-приложение содержит в себе полноценный веб-сервер, как часть самого приложения. Более того, оно может работать в режиме прокси, ощутимо не уступая в производительности nginx-у.

Веб-сервер как часть самого приложения это минус, как это масштабировать? То есть в каждую ноду с приложением мне тащить кроме него самого еще и веб сервер? Страшно представить, как до сих пор живут без своего веб сервера perl, node.js, go и прочие.

Это неправильное предположение. Не понял, на чём оно базируется.

Базируется оно на том, что я до сих пор не видел ничего хоть отдаленно претендующего на энтерпрайз решение где в качестве микросервиса/модуля для php используется .NET(C#). У вас есть что-то чтоб переубедить?

Например, gRPC Server, без прокладок на Go никак, и в режиме бесконечного полнодуплексного бесконечного стриминга -- нужны очень серьёзные приседания и высокие скилы. Т.е. оно как-то решается, но плохо.

Опять мимо

Тож самое касается WebSocket.

Полным полно

Поддержка OpenTelemetry, в глубочайшей альфе и по сути всё делать надо руками, никакой поддержки прозрачной трассировки. Даже метрики негде хранить, кроме как прикручивать какой-нибудь Redis, а это уже влияние, недопустимое для счётчиков производительности.

Ну не в "глубокой альфе" а в бете, особенно учитывая то, что платформе всего несколько лет и это "непрофильная" для php задача.

Асинхронные IO операции, без удержания рабочих процессов и потоков. Тут всё плохо.

Все там нормально с этим, особенно в последние годы.

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

Вот вы пишете такую чушь а потом удивляетесь, откуда минусы. Игры, мобильные приложения... напомню, что php разрабатывался и продолжает разрабатываться в первую очередь как язык для веб приложений.

Какое-то очередное заблуждение. При чём ультимативное, "все...", "никто..", ну да, ну да. Не понятно на чём основано.

Основано на опыте. Ну и как писал выше - разубедите меня, покажите проекты где с php бок о бок работает хоть с чем-то на .NET.

Если на PHP нет ни одной задачи, которую бы он решал лучше, быстрее или оптимальнее чем на том же .NET, и отвечая риторически на вопрос топика, стоит ли учить PHP?

Учитывая то, что PHP это в первую очередь разработка под WEB - конечно стоит. И очевидно, что решает задачи не хуже .NET, т.к. на данный момент в сфере бэкенд фреймворков он занимает лидирующие позиции, в отличии от .NET доля которого несоизмеримо мала.

Но если вот эту часть отбросить и посмотреть взглядом инженера. Зачем?

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

Стоит ли учить PHP в 2022 году

Хорошо, если за платформу взять фреймворк, Symfony, какие у вас к ней претензии?