🤢 Перестаньте использовать express / koa и начните использовать ...

При построении абсолютного любого API мне нужны:

1. Схема API с возможностью интроспекции (трансформации схемы в типизацию языка)
2. UI с демонстрацией API (например, swagger)
3. Типизация функционала библиотеки (чтобы все request и response правильно типизировались по схеме)
4. Миддлвары, logger, контекст для DI, плагины, etc.

Express и koa  -  библиотеки с минимальным набором функционала и добавить туда вышеописанные пункты можно при помощи сторонних библиотек. C 4-м пунктом сторонние библиотеки более менее справляются, а вот с первыми тремя постоянно возникают какие-то проблемы.

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

Но есть библиотека, которая решает все эти вопросы разом - Fastify

Решил собрать трюки по вышеописанным пунктам в данной статье

Мощной, вам, прокачки 💪

😭 Knex JS ломает logger

Knex – одна из самых известных библиотек для работы со SQL в NodeJS. И как полагается, подобного рода библиотеки могут принимать на вход внешний логгер.

НО вместо того, чтобы просто вызывать функции логгера, он переприсвает все его методы в свой класс (фото 1)...

Догадались в чем может быть проблема? Ответ через 3... 2... 1...

А проблема в том, что если ваш логгер под собой использует "this" без байндинга к инстансу (что не является обязательным), то теперь его "this" будет ссылаться на класс внутреннего логгера Knex...

В последних проектах я часто использую логгер Pino и внутри его логики используется "this" без байдинга и это приводит к крашу приложения

Чтобы все заработало приходится использовать мерзкий хак (фото 2)

Чему это нас учит?

"this" очень коварная штука и, конечно, мне хочется сказать "просто перестаньте использовать классовую нотацию" (потому что я ее уже давно не использую), но в реальности прошу вас хотябы не переприсвайте методы другого (особенно неподконтрольного) "объекта"

Мощной вам прокачки 💪

🔐 Шифрование запросов

Мы нашли решение, хочу с вами поделиться:

Задача была сделать дополнительный слой безопасности, помогающий (1) идентифицировать пользователя, (2) сверить, что содержание сообщения не было изменено по пути до сервера. Такое часто нужно, например, при запросах на создание денежных транзакций.

Один из самых простых вариантов – использование HMAC (его используют Ю.Касса, Тинькоф, Страйп, etc.)

Смысл HMAC таков: клиент, после формирования объекта данных транзакции, из значений этого объекта формирует строку, добаляется к ней hmac-секрет и шифрует. Полученая строка-шифр (подпись) добавляется к запросу и отправляется на сервер.

Сервер, получив запрос, делает все теже операции над его содержанием, используя тотже самый hmac-секрет и сверяет с той подписью, которая был отправлен в запросе. Если они идентичны – все супер, если нет, значит или кто-то попытался подменить соедржание пакета или имеют не тот ключ.

Основная проблема это то, что нам нужно хранить тотже самый hmac-секрет, причем привязанный к каждому клиенту (потому что у каждого клиента свой).

Хранить его удобно в БД, но что если БД уведут?

Решение оказалось банально простым: вместо того, чтобы хранить HMAC-секрет в открытом виде, мы будем его шифровать, когда кладем в БД, и дешифровать, когда создаем подпись для сверки.

Для этого идеально подходит алгоритм "aes-256-cbc". Секреты для него хранятся в env приложения.

Получается, даже если уведут БД, у злоумышленников не будет возможности расшифровать hmac-секреты, а чтобы это сделать, нужно иметь или доступ к приложению, или дамп памяти приложения.

Короче, шифрование шифрование шифрованием погоняет, такие дела

P.S.

У меня корона уже 4-ю неделю, поэтому я малоактивный 🙁 Будьте аккуратнее, правда, крайне много заражений последнее время, и даже при хорошем здоровье ощущения, как болеть 3-ный бронхитом

💬 Друзья, у меня к вам есть вопрос: кто-нибудь решал проблему подписей запросов симметричным / асимметричным шифрование?

Товарищи разрабатывают сервис денежных транзакций и выбрали HMAC (симетричное шифрование, где общий с клиентом ключ хранится с обоих сторон), но если хранилище секретов утечет – всему залупа

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

Есть идеи?

Видео по курсу 🔥 Advanced Node.js & TypeScript

Решил еще записать видос, чтобы чуть подробнее рассказать о грядущем курсе:

https://www.youtube.com/watch?v=MUosEJXDvnk

Пока занято 3 места и 5 забронированно из 12 доступных мест, так что если интересно, пишите, забронирую для вас место

P.S.

У меня было всего 3 дня на запись и монтаж, поэтому сорян там нет особо картинок / графики / эффектов / работы с камерой и подобного, только мой чистый пиздеж поток мыслей

🔥 Я запускаю курс "Advanced Node.js & TypeScript" 🔥

За последние полгода я уже провел закрытый поток по курсу на Node.js + TS, а на этих выходных ко мне пришел новый студент.

И как говорится: "Вместе веселее!" – так что я решил сделать открытый набор на 2-ой поток)

Вся информация по ссылке: https://fdd.davidshekunts.ru/advanced-node-js-typescript-course

Курс начинается в январе 2022

До 31-го декабря действует 20% скидка (за привод товарищей тоже есть награда 🤑)

Если у вас есть вопросы, не стесняйтесь писать мне @davidshekunts , с удовольствием отвечу на абсолютно любые вопросы)

🦾 Мощной вам прокачки 💪

λ Функционально Ориентированное Программирование (ФОП) λ

Те, кто читал предпоследний пост про "промежуточные итоги", узнали сюжетный твист: оказывается мы сравнивали не ФП vs ООП, а ФП + ПП (Процедурное Программирование) vs ООП.

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

Я решил рассказать вам о том, как использовать "более продвинутое ПП" или "менее сложное ФП", чтобы получить все преимущества функциональщины без впадания в крайности каждого из подходов и назвал это λ Функционально Ориентированное Программирование (ФОП)

Поскольку это касается программирования в целом, а не написания крупных backend приложений, я выделил все эти знания в отдельную книгу:

Вот вам ссылка на главную страницу книги: https://fop.davidshekunts.ru

А вот ссылка на первую вводную главу: https://fop.davidshekunts.ru/main

И да, весь раздел про борьбу "ФП и ООП", я тоже перенес в эту книгу: https://fop.davidshekunts.ru/fop-vs-oop

P.S.

Мне нужна ваша помощь: пожалуйста прочитайте небольшую статью из последнего поста и заполните 3-х минутный опрос, мне это очень важно и я буду крайне признателен за ваше участие!

#fop

🎓 Чему вас научит FDD 🎓

Ребята, есть одна огромная просьба:

Все эти концепции и методологии это, конечно, очень интересно и красиво, но все они нужны, чтобы решать конкретные проблемы!

Я решил собрать список конкретных проблем и решений, которым вы обучитесь, прочитав данную книгу:

https://fdd.davidshekunts.ru/what-you-will-learn

А помощь мне нужна в том, чтобы понять насколько представленные проблемы и их решения в вас резонируют (и вообще насколько я понятно их описал)

Для этого просьба, после прочтения статьи пройти опрос:

(3 минуты) https://forms.gle/Txo1bLABTBfhsNX67

Это невероятно мне поможет! Всем огромное спасибо!

🃏 Промежуточные итоги ООП vs ПП... ой, то есть ФП... а точнее ФОП... упс... 🃏

Ссылка: https://fdd.davidshekunts.ru/fp-vs-oop/oop-vs-fp-conclusions

Итак, пришло время подвести итоги битвы ООП и ФП.

Он будут короткие, но содержать один очень важный твист...

Не забудьте перейти по ссылке в конце статьи, там вас ждет кое-что интересное.

📰 IT-НОВОСТИ = FDD | REACT-NOTION-X | ИГРА В КАЛЬМАРА JS | CLICKHOUSE + METABASE + YANDEX CLOUD

Первый эксперементальный выпуск IT-Новостей

Начало получилось затянутым (основная часть начинается с 05:50), а также у меня на видео не отображаются главы (таймкоды), но надеюсь, с притоком подписчиков это поправится

Приятного просмотра:

https://www.youtube.com/watch?v=eOu5kGxJZTg

Буду рад любым комментариям