Чат с применением очереди сообщений?

Игорь, зависит от того какой чат пишется, с какими знаниями, под какие нагрузки и на какой инфраструктуре

Чат с применением очереди сообщений?

Игорь, устарел как мир по тому что XML

Правильный ли выбор в сторону Serverless в моей ситуации?

Максим,

А я пока даже и не думал на платные тарифы подключаться)

это так не работает

Правильный ли выбор в сторону Serverless в моей ситуации?

Максим, Да я сам их люблю, более того, у меня есть примеры как люди без технической подготовки делали проекты на serverless. Просто я сразу хочу обозначить риски. Если есть необходимость то я могу отдельно рассказать поверхностно про мир Serverless сегодня. Он-то уже большой, но хватает важных моментов. С одной оговоркой - в Serverless я амбаcсадор AWS)

Правильный ли выбор в сторону Serverless в моей ситуации?

Максим, а в Serverless будет много конфигураций, несколько десятков сервисов, постоянный мониторинг биллинга (не получилась ли лишняя тысяча долларов вчера), выбор вендоров, сетевые издержки и невозможность обработать огромные объемы данных дешево) Обязанностей только же, просто они другие. А ошибки будут более явные и они будут бить не по самолюбию, а по кошельку)

Правильный ли выбор в сторону Serverless в моей ситуации?

Максим, выстрел в ногу будет в любом случае. Говнокод толе будет в любом случае. Вопрос скорее в том какие цели преследуются. Если цель стать хорошим разработчиком то Serverless будет отсутствовать на пути до конца. Если запустить проект то он может рассматриваться как опция.

Есть ли вариант лучше чем делать random?

beduin01, можно распараллелить процесс, не потребуется изменять базу данных

Можно ли получить доступ к API Easypay, не заключая договор?

vyr0d0k, это нелегально вообще-то

Как правильно делпоить на AWS?

Вальдемар Сидельский, тут не достаточно одного пруфа. Тут надо чтобы было хоть какое-то подобие архитектуры чтобы доказательно человеку расписать это. Можно дать ему книгой по голове про SDLC любой. Или про software Architecture

Чат с применением очереди сообщений?

Игорь,

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

Стоит почитать про exact-one-delivery, at-least-one-delivery и at-most-one-delivery и узнать что:

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

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

подтверждение доставки

это делается в принципе на системе событий (читать про Event Sourcing). И опять же, очереди тут не при чем, но опять-же кто я такой чтобы отговаривать)

В чем точно помогут очереди:

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

могу разве что посоветовать до кучи открыть на ютубе тонны разных вариантов архитектур чатов и выбрать что-то для себя

Чат с применением очереди сообщений?

Игорь, Да все можно. Просто при росте чата MySQL масштабировать тяжелее чем просто добавить очередей. Данные они всегда добавляют трудностей. А что до очередей то там еще вопрос какой брокер использовать.

Чат с применением очереди сообщений?

Игорь, Какую задачу она будет решать на одном сервере? Правильно, никакую. На одном сервере все прекрасно работает in-memory

Не могу подключится к socket io с хостинга, проблемы с HTTPS?

andrey_27081,

ssl именно на ip сервера

невозможно

По этому не знаю что тут предпринять

Перестать пользоваться кастомными портами. Есть только https и wss и под них порты фиксированы

Как запушить каталог миграций на проект в гитхабе?

Ветку проверь

Какое архитектурное решение выбрать для ролей пользователей?

snchz,

Как считаете, есть ли "панацея" от этого всего...?

No silver bullet in this world

Делить сейчас на сервисы будет больно.

Я и не призываю, просто говорю как есть. Если что то стоимость разделения монолита на SOA/MSA растет экспоненциально с каждой внедренной фичой.

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

Не хочется - не надо. Мы тут не можем указывать кому-то что делать и чего не делать.

Я сейчас сомневаюсь в правильности дальнейших решений

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

прошу оценить мое решение в данной ситуации

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

Какое архитектурное решение выбрать для ролей пользователей?

snchz, мои соболезнования

Какое архитектурное решение выбрать для ролей пользователей?

Александр Лыкасов, все хорошо кроме того факта что сущность User работает только в монолитах. В SOA/MSA этой сущности нет

Чат с применением очереди сообщений?

Игорь, ага

Какое архитектурное решение выбрать для ролей пользователей?

snchz, разноцелевые интерфейсы это нормально, могут быть хоть разные системы) это на само деле не важно. А вот описание действительно показывает что есть проблема и надо собирать обратную связь со всех пользователей чтобы лучше сформировать роли и права. Как уже писали стоит посмотреть в сторону BDD как минимум.

Про таблицы - тут будет скорее всего мало этого. При таких разных правах напрашивается SOA

Какое архитектурное решение выбрать для ролей пользователей?

snchz, Список аргументов в студию