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

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

Другие темы:

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

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

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

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

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

Форум

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

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

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

 

Просмотров: 1 350

ZlaYa1000 #1 - 1 год назад 0
Попробуйте немного может наивно и слишком агрессивно, но попробую такую стратегию сформулировать:
Что если xgm оставить только приложением, которые хранит данные о профиле пользователя (опыте, абилках), а весь остальной необходимый в доработке функционал делать отдельными (если сторонними, то опенсорс) приложениями (чат, форум, багтрекер?, новостную ленту и прочее), в которые в свою очередь авторизация поизводится через xgm.
Тем самым решаются проблемы:
  1. Нет необходимости сосредотачивать всё у себя, специализированные сторонние приложения будут всегда лучше из-за количества вложенных в них часов и опыта
  2. Нет смысла поддерживать старый код в местах, которые можно вынести вне основного приложения
  3. В случае устаревания функционала приложения его можно просто «выкинуть» портировав пользовательские данные во что-то новое (это сложный момент)
Минусы:
  1. Разные стили кода — разные проблемы
  2. опенсорс — наличие известных эксплоитов, в закрытом коде их надо искать
  3. Фрагментация
  4. Ограничиность передаваемых данных между приложениями. Например нужно передавать статус пользователя (заблокирован, пользователь, модератор, админ) помомимо логина — это отдельный код на каждое приложение.
  5. Отсутствие синхронизации между приложениями (иначе надо городить громоздкие обмены данными и их поддерживать)
alexprey #2 - 1 год назад 0
ZlaYa1000, классический подход микросервисной архитектуры. Очень трудозатратный.
ZlaYa1000 #3 - 1 год назад 0
alexprey:
ZlaYa1000, классический подход микросервисной архитектуры. Очень трудозатратный.
Трудозатратный почему? Из-за поддержки множественных обменов? А если держать только логин как объединяюще? Можно где-то почитай больше?
alexprey #4 - 1 год назад 0
ZlaYa1000,
Легко если приложения не интегрируются друг в друга. Но если понадобится интегрировать все в себя то тут начинается разрастание кучи API, потом при расширении функциональности начинается возня с обратной совместимостью, порядком релиза модулей. Разведение зоопарка из технологий и т.д.
Jusper #5 - 1 год назад 0
ZlaYa1000, и данный подход по сути может лишать тебя одной важной вещи - основного потока трафика.
ZlaYa1000 #6 - 1 год назад 0
Jusper,
ZlaYa1000, и данный подход по сути может лишать тебя одной важной вещи - основного потока трафика.
каким образом? Чтобы попасть в любой микросервис надо авторизоваться через xgm. Да с мобилки например можно не выходить из приложения чата для взаимодействия с сообществом, но это скорее наоборот совсем не проблема.
Jusper #7 - 1 год назад 0
ZlaYa1000, а логин запомнить нельзя что ли :)
Логично же, что трафик будет висеть на микросервисе, а не на центровой базе.
ZlaYa1000 #8 - 1 год назад 0
Jusper:
ZlaYa1000, а логин запомнить нельзя что ли :)
Логично же, что трафик будет висеть на микросервисе, а не на центровой базе.
у тебя будет 10 пар логин\пароль: xgm-чат, xgm-блог, xgm-форум и т.п. Вроде взаимоинтегрировать всё это в сайт проблемы нет, но чем больше данных интегрировать тем больше гемороя, да.
alexprey #9 - 1 год назад 0
ZlaYa1000, тогда вообще теряется смысл самого хгм, для идентификации можно использовать и вк например
NanO #10 - 1 год назад 0
Есть гораздо интереснее варианты:
пример:
Господи, какое же неудобное говно.
Может с мобилки оно еще ок, даже лень смотреть, но с бука выглядит как лютый высер.
ZlaYa1000:
Что если xgm оставить только приложением, которые хранит данные о профиле пользователя (опыте, абилках), а весь остальной необходимый в доработке функционал делать отдельными (если сторонними, то опенсорс) приложениями (чат, форум, багтрекер?, новостную ленту и прочее), в которые в свою очередь авторизация поизводится через xgm.
Нормальная тема. Главное, чтобы сервисы по-максимуму соблюдали "Принцип единственной ответственности".
Ограничиность передаваемых данных между приложениями. Например нужно передавать статус пользователя (заблокирован, пользователь, модератор, админ) помомимо логина — это отдельный код на каждое приложение.
Отсутствие синхронизации между приложениями (иначе надо городить громоздкие обмены данными и их поддерживать)
Пишется отдельный сервис-роутер, основная цель существования которого - быть связующим звеном между другими сервисами. На нём делается нужное количество end-point"ов, на которые обращается, форум/баг трекер/сайт/по хрен что, отдавая или запрашивая нужные данные, а данный сервис знает, что со всем этим делать.
Нормальная система же, много кто так делает.
Jusper #11 - 1 год назад 0
много кто так делает.
Примеры в студию. Желательно из смежной сферы.
Jusper #13 - 1 год назад 0
ну, хайв...
Там все слито в одну экосистему.
Пользователь не чувствует, что переходит в другой сервис.
Если Тыща это имел ввиду в своем предложении, то ок. Но все еще остается проблема поддержки и развития большого количества сервисов.
NanO #14 - 1 год назад (отредактировано ) 0
Там все слито в одну экосистему.
Пользователь не чувствует, что переходит в другой сервис.
Если Тыща это имел ввиду в своем предложении, то ок. Но все еще остается проблема поддержки и развития большого количества сервисов.
Что в данном контексте подразумевается под "чувствует"?)
Натягиваешь везде один схожий дизайн, делаешь поддомены forum.xgm.guru, vodka.xgm.guru итд на каждый сервис с единой сессией и авторизацией да и все.
Реализация не сложная, хоть и трудоёмкая, поддерживать, по сути, с какой-то стороны проще, на самом то деле, чем когда все слито в кучу и ты не понимаешь, где именно баг, в чем проблема и куда лезть, чтобы добавить новую кнопочку или плагин.
Jusper #15 - 1 год назад 0
делаешь поддомены
Хайв не использует поддомены.
NanO #16 - 1 год назад (отредактировано ) 0
Хайв не использует поддомены.
И? Окей, пусть будет xgm.guru/forum xgm.guru/vodka xgm.guru/anythingelse
С ними удобнее, поэтому и написал, но это моё имхо.
alexprey #17 - 1 год назад (отредактировано ) 2
трудоёмкая
в этом и проблема
поддерживать, по сути, с какой-то стороны проще, на самом то деле
не совсем, надо локализовать сперва в каком это сервисе, из-за какого API затем это вылазит, потом пофиксить тот API или его расширить из-за не хватки данных, потом его выкатить, потом пофиксть обработку этого API и потом обновить этот сервис.
когда все слито в кучу и ты не понимаешь, где именно баг, в чем проблема и куда лезть
Даже в такой помойке как код в8, это делается достаточно просто. Не сам фикс, а нахождение бага. Баг локализовать просто, сложно пофиксить в некоторых случаях из-за отвратной не структурированной архитектуры.
Все сложно поддерживать если нету четкой и структурированной архитектуры. Можно заделать кучу микросервисов, но толку, если они будут не правильно структурированы. Проблема в текущем решении ХГМ - это использование его как песочницы. Потому что большинство фич которые прикручивались - это лишь способ попробовать что-то новое из технологий или в программировании. Отсюда и появляется функционал которым пользуется 1 или 2 пользователя, который ничего не дает, в нем куча багов, структура кривая и непонятное, потому что автор просто хотел поиграться с новой технологией.

По личному опыту поддержки и разрботки высоконагруженных распределенных систем, развивать микросервисную архитектуру, а тем более отлаживать в случае заковыристых багов очень сложно. Вот у нас тут есть пайплайн из уже почти 10 разных микросервисов и иногда понять в какой момент отвалились данные, весьма сложно. А потом еще и исправить это, особенно если фикс приходится на несколько сервисов, достаточно проблемно.
В этом есть несомненнно плюсы, но не при разработке портала как например хгм, оно того не стоит. Потому что все это сольется опять же в ту же кашу. Смотрите пункт про песочницу
Clamp #18 - 1 год назад 0
Даже в такой помойке как код в8, это делается достаточно просто. Не сам фикс, а нахождение бага. Баг локализовать просто, сложно пофиксить в некоторых случаях из-за отвратной не структурированной архитектуры.
Все сложно поддерживать если нету четкой и структурированной архитектуры. Можно заделать кучу микросервисов, но толку, если они будут не правильно структурированы. Проблема в текущем решении ХГМ - это использование его как песочницы. Потому что большинство фич которые прикручивались - это лишь способ попробовать что-то новое из технологий или в программировании. Отсюда и появляется функционал которым пользуется 1 или 2 пользователя, который ничего не дает, в нем куча багов, структура кривая и непонятное, потому что автор просто хотел поиграться с новой технологией.
Слышу крик души
ZlaYa1000 #19 - 1 год назад 0
Идея микросервисной архитектуры в том, чтобы эти сервисы самостоятельно не разрабатывать, а разрабатывать с сообществом этого сервиса: раньше известны баги, апдейты, но отсюда ограничение кастомизации, лишние свистелки-перделки от сообщества.
короче накатил путинки, развернул коробочек, настроил между них мосты интегрировал в общую верстку по аналогии с xgm.guru/shoutbox и радуешься, как Кет. Плюс коробочек, что у них могут быть свои мобильные приложения, но вон джаспер это и минусом считает, потому что люди вообще перестанут на сайт заходить.
Doc #20 - 1 год назад (отредактировано ) 2
Я знаю что это не особо нужно но из модных форумов есть еще github.com/discourse/discourse
Не знаю спиздил дискорс у фларума дизайн или наоборот но они очень похожи, например
alexprey #21 - 1 год назад 0
Слышу крик души
да, так и есть