danforth

Для ТСа вариантов других и нет. Но я для себя решил, что если что-то хоть немного сложнее блога, то я это делаю на самописе. Есть библиотеки, с которыми я привык работать (логирование, роутинг, ABAC, иногда ORM), подключаются 4 командами, шаблонизацию на бекенде вообще не вижу смысла лепить, только байты туда-сюда гонять. Делаю файлик с декларацией OpenAPI, по нему генерирую и клиент, и сервер. На фронте все красиво делается на том же Vue. В итоге сами CRUDы пишутся очень быстро. Бизнес-логику оставляю на уровне entites/use-cases, все через DI интерфейсов, в итоге любой слой можно мокать и тестировать. На выходе получаем код:

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

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

Более того, вот список фич, которые вы практически никогда не сможете реализовать на CMS:

• UUID PK, очень удобно, когда постоянно добавляются/обновляются сущности пачками, особенно со M:M связями. Я могу сгенерировать ID у сущностей без единого запроса к базе, добавить связи к ещё не существующим сущностям. Также, это открывает возможности для масштабирования. Заложив такой функционал ещё в фундаменте, можно решить очень много проблем в будущем.
• роутинг, хорошо, если он из коробки адекватный, но если ты хоть на секундочку задумаешься его сменить, то есть вероятность наткнуться в модулях и JS скриптах на захардкоженые значения (изменить которые ты не сможешь, потому что придеться попрощаться с обновлениями)
• эксепшены, выброшенные модулями, часто ломают работу всего сайта целиком. нет возможности сделать graceful degradation. например, какой-нибудь плагин микроразметки может выбросить эксепшн из-за отсутствия нужного ему класса, но вместо того, чтобы просто не рендерить нужный блок и написать ошибку в логи, мы получаем 500 статус на всю страницу целиком, и сообщение об ошибке. такое регулярно случается в том же Webasyst.
• дикий паравоз зависимостей, когда фронтенд использует кучу модулей jQuery, зависящих от версии, все это грузится в шапке сайта. вынести все в конец body невозможно, потому что в том же head плагины подключают свои JS скрипты, которые зависят от jQuery. Опять же, на примере Webasyst. Как результат, получаем 3 балла по Google PageSpeed, вонь сеошников, и корвалол на столе директора.
• не оптимальный дизайн БД и вытекающие оттуда проблемы. либо разработчики упарываются до 25 нормальной формы, либо делают только им понятный дизайн. На примере того же Webasyst, я кидал им PR где ускорял два запроса, которые работают каждый раз при открытии категории, в 20 раз. PR так и висит (как и все остальные PRы у них чуть больше чем в одну строку кодом). Тут же идет очередной сайд-эффект, в разработке всегда есть свои трейд-оффы, почти все решения хороши в чем-то одном, но абсолютно не приемлимы в другом. Если вам не повезло, и в вашем кейсе какой-то запрос тормозит, чтобы сменить дизайн базы, вам скорее всего придеться править ядро, которое ставит крест на обновлениях
• отсутствие обновлений ставит под угрозу безопасность проекта. даже корявый самопис с дырками вряд ли кто-то взломает, ведь проще купить уязвимость на форуме и пройтись скриптом по CMSкам, получив профит в несколько сотен/тысяч ломаных сайтов, чем ломать один определенный сайт, не имея никакого понятия где у него эндпойнты, куда заливать шелл, и т.д.

Все эти проблемы распространяются на большинство CMS, и тот же Битрикс из коробки будет обладать теми же самыми проблемами, а ещё всякое легаси, о которых я даже не вижу смысла упоминать.

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

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

Но с _SP_ я в чем-то согласен, иногда существует целая куча решений, которые могут чуть-ли не кофе заваривать, но не могут в какую-то самую простую вещь, которая важна. Не могут, потому что нет хука. Добавить хук - редактировать ядро. Редактировать ядро - прощай обновления. И начинается. Это все на примере того же Shop-Script.

Хотелось бы увидеть пример того магазина, о котором говорит _SP_.

https://downforeveryoneorjustme.com/webmoney.ru

а тут пишут что лежит, и у меня не грузится. штош, подождем

А у вас грузится?

awasome, уже либо шоссер тогда, либо ситик. А это ни то ни сё. Посмотри Orbea Carpe, Cannondale Bad Boy. Эти хотя бы выглядят не слащаво. А вообще под ситик нужно чтобы он был не дорогим (если украдут) и не капризным в обслуге (без топовых навесок, с ригидкой и т.д.). Например, трансмиссия ременная, тормоза механика, зазор под покрышки пошире, чтобы можно было под сезон обувать резину. Возможно наличие бонок для навески всяких утилитарных штук.

_SP_, опять же, если стоит задача читать данные и рисовать графики - можете взять любую TSDB (InfluxDB, Prometheus) и визуализатор данных под неё (Grafana, Kibana, etc.). Демон читает данные из SPI и экспортирует в метрики Prometheus, тот их вычитывает по интервалу и хранит, а сам визуализатор отрисовывает и строит запросы к хранилищу. На проме автоматизации не будет (если это сервоприводы какие-то, там только алерты, даже событий по условиям нет). InfluxDB + Telegraph + Kapacitor умеет в эвенты и всякого рода веб-хуки.

_SP_, не понял, как сочетается SPA/вебморда и автоматизация датчиков/механизмов? Графики с IoT хорошо рисует связка Prometheus/Grafana, я для метеостанции и контроля климата в доме использую это решение. Но там нет автоматизации (можно делать триггеры по алертам в проме, но это костыль).

Ну создайте A запись admin.site.ru ведущий на 1 сервер. Либо ручками ходите напрямую на айпи. Либо поставьте балансер, и если путь к админке, то проксируете на 1 сервер, в остальных случаях балансируйте по всем.

Отредактировать файл без рута не получится.

Да, но точно не тобой.

Сейчас все брошу, и побегу рассказывать.

Вот смотри, буквально недавно ты писал:

А теперь вычитка из кафки у тебя не работает.

Затем ты рассказываешь про видеострименг в твоей Джанге:

Тебя спросили про пакеты

После чего, ты не смог ни одного пакета назвать.

Резюмирую: ты работаешь в какой-то команде, где тех.лид принимает решения использовать какие-то инструменты (о которых тебя даже не спрашивают), они иногда сталкиваются с какими-то проблемами, про которые в курилке ты слышишь краем уха, после чего бежишь на этот форум, и выкладываешь все эти бессвязные термины, которые услышал. Я не вижу в этих действиях никакого смысла, кроме как самоутвредится. Выглядит это конечно убер-жалко, но лулзы доставляет. Даже ArbNet с этого рофлит, очевидно же.

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

Насколько сильно?

По хорошему, нужно:

1. Включить лог медленных запросов

2. Посмотреть какие запросы действительно тормозят

3. Решить как можно ускорить