Принцип DRY на примере Laravel

У меня для вас две новости.
Во-первых, если у вас в приложении не одно место, где создается пользователь — что-то явно не так с вашим приложением.
Во-вторых, раз у вас несколько мест — хорошо, используйте декоратор. Но сделайте его так, как упомянул товарищ DExploN, а именно через правильный класс (который не наследуется, а реально декорирует вызов метода другого объекта).

Принцип DRY на примере Laravel

Без проблем.
Берём класс LogCreateUser и задаемся вопросом что он делает:
— создаёт пользователя
— логирует создание пользователя
— всё выше сказанное.
Ответ: всё выше сказанное. А значит нарушили SRP.
Второй момент: с какого испуга класс логирования должен наследоваться от класса создания? Композиция — да, но не наследование.

Мой вывод: логирование — это прекрасно. Но это отдельная операция, которая живет в другом слое кода, никак не связанном с созданием.
Простейший пример на псевдокоде:

log('User creation: start')
userService->create()
log('User creation: end')

Принцип DRY на примере Laravel

Декоратор хорошо, но SRP нарушен.

Докеризация приложения, построенного на базе React, Express и MongoDB

Цитирую итоговый Dockerfile

FROM node:12-alpine as builder
WORKDIR /app
COPY package.json /app/package.json
RUN apk --no-cache add --virtual builds-deps build-base python
RUN npm install
COPY . /app
RUN npm run build
FROM node:12-alpine
WORKDIR /app
COPY --from=builder /app/dist /app
COPY package.json /app/package.json
RUN apk --no-cache add --virtual builds-deps build-base python
RUN npm install --only=prod
EXPOSE 8080 
USER node
CMD ["node", "index.js"]

Лично я здесь вижу установку python дважды.
По всей логике, этот python остается в production image. А это совсем не фонтан.

Докеризация приложения, построенного на базе React, Express и MongoDB

Что это за история такая с bcrypt и python?! Чушь какая-то, тащить за собой целый python только чтоб работала какая-то либа…

Маппинг данных из реляционной БД

Оно и понятно.
Я за любые начинания, лишь бы меньше было отдельных DSL на каждый чих.
Dot notation вроде как уже давно известная штука. Laravel разработчики точно с ней знакомы и пользуются постоянно. Это просто как пример.
В js вообще весь lodash для объектов на dot notation выстроен.

Маппинг данных из реляционной БД

Заберите пример бенчмарка тут

Эта реализация dot notation не поддерживает группирования, потому проверяется возможность собрать массив результатов, в котором для одной книги ровно один автор. В общем и целом, неполная имплементация Вашей функциональности, но для оценки производительности вполне хватает.

Маппинг данных из реляционной БД

Я бы с радостью, но для начала нужно исправить Ваш бенчмарк.

Во-первых, в настройках конфигурации (строки 79 и 116), Вы указываете свойство author, а в load() Вы ожидаете authors. В итоге, Вы тестируете PHP Warning: Invalid argument supplied for foreach()

Во-вторых, в строке 123 Вы указываете, что ожидаете 0-й элемент, но его там никогда не бывает. В итоге, Вы тестируете PHP Notice: Undefined offset: 0 in

Маппинг данных из реляционной БД

Немножко промазал с ответом

Маппинг данных из реляционной БД

Без проблем: берем, к примеру, adbario/php-dot-notation.
Дальше, как было выше показано, делаем манипуляции:

SELECT
    books.id AS id,
    books.name AS name,
    authors.id AS author.id,
    authors.name AS author.name
FROM
    books
LEFT JOIN relations ON relations.books_id = books.id
LEFT JOIN authors ON authors.id = relations.authors_id

Ну а дальше перебор (просто как пример, считать псевдоязыком):

$rows = [];
foreach ($databaseRows as $databaseRow) {
    $dot = dot([]);
    $dot->set($databaseRow);
    $rows[$dot->get('id')] = $dot->get();
}

Пример не является точной инструкцией к решению. Я просто попытался показать, что можно обойтись без дополнительного DSL, коим является указание префиксов и/или других путей для парсинга значений массивов.

Маппинг данных из реляционной БД

Только мне одному кажется, что в этом случае, раз такая пьянка, лучше использовать dot notation и дальше делать из этого массивы без ограничения вложенности? Благо готовых решений — пруд пруди.

История о том, как я разработал язык программирования

Как по мне, фатальный недостаток в действии.

«RTFM, dude!», или как бесплатный сыр обошелся мне в $5. А мог бы и в $80+

А нельзя было сервак взять за 2.99 где-то примерно на scaleway и не переживать за тарификацию?

Как улучшить ваш API сервис на node.js. Часть 1

Если существующий код не может без проблем перенестись на nest, то лучше такой код сразу выбросить и заново написать, используя хорошие практики.
Если же ваш код переносится без проблем — у вас хороший код. Не на nest ли часом?

Как улучшить ваш API сервис на node.js. Часть 1

Не подумайте, что реклама, но… начинаем свой проект на nest и всё. Стандартизация и хорошие практики с коробки, без бубнов.

Рейтинг скоростных веб-фреймворков 2020

Тот же никель взять: он же по скорости обработки запросов все вышеуказанные победит даже не задумываясь…

Ошибки в JavaScript: исправляем, обрабатываем, чиним

Моя реплика относится к этой фразе:

Конструкция try… catch встречается во всех современных языках программирования.

Ошибки в JavaScript: исправляем, обрабатываем, чиним

Чем Вам golang не современный язык? А вот try/catch там нет :)

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

artillery.io тоже можно посмотреть

Введение в Git

Ещё можно посмотреть в сторону gitless.
Успешно использую с первых релизов.