JS Fest 2019. Игорь Березин и Николай Крещенко. Эволюция архитектуры многогранного Node.js проекта

Эволюция архитектуры
многогранного Node.js
проекта

• Как жить в условиях работы с
большим количеством данных и
вычислений?
• Как можно организовать
самодокументацию и контракты?
• Важность выбора стека под задачу
• Как управлять техдолгом в условиях
миграции технологий
О чем поговорим?

Реалии типичного
стартапа
Высокий темп
разработки
Ограниченный бюджет
на поддержание
инфраструктуры
Маленькая команда
байдарки
мы работаем за еду,

А кто такой Koyfin, простите?

● MonoRepo архитектура
● База не справляется с
нагрузкой
● Блокировка Event Loop`a
● Server-side рендер

База данных
● Блокировка чтения записью из
множества источников
● Переполнение ОЗУ огромным
кол-вом индексов
● Нулевая отказоустойчивость

● Вывести клиент в отдельное приложение
● Реплицировать базу данных (и станет хорошо)
● Наконец-то прикрутить eslint
● А что же с Event Loop?...
Sounds like a plan

Просто разрежьте на логические
части
(для начала)

JS Fest 2019. Игорь Березин и Николай Крещенко. Эволюция архитектуры многогранного Node.js проекта

Как организовать?
1. Писать в БД может только один сервис
2. Поток записи данных должен быть
однонаправленный
3. Если кому-то нужны данные - выдаем права в БД
только на чтение

Новые проблемы...
● Большое количество микросервисов, которые общаются друг с другом
● Разный формат сообщений
● Нужно иметь возможность разрабатывать части системы параллельно
разными разработчиками

Необходимо договориться
Основная идея контрактного
программирования — это модель
взаимодействия элементов
программной системы, основывающаяся
на идее взаимных обязательств и
преимуществ. Как и в бизнесе, клиент и
поставщик действуют в соответствии с
определенным контрактом.
(Википедия)

«TypeScript - это JS для Jav’истов»
© Конфуций, 2018 год
Внедрение типизации

Тестирование идеи

1. Пишем TypeScript интерфейсы для взаимодействия
между микросервисами

1. Определяем типы переменных в функциях через
JSDoc блоки внутри JS кода

1. Определяем типы переменных через интерфейсы в
функциях через JSDoc блоки внутри JS кода
1. Ставим на precommit вызов TypeScript компилятора и
делаем его частью обязательных тестов для коммита

Полный переход на TS

1. Использование декораторов для краткости и
элегантности

Простая мемоизация

Routing-controllers
● Декларативность
● Простота композиции
● Инъекция важных частей
запроса прямо в функцию
( User, Body, etc. )

www.koyfin.com
if(usersSeesCapture() ===
){
alert(‘Похоже у
нас невалидные данные!’)
}
Первая версия валидации

Вторая версия валидации

• Использование декораторов для краткости и
элегантности
• Генерация схемы валидации (JSON schema) из TS
интерфейсов

TS Interface
20 строк
typescript-json-schema ./src/validation/tsconfig.json "*"
-o "./src/validation/validations.json"
--required=true
--strictNullChecks=true
--noExtraProps=true
--noExtraItems=true

ТЕХНИЧЕСКИЙ ДОЛГ?

9999999
Давай, расскажи мне про миграцию на TS
MyCompany

“allowJs”: true - легкий путь к
“плавной” миграции

Подходы оптимизации
расчетов
● Precalculated data
● Мемоизация
● Логический кеш + Warm Up

✚ Данные считаются на этапе записи в БД
Precalculated data

● процедуры + триггеры в БД
● логика при записи
● отдельные воркеры, которые по событию
или расписанию производят пересчет
Precalculated data

✚ Не нагружаем БД и мозг сложными запросами
✚ Отличная производительность
Precalculated data

✖︎ При обнаружении ошибок в данных - нужно
проводить полный перерасчет производных
✖︎ Денормализация и дублирование
✖︎ Тяжело отслеживать место возникновения
ошибок в расчетах
Precalculated data

✚ Данные считаются на лету
✚ При выявлении ошибок в расчетах или исходных
данных - достаточно просто сбросить кеш
✚ Неплохая производительность
Мемоизация

✖︎ Все еще CPU-intensive задача
✖︎ Плохо работает для часто обновляемых данных
✖︎ Нужно думать о соблюдении порядка аргументов
Мемоизация

✚ Данные считаются на лету
✚ Кеш проще переиспользовать, чем при
мемоизации
✚ Простая инвалидация при обновлении исходных
данных
✚ Отлично подходит для постоянно обновляемых
данных
Логический кеш

✖︎ Занимает много места
✖︎ Нужно реализовывать логику под каждый кейс
✖︎ Нужно прогревать
Логический кеш

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

Рассмотрите типизированные языки для организации
контрактов обмена данными и написания более
самодокументированного кода
Выводы

Решайте проблемы на правильных уровнях.
Выводы

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

Всем крепких костылей!

JS Fest 2019. Игорь Березин и Николай Крещенко. Эволюция архитектуры многогранного Node.js проекта

More Related Content

What's hot (20)

Similar to JS Fest 2019. Игорь Березин и Николай Крещенко. Эволюция архитектуры многогранного Node.js проекта (20)

More from JSFestUA (20)

JS Fest 2019. Игорь Березин и Николай Крещенко. Эволюция архитектуры многогранного Node.js проекта

Editor's Notes