Это не легаси-код, это PHP

Автор оригинала: Matt Brown
  • Перевод


За последний год разработчики Vimeo писали код бэкенда на множестве языков — PHP, Go, Ruby, Python, NodeJS, Java, C, C++ и немного на Rust.

В 2004 году мы начинали всего с одного: PHP. Это был идеальный язык для новых стартапов наподобие Vimeo. Интерпретатор PHP позволял предпринимателям быстро разрабатывать прототипы и имел большую стандартную библиотеку, позволявшую избавиться от мороки с повседневными задачами типа отправки писем и доступа к базам данных.

Большинство стартапов развалилось, однако некоторые из них, взявшие за основу PHP, по-прежнему были живы спустя десяток лет. Немногие из них добилась резкого роста, а в дальнейшем кое-кто из этих стартапов (самым заметный пример — это Facebook) решил, что PHP является узким местом, и начал мигрировать с него. Для этого исхода было две серьёзные причины: производительность PHP и сложность поддержки больших кодовых баз PHP.


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

С 2004 года за десять лет Vimeo вырос во много раз, и наша кодовая база PHP росла вместе с ним, но мы не выросли настолько, чтобы эти проблемы встали перед нами в полную силу. Однако когда Facebook публично отказался от использования PHP, некоторые разработчики решили, что PHP постепенно становится FORTRAN эпохи Интернета. Новая волна бэкенд-разработчиков начала планировать, как нам преобразовать 500 тысяч строк кода на PHP в набор лучше спроектированных, более производительных и удобных для тестирования сервисов на Go.

Какое-то время это казалось неизбежным, но мы так и не дошли до полного отказа от PHP. На то были очевидные причины: переписывание всей кодовой базы — это затратный и подверженный ошибкам процесс. Однако была и ещё одна, менее очевидная причина: PHP стал лучше.

Слова «PHP стал лучше» не в полной мере описывают его преобразование. За последние шесть лет в два с лишним раза уменьшилось время выполнения кода на PHP, значительно выросло сообщество разработчиков и появилась популярная тенденция совершенствования кодовых баз на PHP (старых и новых) на основе выводов, сделанных исходя из статического анализа.

Для проникновения усовершенствований PHP в Vimeo потребовалось какое-то время. Сначала нам пришлось избавиться от старой версии PHP (5.4), работавшей в продакшене долгие годы уже после истечения её «срока годности». Благодаря миграции на PHP 7 значительно ускорилась реакция бэкенда; кроме того, улучшенный синтаксис PHP 7 позволил нашим разработчикам писать чуть более чистый код с полной поддержкой типов возвращаемых значений и параметров.

PHP не прекратил обновляться — выпущенная в конце ноября версия 8 принесла с собой множество усовершенствований на уровне языка, которые позволят нашим разработчикам выражать бизнес-логику более кратко. Мы планируем перейти на новую версию в начале 2021 года.

Статический анализ — это круто


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

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

Базовая функциональность Psalm приблизительно похожа на контроль типов в TypeScript, а также позаимствовала кое-какие идеи у созданного Facebook языка Hack (производного от PHP). Psalm сообщает разработчику, когда код на PHP может вызвать ошибку несоответствия типов в продакшене, а также когда логика непонятна. Кроме того, инструмент имеет дополнительную функциональность наподобие обнаружения неиспользуемых классов и методов, позволяя автоматически устранять многие найденные проблемы.

Использование Psalm в нашем конвейере CI в течение последних нескольких лет преобразовало подход к написанию кода на PHP в Vimeo: Psalm обеспечил нам уверенность в том, что можно вносить крупномасштабные изменения, не беспокоясь о том, что всё целиком сломается.

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

Я создал Psalm для решения своих проблем, но когда мы выпустили его в open source, он смог помочь и проблемы множества других людей. Недавно Psalm помог нам выявить кучу уязвимостей защиты в нашей кодовой базе ещё до того, как ими могли воспользоваться злоумышленники.

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

Старый код необязательно является легаси


В середине 2000-х не существовало качественных ORM для PHP, поэтому мы создали собственное. К счастью, в PHP есть множество строительных блоков для создания простого ORM в стиле ActiveRecord, в том числе и с поддержкой MySQL, привязкой параметров запросов и магическими геттерами и сеттерами. Помогло нам и то, что этой задачей занялись по-настоящему умные инженеры.

Последнее крупное обновление нашего ORM было выпущено десять лет назад. В него вошли некоторые незначительные усовершенствования — устранение багов, улучшенные типы и несколько новых фич, но базовая структура осталась неизменной.

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

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

  • Эффективно выполняет свою задачу
  • Прост для статического анализа
  • Хорошо протестирован
  • Идиоматичен

К счастью, созданное нами ORM удовлетворяет всем четырём критериям.

Кроме того, сохранение надёжного старого кода даёт нам возможность сосредоточить усилия разработчиков на том, что приносит бизнесу материальную выгоду, и в соответствии с договором я обязан (но в то же время и рад) сказать, что в последнее время Vimeo находится на подъёме, выпустив множество отличных продуктов наподобие Vimeo Record.

«PHP не обязан быть ужасным»


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

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

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



На правах рекламы


Эпичные серверы — это виртуальные серверы для размещения сайтов от маленького блога на Wordpress до серьёзных проектов и порталов с миллионной аудиторией. Создайте собственный тарифный план в пару кликов, максимальная конфигурация — 128 ядер CPU, 512 ГБ RAM, 4000 ГБ NVMe!

VDSina.ru хостинг серверов
Серверы в Москве и Амстердаме

Комментарии 76

    +4

    В PHP меня расстраивает только один факт: я не могу писать на нем все-все-все, как на NodeJS. А так, я бы с удовольствием пилил на нем и мобильные приложения, и десктоп, и cli утилиты. Но, к сожалению, я не нашел популярного способа хотя бы упаковать PHP код в бинарник, чтобы его можно было распространять как есть, без необходимости ставить рантайм.

      +3
      У каждого языка своя направленность, а когда пытаются засунуть один язык везде… Вот это удручает, что приложения пишутся вот так
        +2
        Удручает больше тот факт, что программирование в сущности это про работу с текстовыми данные (подразумеюваются не только исходники), но единого инструмента для этого как не было, так и не предвидится.
          0
          Но исходники это в первую очередь не текст, а программа на каком-то языке, текстовое представление AST, которое удобнее обрабатывать специализированным инструментом, нежели обычным текстовым редактором. А поскольку языки все разные, то единый инструмент вряд ли возможен, и даже плагины для всех языков в одной IDE будут иметь достаточно большие отличия в поведении.
            0
            По факту любой автомат этот текст.
            Текст это чудо которое сотворили люди, а не природа, но проблема в том что люди не могут думать иначе чем текст
              0

              Диаграммами могут некоторые...

        0

        Ну можно сделать велосипед с архивом, куда придётся ложить ещё и интепритатор. Компиляция в бинарь была бы мега пушка, можно было бы хотя бы простые консольные штуки пилить, с ui сложнее

          +3

          Да всё это было. Просто с ростом культуры кода забылось.
          Могу поделиться упакованными екзешниками php 4.4 под винду, которые весят от 635кб до 1434кб (в зависимости от комплектации). При запуске выполняют рядом лежащий index.php (зловонный Index.php с демонстрацией окошек прилагаю)
          https://yadi.sk/d/oZmQ9bQGgXawjQ
          Естественно, можно было бы весь код упаковать в 1 файл, но тут весь смысл в переносе компилятора на любую машину с возможностью в блокноте написать нужный код. В армии это особенно принесло пользу — надо было написать скрипт по умному переименованию сотен-тысяч mp3-файлов (убрать префиксы и прочий мусор из названий). Накидал код в блокноте и готово.
          php5 упаковывать уже накладно (выходит более 5мб), поэтому лучше dll класть в папочку и таскать с собой. Решения есть и под php7. Странно, что под php8 пока всё выглядит немного уныло даже с ffi уже в комплекте. Но это вопрос времени, как мне кажется.

            0

            Это как я понял просто скомпиленый php.exe с нужными расширениями, я подобный компилил для андройда, во времена когда не было всяких ksweb

            0
            Может, в настоящее время вместо велосипеда с архивом решением имеет право стать Docker-контейнер?
            +3

            Так в ноде насколько я знаю тоже нет варианта упаковать все в один бинарь.

              0

              Есть — https://www.npmjs.com/package/pkg
              Правда под виндой у меня бинарник выходил больше 40мб точно

                +4

                Это разве не упаковка ноды вместе с исходниками? Если да то не вижу причин почему на пхп так нельзя сделать

              0
              и не нужно писать всё всё на одном языке.
              выучить библиотеку для написания чего-то нового по времени и трудозатратам ничем не меньше, чем выучить новый подходящий для этого язык.
                +1
                Есть DevelNext, этакий гибрид из Java-runtime и php. Интересная вещь, жаль, что не очень широкие возможности. Писал на нём маленькое приложение
                  0
                  Но, к сожалению, я не нашел популярного способа хотя бы упаковать PHP код в бинарник

                  Было что-то лет пятнадцать назад, но особо не взлетело.

                    +5
                    В PHP меня расстраивает только один факт: я не могу писать на нем все-все-все, как на NodeJS.

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


                    Разве что сталкивался с проблемами uint64_t, в OpenGL, но оно обходилось явным выделением памяти под этот тип, а оверфлоу будет только при касте к пыховскому инту (который не unsigned).


                    А так, я бы с удовольствием пилил на нем и мобильные приложения, и десктоп, и cli утилиты.

                    И кто мешает? С мобилой сложнее, нужно через terminus запускать, а не паковать в apk. Но в теории можно придумать и нормальный запуск. Не копал в этом направлении от слова "вообще", но раз на сишке можно писать под мобилу, значит и на пыхе можно, просто чуть иначе перепаковать бинарь.


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

                    Тут или шашечки, или ехать. Java, JS или любой другой платформонезависимый код поставляется с рантаймом. Никто не мешает поставлять в своей сборке и бинарь рантайма, как это делается, например, в случае с IDEA. С точки зрения реюзабельности — это самый профитный вариант.




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

                      +1

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

                        0
                        Про джаву не совсем правда-она вполне успешно компилируется в бинарь

                        Признаться, подобных подходов вообще ни разу не встречал. Ну или не обращал внимания просто… Буду знать, спасибо.

                      +1
                      Без обид, но те, кто пишет на js все-все-все (особенно мобилки и десктоп), будут гореть в аду. Производительность этого всего-всего-всего никакая-никакая-никакая. Только php в этом формате нам и не хватает для полного счастья. Консольные утилиты — ок, в этой области претензий нет.
                        +1
                        Наоборот, тенденция в мире такая, что все хотят один язык для всего. Поэтому Go, JS, C#, Kotlin, etc — все хотят пролезть во всё.
                          0
                          Для всего не выйдет, как ни крути. Ибо любой язык с GB никогда не вступят на территорию, где главенствуют C, C++, ну и Rust в последнее время. В то же время все эти языки никогда не подойдут для целей, для которых создавались PHP, Python или JS.
                        0
                        Если все что я прочитал про PHP 8 я понимаю верно, то у разработчиков такая же хотелка, поэтому они добавили JIT, это первый шаг. Вангую что скоро будет добавлено и упрощение сборки в бинарник.
                          0

                          После доклада Дмитрия Стогова о JIT на PHPFest 2020 был вопрос:


                          Планируется ли версия PHP, которая будет компилировать код в бинарник (по аналогии с C или Go)

                          Дмитрий ответил:


                          Нет, не планируется, хотя в принципе я не вижу ничего сложного — для этого всё уже есть… Если вы хотите распространять close source проекты и зарабатывать деньги, тогда пожалуйста, сами делайте
                            0
                            бинарник

                            close source проекты

                            Нда, ответил на совсем другой вопрос.
                              +1

                              А разве


                              Нет, не планируется

                              Не ответ на ТОТ вопрос?

                                0

                                Мотивация создания бинарников не понята, наверное. А потому ответ может быть не на ТОТ вопрос.

                                  0
                                  В такой постановке вполне не тот вопрос — нет. Единственную необходимость в исполнимых, какую он наиболее предполагает — закрытые исходники, про что он дополнил. А на основе этих ответов можно предложить, почему вам нужна компиляция и что это даст сообществу.
                                    0

                                    Лично мне она нужна для удобства инхаус разработки и эксплуатации )Это если говорить именно об исполнимом бинаринике/ Ещё хотелось бы аналог .pyc файлов в python

                                      0
                                      phar не подходит?
                                        0

                                        Неа. Он содержит только php код. Если бы ещё, например, расширения вкладывались то частично бы подошёл

                                          +1
                                          Я знаю, что только код. Можно же скомпилить себе пых с нужными расширениями и будет всего пара файлов. При желании, упаковать их в архив с самозапуском из памяти. Наверняка подобные решения есть. Конечно, это не так просто, если бы всё было заготовлено. Но решаемо.
                                            0

                                            Мне это нужно, чтобы упростить ежедневную работу, а не усложнить ) Коробочным решением с удовольствием бы пользовался — в гоу понравилось когда его немного пробовал, а что-то костылять плохо стандартизированное… Лучше уж докер-контейнерами доставлять — стандарт де-факто уже можно сказать. Если админы-девопсы есть, то им даже специфика ПХП особо не нужна

                          0
                          В PHP меня расстраивает только один факт: я не могу писать на нем все-все-все, как на NodeJS.
                          Вы и на ноде не можете. Просто php-разработчики обычно не испытывают иллюзий по поводу границ применимости своего языка.

                          Здесь должна быть шутка про «Один пацан писал все на JavaScript...»
                            0
                            ну и шутки про js тоже не надо забывать
                            Картинка
                            image
                            0

                            Есть babel-preset-php, который синтаксис PHP7, кроме деструкторов, ссылок, die(), суперглобальных массивов с данными запроса и еще некоторых моментов транспилирует в JS, который можно обернуть в Cordova/PhoneGap и получить десктопное или мобильное приложение.
                            Реальных проектов не видел.

                              0
                              Но зачем? Это может и добавит простоту разработки (не надо учить другой язык), но на выходе получится ужас для десктопа вроде Electron…
                                0

                                тут надо разделять просто упаковку в бинарник как замену php program.phar или php -S и всякие извращения с GUI типа завернутого хромиума

                              +1

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

                                +2
                                это не совсем то, что ожидают от полноценной экосистемы абстрактного языка в вакууме

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

                                  +2
                                  Сообщество PHP 2004 года и даже 2014 это разные вещи. Я уж молчу про сейчас, когда инструментов более чем достаточно.
                                  +2
                                  Жду момента когда на пхп из коробки можно будет легко и просто написать самостоятельный микросервис, как на ноде например. Без установки отельного веб сервера, без swoole и roadrunner, без танцев с pthreads. Это будет новый виток эволюции.
                                    0
                                    Скорее всего к этому таки придут, но еще надо подождать пару лет.
                                      0

                                      А кто мешает? Я писал такое ещё на PHP3. Открываем сокет слушаем обрабтывае. Да, синхронно, да однопоточно, да память текла во всю тогда… Сейчас со многим лучше. Генераторы вон можно прикрутить

                                        –1
                                        Какой смысл с однопоточного сервера? Мы же о серьезных вещах говорим.
                                          +3

                                          А ничего, что в ноду многопоточность только недавно завезли (и то не факт, что прикрутили к эвентлупу, тут надо жсников спрашивать), а раньше как бы никого это и не волновало особо? В чём отличия-то?

                                            –2
                                            в ноду многопоточность только недавно завезли

                                            А об этом все забывают, один случайный sleep в 15м году убивал весь сервер :)
                                            0

                                            Автомасштабирование в кубере или ещ' где настраиваем — полушутка

                                          0
                                          Эм, php -S localhost:8000, с PHP 5.4.
                                            0
                                            Чем вам вебсервер не угодил? Как по мне, то это замечательно, что в пыхе нет веб-сервера для прода. Бери любой под свои потребности и не парься.
                                              0
                                              Ничего не имею против отдельного веб сервера, просто не всегда подходит что скрипт живет только один запрос. Бывает нужно сделать демон со своим состоянием, например для лучшей производительности или из-за особенностей бизнес-логики.
                                                0
                                                А в чём проблема взять для этого сторонний инструмент? В любом случае что-то живое будет написано на фреймворках и прочем, голый PHP использовать нет смысла.
                                                  0

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

                                                  0
                                                  Ну вот как раз для этого и есть подходящие решения! И это здорово, как по мне
                                                  +1

                                                  Хотелось бы все-таки, чтобы -S годился для прода просто как запускальщик index.php условного для микросервисов

                                                    0
                                                    Зачем, если есть nginx \ swoole?
                                                      0

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


                                                      Да и вообще, два компонента обычно сложнее в разработке, разворачивание поддержке чем один.

                                                        –1
                                                        Философия докера: один контейнер — один процесс. Значит веб-сервер в свой контейнер.
                                                        Как пользовательскую статику отдавать? А как вы ее обычно отдаете? Если у вас один инстанс, то к нему можно просто примаунтить ФС, но статику я бы отдал на откуп cdn\s3 и забыл как страшный сон
                                                          +1

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


                                                          P.S. Облачные сервисы не рассматриваем по ряду причин, кроме как базу для подъёма виртуалок и сетей между ними. И то, обычные хостеры предпочтительней, особенно если АПИ дают по цене обычного ВДС хостинга. А так на текущем проекте обычные дедики

                                                            –1
                                                            Философия докера: один контейнер — один процесс.

                                                            Ну вот и получается что микросервис на php невозможно задеплоить менее чем в двух контейнерах. Является ли это достоинством?

                                                              +2

                                                              посмотрите на nginx unit

                                                                0

                                                                Выглядит очень интересно. А то уже думал может апачем пхп запускать для одного процессаю Спасибо за наводку. В проде пробовали?

                                                                +1
                                                                Ну вот и получается что микросервис на php невозможно задеплоить менее чем в двух контейнерах.

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

                                                                  0

                                                                  Нормально один nginx на N php-fpm пулов или даже процессов (разные версии пхп например) на одном сервере под управлением системного systemd. С докером же это не очень нормально получается — выходит 1+N процессов nginx чтоб более-менее удобно деплоить отдельные приложения/сервисы

                                                                    0

                                                                    Для начала стоит определиться с тем, что используется:
                                                                    1) nginx — это внешний сервер.
                                                                    2) fpm — это супервизор для php с fcgi гейтом.
                                                                    3) systemd — это ещё один супервизор (и крон в т.ч.) под всё остальное.


                                                                    Два из этих сервиса (fpm + systemd) — это супервизоры, а значит должны быть непосредственно прибиты к контейнеру, в котором они там что-то менеджерят. Ну или делать это снаружи (например systemd может мониторить докер контейнер), так?


                                                                    Получается, что у нас только один контейнер с fpm, который открывает наружу порт к которому nginx уже коннектится через fcgi.


                                                                    А если подобная ситуация не нравится по какой-либо причине, то они выкидываются, а nginx разворачивается как реверс прокси и/или балансер напрямую на пыховский сервер (благо их туча: amp, react, swoole, PEAR, etc).


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


                                                                    P.S. А ещё вместо fpm можно взять roadrunner, он выполняет примерно ту же роль процесс менеджера, что и сабж. И вместо контейнера с fpm надо будет стартовать уже rr. Остальные телодвижения примерно те же самые.

                                                                      +2

                                                                      Типичный (для меня и вообще на просторах мануалов и туториалов) сетап сервера для нескольких пхп приложений (на примере убунту по памяти)


                                                                      • nginx c конфигами для статики и fastcgi_pass в /etc/nginx/sites-enabled/* для каждого приложения
                                                                      • php-fpm c конфигами в /etc/php/7.4/fpm/pool.d/* для каждого приложения со своим портом/файл-сокетом
                                                                      • всё это systemd держит

                                                                      На докере обычно получается, что приложение — это два контейнера в связке с конфигами для выделенного nginx и php-fpm. Или запихнуты в один плюс, обычно, supervisor. Плюс общесистемный nginx или haproxy (trаefik вроде тоже) как http reverse proxy в качестве чисто http роутера/"ингресса"


                                                                      Хотелось бы чтобы php приложение было в одном процессе, слушало http, эффективно раздавало статику из публичного каталога приложени, ну и обслуживало динамику. И всё это гибко, очень гибко, настраиваемо на уровне билда или старта контейнера/ Как рабочий функционирующий пример: apache2+libphp или вон в комментах узнал про nGinx Unit.


                                                                      Так понятнее? )

                                                                        +2

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


                                                                        В общем, есть БД для небольших приложений под небольшую загрузку, которые не требуют оркестарции — sqlite. Это вполне себе production-ready решение, но для определённого круга задач. Когда из мелкого сервиса оно превращается в большой — возможностей sqlite уже не хватает и народ переезжает на полноценное ПО, которое предоставляет больше возможностей — pgsql/mssql/etc, так?


                                                                        С серверами всё точно так же. Если не нужно ничего особо крутого, то в node достаточно использовать express, в ruby webrick, а в php перечисленные мною выше в заминусованном комментарии. Они вполне эффективно (и местами эффективнее, нежели nginx), отдают и статику, и гибкие, и настраиваются в билде и вообще всё, что вы перечислили, просто потому что написаны на том же PHP. И не надо ничего ставить кроме самого PHP. Но при масштабировании требуется уже больше возможностей, поэтому ставят специально заточенное под это дело внешнее ПО.


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


                                                                        Ну как-то так…

                                                                          0
                                                                          Когда из мелкого сервиса оно превращается в большой — возможностей sqlite уже не хватает и народ переезжает на полноценное ПО, которое предоставляет больше возможностей — pgsql/mssql/etc, так?

                                                                          В мире PHP обычно всё же по умолчанию mysql, за сотни собеседований от трейни до лида второй команды только пару человек вообще пробовали с ним работать.


                                                                          Так и с остальным, наверное. Раньше apache+modphp стандартом де-факто для самого простого хелловорда были, потом nginx+php-fpm, сейчас — они же в докере (с кмпозом в качестве оркестратор), хорошо если не кубер поднимают для бложика на вордпресе. При этом вопрос масштабирования/отказоустойчивости если и поднимается при выборе этой части инфраструктуры, то только горизонтального и бэкапов. В крайнем случае в уме держат реплику мускула для отчётов и тех же бэкапов.


                                                                          Думаю, популярность этого связана с простой, если не самих средств, то их разворачивания и минимального конфигурирования путем копипасты нескольких готовых конфигов. Да даже ещё раньше, со времён массовой популярности апачи виртхостингов, где вообще свой софт установить или свой cli php процесс запустить нельзя было. Это всё досатточно простое чтобы стать, скорее всего, самым массовым способом создать работающее веб-приложение. При этом с большим запасом "прочности" когда задачи становятся сложнее. Тепрь туда добавился докер и идёт кубер. И, не дай бог, сделают лямбды на авс нативные )


                                                                          Swoole (на С написан скорее всего) и ко для тех, кто вырос на LAMP и продолжателях, сложнее по факту. Скорее рассматривается как "вот понадобится масштабироваться, работать асинхронно и т. п. — у нас есть такие варианты в запасе чтоб не переписывать всю кодовую базу на Go/Kotlin"


                                                                          P.S. плюсиков добавил — интересный диалог

                                                                            –1

                                                                            Не, ну понятное дело что cgi удобнее демона по части забивания болтов на утечки памяти, отсюда и любовь к "классическим связкам". Но с другой стороны тут претензии были выше от mayorovp к тому, что PHP не умеет вообще никак иначе.


                                                                            Ну и, думаю, довольно странно при таком количестве технологий закрывать на это глаза и рефлексом ставить "sudo apt install php-fpm". Для какого-нибудь хоумпейджа никто не запрещает поэкспериментировать с другими технологиями, которые могут вполне оказаться и удобнее в оркестарии и стабильнее.


                                                                            P.S. Для бложиков я уже поднимал sqlite и могу сказать, что разницы с mysql вообще не заметно (при такой-то нагрузке, которой особо и нет). А это значит, что на VPS можно вполне минуснуть пол гига оперативы и кусок места на харде, просто избавившись от mysql в пользу локальной sqlite.


                                                                            Тоже касается и React + Swoole (другое не проверял). Полёт вполне себе нормальный. Так что уже начинаю воспринимать не как "модную шняжку", а как вполне себе рабочее решение, которое можно и на чуть более серьёзных проектах использовать.

                                                                              0

                                                                              Бывает же. Первый раз вчера за 8 месяцев работы прилетела задачка оценить разработку почти стороннего для основной системы демо-сайт, даже без технической интеграции любой, чисто брендовость общая. Прочитал ваш комент в 2 часа ночи и до 7 утра экспериментировал со  Swoole.  Поднял в докере http/ws сервер. чатик в памяти — вроде работает. Впечатление двойственное: давно такое низкоуровневое и, я бы сказал, процедурное чуть ли не PHP3, и без поддержки в IDE нормальной не писал (ide-helper помогает, но не сильно — они сами признают, что он минимальный, но развивать нет ресурсов особо). И документация какая-то специфичная для таких проектов.


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

                                                                                +1

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


                                                                                Так что лично я бы выбрал лучше React (если о качестве исходников говорить) или Amp (если об удобстве использования).

                                                                                  0
                                                                                  А Workerman не вариант?
                                                      +2
                                                      php-cli через supervisord? :)
                                                      И забудете о всех межпроцессорных штуках
                                                      Нужно пообщаться между скриптами — memcached, реббит, редис
                                                        0
                                                        а почему забыть? IPC вроде есть под PHP
                                                          0

                                                          По памяти он именно "вроде", просто биндинги

                                                      –1
                                                      Отвратительный перевод. Если вы постите перевод статьи из гуглтранслейта — это плохо. Хотя бы вычитывайте после автоперевода статью.

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

                                                      Самое читаемое