Комментарии 15
Т.е. вебсокет как замена ресту? (Это из текста не совсем ясно). Если да, то думали ли вы уже как будете масштабироваться и балансировать соединения при росте нагрузки? С учетом асинхронной природы сокетов там хватает подводных камней как например неоднородная загрузка серверов: уперлись в лимит коннектов по вебсокету (в файловые дескрипторы, например), а вычислительные ресурсы сервера простаивают (пользователи онлайн но ничего не делают); или наоборот — один пользователь на сервере, но кучей запросов в секунду его кладёт (коммуникация асинхронная, сообщений можно накидать в сокет столько, что сервер захлебнётся это разгребать). Все же синхронные коммуникации от этого уберегают.
> Без дальнейшего промедления, я срочно приступил к разработке своей CMS.
Что-то сразу вспомнил как в школе ЦМС писал. Лет 20 назад это было популярно.
P.S. Надо ещё больше болда на ключевые слова, поисковики ведь тоже застыли во времени в прошлом и до сих пор подобные фокусы любят.
Не совсем так. WebSocket используется в качестве протокола для получения инструкций от клиента на рендеринг тегов фреймворка. REST API можно использовать также, есть специальный тег для этого во фреймворке. Ну или из JS уже что-то по AJAX доставать.
> Если да, то думали ли вы уже как будете масштабироваться и балансировать соединения при росте нагрузки?
За год использования в крупной платформе не разу такого не случалось. Все зависит от реализации фронэнда.
Аминь. Все мы писали свою самую лучшую, удобную, placeholder cms/cmf... а потом выкинули и стали нормально работать на продуктах, которые имеют нормальное сообщество и поддержку. Вопрос не в том, что ваш продукт отличный, а в том, сколько разработчиков на нем могут. Однако, для себя, вероятно, вы создали классное портфолио.
Ну и это просто pr, продукт не открытый, смотреть нечего, нигде. Я пиарюсь уже отменили? Теперь можно просто все что угодно, как угодно на Хабре пиарить?
В планах дальнейшего развития фреймворка выделить community версию.
mastermindcms.co/site/documentation.html — Здесь есть документация, я же оставил ссылки в статье.
> а потом выкинули и стали
А зря))). Может кто-то бы ваш продукт использовал сейчас в проектах.
> Я пиарюсь уже отменили? Теперь можно просто все что угодно, как угодно на Хабре пиарить?
Так развивают свои продукты, если о нем не рассказывать, то так никогда и не получишь фидбека от сообщества. А не будет фидбека, не будет продукта.
да, если они community, а не закрытый код. Для иного на Habr есть корпоративные блоги. На ваш продукт фидбэка дать не получится, потому что на гитхабе даже нет хелловорлда на вашем фреймворке.
Я в личном порядке могу выдать community версию. Пока времени не хватает на поддержание всей инфраструктуры. Документацию на этой неделе закончили. Сейчас можно думать о версии для коммъюнити.
Сейчас перевожу на Wagtail сложный сайт с Laraver. Так на wagtail-е кода получается раз в десять меньше, а гибкости по работе с контентом больше.
Сначала обрадовался вашему комменту, пошёл читать -- а она на Django.. нее, спасибо, я лучше попробую October или Pyro.
Я посмотрел сегодня пару туториалов по Wagtail на YouTube, и увидел что все же бекэнд писать надо.
А в чем минус Django? Я интересуюсь, не разу на этом фреймворке ничего не делал.
Да используйте смело. Это широко распространенный хорошо документированный фреймворк. В другие движки имеет смысл лезть, если нужно что-то полегче, супербыстрое, сложные запросы к базе данных.
Я посмотрел сегодня пару туториалов по Wagtail на YouTube, и увидел что все же бекэнд писать надо.
Да, это не CMS, это фреймворк. Но… десяток строк кода там делают чудеса.
Во-первых, это Python, а не РНР, во-вторых, там куча унаследованных с древних времён сложностей (примерно как у Drupal или Wordpress), ну и эксепшены по любым поводам и не самый лучший шаблонизатор. В общем, если Питон вы знаете, а ПХП нет, то Джанго, если иначе -- я бы лучше взял что-то из РНР-мира, от Joomla до CraftCMS или October, выбор огромный.
Экзепшены в джанге появляются у слабых питонистов. В продакшене 500 ошибок быть не должно, независимо от запросов пользователя.
Что касается рудиментов, то их там не так уж много. Шаблонизатор там уже давно меняется через настройки. Jinja2 вполне себе заменяет дефолтный шаблонизатор. Использование ORM там тоже не жёсткое. Просто, ORM - это фича джанги, и я лично не вижу особого смысла использовать джангу без него.
Вы совершенно не описываете главных минусов джанги: это много лишнего кода, низкая скорость работы, в сравнении с более легковесными фрэймворками, слишком жёсткий стиль организации кода с большим набором всевозможных файлов (когда можно было бы обойтись парой файлов). Слишком много концепций, и для написания нормального кода на Django следует знать прямо очень много деталей и постоянно следить за обновлениями пакетов. Плюс, концепция Django - это универсальность. Фрэймворк, и основные дополнения к нему, типа DRF, пытается покрыть максимум кейсов. Из-за этого, для добавления простого эндпоинта ты вынужден писать много кода во множество файлов, попутно решая, какие миксины и наследования использовать, чтобы оно работало как надо и без повторов кода. То есть, даже с появившейся недавно поддержкой async во многих местах, джанга - так себе решение для большинства микросервисов.
Вообще-то, на многих CMS бэкенд писать надо. Другой вопрос: а почему вы считаете, что написали именно CMS, а не фрэймворк?
Вообще-то, на многих CMS бэкенд писать надо.
Наша цель как раз этого избежать. Выпишу сюда цитату из своей статьи:
«Миллионы web-проектов увидели свет, но изо дня в день программисты все еще пишут тонны исходного кода, решая похожие задачи на разных инструментах.»
Я хотел бы покрыть максимально возможное количество задач которые программисты решают для создания платформ и сайтов ежедневно. Вывести все на абстрактный уровень реализации, так сказать не привязываясь к контексту проекта. По моему мнению исходя из своего опыта это возможно. И в принципе я убедился в этом использовав эту CMS в крупном проекте.
А для задач с которыми сталкиваются программисты редко, у нас есть проект микросервисов. Мы также использовали в своем проекте микросервис интеграции с Ai-фреймворком написанном на Python.
а почему вы считаете, что написали именно CMS, а не фрэймворк?
Собственно говоря это комбинация фреймворка и CMS.
CMS потому-что есть модули которые содержат готовый функционал для применения его уже реальных проектах. А также есть собранный dashboard для административных задач. Но в отличии от других CMS, этот dashboard можно с легкостью переделать полностью под любой другой UI-дизайн и структуру.
Фреймворк потому-что существует возможность использовать инструкции для динамических шаблонов, где из сразу вы получаете data-binding.
MastermindCMS – что это такое? Система управления контентом? Фреймворк?