tysch_tysch
Он вам не клоун!

По технической реализации xgm

Добавлен , опубликован
Тема
Dev
По технической реализации

Другие темы:

По ux/usability сайта / дизайн
Обсуждение DT
Контентная стратегия

Текущие проблемы:

  1. Огромная база данных, терять которую бы не хотелось
  2. Архитектура форума построена на одном старом форуме и это усложняет работу
  3. Нет ресурсов
  4. Сайт не адаптируется под мобильники
  5. Любое новое решение надо интегрировать с текущей инфраструктурой
  6. Возможно нужно возвродить в том или ином виде форум
  7. Нужна вики

Для чего этот тред?

  1. Предложит свою помощь
  2. Предложить то или иное техническое решение в части инфраструктуры

Обсуждаемые решения

Форум

xf2demo.xenforo.com
https://discuss.flarum.org
Открыть текущий

Система чатов вместо оффтопки

Открытые аналоги Slack
https://rocket.chat
https://about.mattermost.com
Инквизитор
Это форумный движок номер один на данный момент. Создан выходцами из воблы, но быстро отнявшие первое место у нее же. Щас идет девелопер превиев у второй ветки движка. xf2demo.xenforo.com
ВСЕ современные форумы охотно переносят свои ресурсы на рельсы ксена. По опыту администрирования форумов на этом движке скажу, что более быстрого и удобного форумного движка не существует. И тк я интересуюсь им, могу сказать, что на нем возможно запилить, что угодно. Он вордпресс из мира форумных движков.
alexprey
Инквизитор, а ты не понимаешь, что значит мейнейнить сайт на котором уже данных в базе на несколько десятков гигабайт =_= ты знаешь как это выглядит снаружи, но совершенно не разбираешься видимо во внутренностях.
H
xf2demo.xenforo.com
та же параша из 2000 годов. Ничего нового. Есть гораздо интереснее варианты:
https://discuss.flarum.org
пример:
https://community.letsencrypt.org
но один фиг никто не будет xgm на форум переносить =)
25 мар 2017
5 770
`
ОЖИДАНИЕ РЕКЛАМЫ...

Показан только небольшой набор комментариев вокруг указанного. Перейти к актуальным.
1
Показать
35
1
Показать
Попробуйте немного может наивно и слишком агрессивно, но попробую такую стратегию сформулировать:
Что если xgm оставить только приложением, которые хранит данные о профиле пользователя (опыте, абилках), а весь остальной необходимый в доработке функционал делать отдельными (если сторонними, то опенсорс) приложениями (чат, форум, багтрекер?, новостную ленту и прочее), в которые в свою очередь авторизация поизводится через xgm.
Тем самым решаются проблемы:
  1. Нет необходимости сосредотачивать всё у себя, специализированные сторонние приложения будут всегда лучше из-за количества вложенных в них часов и опыта
  2. Нет смысла поддерживать старый код в местах, которые можно вынести вне основного приложения
  3. В случае устаревания функционала приложения его можно просто «выкинуть» портировав пользовательские данные во что-то новое (это сложный момент)
Минусы:
  1. Разные стили кода — разные проблемы
  2. опенсорс — наличие известных эксплоитов, в закрытом коде их надо искать
  3. Фрагментация
  4. Ограничиность передаваемых данных между приложениями. Например нужно передавать статус пользователя (заблокирован, пользователь, модератор, админ) помомимо логина — это отдельный код на каждое приложение.
  5. Отсутствие синхронизации между приложениями (иначе надо городить громоздкие обмены данными и их поддерживать)
1
Показать
29
1
Показать
ZlaYa1000, классический подход микросервисной архитектуры. Очень трудозатратный.
0
Показать
35
0
Показать
alexprey:
ZlaYa1000, классический подход микросервисной архитектуры. Очень трудозатратный.
Трудозатратный почему? Из-за поддержки множественных обменов? А если держать только логин как объединяюще? Можно где-то почитай больше?
0
Показать
29
0
Показать
ZlaYa1000,
Легко если приложения не интегрируются друг в друга. Но если понадобится интегрировать все в себя то тут начинается разрастание кучи API, потом при расширении функциональности начинается возня с обратной совместимостью, порядком релиза модулей. Разведение зоопарка из технологий и т.д.
0
Показать
28
0
Показать
ZlaYa1000, и данный подход по сути может лишать тебя одной важной вещи - основного потока трафика.
0
Показать
35
0
Показать
Jusper,
ZlaYa1000, и данный подход по сути может лишать тебя одной важной вещи - основного потока трафика.
каким образом? Чтобы попасть в любой микросервис надо авторизоваться через xgm. Да с мобилки например можно не выходить из приложения чата для взаимодействия с сообществом, но это скорее наоборот совсем не проблема.
0
Показать
28
0
Показать
ZlaYa1000, а логин запомнить нельзя что ли :)
Логично же, что трафик будет висеть на микросервисе, а не на центровой базе.
0
Показать
35
0
Показать
Jusper:
ZlaYa1000, а логин запомнить нельзя что ли :)
Логично же, что трафик будет висеть на микросервисе, а не на центровой базе.
у тебя будет 10 пар логин\пароль: xgm-чат, xgm-блог, xgm-форум и т.п. Вроде взаимоинтегрировать всё это в сайт проблемы нет, но чем больше данных интегрировать тем больше гемороя, да.
0
Показать
29
0
Показать
ZlaYa1000, тогда вообще теряется смысл самого хгм, для идентификации можно использовать и вк например
0
Показать
25
0
Показать
Есть гораздо интереснее варианты:
https://discuss.flarum.org
пример:
https://community.letsencrypt.org
Господи, какое же неудобное говно.
Может с мобилки оно еще ок, даже лень смотреть, но с бука выглядит как лютый высер.
ZlaYa1000:
Что если xgm оставить только приложением, которые хранит данные о профиле пользователя (опыте, абилках), а весь остальной необходимый в доработке функционал делать отдельными (если сторонними, то опенсорс) приложениями (чат, форум, багтрекер?, новостную ленту и прочее), в которые в свою очередь авторизация поизводится через xgm.
Нормальная тема. Главное, чтобы сервисы по-максимуму соблюдали "Принцип единственной ответственности".
ZlaYa1000:
Ограничиность передаваемых данных между приложениями. Например нужно передавать статус пользователя (заблокирован, пользователь, модератор, админ) помомимо логина — это отдельный код на каждое приложение.
Отсутствие синхронизации между приложениями (иначе надо городить громоздкие обмены данными и их поддерживать)
Пишется отдельный сервис-роутер, основная цель существования которого - быть связующим звеном между другими сервисами. На нём делается нужное количество end-point"ов, на которые обращается, форум/баг трекер/сайт/по хрен что, отдавая или запрашивая нужные данные, а данный сервис знает, что со всем этим делать.
Нормальная система же, много кто так делает.
0
Показать
28
0
Показать
NanO:
много кто так делает.
Примеры в студию. Желательно из смежной сферы.
Показан только небольшой набор комментариев вокруг указанного. Перейти к актуальным.
Чтобы оставить комментарий, пожалуйста, войдите на сайт.