LINUX.ORG.RU

cms на php на замену wordpress

 , ,


2

2

Всем привет.

Нужна современная цмска на php, которая бы тормозила не как WP, архитектурно была более стройной, не с миллиардом sql-запросов на каждой странице, поддерживала postgresql, с какой-то симпатичной, можно простенькой, легко настраиваемой админкой. Полноценный инет-магазин с корзинами делать нет необходимости, но каталог товаров / витрина предполагает тегирование, множественную принадлежность одного товара разным группам, удобную загрузку картинок и связанные товары («чаще с этим товаром покупают еще и ...»), возможность организации раздела статей, в котором статьи редактируются через wysiwyg и этот редактор выглядит прилично, реальный wysiwyg - что видим в нем, то видим и на сайте. Все искаробки или плагинами, главное чтоб они были :)

Задача: сделать минимальными усилиями сайт, который бы реализовал вышеописанную функциональность. Только cms, не фреймворки (я сам могу написать на джанге / фласке и подобном, в том числе WP это за пару дней, но есть одно но - не хочу заниматься поддержкой в будущем решений на фреймворках, а WP не подходит из-за тормознутости), попросили знакомые, которым я готов *разово* помочь и в будущем проконсультировать, но не впрягаться в веб-разработку.

Язык cms строго php, потому что этот микро-бизнес вряд ли будет готов платить 20+ баксов в час рельсовикам и джангистам, laravel-гуру и прочим достойным личностям, при всем моем к ним уважении. Нужен дешевый и доступный, желательно в конкретном городе (накрайняк на фрилансе), саппорт. А это php и есть.

Джумлы, друпалы, DLE и проприетарщину завендорлоченую (в том числе SAAS) просьба не предлагать. Если вдруг каким-то чудом вы знаете прям вот супер-пупер cms на ruby / python (именно cms, а не фреймворк) - ну напишите, хоть это и офтоп. perl, js, erlang / elixir, haskell, coq, idris, rust, dart, shen не рассматриваю :)

P.S.: если к этому делу потенциально на фронтенд можно прикрутить vue или что там щас модно - вообще замечательно.

Ставь WP Rocket и не ипи моск. Весь тот бред, что ты расписал - под него ни одна CMS не подходит.

FilosofeM ★★
()

в том числе WP это за пару дней

Скорее за пару лет.

WP не подходит из-за тормознутости

Тормозят там миллион васянских говноплагинов. Из коробки всё относительно быстро. В конце-концов можно прикрутить кэш. Ещё посоветую вот эту штуку https://wordpress.org/plugins/wp-performance-pack/ в смысле использования gettext, потому что нативный парсер mo в WP действительно тормозной.

no-such-file ★★★★★
()
Ответ на: комментарий от no-such-file

Тормозят там миллион васянских говноплагинов

Именно, а без плагинов оно не юзабельно особо.

В конце-концов можно прикрутить кэш

Не подходит, инфа будет часто обновляться, и с вероятностью 99% сайт будет на хостинге, а не vps.

Ещё посоветую вот эту штуку

Спасибо, гляну если не найду вариков получше, чем WP.
Из этого случайно ни с чем не приходилось иметь дело https://1stwebdesigner.com/8-free-lightweight-cms-engine-alternatives-wordpress/ ?

alienclaster ★★★
() автор топика
Ответ на: комментарий от alienclaster

с вероятностью 99% сайт будет на хостинге, а не vps.

Серьезно, есть деньги переписать водпрес, а на впс нету?

goingUp ★★★★★
()
Ответ на: комментарий от goingUp

с вероятностью 99% сайт будет на хостинге, а не vps.

Серьезно, есть деньги переписать водпрес, а на впс нету?

Почему переписать? Сайта пока что нет вообще никакого. А vps не будет не из-за денег, а потому что его нужно администрировать, а этим заниматься некому. На хостинге же все унифицировано. Ну... на крайняк можно и vps, если хостинг по каким-то причинам не даст запустить убер-цмс на пхп. Но не хотелось бы.

alienclaster ★★★
() автор топика

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

Ford_Focus ★★★★★
()
Ответ на: комментарий от Ford_Focus

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

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

alienclaster ★★★
() автор топика
Ответ на: комментарий от deep-purple

Ну вот нахрена им в самом начале стартапа фреймворки?

Оно может быть оправдано, я помогал запускать «стартапы» и небольшие бизнесы по части сайтов. В большинстве случаев использование фреймворка имело смысл и окупалось очень быстро. Но в данном случае это не стартап, а мелкий устоявшийся бизнес в небольшом городе из сегмента потребительских услуг. Фреймворки тут не нужны по озвученным выше причинам, инфа сотка :)

alienclaster ★★★
() автор топика
Ответ на: комментарий от alienclaster

Тем более.

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

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

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

Ну или бери готовую цмс магазина.

deep-purple ★★★★★
()
Ответ на: комментарий от deep-purple

А в современных реалиях все ядра вменяемых пыхо-цмсок перекатились уже давно на фреймворки и пэ-эс-эры.

Т.е. cms на основе laravel или что там щас в мире пхп самое нормальное? Давно не смотрел на вебню уже как пару лет, особенно в php-реальность.

Ну или бери готовую цмс магазина.

opencart выглядит и работает отвратно, с остальным пхп-миром движков для магазинов я не знаком, и не очень хочется в этот «мир» углубляться.

alienclaster ★★★
() автор топика
Ответ на: комментарий от alienclaster

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

по опенкарту помню был плагин под названием «тысяча и один запрос» который сильно уменьшал колво запросов на страницу. и было дело давно, я в опенсрате прикручивал карты с геокодером для расчета стоимости доставки от расстояния, да, скрипя зубами.

но не опенкартом же единым...

а вот есть еще готовые площадки типа wix - может в эту сторону?

deep-purple ★★★★★
()
Ответ на: комментарий от deep-purple

Готовые площадки, чуйствую, тоже придется рассмотреть...

но не опенкартом же единым...

с оупенкартом точно связываться не хочу, хоть 1001 запрос, хоть 100тыщ и один.

alienclaster ★★★
() автор топика
Ответ на: комментарий от alienclaster

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

жди, может еще что подскажут.

deep-purple ★★★★★
()
Ответ на: комментарий от FilosofeM

Я как-раз в теме. Вне темы - это ты.

Я да, был бы в теме пхп-цмсок то не задавал бы вопросов, а отвечал на них. А ты по делу хоть что-то скажешь, кроме «юзай wp»?

alienclaster ★★★
() автор топика

Ковыряй opencart. Не хочешь ковырять - делай сам на ларавели, симфонии, что там сейчас модно.

crutch_master ★★★★★
()
Последнее исправление: crutch_master (всего исправлений: 1)
Ответ на: комментарий от alienclaster

Тебе уже сказали что делать - ставить WP Rocket, WooCommerce, удалять помойные ненужные плагины и прогонять сайт на скорость в GTMetrix и Pingdom.

FilosofeM ★★
()
Ответ на: комментарий от alienclaster

opencart выглядит

Какой шаблон воткнешь, так и будет выглядеть. Что за программисты пошли? Внутри там обычный MVC. Берешь и всовываешь хоть вуе, хоть реакт.

работает отвратно

В каком месте? Опенкарт - дефолтный магазин, который по-другому просто не сделаешь. По-моему там даже нет ОРМ-говен, что большой плюс. В любом случае, не нравится, лезешь и чинишь. Эта поделка намного качественнее и грамотнее чем все эти WordPress WooCommerce и подобное дерьмище на 100 позиций.

crutch_master ★★★★★
()
Последнее исправление: crutch_master (всего исправлений: 3)
Ответ на: комментарий от alienclaster

ни с чем не приходилось иметь дело

Чувак, все эти cms на фреймворках будут тормозить ещё больше WP. Особенно взоржал от drupal. Ну и да, с поддержкой будет жопа. Напрасно ты кочевряжишься и придумываешь отмазки про скорость.

no-such-file ★★★★★
()

Drupal 8 + Varnish + Redis + Hetzner. Ничего не будет тормозить. Гарантирую это.

anonymous
()
Ответ на: комментарий от FilosofeM

Тебе уже сказали что делать - ставить WP Rocket, WooCommerce

Ты себе лучше расскажи что делать - а именно читать хотя бы на что отвечаешь. Или заголовок топика для начала, в котором я явно ищу замену WP, а значит подходы с «оптимизировать» и улучшать эту хрень я не собираюсь. WooCommerce сам используй это говно.

удалять помойные ненужные плагины и прогонять сайт на скорость в GTMetrix и Pingdom.

Там практически все плагины становятся «помойными и ненужными» просто из-за соответствующей архитектуры WP. Короче хватит уже тупить.

alienclaster ★★★
() автор топика
Ответ на: комментарий от crutch_master

opencart выглядит

Какой шаблон воткнешь, так и будет выглядеть. Что за программисты пошли? Внутри там

Вот он внутри и выглядит как говно, вместе со всеми его недоделанными плагинами.

Берешь и всовываешь хоть вуе, хоть реакт.

Я как раз vue и всовывал, но бекенд и наклепанные в подворотнях плагины тормозить и глючить от этого не переставали.

работает отвратно

В каком месте?

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

Опенкарт - дефолтный магазин, который по-другому просто не сделаешь.

Там не не сделаешь, а вообще все надо иначе делать изначально.

По-моему там даже нет ОРМ-говен, что большой плюс.

Охх, лол. Давайте все на sql в строчках писать как в 90х.

В любом случае, не нравится, лезешь и чинишь.

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

Ну и, если бы ты внимательно прочел изначальный вопрос, то обнаружил бы - что мне НЕ нужен интернет-магазин, корзины и прочее.

alienclaster ★★★
() автор топика
Ответ на: комментарий от GalleryPoster

Мы мигрировали с Wordpress на похапе на Hakyll на хаскеле

И какие профиты в итоге получили в цифрах, если можно?

alienclaster ★★★
() автор топика
Ответ на: комментарий от pkurg

Да, пока что единственное, к чему по итогу присматриваюсь это octobercms.

alienclaster ★★★
() автор топика
Ответ на: комментарий от alienclaster

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

GalleryPoster
()
Ответ на: комментарий от GalleryPoster

Хаха, ну да кулхацкеры даже если получат доступ к исходникам охренеют от того, что там хаскель под капотом. Если в фреймворке предусмотрена защита от sql-инъекций и csrf тогда уже вполне можно жить, но выбор все равно неясен - чисто по приколу что ли взяли хаскель, а не руби например?

Нет нужды платить за хостинг с похапешкой.

Ну за vps с хаскелем-то все равно платить приходится, наверняка.

Ушёл весь геморой с поддержкой и обновлением.

Можно поподробнее?

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

Какая связь со статической типизацией?

alienclaster ★★★
() автор топика
Ответ на: комментарий от alienclaster

Ты немного не понял. Это просто генератор статических html-страниц. Нагенерил - положил на хостинг. Генеришь-то не на хостинге, а на своей тачке.

dimuska139 ★★
()
Ответ на: комментарий от alienclaster

Если в фреймворке предусмотрена защита от sql-инъекций и csrf тогда уже вполне можно жить, но выбор все равно неясен - чисто по приколу что ли взяли хаскель, а не руби например?

Это статический генератор. Выбор обусловлен простотой и расширяемостью фреймворка. Ну и сам язык типизирован, ошибки моментально ловятся, а не когда-то потом как в случае с рубями

Ну за vps с хаскелем-то все равно платить приходится, наверняка.

Не приходится. Сайт хостится на гитхабе.

Можно поподробнее?

Все работы ведутся на клиентской машине. На рабоспособность сайта это никак не влияет. Т.е. никаких «не отлаживай на боевой» не требуется. И если что-то пойдёт не так, на сайте это никак не отразится.

Какая связь со статической типизацией?

Никакой. Речь о статическом сайте (нагенеренный автоматом html)

GalleryPoster
()
Ответ на: комментарий от alienclaster

Охх, лол. Давайте все на sql в строчках писать как в 90х.

Нет, давайте херачить в базу по 5 запросов в цикле по всем товарам, как все модные пацаны. Компетенция лезет из всех щелей.

а вообще все надо иначе делать изначально

Заявление уровня тёти Зины из бухгалтерии. Что конкретно и почему?

но бекенд и наклепанные в подворотнях плагины тормозить и глючить от этого не переставали

Так зачем было впихивать туда плагины из подворотни?

Ну и, если бы ты внимательно прочел изначальный вопрос, то обнаружил бы - что мне НЕ нужен интернет-магазин, корзины и прочее.

А да, у тебя там ВП.

олноценный инет-магазин с корзинами делать нет необходимости,

но каталог товаров / витрина предполагает тегирование, множественную принадлежность одного товара разным группам, удобную загрузку картинок и связанные товары («чаще с этим товаром покупают еще и ...»)

Ты уж определись, нужен тебе магазин или нет.

crutch_master ★★★★★
()
Ответ на: комментарий от crutch_master

Нет, давайте херачить в базу по 5 запросов в цикле по всем товарам

Эм, вообще-то в нормальных orm запросы к бд ленивые и композитные, тебя никто не заставляет писать говнокод.

Компетенция лезет из всех щелей.

Да, оно и видно :)

а вообще все надо иначе делать изначально

Заявление уровня тёти Зины из бухгалтерии. Что конкретно и почему?

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

но бекенд и наклепанные в подворотнях плагины тормозить и глючить от этого не переставали

Так зачем было впихивать туда плагины из подворотни?

А вы ж других не пишете просто.

А да, у тебя там ВП.

Сайта еще *нет*, вы как посты читаете, так и плагины пишете криво и sql строчками гоняете в 2020 году.

Ты уж определись, нужен тебе магазин или нет.

Перечитай пост, харе тупить.

alienclaster ★★★
() автор топика
Ответ на: комментарий от alienclaster

и sql строчками гоняете в 2020 году

Как будто в этом есть что-то плохое. Бывают запросы, которые не только с помощью ORM не сделать, но и для которых даже кверибилдер не помогает особо.

dimuska139 ★★
()
Ответ на: комментарий от alienclaster

Эм, вообще-то в нормальных orm запросы к бд ленивые

Да ты шо? И что это? На каждый getValue получишь запрос в базу? Отлично.

тебя никто не заставляет писать говнокод

Удачи тебе в написании неговнокода на орм и его поддержи, особенно, когда оно сильно вылезет за пределы CURD, умник.

Ну там вся архитектура кривая изначально

«Всё неработает» или «Всё кривое» претензия уровня бухгалтерши. Ей можно такое простить. Человеку, который на что-то там претендует - нет. Из этого просто делается вывод, что он сам - жопорук, который поливает всё дерьмом не имея никаких оснований.

хамоватое

Тут не клуб благородных девиц.

А вы ж других не пишете просто.

Кто «мы»? Иди остудись.

crutch_master ★★★★★
()
Последнее исправление: crutch_master (всего исправлений: 1)
Ответ на: комментарий от alienclaster

Перечитай пост, харе тупить.

Так у тебя в начале предложения, написано

Полноценный инет-магазин с корзинами делать нет необходимости

А потом ты перечисляешь всё фичи магазина, кроме корзины.
Ну так что?

crutch_master ★★★★★
()
Ответ на: комментарий от crutch_master

Да ты шо? И что это? На каждый getValue получишь запрос в базу?

Запросы _отложенные_, алё, и происходят ровно тогда, когда реально в этом есть необходимость. Ты бы вместо демонстрации своей некомпетентности лучше бы что-то почитал умное.

Удачи тебе в написании неговнокода на орм и его поддержи, особенно, когда оно сильно вылезет за пределы CURD, умник.

В нормальных orm часть запроса в сложных случаях пишется на самом orm, чего не хватает - *добавляется* строчка на sql, которая мапит результаты все равно на нужные нам языковые структуры, с которыми в дальнейшем удобно работать. А в *хороших* orm / sql-dsl можно формировать запросы _произвольной_ сложности без хераканья sql-строчек вообще. И делать это намного удобнее, чем некомпозитный вырвиглазный sql на 5 экранов (часто в нетривиальных случаях).

«Всё неработает» или «Всё кривое» претензия уровня бухгалтерши.

Зачем мне тратить на тебя время, ты все равно не врубаешься в даже элементарные вещи. А еще и не просто тупой, но и хамоватый.

Отлично.

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

alienclaster ★★★
() автор топика
Ответ на: комментарий от dimuska139

и sql строчками гоняете в 2020 году

Как будто в этом есть что-то плохое. Бывают запросы, которые не только с помощью ORM не сделать, но и для которых даже кверибилдер не помогает особо.

Плохо писать *все* запросы в sql (кроме особых случаев, например, тебе разово нужно что-то дернуть из базы для аналитики - ты работаешь каким-нибудь аналитиком данных - и запрос тривиальный, при этом важна контролируемая эффективность самого запроса), там где можно воспользоваться нормальной orm, ключевое слово - нормальной. Когда ее возможностей не хватает - запрос построенный средствами orm *дополняем* sql-лапшой. Но лучше сразу использовать sql-dsl, в которых можно формировать запросы произвольной сложности, а полученные результаты обрабатывать как родные структуры данных хостового языка.

alienclaster ★★★
() автор топика
Ответ на: комментарий от alienclaster

Запросы _отложенные_, алё, и происходят ровно тогда, когда реально в этом есть необходимость.

Конечно в этом есть необходимость. И ты будешь делать n запросов в базу вместо одного.

Ты бы вместо демонстрации своей некомпетентности лучше бы что-то почитал умное.

Попробуй не считать себя Д'Артаньяном иногда.

В нормальных orm часть запроса в сложных случаях пишется на самом orm, чего не хватает - *добавляется* строчка на sql, которая мапит результаты все равно на нужные нам языковые структуры

Молодец. Вот ты сам его и выкинул на помойку и остался только маппер с твоими любимыми sql портками.

Зачем мне тратить на тебя время

Ты и так его тратишь, мог бы и написать, что конкретно там не так, вместо пустых ничем не обоснованных обвинений.

То что ты некомпетентен, в этом нет ничего отличного.

Так обоснуй это. Пока у тебя только «всё кривое, орм рулит» и пригорания.

crutch_master ★★★★★
()
Ответ на: комментарий от crutch_master

Запросы _отложенные_, алё, и происходят ровно тогда, когда реально в этом есть необходимость.

Конечно в этом есть необходимость. И ты будешь делать n запросов в базу вместо одного.

Это твои больные фантазии.

В нормальных orm часть запроса в сложных случаях пишется на самом orm, чего не хватает - *добавляется* строчка на sql, которая мапит результаты все равно на нужные нам языковые структуры

Молодец. Вот ты сам его и выкинул на помойку и остался только маппер с твоими любимыми sql портками.

У тебя реально дислексия. Специально же выделил для тебя ключевые слова *звездочками* и написал про sql-dsl, в которых не надо никаких строчек с sql-ем.

Зачем мне тратить на тебя время

Ты и так его тратишь, мог бы и написать, что конкретно там не так, вместо пустых ничем не обоснованных обвинений.

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

То что ты некомпетентен, в этом нет ничего отличного.

Так обоснуй это. Пока у тебя только «всё кривое, орм рулит» и пригорания.

Что тебе обосновывать, что sql плохо масштабируемое говно? Что запросы из базы надо как-то мапить? Что нормальные люди параметризуют запросы и обрабатывают промежуточные результаты как родные структуры / объекты языка? Что sql в строчках это неотлаживаемая херота, в которой просто допустить ошибку? Что sql в строчках не умеет в автодополнение по полям базы и вменяемой верификации хотя бы синтаксической корректности? Что нормальные люди используют ленивые запросы к базе и sql-dsl? Мне это и многое другое тебе надо объяснять? Зачем? Иди лучше доку почитай какую-то.

alienclaster ★★★
() автор топика
Ответ на: комментарий от alienclaster

ключевое слово - нормальной

Это какая, например? Монструозная Doctrine в php, невероятно «удобный» Gorm в go или SqlAlchemy в Python, которая, если не ошибаюсь, не дружит с асинхронщиной? Я не говорю, что все надо пилить на голом SQL, но лично я на текущий момент удобную и простую ORM не видел. Квери-билдеры - да, но не ORM.

dimuska139 ★★
()
Последнее исправление: dimuska139 (всего исправлений: 2)
Ответ на: комментарий от dimuska139

ключевое слово - нормальной

Это какая, например? Монструозная Doctrine в php, невероятно «удобный» Gorm

Относительно нормальные orm из традиционных языков у нас есть только в python и ruby, в остальных языках их нет и не предвидятся.

SqlAlchemy в Python, которая, если не ошибаюсь, не дружит с асинхронщиной

На сколько я помню, да (я пару лет вебом не занимался, может что-то изменилось), но как часто тебе нужна именно асинхронная orm? django вот сейчас с версии 3.х начали переписывать на асинхрон, кстати, django-orm весьма неплохая, она проигрывает sql-alchemy по возможности составления сложных запросов (но и в той и в другой ты все равно упрешься в некий предел, только в django-orm чуть быстрее), зато у нее на мой взгляд более симпатичный дизайн и нормальные миграции.

Пока что в питоне асинхронный код работает с «обычными» orm через прослойки.

Я не говорю, что все надо пилить на голом SQL

Я знаю, это говорил другой чувак, а ты ответил на мой ответ ему.

но лично я на текущий момент удобную и простую ORM не видел.

Ok, чем тебе, допустим, sql-alchemy не нравится или django-orm?
Вот еще список orm разной степени нормальности https://www.fullstackpython.com/object-relational-mappers-orms.html

Квери-билдеры - да, но не ORM.

Нормальную orm (на которой можно было бы составлять эффективные запросы к базе любой сложности в красивом виде + кеширование + отложенные вычисления + композитность + миграции + тестирование + автодополнение + автоматизация + расширяемость за вменяемое время + ... +++) в традиционных языках вообще не сделать, если что. На лиспе вполне возможно: 1) postmodern на common lisp 2) honeysql на clojure 3) mito на common lisp.

alienclaster ★★★
() автор топика
Ответ на: комментарий от alienclaster

как часто тебе нужна именно асинхронная orm

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

Ok, чем тебе, допустим, sql-alchemy не нравится или django-orm?

Насчет sql-alchemy ничего не скажу (с ней, можно сказать, не работал), но django-orm не нравится, например, тем, что ее без Django юзать нельзя. А юзать Django в 2020-м, когда во фронте господствуют вуи и реакты вообще бессмысленно (правда я-таки юзаю), потому что большая часть функциональности Джанги все равно использоваться по итогу не будет. К тому же даже если вытащить как-то ORM из Django, ума не приложу, как ее в юнит-тестах можно замокать, чтобы запросы в базу не ходили (например, для тестирования сервисного слоя)?

Что касается миграций, то их вообще можно юзать хоть сторонним инструментом. Тем более, что этот процесс неплохо было бы контролировать и видеть запросы глазами, а не через объекты ORM. А то на огромную таблицу в проде поедет миграция создания индекса без CONCURRENTLY - и приехали.

dimuska139 ★★
()
Последнее исправление: dimuska139 (всего исправлений: 1)
Ответ на: комментарий от anonymous

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

pkurg ★★★★
()
Ответ на: комментарий от dimuska139

Если пилишь бложик, нафиг не надо. Если пилишь микросервис

Да не только бложик, магазин вполне можно без асинхронщины запилить и много примеров таких магазинов у нас есть, успешных крупных высоконагруженных - без асинхронщины. Да, часто это уже по историческим причинам, но в бизнесе более важно вовремя запуститься, протестировать и обкатать идею, а о производительности (в разумных пределах) можно подумать потом, потому что вероятность банкротства бизнеса over 90%, независимо от того на сколько быстро там работает сайтик.

Микросервис никто и не предлагает писать на джанге. Для этого существуют другие либы.

django-orm не нравится, например, тем, что ее без Django юзать нельзя

Если не нужна джанга, то, скорее всего, не нужна и django-orm, очевидно. Но вообще можно юзать так, что джанга там и незаметна будет совсем.

А юзать Django в 2020-м, когда во фронте господствуют вуи и реакты вообще бессмысленно (правда я-таки юзаю)

Я тоже, не на всех сайтах нужна асинхронщина, серьезно. Да и на сервере иногда что-то предварительно отрендерить не помешает.

К тому же даже если вытащить как-то ORM из Django, ума не приложу, как ее в юнит-тестах можно замокать, чтобы запросы в базу не ходили (например, для тестирования сервисного слоя)?

Не могу подсказать, не использовал эту orm вне фреймворка. Но принципиальных сложностей не вижу.

Что касается миграций, то их вообще можно юзать хоть сторонним инструментом.

Можно, но неудобно. По крайней мере в языках типа python / ruby / php.

Тем более, что этот процесс неплохо было бы контролировать и видеть запросы глазами, а не через объекты ORM.

Там есть возможность посмотреть глазами перед применением непосредственно миграции. Есть история миграций, можно откатываться.

А то на огромную таблицу в проде поедет миграция создания индекса без CONCURRENTLY - и приехали.

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

alienclaster ★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.