Хорошие книги: Designing Data-Intensive Applications

Привет!

Четверговые посты начну с рубрики "хорошие книги".

А рубрику "хорошие книги" начну с актуального - Designing Data-Intensive Applications.

Эту книгу я читаю сейчас и прочитал пока только треть, но уже в восторге, поэтому рекомендую.

Designing Data-Intensive Applications - это приложения которые упираются не в CPU, а в количество, скорость поступления или сложность данных.
Т.е. считай все бэки.

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

Рекомендую бакэндерам всех уровней - юниорам просто как введение в разработку, сеньёрам - как способ лучше структурировать знания по теме (да и хоть что-то новое тоже наверняка найдёте).
Своим юниорам на бэках я точно буду экзамен по этой книге проводить:)

Для фронтэндеров тоже есть практически полезная 4-ая глава о форматах взаимодействия бэка и фронта и его версионирования.

#books@ergonomic_code #databases@ergonomic_code

Привет!

Начинаю потихоньку возвращаться с каникул и решил написать линко-мысли-в-слухо-пост.

Подвернулся недавно вот этот пост.

Если вкратце, Лукас Эдер (автор jooq-а), предлагает тянуть json сразу из базы, не заморачиваясь на маппинг в энтити, а потом в ДТО.

И этот пост прям хорошо лёг на то, что я в последние пару месяцев качнулся в сторону "облегчения" разработки. Я тут недавно в одном из своих "хорошо" спроектированных проектов добавлял одно поле и мне для этого потребовалось потрогать штук 5-6 классов, в паре-тройке пакетов. И мне это не понравилось. А с таким подходом мне надо было бы поправить ровно два места - в схеме БД и в запросе. Это та самая вторая часть SRP - одна "вещь" должна делаться в одном месте.

До этого подхода тоже, конечно, можно докопаться с разной степенью успешности:

1. Он подходит только если json сливается напрямую в ответ, без какой либо обработки в приложении.
2. Он не подходит если итоговый ответ надо собрать из нескольких источников.
3. Слой работы с БД по факту сцепляется с веб-слоем. Если в ответе надо будет поменять имя поля, то это надо будет делать в репозе.
4. Логика помещается в БД. Тут я уже не согласен. Во-первых, это вообще сейчас модно (Datomic, VoltDB, например, реализуют транзакции только через хранимки). Во-вторых, логика всё равно остаётся в "приложении" - в том же репозитории, по соседству с вызывающим кодом. Написана просто на встроенном DSL-е.
5. Зависит от технологии работы с БД и самой БД, но скорее всего прямо json из базы вернётся каким-то специфичным для базы типом. И это уже будет нарушением принципа сокрытия информации, что совсем плохо. Это можно обойти, вернув из базы или репоза строку и получив stringly typed код.

Тем не менее, мне кажется что для простого веб АПИ к БД, такой подход должен хорошо работать. Я собираюсь попробовать:)

Так же этот подход хорошо согласуется с ещё одной идеей по облегчению разработки - замена "тупых" сервисов на функциональные типы. Мне всегда резал глаз код вроде этого:

class UsersConf {
    @Bean fun usersRepo() = UsersRepo()
    @Bean fun usersService() = UsersService(usersRepo())
    @Bean fun usersController() = UsersController(usersService())
}
class UsersController(val usersService: UsersService) {
    fun findById(id: Long) = userService.findById(id)
}
class UsersService(val usersRepo: UsersRepo) {
    fun findById(id: Long) = userRepo.findById(id)
}

Сейчас я хочу попробовать вместо этого писать так:

class UsersConf {
    @Bean fun usersRepo() = UsersRepo()
    @Bean fun usersController() = UsersController(usersRepo()::findById)
}
class UsersController(val findUserById: (Long) -> User) {
    fun findById(id: Long) = findUserById(id)
}

Кода меньше, а в плане связности так даже лучше - контроллер вообще зависит только от платформы.

В общем буду теперь двигать эргономичный подход в сторону баланса между удобством навигации/рефакторинга/типобезопасностью и количеством кода, который надо навигировать/рефакторить/использовать.

P.S.

Как вытянуть json в Postgres

#posts@ergonomic_code #ergo_persistance@ergonomic_code #ergo_approach@ergonomic_code #databases@ergonomic_code

Привет!

Postgres Professionals - российская контора по разработке и коммерческой поддержке постгреса, выпустила книгу (на русском!) об устройстве постгреса. Сам, естественно, ещё не читал, но добавил себе в список прочтения.

#books@ergonomic_code #databases@ergonomic_code

Привет!

Пока новый пост варится - радую вас линками:)

Я нашёл базу данных мечты - EdgeDb.

Что в ней крутого:
1) Она на базе Постгреса. Т.е. ядро надёжное и если с верхним слоем будут проблемы - можно будет цепануться к Постгресу напрямую
2) У неё графово-реляионна модель данных
2.1) Она поддерживает вложенные инсёрты
2.2) Она поддерживает наследование и полиморфные связи
2.3) Она поддерживает выборку иерархичных данных
2.4) Запросы на EdgeQL композируемые (Composable)
3) Судя по гиту, пилят её уже 13 лет и сейчас пилят активно как никогда - на момент написания предыдущий мёрж в мастер был 43 минуты назад, а за последние 2 дня вмёржили 20 ПРов
4) Free как и свобода и как пиво
5) Поддерживает GraphQL из коробки
6) У неё релиз версии 1.0 в феврале

Одна проблема - нет клиентов под JVM 😂

#posts@ergonomic_code #ergo_persistance@ergonomic_code #tools@ergonomic_code #databases@ergonomic_code

Привет!

Тихой сапой прочитал Next Generation Databases.
В целом хорошее краткое изложение (по сути - 200 страниц с картинками) истории, текущего состояния и будущего систем хранения данных.
Книги уже 7 лет, но на удивление с тех пор ничего особо не поменялось.
Любопытный факт - по мнению автора РСУБД всё ещё лучший выбор для подавляющего большинства приложений.
Хотя архитектура всех основных современных РСУБД, уходящая корнями в System R 70-ых годов изрядно устарела.

О чём пишет Стоунбрейкер в The End of an Architectural Era (It's Time for a Complete Rewrite)
В этой статье он расписывает почему текущие архитектуры устарели и как надо по другому.
"По другому" можно уже сейчас попробовать в его VoltDB и Datomic Рича Хикки.

Это "по другому" среди прочего предполагает переход на хранимые процедуры. Потому что все наши проблемы с ленивой загрузкой и/или монструозными запросами для вытаскивания всех данных в один заход вызваны компромиссным решением разнести код и данные по разным узлам. И кажется подходит время это решение пересмотреть.

При том и VoltDB и Datomic требует, чтобы хранимки были чистыми. Так что ФП - наше всё.

Как вы понимаете, в этом канале я, конечно же, не могу не упомянуть эргономичный подход:)

Эргономичный подход к тестированию в новой реальности будет чувствовать себя прекрасно - для него это будет невидимая низкоуровневая деталь реализации.

Выделение максимума кода в чистое ядро тоже будет как дома в завтрашнем дне - чистое ядро просто уйдёт в хранимки.

А вот с концептуальной декомпозицией системы, кажется, придётся повозиться. Но, справедливости ради, я и в текущей реальности эту часть не довёл до логического завершения.

В общем у нас впереди предстоит много интересного:)

#books@ergonomic_code #databases@ergonomic_code