Для вступления в общество новичков и профессионалов домен-индустрии, пожалуйста нажмите здесь ...

   
 Купля-продажа и обсуждение доменных имён
        

  
Вернуться   Форум о доменах > Дизайн и развитие проектов > Программирование
Регистрация Реноме Правила форума Справка Пользователи Социальные группы Все разделы прочитаны
Программирование PHP, Perl, HTML, XHTML, CSS, JavaScript, MySQL и другие языки кодирования.

Ответ
 
Опции темы
Сегодня
от 149р за .RU
Аренда сервера
2x Intel Hexa-Core Xeon E5-2420
Всего 79 евро!

с видеокартой GeForce GTX 1080 Ti
всего 99 евро!

от 149р за .РФ Реклама на DomenForum.net
Старый 02.07.2020, 04:33   #1
 
Аватар для buxar
 
Регистрация: 24.03.2006
Адрес: Vilnius, Lithuanian
Сообщений: 176
Доменные сделки: 0
Реноме: -19
Одобрения
Спасибо (Отдано): 1
Спасибо (Получено): 8
Свой движок - стоит ли?

Тема наверняка не раз поднималась по разным причинам и из разного ракурса.

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

Идея состоит в том, что бы объединить все существующие проекты на одном движке и создавать новые на нем же.

Силами конечно сторонних разработчиков, сам на начальном уровне.

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

Вот мне пожалуйста подскажите, есть ли в природе что-то готовое?

Мультиязычность-Мультидоменность мне подсказали есть на Вордпрес и Битрикс.

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

Второй - для меня вообще зло по моим убеждение , да и к тому же платный брать смысла не виду, если все равно в написание платных модулей придется вкладывать.

В моем понимании остается одно, вложиться в написание своего движка, отвечающего следующим требованиям:

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

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

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

Глубокая локализация- в зависимости от страны должно быть возможно не только выводить определенные модули или настройки их, но и использовать хранение данных в отдельных базах (соблюдая требования некоторых стран о хранение конфиденциальной информации в локальной стране)

API для взаимодействия между разными сайтами на этом же движке.

Ну и конечно, движок должен отвечать всем современным требованиям, это: минимальная нагрузка на хостинг, быстрая работа, безопасность, СЕО оптимизация.

В общем решение я в принципе принял, он мне нужен, только начинать с белого листа или брать за основу какой либо open source я пока не могу решить, так как 100% подходящих open source я не нашел. Но и грамотно разработать структуру думаю не каждый программист сможет, а в этом я точно профан.

Итак, делаю (чужими руками) open source и жду ваших советов.

Возможно стоит за основу взять наработки человека с ником boolive https://habr.com/ru/post/51152/ или его последнее творение https://habr.com/ru/post/211488/ . Честно понравилось по описанию, но руками пока не щупал, да и что мне щупать, нужно сравнивать производительность, другие параметры а я врятли с этим справлюсь. Сам проект заброшен и не поддерживается

Так же интересный проект https://max-3000.com/, позиционирующий себя как более легкий аналог вордпресса, но он на флеймфорке и менее подвижный.

Есть какие советы какую структуру строить, может какие наработки взять в основу?

Может кто хочет присоединится как наемный программист или даже партнер?
__________________
http://BuxarExchange.ru, http://Buxar-Host.ru Домены от 2.99$, Хостинг от 0.25$,
buxar вне форума   Ответить с цитированием
Старый 02.07.2020, 13:16   #2
 
Регистрация: 09.06.2006
Адрес: Minsk
Сообщений: 670
Доменные сделки: 20
Реноме: 960
Одобрения
Спасибо (Отдано): 2
Спасибо (Получено): 44
Отправить сообщение для igrek с помощью ICQ
имхо,

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

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

в итоге пришли к тому,
что выделяем для себя типы проектов
и какие-то делаются на готовых движках (тот же битрикс, wordpress)
какие-то делаются с нуля (но с использованием фреймворков)
igrek вне форума   Ответить с цитированием
Старый 02.07.2020, 15:48   #3
 
Регистрация: 08.07.2015
Адрес: Екатеринбург
Сообщений: 516
Доменные сделки: 3
Реноме: 404
Одобрения
Спасибо (Отдано): 25
Спасибо (Получено): 166
вот именно , что время на поддержку и деньги для своего скрипта нужны если не прогер , тем более крупный проект будет зависит от этих прогеров , стоит ли овчинка ?
Navigator вне форума   Ответить с цитированием
Старый 02.07.2020, 19:26   #4
 
Регистрация: 19.12.2013
Сообщений: 604
Доменные сделки: 4
Реноме: 393
Одобрения
Спасибо (Отдано): 41
Спасибо (Получено): 120
Сообщение от buxar Посмотреть сообщение
на одном движке
Вот это основная ваша ошибка. Не нужно зацикливаться на том, чтобы свой движок был только один. Можно использовать несколько своих

добавлено через 7 минут
Сообщение от buxar Посмотреть сообщение
как пользователь
Вот это тоже. Вы, как пользователь, можете не потянуть разработку большого кол-ва разнообразного качественного софта под ваши проекты. Хотя это зависит от качества ваших проектов в смысле уже приносимой ими маржи Возможно, придется «развиваться» постепенно, проект за проектом.

добавлено через 11 минут
P.S. Проекты многих «не достойны» того, чтобы работать на вменяемом софте. Для таких и придумали WP, Битрикс и т.п. Хотя бабла они часто выжирают не меньше.

Последний раз редактировалось miketomlin; 02.07.2020 в 19:38. Причина: Добавлено сообщение
miketomlin вне форума   Ответить с цитированием
Старый 03.07.2020, 01:08   #5
 
Регистрация: 06.01.2017
Сообщений: 1,011
Доменные сделки: 7
Реноме: 661
Одобрения
Спасибо (Отдано): 494
Спасибо (Получено): 473
Движок с нуля (самопис) с такими задачами можно делать, только если есть под рукой грамотные разработчики и средства на их содержание. Или если вы сам кодер и есть время и желание. Иначе это будет обычная благотворительность.

Если брать в основе модульную систему, то готов спорить: рано или поздно будет написан wordpress v.2 )) Идея у Вас классная, но, зараза, дорогая и сложная. С самописами тоже не все так гладко: однажды какая-то "хотелка" упирается в ограничения системы и начинаются костыли.

Технически можно взять уже готовый двиг и перепилить его на свои нужды. Но взяв тот же wp, каждую неделю придется читать сводки уязвимостей и править свою версию, если она изменится настолько, что перестанет обновляться (а она изменится ). Поэтому я всегда за самопис в серьезных делах, разделение и интеграцию.

добавлено через 1 час 16 минут
Почитал по ссылкам на хабре. Интересное решение, хорошая работа, грамотная. Но вот этот комментарий от автора, мне кажется наложит серьёзные ограничения на объёмы данных и скорость работы:
 
Для самих объектов используется две таблицы, одна для идентификации uri, в другой атрибуты объекта. Одна строка – один объект.Ещё есть таблица для больших текстов с поддержкой полнотекстового поиска. Фактически все объекты в одной таблице.
Это беда всех универсальных объектно-ориентированных систем. Либо в той или иной мере отказываемся от универсальности, либо ограничиваемся объемами.
__________________
Долларовый тысячионер.

Последний раз редактировалось Eskander; 03.07.2020 в 02:25. Причина: Добавлено сообщение
Eskander вне форума   Ответить с цитированием
Старый 03.07.2020, 09:09   #6
 
Регистрация: 19.12.2013
Сообщений: 604
Доменные сделки: 4
Реноме: 393
Одобрения
Спасибо (Отдано): 41
Спасибо (Получено): 120
Eskander, в этом комменте автор написал, что возможны варианты. Но в общем я с вами согласен. Использовать этот способ в качестве основного даже на начальном этапе не оч. хорошо. У нас, например, «материализованный путь» используется только в паркинге, причем такие «пути» хранятся без отрыва от объектов в одной таблице (на один хост, т.е. единая таблица со связыванием по id хоста НЕ используется). Такое совмещение стало возможно за счет того, что кол-во типов объектов в данном сервисе не слишком велико и разнообразно. Хосты и пользователи, естественно, хранятся в отдельных таблицах.

Вообще объединение объектов и их адресных идентификаторов (т.е. данных для роутинга), например слагов, используется в нашем софте повсеместно. Но в системах общего назначения пути уже НЕ хранятся целиком, а делятся на части (каждая часть хранится вместе со своим объектом иерархии). Например, вот описание простой базовой модели, в которой по аналогии с хостом и материализованным путем для этого хоста делается деление на категорию, которой соответствует первый компонент пути, и объект, которому соответствует концовка пути, причем концовку, если она многокомпонентная (aaa/bbb), не обязательно хранить в одной таблице – можно продолжать структурное деление: Простая модель данных.

Последний раз редактировалось miketomlin; 03.07.2020 в 09:12.
miketomlin вне форума   Ответить с цитированием
Старый 03.07.2020, 13:29   #7
 
Регистрация: 06.01.2017
Сообщений: 1,011
Доменные сделки: 7
Реноме: 661
Одобрения
Спасибо (Отдано): 494
Спасибо (Получено): 473
miketomlin, в таблицу маршрутизации можно закинуть хоть миллион объектов, она будет работать нормально. Это нормальная практика и здесь это не главная головная боль. В описываемом случае основная проблема в том, что в одной таблице хранятся все сущности: юзеры, посты, товары, комментарии и т.д., а также все атрибуты всех объектов описанных выше объектов. Как понял из описания концепции, по другому сделать хранение данных крайне проблематично. Может ошибаюсь, но вроде так, и затык будет именно на сервере БД. И например, магазину вроде лероя, скорее всего на этом движке будет крайне тяжело.
И даже модель объектного наследования в БД, когда каждая таблица содержит только id предка и расширяемые атрибуты потомка - тоже неоднозначное решение. Вроде бы изящное, но на хайлоаде, с большими объемами данных и наборами классов может начать подтормаживать. Причем экспоненциально. Я делал такую систему году в 2000-м для десктопов: трехуровневая архитектура, иерархическая БД на реляционной, сервер приложений и тонкие клиенты. Прикольно и жизнеспособно вобщем-то, но там объектов всего в сотнях тыщ и клиентов штук 5. Хотя, честно говоря, давно не читал кейсов - может щас и нормально, тогда желез было другое.
__________________
Долларовый тысячионер.
Eskander вне форума   Ответить с цитированием
Старый 03.07.2020, 13:56   #8
 
Регистрация: 19.12.2013
Сообщений: 604
Доменные сделки: 4
Реноме: 393
Одобрения
Спасибо (Отдано): 41
Спасибо (Получено): 120
Eskander, это вообще полный вынос мозга, так что я на это даже не обратил внимание. Я не понимаю, как такое может норм. работать в реляционной БД. Все на кастэмных полях что ли?

добавлено через 17 минут
В репозитории никаких изменений с 14-го года. Наверное, автор протестировал свою систему более чем на 10 объектах и почувствовал «боль»

Последний раз редактировалось miketomlin; 03.07.2020 в 14:13. Причина: Добавлено сообщение
miketomlin вне форума   Ответить с цитированием
Старый 03.07.2020, 16:42   #9
 
Регистрация: 06.01.2017
Сообщений: 1,011
Доменные сделки: 7
Реноме: 661
Одобрения
Спасибо (Отдано): 494
Спасибо (Получено): 473
Сообщение от miketomlin Посмотреть сообщение
Все на кастэмных полях что ли?
Можно использовать разные компромиссные подходы, как то таблицы с набором полей разных типов для хранения значений атрибутов, а их тип устанавливается в самом объекте и на его основе тянется соотв. поле; разные таблицы под разные типы данных; json, sql_variant и т.д. В любом из них куча подводных камней и всплывают в самых неподходящих местах. Какие-то задачи "универсальные таблицы" позволяют решать, но строить крупный проект лишь на основе их это безумие.

Сообщение от buxar Посмотреть сообщение
на модулях которые могли бы легко заменяться/подключаться/отключаться без каких либо поломок
Так, прям совсем идеально, не получится. Модули в любом случае могут зависеть друг от друга. Можно разработать систему интерфейсов (не те, которые UI, а взаимодействия) можно сделать. Но этот интерфейс кто-то (модуль) должен реализовать.

Еще в задании есть несколько плохо уживающихся вводных, например:

 
использовать хранение данных в отдельных базах (соблюдая требования некоторых стран о хранение конфиденциальной информации в локальной стране)
И
 
быстрая работа
__________________
Долларовый тысячионер.
Eskander вне форума   Ответить с цитированием
Старый 12.07.2020, 03:58   #10
 
Аватар для buxar
 
Регистрация: 24.03.2006
Адрес: Vilnius, Lithuanian
Сообщений: 176
Доменные сделки: 0
Реноме: -19
Одобрения
Спасибо (Отдано): 1
Спасибо (Получено): 8
Сообщение от Navigator Посмотреть сообщение
вот именно , что время на поддержку и деньги для своего скрипта нужны если не прогер , тем более крупный проект будет зависит от этих прогеров , стоит ли овчинка ?
я и сейчас завижу от прогеров и причем не от одного-двух, так как каждый берется только за определенные движки.

а коммерческие с закрытым кодом вообще не реально переделывать

так что поддерживать один движок или 10 есть явно разница в пользу поддержания одного, пусть на фрейморке, но одного а не десяти или двадцати

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

добавлено через 31 минуту
Сообщение от miketomlin Посмотреть сообщение
Вот это основная ваша ошибка. Не нужно зацикливаться на том, чтобы свой движок был только один. Можно использовать несколько своих
Вы не понимаете видимо суть идеи.
Если ядро будет содержать только логику, то проблем в построении разных проектов не будет.
Во всех проектах можно использовать одинаковые модули к ядру которые отвечают за функционирование движка (системные модули).
Во всех можно использовать одинаковые модули такие как модуль регистрации, авторизации, профиля, обратной связи, модули вывода информации, модули шаблонов (вспомогательные модули).
И только специфические модули отвечающие за функционал конкретного проекта (уникальные модули).
Если не считать проектирование движка и разработку начальной логики взаимодействия ядра с модулями, дальнейшая разработка как раз будет дешевой.
Так как написав один раз системный или вспомогательный модуль, он пойдет на все проекты без каких либо затрат на разработку
 
добавлено через 7 минут
Вот это тоже. Вы, как пользователь, можете не потянуть разработку большого кол-ва разнообразного качественного софта под ваши проекты. Хотя это зависит от качества ваших проектов в смысле уже приносимой ими маржи Возможно, придется «развиваться» постепенно, проект за проектом.
Выше уже ответил, сделав один проект, на второй и последующие затрат будет на процентов 70-80 меньше, так как основная часть (ядро, системные и вспомогательные модули) подойдут с предыдущего проекта
 
добавлено через 11 минут
P.S. Проекты многих «не достойны» того, чтобы работать на вменяемом софте. Для таких и придумали WP, Битрикс и т.п. Хотя бабла они часто выжирают не меньше.
Подобные проекты в первую очередь это проекты для контента.
Хотя Битрикс имеет 3 продукта, CMS, CRM и Магазин. И исходя из моих требований, не более 30% моих потребностей их разработки могут охватить сейчас, а 70% нужно писать, не вижу смысла писать под коммерческие движки и быть привязанным к их продукту. Да и то что у них реализовано, сделано понятно что не так как мне нужно

Сообщение от Eskander Посмотреть сообщение
Движок с нуля (самопис) с такими задачами можно делать, только если есть под рукой грамотные разработчики и средства на их содержание. Или если вы сам кодер и есть время и желание. Иначе это будет обычная благотворительность.

Если брать в основе модульную систему, то готов спорить: рано или поздно будет написан wordpress v.2 )) Идея у Вас классная, но, зараза, дорогая и сложная. С самописами тоже не все так гладко: однажды какая-то "хотелка" упирается в ограничения системы и начинаются костыли.

Технически можно взять уже готовый двиг и перепилить его на свои нужды. Но взяв тот же wp, каждую неделю придется читать сводки уязвимостей и править свою версию, если она изменится настолько, что перестанет обновляться (а она изменится ). Поэтому я всегда за самопис в серьезных делах, разделение и интеграцию.

добавлено через 1 час 16 минут
Почитал по ссылкам на хабре. Интересное решение, хорошая работа, грамотная. Но вот этот комментарий от автора, мне кажется наложит серьёзные ограничения на объёмы данных и скорость работы:

Это беда всех универсальных объектно-ориентированных систем. Либо в той или иной мере отказываемся от универсальности, либо ограничиваемся объемами.
Разработчиков ищу, кто-то уже предлагает за основу свои разработки, кто-то писать на фреймворках, кто-то готов писать с нуля, но пока конкретики нет и я боюсь промахнуться и пойти не по тому пути.
Мой путь точно не ВП, во первых это не CMS, а скорее UMS (юниверсал), в ВП как и во всех CMS уже основной функционал вшит в джижок и ориентирован на работу с контестом а не другими вещами, а дальше идут извращения с плагинами , которые собственно и режут исходные коды системы по своему усмотрению.
Мне не такой подход нужен, да и движок не для тех целей.
А что бы не разростался, для этого модульность и нужна, нету смыла как во всех CMS вшивать по умолчанию то, что не всем нужно, пусть это будет модулем под конкретный проект

добавлено через 39 минут
Eskander, Быстрая работа и базы данных в разных странах по моему не столь критичное, нужно же хранить только персональные данные а не все.
А значит запрос к этим данным осуществляется не так часто.
В основной базе может быть вся информация не подпадающая под закон о персональных данных и этого достаточно что бы юзер нормально работал с проектом, а если если взять к примеру обменник нужна для обмена персональная информация, идет обращение к удаленной базе данных и берется нужная информация.
Я пока масштаб обращений не представляю, но учитывая что это не постоянная связь с удаленной базой, думаю проблем с этим не будет.
А нужно будет ввести таймаут, это тоже не проблема, клиент получает аякс заставочку "проверка данных" и подождет 10 секунд пока данные будут получены и сверены.
Главное что бы это не влияло на скорость работы самого проекта в целом.

Как посоветуете поступать с базой данных если учитывать ошибки проекта с хабра?
__________________
http://BuxarExchange.ru, http://Buxar-Host.ru Домены от 2.99$, Хостинг от 0.25$,

Последний раз редактировалось buxar; 12.07.2020 в 04:37. Причина: Добавлено сообщение
buxar вне форума   Ответить с цитированием
Ответ



Реклама

Здесь присутствуют: 1 (пользователей: 0 , гостей: 1)
 
Опции темы
Закладки Добавить Тема в закладки

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.

Быстрый переход


Текущее время: 22:36. Часовой пояс GMT +4.