Есть ощущение, что вы прочитали статью очень сильно по диагонали. Время жизни токена вы задаете сами: у меня это, как правило, две недели. Про сумасшедшую нагрузку на базу я тоже не писал. Статья в принципе не об этом.
в токене указываем два времени:
до которого он действителен - +1 год
после которого нужно выполнить верификацию валидности/забаненности итп
on-demand периодически валидируем все токены, обновляя второе время в них (то есть перевыдавая Set_Cookie)
Вы точно мою статью пересказываете? Придумали какие-то годы и минуты и перевалидацию всех токенов.
Спасибо за ссылку на статью, ознакомился. Выкрутились они примерно также: затащили в проект Symfony и, в конечном счете, всю обработку запросов направили именно на него. Дальше, если требовалось вызвать старый код, он вызывался уже из Symfony приложения. Единственно, что мне не понравилось, это переплетение старого и нового приложений, что автор отразил в том числе на схемах.
Ну а самое главное отличие состоит вот в чем: команде, описываемой в статье, на которую вы ссылаетесь, выделили время (и, судя по всему, немаленькое) на рефакторинг. В нашем случае было потрачено полтора месяца моего времени, и все. Остальная команда не отрывалась от решения бизнес-задач. Если б у нас была возможность всей командой хотя бы четверть времени тратить на рефакторинг на протяжении какого-то длительного времени (а судя по вашей статье, команда начала рефактор в 17 году и закончила в 20), то, можно было бы много крутых вещей сделать.) Причем, само решение осталось бы таким же, каким я его описал, но вот старого кода можно было бы ооочень много выпилить, перенеся те же модели полностью на доктриновский мапинг с выносом бизнес-логики в доменный слой.
Ну и на счет траты ресурсов добавлю.) Поверьте это такая мелочь на фоне многочисленных кусков, где в тройном вложенном цикле дергается одна штучка ActiveRecord, что порождает десятки тысяч запросов к базе.
Чтобы начать думать о том, о чем вы говорите, нужно сначала забороть все вот такие вот места.)
Очень хорошее замечание, спасибо. Тут надо понимать, что в описываемом проекте вообще нет хороших решений.) Есть тяжелый код, который надо дорабатывать, команда немаленькая, кодовая база ежедневно пополняется. Искался путь хоть как-то облегчить написание нового кода и задепрекейтить старый, трогать его как можно реже, что почти невозможно, т. к. все равно на старый код приходится опираться (тут уже надо интерфейсами отгораживаться, но я снова ухожу в архитектуру)).
Соответственно, если при решении своей задачи разработчик попал в ситуацию, которую вы описываете, то у него есть как минимум два пути:
Сделать новый доктриновский мапинг на все данные, изменение которых происходит внутри транзакции.
Открыть транзакцию доктриновским коннектом, флашнуть те энтити, которые у него есть, а остальные данные изменить нативными SQL запросами (можно востользоваться DBALовским QueryBuilder).
Я однозначно за первый вариант: второй грязноват, да и новый мапинг в будущем все равно пригодится, ведь в идеале хотелось бы со временем покрыть доктриной все 250 таблиц и оставить старые ActiveRecord только как носители кусков бизнес-логики. Как я сказал, в этом проекте нет хороших решений, приходится работать с тем, что есть.)
Да, два отдельных коннекта, каждый из которых является оберткой PDO. ActiveRecord и Доктрина друг другу никак не мешают. В Yii коннект к базе представлен, как и все прочее, компонентом фреймворка и доступен через глобальный объект \Yii. Когда иишный Appication инстанцируется, загружаются и все компоненты Yii. Соответственно, с этой секунды нам доступен как сам коннект (параметры которого берутся из конфига Yii), Так и все классы-наследники ActiveRecord, которые внутри себя дергают этот самый коннект через обращение к Yii::$app->getDb().
Соответственно, в симфонийском DIC у нас зарегистрирован доктриновский DBAL Connection, который также является оберткой над PDO и сконфигурирован из doctrine.yaml. Даже если представить себе ситуацию, когда мы в одной репе начнем дергать ActiveRecord и доктриновские EntityRepository одновременно, под капотом будут именно два PDO коннекта к одной и той же базе.
В плане работы с моделями подход такой: Легаси-модели, наследники ActiveRecord стараемся дорабатывать как можно реже, только при крайней нужде. При решении новых задач создаем новые модели, которые мапятся на те же таблицы. Для того, чтобы не терять темп разработки, разрешается в рамках задачи мапить только те поля, которые нужны для ее решения. То есть, если у нас старая модель ActiveRecord на 50 полей, то новую можно сделать только на 5 полей, если для решения текущей задачи их достаточно. При решении последующих задач новую модель можно дополнять полями, можно выделять новые модели, которые смотрят на ту же таблицу. Была у нас монструозная легаси-модель на 50 полей, а мы ее постепенно разбили на 5 новых красивых моделей, пусть они и наполняются данными из одной таблицы.
Надеюсь, понятно объяснил, тут уже начинается история про архитектуру, можно несколько отдельных статей написать.)
На счет ваших пожеланий: здесь жанр другой. Рассказываю что и как делал, вдруг кому потребуется повторить. Цели как-то рекламировать решение не было и агитировать повторять за мной.
Строчку в резюме обязательно добавлю, хоть и не руководитель и решения не принимал.)
Количество строк измеряли плагином статистика в шторме. Плохо или хорошо иметь 180 тыс. строк связанного кода, решайте сами. Мне - плохо. За сколько их написали - понятия не имею, и не знаю, чем такая информация может быть полезна.
По второму пункту ответить вам сложно. Переход на фреймворк не повлиял на старые фичи, они как работали, так и работают, в том и была цель, чтобы их не зааффектить.
А на счет того, как в ваших глазах выглядит проект: правда в глазах смотрящего. В моих глазах он стал выглядеть намного лучше. И если я ни текстом статьи ни ответами на ваши и подобные комментарии не смог донести, почему стало лучше, то уже, видимо и не смогу.
Сто процентов нет такой грусти.) А вот о статье, как пользоваться профайлером xdebug для этих целей действительно подумываю.) Боюсь спросить, как Laravel ускоряет проекты.) На Yii2 действительно видел один раз проект лет пять назад, где загрузка самого фреймворка забирала почти 2 секунды в каждом запросе. Не погружался тогда в причины, т. к. не мой проект был. Что до Symfony, то тоже как-то раз видел долгоживущий проект, где почти все классы были загружены в DIC, что добавляло нормально времени на его загрузку. Но в целом, скорость не от фреймворка зависит, а от разработчика. На любом фреймворке и языке можно шляпу написать.)
Цели постарался в начале статьи перечислить, но коротко вы удачно описали: начать дорабатывать новые фичи уже на базе другого фреймворка.) В целом ситуация была такая: есть проект, написанный аутсорсом как попало. Дальше проект был передан продуктовой команде, которая при виде такого счастья пришла в уныние. Встал вопрос: как без остановки поставки бизнес-ценностей начать писать более аккуратный код на более понятном и приятном стеке.
Хочется же и валидатор, и сериалайзер, и доктрину, и другие симфонийские радости.) Тут надо понимать, что помимо смены фреймворка была и смена парадигмы разработки и архитектурного подхода. Просто описать все это в одной статье нереально, я и так старался покомпактнее, а получился большой текст.)
Я единственно хотел бы подчеркнуть, что не симфони был вкручен в проект, а проект был обернут в симфони. Больше того, новый код писался в новых папках. То есть, мы старое легаси оставили в проекте, но старались его не трогать, то есть не дописывать без крайней нужды. А когда старый код вызывался, то это делалось это по уму (про это отдельную статью можно написать).
А так, у нас появилась возможность писать новые чистенькие контроллеры, сервисы, модельки и прочее.
Да, все верно: монолит как был, так и остался. Оттого и упомянут, что в микросервисной архитектуре подход к решению задачи был бы другим. Вернее, там такая задача и не встала бы скорее всего.
А на счет переписать 180 тыс. строк высокосвязанного кода в проекте, который нонстопом дорабатывает 10 бэков, выпуская по несколько фичей в день - это что-то за гранью реального.)
Вот у вас первое приложение, в котором 180 тыс. строк PHP кода и 250 таблиц. Команда из 10 бэков. Стартап, который очень нервно считает свои деньги. Менеджмент льет на команду требования по выпуску десятков фичей.
Как вы, начав новое приложение в отдельном контейнере будете опираться на бизнес-логику и данные из старого? Конечно, если есть возможность начать с чистого листа, любой ей воспользуется, извращенцев нет.)
Тут как раз речь шла о ситуации, когда сменилась команда с аутсорсной на продуктовую, все смотрели на старый код и выли. И нужно было как-то начать писать по-новому, не отказываясь от старого, не тратя много ресурсов на переход и ни на день не стопоря выпуск новых фичей.
Мне при написании статьи эта мысль казалась настолько очевидной, что я об этом даже не упомянул.) Возможно, стоит написать еще одну статью, которая дополнит эту.)
Ну вообще цель была остановить то, что у вас на правой картинке, как-то это задепрекейтить и начать писать более упорядоченно, перейдя на современный стек. Вижу по комментам, что у читателей сложилось противоположное мнение. Значит, я не до конца донес свою мысль. На то она и первая статья.)
Есть ощущение, что вы прочитали статью очень сильно по диагонали. Время жизни токена вы задаете сами: у меня это, как правило, две недели. Про сумасшедшую нагрузку на базу я тоже не писал. Статья в принципе не об этом.
Вы точно мою статью пересказываете? Придумали какие-то годы и минуты и перевалидацию всех токенов.
Спасибо за ссылку на статью, ознакомился. Выкрутились они примерно также: затащили в проект Symfony и, в конечном счете, всю обработку запросов направили именно на него. Дальше, если требовалось вызвать старый код, он вызывался уже из Symfony приложения. Единственно, что мне не понравилось, это переплетение старого и нового приложений, что автор отразил в том числе на схемах.
Ну а самое главное отличие состоит вот в чем: команде, описываемой в статье, на которую вы ссылаетесь, выделили время (и, судя по всему, немаленькое) на рефакторинг. В нашем случае было потрачено полтора месяца моего времени, и все. Остальная команда не отрывалась от решения бизнес-задач. Если б у нас была возможность всей командой хотя бы четверть времени тратить на рефакторинг на протяжении какого-то длительного времени (а судя по вашей статье, команда начала рефактор в 17 году и закончила в 20), то, можно было бы много крутых вещей сделать.) Причем, само решение осталось бы таким же, каким я его описал, но вот старого кода можно было бы ооочень много выпилить, перенеся те же модели полностью на доктриновский мапинг с выносом бизнес-логики в доменный слой.
Спасибо за вашу оценку.)
Ну и на счет траты ресурсов добавлю.) Поверьте это такая мелочь на фоне многочисленных кусков, где в тройном вложенном цикле дергается одна штучка ActiveRecord, что порождает десятки тысяч запросов к базе.
Чтобы начать думать о том, о чем вы говорите, нужно сначала забороть все вот такие вот места.)
Очень хорошее замечание, спасибо. Тут надо понимать, что в описываемом проекте вообще нет хороших решений.) Есть тяжелый код, который надо дорабатывать, команда немаленькая, кодовая база ежедневно пополняется. Искался путь хоть как-то облегчить написание нового кода и задепрекейтить старый, трогать его как можно реже, что почти невозможно, т. к. все равно на старый код приходится опираться (тут уже надо интерфейсами отгораживаться, но я снова ухожу в архитектуру)).
Соответственно, если при решении своей задачи разработчик попал в ситуацию, которую вы описываете, то у него есть как минимум два пути:
Сделать новый доктриновский мапинг на все данные, изменение которых происходит внутри транзакции.
Открыть транзакцию доктриновским коннектом, флашнуть те энтити, которые у него есть, а остальные данные изменить нативными SQL запросами (можно востользоваться DBALовским QueryBuilder).
Я однозначно за первый вариант: второй грязноват, да и новый мапинг в будущем все равно пригодится, ведь в идеале хотелось бы со временем покрыть доктриной все 250 таблиц и оставить старые ActiveRecord только как носители кусков бизнес-логики. Как я сказал, в этом проекте нет хороших решений, приходится работать с тем, что есть.)
Да, два отдельных коннекта, каждый из которых является оберткой PDO. ActiveRecord и Доктрина друг другу никак не мешают. В Yii коннект к базе представлен, как и все прочее, компонентом фреймворка и доступен через глобальный объект \Yii. Когда иишный Appication инстанцируется, загружаются и все компоненты Yii. Соответственно, с этой секунды нам доступен как сам коннект (параметры которого берутся из конфига Yii), Так и все классы-наследники ActiveRecord, которые внутри себя дергают этот самый коннект через обращение к Yii::$app->getDb().
Соответственно, в симфонийском DIC у нас зарегистрирован доктриновский DBAL Connection, который также является оберткой над PDO и сконфигурирован из doctrine.yaml. Даже если представить себе ситуацию, когда мы в одной репе начнем дергать ActiveRecord и доктриновские EntityRepository одновременно, под капотом будут именно два PDO коннекта к одной и той же базе.
В плане работы с моделями подход такой: Легаси-модели, наследники ActiveRecord стараемся дорабатывать как можно реже, только при крайней нужде. При решении новых задач создаем новые модели, которые мапятся на те же таблицы. Для того, чтобы не терять темп разработки, разрешается в рамках задачи мапить только те поля, которые нужны для ее решения. То есть, если у нас старая модель ActiveRecord на 50 полей, то новую можно сделать только на 5 полей, если для решения текущей задачи их достаточно. При решении последующих задач новую модель можно дополнять полями, можно выделять новые модели, которые смотрят на ту же таблицу. Была у нас монструозная легаси-модель на 50 полей, а мы ее постепенно разбили на 5 новых красивых моделей, пусть они и наполняются данными из одной таблицы.
Надеюсь, понятно объяснил, тут уже начинается история про архитектуру, можно несколько отдельных статей написать.)
На счет ваших пожеланий: здесь жанр другой. Рассказываю что и как делал, вдруг кому потребуется повторить. Цели как-то рекламировать решение не было и агитировать повторять за мной.
Строчку в резюме обязательно добавлю, хоть и не руководитель и решения не принимал.)
Количество строк измеряли плагином статистика в шторме. Плохо или хорошо иметь 180 тыс. строк связанного кода, решайте сами. Мне - плохо. За сколько их написали - понятия не имею, и не знаю, чем такая информация может быть полезна.
По второму пункту ответить вам сложно. Переход на фреймворк не повлиял на старые фичи, они как работали, так и работают, в том и была цель, чтобы их не зааффектить.
А на счет того, как в ваших глазах выглядит проект: правда в глазах смотрящего. В моих глазах он стал выглядеть намного лучше. И если я ни текстом статьи ни ответами на ваши и подобные комментарии не смог донести, почему стало лучше, то уже, видимо и не смогу.
Сто процентов нет такой грусти.) А вот о статье, как пользоваться профайлером xdebug для этих целей действительно подумываю.) Боюсь спросить, как Laravel ускоряет проекты.) На Yii2 действительно видел один раз проект лет пять назад, где загрузка самого фреймворка забирала почти 2 секунды в каждом запросе. Не погружался тогда в причины, т. к. не мой проект был. Что до Symfony, то тоже как-то раз видел долгоживущий проект, где почти все классы были загружены в DIC, что добавляло нормально времени на его загрузку. Но в целом, скорость не от фреймворка зависит, а от разработчика. На любом фреймворке и языке можно шляпу написать.)
Цели постарался в начале статьи перечислить, но коротко вы удачно описали: начать дорабатывать новые фичи уже на базе другого фреймворка.) В целом ситуация была такая: есть проект, написанный аутсорсом как попало. Дальше проект был передан продуктовой команде, которая при виде такого счастья пришла в уныние. Встал вопрос: как без остановки поставки бизнес-ценностей начать писать более аккуратный код на более понятном и приятном стеке.
Хочется же и валидатор, и сериалайзер, и доктрину, и другие симфонийские радости.) Тут надо понимать, что помимо смены фреймворка была и смена парадигмы разработки и архитектурного подхода. Просто описать все это в одной статье нереально, я и так старался покомпактнее, а получился большой текст.)
Я единственно хотел бы подчеркнуть, что не симфони был вкручен в проект, а проект был обернут в симфони. Больше того, новый код писался в новых папках. То есть, мы старое легаси оставили в проекте, но старались его не трогать, то есть не дописывать без крайней нужды. А когда старый код вызывался, то это делалось это по уму (про это отдельную статью можно написать).
А так, у нас появилась возможность писать новые чистенькие контроллеры, сервисы, модельки и прочее.
Да, все верно: монолит как был, так и остался. Оттого и упомянут, что в микросервисной архитектуре подход к решению задачи был бы другим. Вернее, там такая задача и не встала бы скорее всего.
А на счет переписать 180 тыс. строк высокосвязанного кода в проекте, который нонстопом дорабатывает 10 бэков, выпуская по несколько фичей в день - это что-то за гранью реального.)
Вот у вас первое приложение, в котором 180 тыс. строк PHP кода и 250 таблиц. Команда из 10 бэков. Стартап, который очень нервно считает свои деньги. Менеджмент льет на команду требования по выпуску десятков фичей.
Как вы, начав новое приложение в отдельном контейнере будете опираться на бизнес-логику и данные из старого? Конечно, если есть возможность начать с чистого листа, любой ей воспользуется, извращенцев нет.)
Тут как раз речь шла о ситуации, когда сменилась команда с аутсорсной на продуктовую, все смотрели на старый код и выли. И нужно было как-то начать писать по-новому, не отказываясь от старого, не тратя много ресурсов на переход и ни на день не стопоря выпуск новых фичей.
Мне при написании статьи эта мысль казалась настолько очевидной, что я об этом даже не упомянул.) Возможно, стоит написать еще одну статью, которая дополнит эту.)
Ну вообще цель была остановить то, что у вас на правой картинке, как-то это задепрекейтить и начать писать более упорядоченно, перейдя на современный стек. Вижу по комментам, что у читателей сложилось противоположное мнение. Значит, я не до конца донес свою мысль. На то она и первая статья.)
Человек может поделиться опытом своей попытки устроиться в vk.)
Нанять 5 разработчиков по итогу 20 техинтервью - это, конечно, эффективность, вызывающая лютую зависть. Вашим HR, осуществляющим предварительный отбор, надо поставить памятник.)