vasIvas: да, обычно рядом с сервисами, и да мне пока не нравится. К сожалению лучше пока ничего нет, альтернатива - написать свой примитивный дата мэппер и ворах кастылей. Но для 99% проектов на фронтэнде все это не надо, так как там процент бизнес логики в сущностях (а именно это предоставляет js-data, сущности а не модель) незначительный, тупо UI и тонкий слой бизнес логики.
XenK: говорю вам это на личном опыте, по трудозатратам это намного проще. Есть отдельные моменты когда нет, но из вашего вопроса не прослеживаются никаких деталей.
XenK: нужен. Вы можете конечно взять ratchet для reactphp, как единственную адекватную реализацию которую можно юзать в продакшене, но проще поставить рядом ноду, поставить pub/sub и жить себе спокойно.
Алексей Нечаев: ну просто кто-то делал карту. скорее всего в рамках опроса кто чем пользуется и кто собирается что-то еще учить помимо java.
В целом как хотите, вы хотели пример структурированной информации что для чего и тд. майд мэпы самое то для этого. И да, всего много. С годами будете знать в чем отличия и т.д. Так сразу это всеравно займет много времени да и нет смысла учить все. Просто выбираете самое мэйнстримное и юзаеете. Постепенно узнаете что-то новое и т.д.
Это все всего-лишь инструменты. Главное понимать суть, the big picture. Если вы пишите на java то всеравно занимаетесь чем-то конкретным, будь то десктоп, мобильщика или web. Все слишком сильно отличается что бы знать вообще все.
Алексей Нечаев: эта карта приводит лишь кусочек, относящийся к web. Есть еще куча всего. Но вообще хорошей идеей будет составить свою карту, так удобнее информацией управлять.
Dmitry Shvalyov: нет, каждая директива получает один и тот же сервис на всех. Более того, сервис сам по себе не должен в идеале сохранять состояние (только если от него это требуется). Вы можете сделать сервис-фабрику которая будет делать инстансы для каждой директивы столько столько она попросит. Как пример можете посмотреть на реализацию $cacheFactory
yokotoka: словом для меня главное преимущетсво разделения приложение на контейнеры - меньше бойлерплейта и тупой фигни, я не хочу тратить время на прописывание в Dockerfile кучи bash-скриптов что бы поставить все зависимости. Я хочу сделать docker pull redis и все.
yokotoka: как по мне нет разницы, сбэкапить один слой по крону или два (мы же data-volumes будем бэкапить а не базу там или контейнер). Разворачивание так же простое.
Я не вижу преимуществ. Год назад да, преимущество было ибо docker-compose (или даже fig тогда) были довольно тупыми штуками которые не позволяли делать дела нормально и приходилось писать bash скрипты. Для простых проектов оно так норм, но только в контексте быстрого деплоя.
Сейчас, когда docker-compose стал более-менее функциональным и удобным, намного выгоднее делать все как маленькие части. Скажем захотели вы подключить redis в качестве кэша - не вопрос, ставим рядом контейнер, линкуем и готово. А так надо будет пересобирать контейнер с приложением, базой и прочим. А мы просто хотели быстро замутить счетчик просмотров или еще какую-нибудь хрень.
Что до бэкапов - дата-волумы это хорошая абстракция, нам пофиг что мы бэкапим. Будь то база данных, файлы или еще что. А если нет разницы, при плюсах которые дают разбиение на компоненты, лучше последнее.
