а сейчас вот так

раньше и бандлы двигали

раньше и бандлы двигали

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

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

вот такое я не застал походу)

А на хой?

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

ну не совсем

они давали возможность

но не заставляли это делать)

они давали возможность

Так то возможность никуда не делась

и выставляли это как фичу

типа в одном приложении можете иметь несколько

У меня мысля "микросеврисы" так сделать)

вы хотите поговорить о микросервисах?

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

Но это были только мысли)

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

если ты сможешь разрабатывать и деплоить каждый "микросервис" по отдельности - то это микросервисы) иначе это монолит

APP_KERNEL как environment передавать

Я даже не помню, что я этим решить пытался

Скорее всего хотел избавится от подобия CoreBundle.

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

не, это не микросервисы

это оптимизации, не более)

Да, причём в 99% случаев бестолковые

Кстати. В 3.4 и 4.0 кеш уже ready only?

Я что-то упустил этот момент

Скорее всего хотел избавится от подобия CoreBundle.

core bundle плохо....

core bundle плохо....

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

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

это инфраструктура, это нормально.

и упрости все до "модулей" а не микросервисов. Проще будет

модули, coheasion, coupling, устранение циклических зависимостей

Да, стараюсь так делать

Про кеш никто не знает?

да, кэш теперь read only

Где то на симфони видел обсуждение, что хотели кеш сделать ридонли. Чтобы кеш можно было вармапить ещё на этапе билда контейнера

оу, можно заюзать

теперь они хотят добавить var/tmp для всей фигни генерящейся в рантайме

Где то на симфони видел обсуждение, что хотели кеш сделать ридонли. Чтобы кеш можно было вармапить ещё на этапе билда контейнера

уже давно можно

https://github.com/symfony/symfony/issues/23354

оу, можно заюзать

проблемы раньше были только с отдельными бандлами но не с симфони

с тех пор как .env завезли полноценный

Там вроде главная беда с env как раз

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

Там вроде главная беда с env как раз

нет никакой беды

просто что бы скомпилить кэш тебе нужен env, но если ты посмотришь сдампленный контейнер ты увидишь что вместо конкретных значений там будет

в смысле была

getenv(...)

в 3.3 точно нормально уже было

скорее всего даже с 3.2

Доброго, коллеги! Не подскажите, может кто сталкивался, есть ли бандлы, может "черновики" бандлов, для реализации биллинга с привязкой к FOSUser. Тарифы с ограничениями, списание средств и т.п. Или самому реализовывать?

Доброго, коллеги! Не подскажите, может кто сталкивался, есть ли бандлы, может "черновики" бандлов, для реализации биллинга с привязкой к FOSUser. Тарифы с ограничениями, списание средств и т.п. Или самому реализовывать?

зачем тебе привязка к fos user?

тот факт что он у тебя есть не означает что нужна привязка к нему

А как блокировать учетку?

если нет средств

ты заблокируешь юзера, биллинг тут причем?

если нет средств

это уже сам

ловиш событие/исключение и лочишь юзера

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

а биллинг поверх сам пиши

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

Ну думаю да, нужно писать самому, просто не сталкивался с этим

А насколько грамотно, обходить по крону: Допустим, баланс юзера....?

смотря для чего)

и что такое "баланс юзера"

баланс юзера очень занятная штука )) db race condition доставляют если не учесть)

если с баланса списывает пользователь своим действием

вряд ли что-то готовое есть, это ж вокруг бизнеса все со своими нюансами

Ну допустим: Тариф А - 100 руб (Ораничения: 10 чего-то) Тариф Б - 50 руб (Ограничения: 5 чего-то) Я так понимаю нужно в тб юзер занести инфу о балансе и тарифе

потом проходить кроном на наличие этих 100 руб

ERROR: S client not available

вряд ли что-то готовое есть, это ж вокруг бизнеса все со своими нюансами

лэджеры есть)

я б лучше транзакции списания/пополнения заводил, и вычислять баланс

лэджеры есть)

по англ как погуглить ?

для подписок есть готовые сервисы

по англ как погуглить ?

account ledger

для подписок есть готовые сервисы

Можно уточнить? Сервисы - сторонние сайты или сервисы в симфони (которые нужно писать)?

Можно уточнить? Сервисы - сторонние сайты или сервисы в симфони (которые нужно писать)?

сторонние сервисы

account ledger

Где почитать можно? Что-то в гуглёшь к вечеру не получается

getenv(...)

ты кстати с parameters.yml уже давно сьехал?

Можно уточнить? Сервисы - сторонние сайты или сервисы в симфони (которые нужно писать)?

ну и бандлы тоже есть, но могут не подойи

ты кстати с parameters.yml уже давно сьехал?

год как

ты кстати с parameters.yml уже давно сьехал?

но не все можно в env переменные запихнуть. Когда вайтлейблы были - там юзал конфиги которые подмешивались в момент сборки образов (по образу на вайтлейбл)

но не все можно в env переменные запихнуть. Когда вайтлейблы были - там юзал конфиги которые подмешивались в момент сборки образов (по образу на вайтлейбл)

ну в parameters.yml тоже не все впихнешь

ну в parameters.yml тоже не все впихнешь

ну тип того)

Где почитать можно? Что-то в гуглёшь к вечеру не получается

https://github.com/paragonie/chronicle

вот например

Можно уточнить? Сервисы - сторонние сайты или сервисы в симфони (которые нужно писать)?

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

да и есть шанс загуглить "subscriptions bundle" и найти что-то готовое

вот например

А есть что по ведению склада?

А есть что по ведению склада?

тот же кроникл можешь заюзать)

ведение склада - это все что угодно

Там про зерервирование есть?)

Там про зерервирование есть?)

нет. это append-only база данных

то есть ты хранишь стэйт приложения как набор фактов. "кто-то завоз товар, кто-то забрал товар"

но это можно и на mysql сделать

Тупо погуглил с фразой "billing bundle" есть варианты. Вот пример https://github.com/wobblecode/WobbleCodeBillingBundle поизучаю

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

Тупо погуглил с фразой "billing bundle" есть варианты. Вот пример https://github.com/wobblecode/WobbleCodeBillingBundle поизучаю

тебе биллинг или подписки?)

Тупо погуглил с фразой "billing bundle" есть варианты. Вот пример https://github.com/wobblecode/WobbleCodeBillingBundle поизучаю

4 коммита год назад.... ты уверен?)

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

ну вот у тебя будет набор фактов: - Вася зарезервировал деталь А, Петя зарезервировал деталь Б.

дальше все сам, проекции данных, блокировки

Что такое проекции?)