Здравствуйте, Подскажите, как по-итогу ощущается после года эксплуатации? Есть какие-то существенные проблемы/минусы/неудобства в пользовании и в администрировании?
Если вы уперлись в ресурсы при использовании FPM, и при этом у вас требования как у высоконагруженного приложения с возможностью асинхронной обработки огромного кол-ва запросов и асинхронной передачи их в дальнейшие сервисы.. То почему просто не сменить инструмент на "нормальный" (в рамках необходимых требований), например тот же GO?
Считаю, что переучивать разработчиков которые годами росли в контексте "PHP рождён, чтобы умереть" с синхронным исполнением кода, на асинхронщину на том же PHP - это дорога в никуда. На рынке очень мало востребованных позиций с асинхронным PHP, и на рынке будет очень сложно найти квалифированного PHP разработчика имеющего опыта %костыль% и умеющего в асинхронщину (удачи).
А вот если говорим про тот же Go (или другой подобный инструмент), то тут сразу понятно, что такой разработчик умеет в асинхронщину, во всякие mutex, потоки, и прочее.. И в таком случае, эффективность решения будет в разы выше, чем костыли (swoole, gorunner и прочее) на PHP. Потому-что на "нормальном" инструменте (опять-таки Go), сможете намного лучше утилизировать доступные ресурсы.
Поэтому, если так сложилось, что в компании только PHP разработчики.., считаю перспективным решением найти пару разработчиков на "нормальном" инструменте в компанию, и вокруг них уже организовать процессы обучения php разработчиков в "нормальный" инструмент.
Лучше немного побуксовать на старте (смена стека), чем потом докупать пачками сервера под PHP, и каждого нового PHP разработчика обучать мертворождённым костылям.
Если PHP претендует на OOP с SOLID, тогда почему они немогут реализовать нормальное ковариантное наследование как в других языках. Вместо этого зачем-то делают костыли в виде нарушения принципа Лисков. Можно еще ознакомится с этим PR и отношением PHP сообщеситва к таким изменениям.
Здравствуйте,
Подскажите, как по-итогу ощущается после года эксплуатации? Есть какие-то существенные проблемы/минусы/неудобства в пользовании и в администрировании?
Если вы уперлись в ресурсы при использовании FPM, и при этом у вас требования как у высоконагруженного приложения с возможностью асинхронной обработки огромного кол-ва запросов и асинхронной передачи их в дальнейшие сервисы.. То почему просто не сменить инструмент на "нормальный" (в рамках необходимых требований), например тот же GO?
Считаю, что переучивать разработчиков которые годами росли в контексте "PHP рождён, чтобы умереть" с синхронным исполнением кода, на асинхронщину на том же PHP - это дорога в никуда. На рынке очень мало востребованных позиций с асинхронным PHP, и на рынке будет очень сложно найти квалифированного PHP разработчика имеющего опыта %костыль% и умеющего в асинхронщину (удачи).
А вот если говорим про тот же Go (или другой подобный инструмент), то тут сразу понятно, что такой разработчик умеет в асинхронщину, во всякие mutex, потоки, и прочее.. И в таком случае, эффективность решения будет в разы выше, чем костыли (swoole, gorunner и прочее) на PHP. Потому-что на "нормальном" инструменте (опять-таки Go), сможете намного лучше утилизировать доступные ресурсы.
Поэтому, если так сложилось, что в компании только PHP разработчики.., считаю перспективным решением найти пару разработчиков на "нормальном" инструменте в компанию, и вокруг них уже организовать процессы обучения php разработчиков в "нормальный" инструмент.
Лучше немного побуксовать на старте (смена стека), чем потом докупать пачками сервера под PHP, и каждого нового PHP разработчика обучать мертворождённым костылям.
Проще уж выбрать PHP, всё тоже самое, только нет проблем с нагрузкой и есть рынок кандидатов
Ответ на вопрос?)
Если PHP претендует на OOP с SOLID, тогда почему они немогут реализовать нормальное ковариантное наследование как в других языках. Вместо этого зачем-то делают костыли в виде нарушения принципа Лисков. Можно еще ознакомится с этим PR и отношением PHP сообщеситва к таким изменениям.
Используйте ORM для CRUD. А для всего остального QueryBuilder.