romasovest, вот про это я и говорил. Это плохо. Обращение к файловой системе дополнительно это в принципе плохо. Это медленно, это дополнительно нагружает диск. На проекте в 10-20 человек вы это не заметите, но под нагрузкой просто ахтунг
eliastro,
1. на мойкруг очень мало вакансий
2. Вы сравниваете довольно специфическим образом ибо про бэкэнд может и не быть указано в вакансии.
3. Вы сравнили 2 фреймворка и один язык программирования
Исследование на коленке м претензией на адекватность, но без таковой
Биллинг может состоять из нескольких микросервисов, например. Тут все зависит от деталей. В общем, в этом и состоит одна из главных задач в архитектуре - настроить потоки взаимодействия
Николай Егоров, перестаньте думать Entity first. Меня сейчас запирают всякие симфонисты, но есть только один способ правильной архитектуры бд - Database first. Нарисуйте себе EER диаграмму и от нее нарисуйте связи
xmoonlight, бизнес-процессы при внедрении технологий гарантированно изменяются, что так же влечет за собой изменение технологий. Это такой порочный круг. Поэтому интегратор не подходит - он не меняет бизнес-процессы. А вот результат работы интегратора влечет за собой изменение процессов как следствие. Только при такой последовательности обычно бывает больно. Поэтому в идеале нужен CTO
xmoonlight, интегратор не занимается бизнес-процессом. Он занимается созданием технологических решений по требованию заказчика, что и является, как правило, узким местом. Уровень компетенции заказчика часто очень низок.
Про Compose не знаю, я с ним не разбирался. Про AWS могу рассказать отдельно много интересного, но там половину наработанных знаний приходится в помойку выкидывать и приобретать новые. Там другие подходы. Но он однозначно того стоит - я сдаю уже вторую сертификацию по нему. Но он не дешев в целом - всегда можно сделать дешевле, но при этом пожертвовать надежностью.
Админить все это не сложно, от слова совсем. Оно же все из коробки ставится и многим компаниям хватает так.
Redis имеет такие возможности, но я пока с нему отношусь скептически. Не слышал еще ни на одном крупном докладе вроде Highload++ или Devoxx чтобы кто-то серьезно говорил про их pub/sub. Все за RMQ, Kafka и AWS SQS/SNS. У AWS есть сервис ElastiCache где можно выбрать Memcached или Redis. Делаем выводы из названия)
riddlr, во-первых брокер ничего сам по себе не отправляет. Он кладет сообщение в очередь из которой обработчики из забирают. Есть push и pull варианты. Разбираться в Rabbit MQ проще простого - у них прекрасный мануал на сайте. Когда он мне понадобился я потратил всего лишь час на то чтобы в принципе начать с ним работать и не больше 10 часов суммарно когда стал ковыряться в плагинах и безопасности.
В принципе идея основная такова что у вас есть апи для постинга сообщений, и есть клиенты. Клиентов много, они могут быть подписаны на разные группы сообщений, а кроме WS клиента у вас потом может понадобиться делать Push Notifications, например, в браузер или приложение. Поэтому архитектуру надо сразу строить с низкой связанностью. Вы можете поставить любое число обработчиков с разной логикой и делать с одним и тем же сообщением сколько угодно логических операций.
REST API просто кладет сообщение в очередь "у меня новое сообщение. Разберитесь кому надо. Данные прилагаю". Понятное дело что все в JSON
И, кстати, меня закидают камнями, но Rabbit MQ куда проще чем Kafka, но они оба решают свои задачи.
riddlr, очень любопытно, но жесть как не надежно) ибо если у вас один сокет-сервер то он может упасть по любой причине, не удивляйтесь. Советую между API и Socket.io поставить Message Broker. Для надежности, можно сказать. Еще и удобнее потом будет развивать систему
Вы указали несколько вещей - приложение, REST api, бд и socket. Попробую предположить что у вас есть REST API, которое оперирует данными в БД и вы хотите прикрутить сбоку сокеты. Есть несколько вариантов решения, но есть вопрос - чего вы пытаетесь добиться сокетами?
