romy4: IoC в Symfony отличный, точнее там контейнер зависимостей. Он умеет все что только можно. Но вопрос в удобстве, для большинства проектов такие вещи как приватные сервисы или компайл пасы просто не нужны. Правда с учетом того что появился автовайринг то в принципе работать с ним стало удобее. В Laravel IoC попроще просто и от того удобнее для небольших проектов. А вы ж микросервисы планируете...
romy4: ну зато скорость разработки выше. Я просто в запросах на чтение использую напрямую DBAL и мэплью данные на DTO, со сложными запросами это удобно и эффективно. А на простых проектах доктрина дико удобно (если разобраться как с ней работать, она по сравнению с другими ORM несет в себе много сложных концепций).
OnYourLips: ну логики тут нет по сути, просто описание что делать, а как - это все детали.
copal: да, просто PHP объекты какие-то которые делают что-то полезное. Фреймворки типа Laravel это UI фреймворки, они вашему приложению добавляют UI и позволяют организовать общение, но это не само приложение.
Илья Белобородов: начинающим нужен бондаж, строгие фреймворки, TDD и жесткое код ревью. Когда они начнут понимать что делают и почему оно так, тогда можно уже разжимать тиски.
copal: и да, названия ресурсов - существительные в множественном числе. Рекомендую посмотреть для вдохновения API гитхаба например. Или черпнуть идей из jsonapi.org.
copal: по поводу контроллеров - как вам удобнее. Я обычно делаю по контроллеру на ресурс. То есть если у нас есть отдельный ресурс /friends то делаю контроллер, если это только отношение между ресурсами - делаю в том контроллере, который представляет главный ресурс (User в нашем случае).
copal: что API? Никакой разницы, с API в этом даже больше смысла, особенно в случаях когда вам надо заботиться об обратной совместимости (мобильные приложения, публичное API).
copal: давайте забудем на секундочку термин "модель" и подумаем о "сервисах". Контроллер вызывает конкретный сервис (через контейнер зависимостей) и вызывает конкретный метод. Обычно это один вызов одного метода одного сервиса на один HTTP запрос.
А внутри сервиса уже загружаем нужные сущности и работаем с ними, инкапсулируя внутри логику приложения. Читать про transaction scripts.
Иван Тимофеевич: лучше возьмите стандартный PHP7 (его можно использовать в продакшене, мы уже месяц используем и полет нормальный). Если вам нужно писать демоны - придется последить какие экстеншены вы используете, последить за потреблением памяти (некоторые экстеншены не сильно популярные любят течь) ну и т.д.
Для websockets рекомендую использовать aerys, хотя лично я предпочитаю просто использовать node.js + socket-io как шину данных между клиентом и PHP приложением.
Иван Тимофеевич: kphp - бесполезный выкидыш вконтакта, который подходит только им. hip-hop - устарел, ему на смену пришел HHVM на котором сейчас работает википедия и фэйсбук. По сути HHVM с большего полностью совместима с PHP но с точки зрения производительности она не сильно выигрывает у PHP7. Единственное что HHVM предоставляет Hack - грубо говоря PHP с дженериками, async/await, нормальными лямбдами и т.д.
По поводу mod_php - это просто SAPI для PHP интерпритатора. По сути это отдельные пакеты, если конечно не собрано все со статической линковкой. Так же и php-fpm, просто SAPI, интерфейс для взаимодействия с HTTP.
Иван Тимофеевич: если не хотите что бы PHP умирал - можете попытать счастья с amphp или php-pm. В качестве рантайма используется php-cli, сервер в этом варианте реализован на PHP (то есть неплохо сверху поставить nginx в качестве балансировщика и реверс прокси).
