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 767
`
ОЖИДАНИЕ РЕКЛАМЫ...
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:
много кто так делает.
Примеры в студию. Желательно из смежной сферы.
0
Показать
30
0
Показать
Jusper, ну, хайв...
0
Показать
28
0
Показать
Clamp:
ну, хайв...
Там все слито в одну экосистему.
Пользователь не чувствует, что переходит в другой сервис.
Если Тыща это имел ввиду в своем предложении, то ок. Но все еще остается проблема поддержки и развития большого количества сервисов.
0
Показать
25
0
Показать
Jusper:
Там все слито в одну экосистему.
Пользователь не чувствует, что переходит в другой сервис.
Если Тыща это имел ввиду в своем предложении, то ок. Но все еще остается проблема поддержки и развития большого количества сервисов.
Что в данном контексте подразумевается под "чувствует"?)
Натягиваешь везде один схожий дизайн, делаешь поддомены forum.xgm.guru, vodka.xgm.guru итд на каждый сервис с единой сессией и авторизацией да и все.
Реализация не сложная, хоть и трудоёмкая, поддерживать, по сути, с какой-то стороны проще, на самом то деле, чем когда все слито в кучу и ты не понимаешь, где именно баг, в чем проблема и куда лезть, чтобы добавить новую кнопочку или плагин.
0
Показать
28
0
Показать
NanO:
делаешь поддомены
Хайв не использует поддомены.
0
Показать
25
0
Показать
Jusper:
Хайв не использует поддомены.
И? Окей, пусть будет xgm.guru/forum xgm.guru/vodka xgm.guru/anythingelse
С ними удобнее, поэтому и написал, но это моё имхо.
2
Показать
29
2
Показать
NanO:
трудоёмкая
в этом и проблема
NanO:
поддерживать, по сути, с какой-то стороны проще, на самом то деле
не совсем, надо локализовать сперва в каком это сервисе, из-за какого API затем это вылазит, потом пофиксить тот API или его расширить из-за не хватки данных, потом его выкатить, потом пофиксть обработку этого API и потом обновить этот сервис.
когда все слито в кучу и ты не понимаешь, где именно баг, в чем проблема и куда лезть
Даже в такой помойке как код в8, это делается достаточно просто. Не сам фикс, а нахождение бага. Баг локализовать просто, сложно пофиксить в некоторых случаях из-за отвратной не структурированной архитектуры.
Все сложно поддерживать если нету четкой и структурированной архитектуры. Можно заделать кучу микросервисов, но толку, если они будут не правильно структурированы. Проблема в текущем решении ХГМ - это использование его как песочницы. Потому что большинство фич которые прикручивались - это лишь способ попробовать что-то новое из технологий или в программировании. Отсюда и появляется функционал которым пользуется 1 или 2 пользователя, который ничего не дает, в нем куча багов, структура кривая и непонятное, потому что автор просто хотел поиграться с новой технологией.
По личному опыту поддержки и разрботки высоконагруженных распределенных систем, развивать микросервисную архитектуру, а тем более отлаживать в случае заковыристых багов очень сложно. Вот у нас тут есть пайплайн из уже почти 10 разных микросервисов и иногда понять в какой момент отвалились данные, весьма сложно. А потом еще и исправить это, особенно если фикс приходится на несколько сервисов, достаточно проблемно.
В этом есть несомненнно плюсы, но не при разработке портала как например хгм, оно того не стоит. Потому что все это сольется опять же в ту же кашу. Смотрите пункт про песочницу
0
Показать
30
0
Показать
alexprey:
Даже в такой помойке как код в8, это делается достаточно просто. Не сам фикс, а нахождение бага. Баг локализовать просто, сложно пофиксить в некоторых случаях из-за отвратной не структурированной архитектуры.
Все сложно поддерживать если нету четкой и структурированной архитектуры. Можно заделать кучу микросервисов, но толку, если они будут не правильно структурированы. Проблема в текущем решении ХГМ - это использование его как песочницы. Потому что большинство фич которые прикручивались - это лишь способ попробовать что-то новое из технологий или в программировании. Отсюда и появляется функционал которым пользуется 1 или 2 пользователя, который ничего не дает, в нем куча багов, структура кривая и непонятное, потому что автор просто хотел поиграться с новой технологией.
Слышу крик души
0
Показать
35
0
Показать
Идея микросервисной архитектуры в том, чтобы эти сервисы самостоятельно не разрабатывать, а разрабатывать с сообществом этого сервиса: раньше известны баги, апдейты, но отсюда ограничение кастомизации, лишние свистелки-перделки от сообщества.
короче накатил путинки, развернул коробочек, настроил между них мосты интегрировал в общую верстку по аналогии с xgm.guru/shoutbox и радуешься, как Кет. Плюс коробочек, что у них могут быть свои мобильные приложения, но вон джаспер это и минусом считает, потому что люди вообще перестанут на сайт заходить.
2
Показать
29
2
Показать
Я знаю что это не особо нужно но из модных форумов есть еще github.com/discourse/discourse
Не знаю спиздил дискорс у фларума дизайн или наоборот но они очень похожи, например
0
Показать
29
0
Показать
Clamp:
Слышу крик души
да, так и есть
Чтобы оставить комментарий, пожалуйста, войдите на сайт.