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

Другие темы:

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

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

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

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

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

Форум

xf2demo.xenforo.com
Открыть текущий

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

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

Показан только небольшой набор комментариев вокруг указанного. Перейти к актуальным.
0
29
7 лет назад
0
ZlaYa1000,
Легко если приложения не интегрируются друг в друга. Но если понадобится интегрировать все в себя то тут начинается разрастание кучи API, потом при расширении функциональности начинается возня с обратной совместимостью, порядком релиза модулей. Разведение зоопарка из технологий и т.д.
0
28
7 лет назад
0
ZlaYa1000, и данный подход по сути может лишать тебя одной важной вещи - основного потока трафика.
0
35
7 лет назад
0
Jusper,
ZlaYa1000, и данный подход по сути может лишать тебя одной важной вещи - основного потока трафика.
каким образом? Чтобы попасть в любой микросервис надо авторизоваться через xgm. Да с мобилки например можно не выходить из приложения чата для взаимодействия с сообществом, но это скорее наоборот совсем не проблема.
0
28
7 лет назад
0
ZlaYa1000, а логин запомнить нельзя что ли :)
Логично же, что трафик будет висеть на микросервисе, а не на центровой базе.
0
35
7 лет назад
0
Jusper:
ZlaYa1000, а логин запомнить нельзя что ли :)
Логично же, что трафик будет висеть на микросервисе, а не на центровой базе.
у тебя будет 10 пар логин\пароль: xgm-чат, xgm-блог, xgm-форум и т.п. Вроде взаимоинтегрировать всё это в сайт проблемы нет, но чем больше данных интегрировать тем больше гемороя, да.
0
29
7 лет назад
0
ZlaYa1000, тогда вообще теряется смысл самого хгм, для идентификации можно использовать и вк например
0
25
7 лет назад
0
Есть гораздо интереснее варианты:
пример:
Господи, какое же неудобное говно.
Может с мобилки оно еще ок, даже лень смотреть, но с бука выглядит как лютый высер.
ZlaYa1000:
Что если xgm оставить только приложением, которые хранит данные о профиле пользователя (опыте, абилках), а весь остальной необходимый в доработке функционал делать отдельными (если сторонними, то опенсорс) приложениями (чат, форум, багтрекер?, новостную ленту и прочее), в которые в свою очередь авторизация поизводится через xgm.
Нормальная тема. Главное, чтобы сервисы по-максимуму соблюдали "Принцип единственной ответственности".
Ограничиность передаваемых данных между приложениями. Например нужно передавать статус пользователя (заблокирован, пользователь, модератор, админ) помомимо логина — это отдельный код на каждое приложение.
Отсутствие синхронизации между приложениями (иначе надо городить громоздкие обмены данными и их поддерживать)
Пишется отдельный сервис-роутер, основная цель существования которого - быть связующим звеном между другими сервисами. На нём делается нужное количество end-point"ов, на которые обращается, форум/баг трекер/сайт/по хрен что, отдавая или запрашивая нужные данные, а данный сервис знает, что со всем этим делать.
Нормальная система же, много кто так делает.
0
28
7 лет назад
0
много кто так делает.
Примеры в студию. Желательно из смежной сферы.
0
30
7 лет назад
0
Jusper, ну, хайв...
0
28
7 лет назад
0
ну, хайв...
Там все слито в одну экосистему.
Пользователь не чувствует, что переходит в другой сервис.
Если Тыща это имел ввиду в своем предложении, то ок. Но все еще остается проблема поддержки и развития большого количества сервисов.
0
25
7 лет назад
Отредактирован KotoBog
0
Там все слито в одну экосистему.
Пользователь не чувствует, что переходит в другой сервис.
Если Тыща это имел ввиду в своем предложении, то ок. Но все еще остается проблема поддержки и развития большого количества сервисов.
Что в данном контексте подразумевается под "чувствует"?)
Натягиваешь везде один схожий дизайн, делаешь поддомены forum.xgm.guru, vodka.xgm.guru итд на каждый сервис с единой сессией и авторизацией да и все.
Реализация не сложная, хоть и трудоёмкая, поддерживать, по сути, с какой-то стороны проще, на самом то деле, чем когда все слито в кучу и ты не понимаешь, где именно баг, в чем проблема и куда лезть, чтобы добавить новую кнопочку или плагин.
Показан только небольшой набор комментариев вокруг указанного. Перейти к актуальным.
Чтобы оставить комментарий, пожалуйста, войдите на сайт.