Sergey
только вот любая миграция — дело ответственное
и бездумное переименование/добавление полей это уже проблема
Sergey
по мне написание миграции должно быть первым
Антон
бизнес-требования меняются часто, тут бездумность не причем
Sergey
бизнес-требования не обязывают тебя писать миграцию после изменения кода модели
Антон
и я за подход code first, а если точнее, то вообще сначала абстракция, потом код, и потом ты уже думаешь, как это хранить
Sergey
отсюда все проблемы и тормоза обычно
Антон
наоборот)
Sergey
надумают себе охуенных абстракций, а потом думают как эффективно это хранить в базе
и как оптимизировать выборки
Антон
у нас чувак пару месяцев проектировал бд, потом требования координально поменялись)
Sergey
проблема тех кто требует
Ale
Таймураз
бизнес-требования меняются часто, тут бездумность не причем
Тут уж у кого как
Условия в лице бизнеса в нашем разговоре до этого не стояло и намека на него не было
Sergey
кек, ваши бизнес-задачи не подходят под мои офигенные схемы
Когда требования кардинально меняются я тут же увольняюсь
Антон
они всегда меняются
Ale
Когда требования кардинально меняются я тут же увольняюсь
окей, тут у нас явно есть непонимание, что такое "кардинально"?
Таймураз
не, на всяких скриптовых этих вот языках
Ты же согласен, что один сложный запрос на SQL будет быстрее аналогичного решения на множестве примитивных SQL запросов и обработки данных на стороне приложения?
Антон
ну это уже не та степь
Ale
Ты же согласен, что один сложный запрос на SQL будет быстрее аналогичного решения на множестве примитивных SQL запросов и обработки данных на стороне приложения?
ну время на отправку запроса и все такое, вполне вероятно да
Таймураз
Так не только отправка запроса, работа с данными на стороне приложения практически в любом случае будет медленнее аналогии в SQL
Ale
И на собственно исполнение
ну если грубо делать, то один большой мы рассматриваем по сложности как батч простых
Таймураз
Говоря проще, исполнение, да
Ale
поэтому это время будет грубо говоря похожим
Ale
в любом случае больше всего будет потрачено времени на io
Ale
если остальное время одинаковое *
Антон
ну, если массовое изменение большого объема данных, то может и нет)
Антон
но это довольно редкие случаи
Антон
и их обычно рассматривают отдельно
Ale
короче да, но я не понял к чему был этот вопрос, откровенно говоря
Антон
я тоже)
Ale
построение доменных моделей и абстракций мешает делать правильный оптимизированные запросы?
Ale
ну видимо хуевые абстракции у вас)
Ale
или же может вы ничего не выигрываете?
Антон
о, кстати, а ты графкл рассматривал как рид модел?)
Антон
с парой тулз можно обычный круд замутить за 5 секунд с разделением на рид и райт модели, при условии, что вся структура будет описана в моделях секвелайза
Ale
если вопрос мне, то не, я пока не разобрался с графкл как концепцией и разницей с тем, что есть сейчас
Ale
ну и какие профиты получатся
Антон
тебе, ага, ну, если бд нормализованная, и много связей, то чтоб создать одну запись в табле при ресте - тебе нужно сделать запросы на получение айдишников всех связанных моделей, потом вставить айдишники вместо человекочитаемых значений, и только потом ебануть всю эту чачу на бэк опять
Ale
тебе, ага, ну, если бд нормализованная, и много связей, то чтоб создать одну запись в табле при ресте - тебе нужно сделать запросы на получение айдишников всех связанных моделей, потом вставить айдишники вместо человекочитаемых значений, и только потом ебануть всю эту чачу на бэк опять
раздели базы на чтение и запись)
Антон
так вот)
Антон
мы изначально сделали это на вьюхах в постгресе
Антон
но это плохое решение
Антон
при любом изменении структуры надо будует удалять вьюхи, потом делать изменение, и потом пересоздавать вьюхи
Антон
графкл - гибкая замена
Антон
для чтения вообще офигенно, но для записи и изменения - мне не зашла
Антон
надо создавать мутации, там много писанины
Антон
https://github.com/dchester/epilogue - эта штука круче в плане изменений
Антон
из нее же евенты можно пулять, как до изменений, так и после
Ale
при любом изменении структуры надо будует удалять вьюхи, потом делать изменение, и потом пересоздавать вьюхи
ну мы это на уровне приложения делаем, классический cqrs+es с проекторами
Ale
есть шина ивентов, которые пишутся в стрим, есть проекторы, которые по списку ивентов строят нужные для чтения структуры
Ale
соответственно чтобы получить новую структуру, надо сделать проектор и перепроиграть события
Антон
сложнааа, тут ты просто меняешь запрос, и получаешь нужные данные
Антон
я все же пока для себя не оценил подход с хранением ивентов вместо конечных данных, я просто логирую все действия
Ale
я все же пока для себя не оценил подход с хранением ивентов вместо конечных данных, я просто логирую все действия
ну тебе плевать на изменение схемы)
Антон
хранение ивентов от этого не спасает)
Антон
условно говоря возьмем пример выше - нейм разделили на ласт и ферст
Антон
у тебя раньше ивенты были с полем нейм
Антон
и тебе придется все их изменять?)
Антон
или я недопонял подход?
Ale
ивенты ваще редко меняются
Nikita Tolkachev
сделать ивент, который разобьет нейм на ласт и ферст
Антон
при проматывании назад у ивентов до этого ивента не будет нужных филдов
Антон
вот я о чем)
Антон
и тогда придется хранить две реализации кода - первая для новых ивентов, а вторая - для старых
Антон
но профитов я до сих пор не вижу
Антон
это обусловлено только в тех случаях, когда есть потребность вернуть систему в какое-то раннее состояние
Ale
если ивенты меняются часто, то тогда профитов никаких, а если не меняются(очень редко) или их изменения этакие эволюционные(новые виды ивентов), но при этом часто меняется запрос по чтению(разные виды отчетов, разные запросы пользователей и прочее), то профита много
Ale
очевидно ж, что не silver bullet)
Антон
насчет чтения - графкл пока мне кажется очень крутым (пока проектов на нем нет, не могу быть уверенным)
Антон
а вот частые изменения - это норма
A
Народ, тут периодически интересовались о фреймворке Strapi, который поверх Koa.
https://strapi.io
Есть у кого опыт использования?
Dmitrii
Vsevolod
Я честно скажу - пробовал страпи, слишком сложный прикол. Чего-то не хватает, с чем-то перебор. Может, я не понял его просто
Vsevolod
Ребят, а sequelize у нас что, стандарт же факто? А альтернативы типа букшелфа вообще не котируются?