Кстати, тут еще вспомнил, что когда колупал различные скелеты и мануалы по Slim 4, встретил интересный паттерн ADR (Action, Domain, Responder). Это из теорий о гексагональной архитектуре, паттерн сам по себе достаточно спорный и многословный, хотя архитектурно хорош и сделан специально для backend сервисов.
Хотел узнать твое мнение на этот счет.
Смотрел, шчупал (как говорит наш пока президент), но остались двоякие чувства. Для старта заготовка хорошая, но есть пару моментов, которые смущают. Никогда не поздно отправить PR, но сначала подсвечу это тут, чтобы понимать, не нарушает ли это концепцию в целом.
Первое, что меня смутило, это метод process, который нужно явно определять в тех же роутах, вместо `__invoke()`, при использовании которого можно передать просто имя класса.
Второй пункт просто вопрос. Классика миграций — это up/down, но пробовал ли change у phinx? Пишут, что он умеет сам определять, что нужно откатить. И тут в довесок брюзжание на тему, что в одной миграции две таблицы описаны, а лучше бы разделять сущности (имхо).
По толстым контроллерам и нарушением правил по service layer в целом понятно и принято, сделать близко к логике MODX, хоть и не канонично :) Но главное работает.
По github.com/bezumkin/vesp-example кстати, можно поставить в настройках репозитория галочку Шаблон, будет удобно сразу себе в репу утащить и потом просто клонировать уже готовый код, чтобы не возиться с созданием, клонированием, прописыванием remote и тд.
Ты можешь воспринимать это как придирку, твое право. И это твоя система, ты за нее в ответе. В то же время ты сам упоминал, что у вас есть окружения, которые настраивали матерые devops, на k8s и прочем непотребстве и там все намного серьезнее и аккуратнее и ведь неспроста это так, согласись?
Я по стечению обстоятельств тимлидствую ещё и над несколькими девопсами и мои рекомендации и замечания основаны на определенном практическом опыте этих людей.
Зная, что у тебя везде доступы одинаковы, ничего не мешает, утилизируя уязвимость код на php (а они в общем-то могут быть), узнать креды подключения БД и получить полный доступ над системой, а то и всеми твоими проектами сразу. А ты эту информацию уже публично раскрыл. Технически да, они изолированы внутри, но если это продакшен, то лучше так не делать.
docker system prune -a и прочее — это ж если какие другие окружения на докер подняты, грохнет все к херам. Нельзя так, даже если очень хочется. Я б за нож взялся, случись у меня такое. Хоть это и makefile для удобства, но я бы ограничивал бы его областью конкретного окружения, то есть управлять только тем, что описано в docker-compose.
Делать дампы БД, когда в docker есть data-volumes, которые в случае с mysql работают просто как часики (чего не скажешь о postgress) — выглядит крайне крипово. Они сторят файлы БД на локальной машине, сам сервер — в контейнере. При перезапуске данные всегда на месте. Тем более, что конфиги ты через них уже пробрасываешь.
Остальное уже придирки. Инструмент задачу решает — уже хорошо.
Хехе. Те же детские болезни, что у меня в начале. Возня с hosts и nginx-proxy.
Я решил эту проблему, подняв вместо nginx-прокси Traefik, который отвечает за резолвинг локальных доменов, причем он умеет в нормальный https и позволяет декларативно прописывать домены прямо в docker-compose.yml. А чтобы не возиться с хостами, я сделал локальную доменную зону через dnsmasq.
В ближайшее время выкрою время и допишу парочку своих заметок на эту тему.
А вот насчет того, что креды у БД везде одинаковы, это все же небезопасно, даже если крутится в контейнерах.
Потому что простой, без лишнего мусора и сука быстрый. И еще параллельность из коробки, с которой первоклашка разберется. Ну и очень строгие правила, говнокод даже не скомпилится.
У меня нет ответа на этот вопрос, я не зацикливаюсь на конкретных инструментах. При случае, если так будет быстрее/дешевле/удобнее, выберу MODX без зазрений совести. Лично я собираюсь развиваться в сторону управления людьми — Team Lead с перспективой CTO (это другие навыки, не код). Относительно кода — предпочитаю PHP+Golang.
На голой установке без оптимизаций не вывезет. Ну и несколько миллионов — тут следует уточнять, потому что 2 и 20 млн — это все несколько, но разница между цифрами большая.
Я исхожу из того, что у вас описано в вопросе, что у вас там еще накручено дополнительно, я не знаю и знать не могу, поэтому это уже вам решать. Написано было, что количество задается метрами, без всяких count. А следовательно можно купить либо 0.5 м либо 1.5 метра. Это дроби, но ничего не мешает указывать в поле количество сантиметры, как и цену выставить за сантиметр, тогда вообще ничего менять не нужно, кроме форматирования на сайте (там да, нужно будет цифры разделить на 100, цену — уможить на 100).
Так вот со Stripe и беда, потому что они дают просто виджет на JS, который нужно впиндюрить на свой сайт, а там хоть и iframe, снифать не проблема ввод с клавы. В случае перехода на защищенную страницу такой проблемы нет.
Эм, а зачем на сайте запрашивать данные карты? Ну я к тому, что есть системы оплаты, которые проходят сертификацию и аудит по PCI DSS и которым можно доверять (больше чем сайту) и все платежи обрабатывать путем отправки пользователя на эти страницы, не процеся у себя ничего.
Как правило (и это де факто стандарт в разработке) конфиги не синхронизируют при деплоее, т.е. их выносят в исключения в git и других системах контроля версий и так далее. В вашем случае тоже стоит добавить их в исключения и не синхронизировать, следовательно локально и на сервере это будут разные файлы. Менять в процессе разработки вы их тоже не станете, ибо нет нужды. Ну и научитесь то уже MODX писать правильно. :)
Хотел узнать твое мнение на этот счет.
Первое, что меня смутило, это метод process, который нужно явно определять в тех же роутах, вместо `__invoke()`, при использовании которого можно передать просто имя класса.
Второй пункт просто вопрос. Классика миграций — это up/down, но пробовал ли change у phinx? Пишут, что он умеет сам определять, что нужно откатить. И тут в довесок брюзжание на тему, что в одной миграции две таблицы описаны, а лучше бы разделять сущности (имхо).
По толстым контроллерам и нарушением правил по service layer в целом понятно и принято, сделать близко к логике MODX, хоть и не канонично :) Но главное работает.
По github.com/bezumkin/vesp-example кстати, можно поставить в настройках репозитория галочку Шаблон, будет удобно сразу себе в репу утащить и потом просто клонировать уже готовый код, чтобы не возиться с созданием, клонированием, прописыванием remote и тд.
В остальном неплохой инструмент получился, лайк!
Я по стечению обстоятельств тимлидствую ещё и над несколькими девопсами и мои рекомендации и замечания основаны на определенном практическом опыте этих людей.
docker system prune -a и прочее — это ж если какие другие окружения на докер подняты, грохнет все к херам. Нельзя так, даже если очень хочется. Я б за нож взялся, случись у меня такое. Хоть это и makefile для удобства, но я бы ограничивал бы его областью конкретного окружения, то есть управлять только тем, что описано в docker-compose.
Делать дампы БД, когда в docker есть data-volumes, которые в случае с mysql работают просто как часики (чего не скажешь о postgress) — выглядит крайне крипово. Они сторят файлы БД на локальной машине, сам сервер — в контейнере. При перезапуске данные всегда на месте. Тем более, что конфиги ты через них уже пробрасываешь.
Остальное уже придирки. Инструмент задачу решает — уже хорошо.
Я решил эту проблему, подняв вместо nginx-прокси Traefik, который отвечает за резолвинг локальных доменов, причем он умеет в нормальный https и позволяет декларативно прописывать домены прямо в docker-compose.yml. А чтобы не возиться с хостами, я сделал локальную доменную зону через dnsmasq.
В ближайшее время выкрою время и допишу парочку своих заметок на эту тему.
А вот насчет того, что креды у БД везде одинаковы, это все же небезопасно, даже если крутится в контейнерах.