|
Программирование PHP, Perl, HTML, XHTML, CSS, JavaScript, MySQL и другие языки кодирования. |
|
Опции темы |
Сегодня | |||||
|
02.07.2020, 04:33 | #1 | |||
Реноме:
-19
|
Свой движок - стоит ли?
Тема наверняка не раз поднималась по разным причинам и из разного ракурса.
Попробую её поднять не как разработчик которому некуда время девать, а как пользователь у которого с десяток проектов на разных начиная от коммерческих, заканчивая самописными движках. Идея состоит в том, что бы объединить все существующие проекты на одном движке и создавать новые на нем же. Силами конечно сторонних разработчиков, сам на начальном уровне. Учитывая разнообразие проектов (биллинги, инфо сайты, обменники, биржки и т.п.) а так же разнообразие в конечных пользователях (языковые, страны размещения), нужен движок в котором уже на корню заложена мультиязычность, мультидоменность (разный функционал на разных доменах с общей базой), мультилокальность (от страны проживания так же должен определяться функционал в тех же модулях, к примеру требования при регистрации иди доступность платежных систем). Вот мне пожалуйста подскажите, есть ли в природе что-то готовое? Мультиязычность-Мультидоменность мне подсказали есть на Вордпрес и Битрикс. Первый - думаю не годится для серьезных проектов, да и есть сомнение в корректности мультиязочности разных модулей. Второй - для меня вообще зло по моим убеждение , да и к тому же платный брать смысла не виду, если все равно в написание платных модулей придется вкладывать. В моем понимании остается одно, вложиться в написание своего движка, отвечающего следующим требованиям: Мультиязычность - должна быть заложена в самом ядре и легко подхватываемая на любых модулях. Простой механиз добавления локального текста на нужном языке в движок и модули. Мультидоменность - любой состав модулей и их настроек для разных доменов Глубокая модульность - ядро должно быть совершенно пустым, только функции обработки модулей, все остальное на модулях которые могли бы легко заменяться/подключаться/отключаться без каких либо поломок, инсталов, деинсталов (простая иницилизация). Глубокая локализация- в зависимости от страны должно быть возможно не только выводить определенные модули или настройки их, но и использовать хранение данных в отдельных базах (соблюдая требования некоторых стран о хранение конфиденциальной информации в локальной стране) API для взаимодействия между разными сайтами на этом же движке. Ну и конечно, движок должен отвечать всем современным требованиям, это: минимальная нагрузка на хостинг, быстрая работа, безопасность, СЕО оптимизация. В общем решение я в принципе принял, он мне нужен, только начинать с белого листа или брать за основу какой либо open source я пока не могу решить, так как 100% подходящих open source я не нашел. Но и грамотно разработать структуру думаю не каждый программист сможет, а в этом я точно профан. Итак, делаю (чужими руками) open source и жду ваших советов. Возможно стоит за основу взять наработки человека с ником boolive Так же интересный проект Есть какие советы какую структуру строить, может какие наработки взять в основу? Может кто хочет присоединится как наемный программист или даже партнер? |
|||
02.07.2020, 13:16 | #2 | |||
Реноме:
960
|
имхо,
сами проходили такой этап, сделали собственный движок для своих проектов но, он быстро устаревает, а времени на его поддержку и развитие не остается и всегда начинается борьба, либо за его легкость, чтобы в нем было только самый минимальный набор функционала но тогда в каждом проекте от ядра мало что зависит в итоге пришли к тому, что выделяем для себя типы проектов и какие-то делаются на готовых движках (тот же битрикс, wordpress) какие-то делаются с нуля (но с использованием фреймворков)
__________________
|
|||
02.07.2020, 19:26 | #4 | |||
Реноме:
393
|
Вот это основная ваша ошибка. Не нужно зацикливаться на том, чтобы свой движок был только один. Можно использовать несколько своих
добавлено через 7 минут Вот это тоже. Вы, как пользователь, можете не потянуть разработку большого кол-ва разнообразного качественного софта под ваши проекты. Хотя это зависит от качества ваших проектов в смысле уже приносимой ими маржи Возможно, придется «развиваться» постепенно, проект за проектом. добавлено через 11 минут P.S. Проекты многих «не достойны» того, чтобы работать на вменяемом софте. Для таких и придумали WP, Битрикс и т.п. Хотя бабла они часто выжирают не меньше.
__________________
Последний раз редактировалось miketomlin; 02.07.2020 в 19:38. Причина: Добавлено сообщение |
|||
03.07.2020, 01:08 | #5 | |||
Реноме:
661
|
Движок с нуля (самопис) с такими задачами можно делать, только если есть под рукой грамотные разработчики и средства на их содержание. Или если вы сам кодер и есть время и желание. Иначе это будет обычная благотворительность.
Если брать в основе модульную систему, то готов спорить: рано или поздно будет написан wordpress v.2 )) Идея у Вас классная, но, зараза, дорогая и сложная. С самописами тоже не все так гладко: однажды какая-то "хотелка" упирается в ограничения системы и начинаются костыли. Технически можно взять уже готовый двиг и перепилить его на свои нужды. Но взяв тот же wp, каждую неделю придется читать сводки уязвимостей и править свою версию, если она изменится настолько, что перестанет обновляться (а она изменится ). Поэтому я всегда за самопис в серьезных делах, разделение и интеграцию. добавлено через 1 час 16 минут Почитал по ссылкам на хабре. Интересное решение, хорошая работа, грамотная. Но вот этот комментарий от автора, мне кажется наложит серьёзные ограничения на объёмы данных и скорость работы: Для самих объектов используется две таблицы, одна для идентификации uri, в другой атрибуты объекта. Одна строка – один объект.Ещё есть таблица для больших текстов с поддержкой полнотекстового поиска. Фактически все объекты в одной таблице.
__________________
Долларовый тысячионер. Последний раз редактировалось Eskander; 03.07.2020 в 02:25. Причина: Добавлено сообщение |
|||
03.07.2020, 09:09 | #6 | |||
Реноме:
393
|
Eskander, в этом комменте автор написал, что возможны варианты. Но в общем я с вами согласен. Использовать этот способ в качестве основного даже на начальном этапе не оч. хорошо. У нас, например, «материализованный путь» используется только в паркинге, причем такие «пути» хранятся без отрыва от объектов в одной таблице (на один хост, т.е. единая таблица со связыванием по id хоста НЕ используется). Такое совмещение стало возможно за счет того, что кол-во типов объектов в данном сервисе не слишком велико и разнообразно. Хосты и пользователи, естественно, хранятся в отдельных таблицах.
Вообще объединение объектов и их адресных идентификаторов (т.е. данных для роутинга), например слагов, используется в нашем софте повсеместно. Но в системах общего назначения пути уже НЕ хранятся целиком, а делятся на части (каждая часть хранится вместе со своим объектом иерархии). Например, вот описание простой базовой модели, в которой по аналогии с хостом и материализованным путем для этого хоста делается деление на категорию, которой соответствует первый компонент пути, и объект, которому соответствует концовка пути, причем концовку, если она многокомпонентная (aaa/bbb), не обязательно хранить в одной таблице – можно продолжать структурное деление:
__________________
Последний раз редактировалось miketomlin; 03.07.2020 в 09:12. |
|||
03.07.2020, 13:29 | #7 | |||
Реноме:
661
|
miketomlin, в таблицу маршрутизации можно закинуть хоть миллион объектов, она будет работать нормально. Это нормальная практика и здесь это не главная головная боль. В описываемом случае основная проблема в том, что в одной таблице хранятся все сущности: юзеры, посты, товары, комментарии и т.д., а также все атрибуты всех объектов описанных выше объектов. Как понял из описания концепции, по другому сделать хранение данных крайне проблематично. Может ошибаюсь, но вроде так, и затык будет именно на сервере БД. И например, магазину вроде
И даже модель объектного наследования в БД, когда каждая таблица содержит только id предка и расширяемые атрибуты потомка - тоже неоднозначное решение. Вроде бы изящное, но на хайлоаде, с большими объемами данных и наборами классов может начать подтормаживать. Причем экспоненциально. Я делал такую систему году в 2000-м для десктопов: трехуровневая архитектура, иерархическая БД на реляционной, сервер приложений и тонкие клиенты. Прикольно и жизнеспособно вобщем-то, но там объектов всего в сотнях тыщ и клиентов штук 5. Хотя, честно говоря, давно не читал кейсов - может щас и нормально, тогда желез было другое.
__________________
Долларовый тысячионер. |
|||
03.07.2020, 13:56 | #8 | |||
Реноме:
393
|
Eskander, это вообще полный вынос мозга, так что я на это даже не обратил внимание. Я не понимаю, как такое может норм. работать в реляционной БД. Все на кастэмных полях что ли?
добавлено через 17 минут В репозитории никаких изменений с 14-го года. Наверное, автор протестировал свою систему более чем на 10 объектах и почувствовал «боль»
__________________
Последний раз редактировалось miketomlin; 03.07.2020 в 14:13. Причина: Добавлено сообщение |
|||
03.07.2020, 16:42 | #9 | |||
Реноме:
661
|
Можно использовать разные компромиссные подходы, как то таблицы с набором полей разных типов для хранения значений атрибутов, а их тип устанавливается в самом объекте и на его основе тянется соотв. поле; разные таблицы под разные типы данных; json, sql_variant и т.д. В любом из них куча подводных камней и всплывают в самых неподходящих местах. Какие-то задачи "универсальные таблицы" позволяют решать, но строить крупный проект лишь на основе их это безумие.
Еще в задании есть несколько плохо уживающихся вводных, например: использовать хранение данных в отдельных базах (соблюдая требования некоторых стран о хранение конфиденциальной информации в локальной стране)
быстрая работа
__________________
Долларовый тысячионер. |
|||
12.07.2020, 03:58 | #10 | |||
Реноме:
-19
|
а коммерческие с закрытым кодом вообще не реально переделывать так что поддерживать один движок или 10 есть явно разница в пользу поддержания одного, пусть на фрейморке, но одного а не десяти или двадцати каждый проект будет требовать индивидуального модуля и нескольких подходящих для всех проектов. даже если их будут писать под популярные CMS, они все равно будут самописы и при смене кодеров, те же будут проблемы. одна платформа позволит те же модули обратной связи, учетки, оплаты и т.п. как писать так и поддерживать сразу ко всем проектам, а сейчас под каждый проект нужно делать все отдельно и если я начну выбирать подходящие движки под каждый проект отдельно, та же херня выйдет. зачем мне с одного г в другое переходить, если результат будет тот же добавлено через 31 минуту Если ядро будет содержать только логику, то проблем в построении разных проектов не будет. Во всех проектах можно использовать одинаковые модули к ядру которые отвечают за функционирование движка (системные модули). Во всех можно использовать одинаковые модули такие как модуль регистрации, авторизации, профиля, обратной связи, модули вывода информации, модули шаблонов (вспомогательные модули). И только специфические модули отвечающие за функционал конкретного проекта (уникальные модули). Если не считать проектирование движка и разработку начальной логики взаимодействия ядра с модулями, дальнейшая разработка как раз будет дешевой. Так как написав один раз системный или вспомогательный модуль, он пойдет на все проекты без каких либо затрат на разработку добавлено через 7 минут
Вот это тоже. Вы, как пользователь, можете не потянуть разработку большого кол-ва разнообразного качественного софта под ваши проекты. Хотя это зависит от качества ваших проектов в смысле уже приносимой ими маржи Возможно, придется «развиваться» постепенно, проект за проектом. добавлено через 11 минут
P.S. Проекты многих «не достойны» того, чтобы работать на вменяемом софте. Для таких и придумали WP, Битрикс и т.п. Хотя бабла они часто выжирают не меньше. Хотя Битрикс имеет 3 продукта, CMS, CRM и Магазин. И исходя из моих требований, не более 30% моих потребностей их разработки могут охватить сейчас, а 70% нужно писать, не вижу смысла писать под коммерческие движки и быть привязанным к их продукту. Да и то что у них реализовано, сделано понятно что не так как мне нужно Движок с нуля (самопис) с такими задачами можно делать, только если есть под рукой грамотные разработчики и средства на их содержание. Или если вы сам кодер и есть время и желание. Иначе это будет обычная благотворительность.
Если брать в основе модульную систему, то готов спорить: рано или поздно будет написан wordpress v.2 )) Идея у Вас классная, но, зараза, дорогая и сложная. С самописами тоже не все так гладко: однажды какая-то "хотелка" упирается в ограничения системы и начинаются костыли. Технически можно взять уже готовый двиг и перепилить его на свои нужды. Но взяв тот же wp, каждую неделю придется читать сводки уязвимостей и править свою версию, если она изменится настолько, что перестанет обновляться (а она изменится ). Поэтому я всегда за самопис в серьезных делах, разделение и интеграцию. добавлено через 1 час 16 минут Почитал по ссылкам на хабре. Интересное решение, хорошая работа, грамотная. Но вот этот комментарий от автора, мне кажется наложит серьёзные ограничения на объёмы данных и скорость работы: Это беда всех универсальных объектно-ориентированных систем. Либо в той или иной мере отказываемся от универсальности, либо ограничиваемся объемами. Мой путь точно не ВП, во первых это не CMS, а скорее UMS (юниверсал), в ВП как и во всех CMS уже основной функционал вшит в джижок и ориентирован на работу с контестом а не другими вещами, а дальше идут извращения с плагинами , которые собственно и режут исходные коды системы по своему усмотрению. Мне не такой подход нужен, да и движок не для тех целей. А что бы не разростался, для этого модульность и нужна, нету смыла как во всех CMS вшивать по умолчанию то, что не всем нужно, пусть это будет модулем под конкретный проект добавлено через 39 минут Eskander, Быстрая работа и базы данных в разных странах по моему не столь критичное, нужно же хранить только персональные данные а не все. А значит запрос к этим данным осуществляется не так часто. В основной базе может быть вся информация не подпадающая под закон о персональных данных и этого достаточно что бы юзер нормально работал с проектом, а если если взять к примеру обменник нужна для обмена персональная информация, идет обращение к удаленной базе данных и берется нужная информация. Я пока масштаб обращений не представляю, но учитывая что это не постоянная связь с удаленной базой, думаю проблем с этим не будет. А нужно будет ввести таймаут, это тоже не проблема, клиент получает аякс заставочку "проверка данных" и подождет 10 секунд пока данные будут получены и сверены. Главное что бы это не влияло на скорость работы самого проекта в целом. Как посоветуете поступать с базой данных если учитывать ошибки проекта с хабра? Последний раз редактировалось buxar; 12.07.2020 в 04:37. Причина: Добавлено сообщение |
|||
Реклама | |
Здесь присутствуют: 1 (пользователей: 0 , гостей: 1) | |
Опции темы | |
|
|