Иван, вы меня опередили на несколько месяцев. Я точно такую же статью хотело написать, но с закосом не на hibernate. Здесь он совсем не подходит. Проще использовать JOOQ. Я же так же не парился и написал функцию в PostgreSQL. Смотрю, вы тоже использовали его. Можно чуть упростить запросы, так как местами они перегружены sql native.
СУБД должна быть рабочая у разработчика, который запускает приложение. Это может быть независмый экземпляр от контейнера или контейнер c экземпляром СУБД. Кому как удобно. У меня без контейнера!
С описанием json path у меня проблем никогда не было. Более старый способ выглядит логичным. Вот что касается асинхронного запроса, тут можно много спорить. Практика на проде покаже, стоит ли он тех усилий или нет!
У вас с Ktor какой опыт работы? Не кажется ли вам он слишком велосипедным? Приходится бины объявлять вручную, вплоть до объевления уровней логирования и иже с ним слои.
C оптимизацией запросов у меня нет проблем. Само собой, что вначале нужно просто понять, в чем проблема, а уже потом масштабироваться базу. Просто в реальности получается зачастую ситуация, когда времени руководство проекта не даёт на то, чтобы немного поразбираться и проще всего взять и добавить реплику.
Bot API 5.3. В этой версии появилась возможность формировать пользовательские команды для конкретного chat_id. Давно ждал такой фичи. Теперь всегда буду в своих проектах ими пользоваться. Возьмите эту фичу на заметку!
В моём примере готовая архитектура, если нужно добавить новый функционал, то просто наследуемся от InlineKeyboardMarkup или Chooser или Message и ChooseNextStep. Не забываем про паттерны ООП.
Замеры специально не делал, но полноценный маркетплейс, который основан на текущей архитектуре вполне умещается на 500мб ram. Там 500+ классов, очереди и шедулеры
на монолит нужно железо помощнее. Работая на монолите не редко стакиваешься с ситуацией, когда что-то пошло не так и нужно обновить индексы у проекта. И тут приходится обновлять индексы, что занимает не мало времени.
поправил текст, спасибо!
Иван, вы меня опередили на несколько месяцев. Я точно такую же статью хотело написать, но с закосом не на hibernate. Здесь он совсем не подходит. Проще использовать JOOQ. Я же так же не парился и написал функцию в PostgreSQL. Смотрю, вы тоже использовали его. Можно чуть упростить запросы, так как местами они перегружены sql native.
СУБД должна быть рабочая у разработчика, который запускает приложение. Это может быть независмый экземпляр от контейнера или контейнер c экземпляром СУБД. Кому как удобно. У меня без контейнера!
При помощи pgdbf создаём таблицы в PosgreSQL.
Запуск таски generateJooq генерирует нужные классы. В плагнине nu.studer.jooq:6.0.1 срабатывает правило запуска данной таски во время сборки проекта
Весьма полезная выдержка из статей.
С описанием json path у меня проблем никогда не было. Более старый способ выглядит логичным. Вот что касается асинхронного запроса, тут можно много спорить. Практика на проде покаже, стоит ли он тех усилий или нет!
Спасибо за статью! Было полезно почитать и узнать о хитростях)
У вас с Ktor какой опыт работы? Не кажется ли вам он слишком велосипедным? Приходится бины объявлять вручную, вплоть до объевления уровней логирования и иже с ним слои.
C оптимизацией запросов у меня нет проблем. Само собой, что вначале нужно просто понять, в чем проблема, а уже потом масштабироваться базу. Просто в реальности получается зачастую ситуация, когда времени руководство проекта не даёт на то, чтобы немного поразбираться и проще всего взять и добавить реплику.
изменения запушил
Там все дата классы помечаются как nullable. У них есть таска на то, чтобы сделать нормально. Но пока не произошло
Да, вы правы. Просто нужно добавить в .gitignore src/main/java
У вас наверно еще возникнет вопрос: почему не котлин генерация жука? Да всё потому, что котлин генерит до сих пор кривые дата классы POJO объектов
Спасибо за перевод! Очень интересно. Даже где-то актуально в 2021ом году. Только тогда партиционирования и наследования таблиц почти не было.
делю базу на мастер и слейв. Пока хватает! Монолит у меня тоже есть, но он и не дико нагружен, хватает мастера
так и делали в былые времена
Bot API 5.3. В этой версии появилась возможность формировать пользовательские команды для конкретного chat_id. Давно ждал такой фичи. Теперь всегда буду в своих проектах ими пользоваться. Возьмите эту фичу на заметку!
да, конечно. https://t.me/my_flower_com_bot
В моём примере готовая архитектура, если нужно добавить новый функционал, то просто наследуемся от InlineKeyboardMarkup или Chooser или Message и ChooseNextStep. Не забываем про паттерны ООП.
есть в планах. Но у меня не была цель экономии RAM, цель: удобство масштабирования!
Замеры специально не делал, но полноценный маркетплейс, который основан на текущей архитектуре вполне умещается на 500мб ram. Там 500+ классов, очереди и шедулеры
на монолит нужно железо помощнее. Работая на монолите не редко стакиваешься с ситуацией, когда что-то пошло не так и нужно обновить индексы у проекта. И тут приходится обновлять индексы, что занимает не мало времени.