Идемпотентность — звучит сложно, говорят о ней редко, но это касается всех приложений, использующих API в своей работе.
Меня зовут Денис Исаев, и я руковожу одной из бэкенд групп в Яндекс.Такси. Сегодня я поделюсь с читателями Хабра описанием проблем, которые могут возникнуть, если не учитывать идемпотентность распределенных систем в своем проекте. Для этого я выбрал формат вымышленных историй о стажёре Васе, который только-только учится работать с API. Так будет нагляднее и полезнее. Поехали.
Что такое сетевой сервис? Это программа, которая принимает входящие запросы по сети и обрабатывает их, возможно, возвращая ответы.
Есть много аспектов, в которых сетевые сервисы отличаются друг от друга. В этой статье я акцентрирую внимание на способе обработки входящих запросов.
Выбор способа обработки запросов имеет далеко идущие последствия. Как сделать чат-сервис, выдерживающий 100.000 одновременных соединений? Какой подход выбрать для извлечения данных из потока слабоструктурированных файлов? Неправильный выбор приведет к пустой трате сил и времени.
В статье рассмотрены такие подходы как пул процессов/потоков, событийно-ориентированная обработка, half sync/half async паттерн и многие другие. Приводятся многочисленные примеры, рассматриваются плюсы и минусы подходов, их особенности и области применения.
Дело в том, что в мире сейчас есть где-то 5 компаний, обрабатывающие данные подобных объёмов. Все остальные гоняют все эти данные туда-сюда, добиваясь отказоустойчивости, которая им на самом деле не нужна. Люди страдают гигантоманией и гугломанией где-то с середины 2000-ых годов: «мы сделаем всё так, как делает Google, ведь мы же строим один из крупнейших (в будущем) сервисов по обработке данных в мире!»
Паттерн "observer" известен наверное с момента появления самого ооп. Упрощенно можно представить что есть объект который хранит список слушателей и имеет метод "добавить", "удалить" и "оповестить", а внешний код либо подписывается либо оповещает подписчиков
class Observable {
listeners = new Set();
subscribe(listener){
this.listeners.add(listener)
}
unsubscribe(listener){
this.listeners.delete(listener)
}
notify(){
for(const listener of this.listeners){
listener();
}
}
}В redux-е этот паттерн применяется без всяких изменений — пакет "react-redux" предоставляет функцию connect которая оборачивает компонент и при вызове componentDidMount вызовет subscribe() метод у Observable, при вызове componentWillUnmount() вызовет unsubscribе() а dispatch() просто вызовет метод trigger() который в цикле вызовет всех слушателей где каждый в свою очередь вызовет mapStateToProps() и потом в зависимости от того изменилось ли значение — вызовет setState() на самом компоненте. Все очень просто, но платой за такую простоту реализации является необходимость работать с состоянием иммутабельно и нормализировать данные а при изменении отдельного объекта или даже одного свойства оповещать абсолютно всех подписчиков-компонентов даже если они никак не зависят от той измененной части состояния и при этом в компоненте-подписчике необходимо явно указывать от каких частей стора он зависит внутри mapStateToProps()
Этот список появился как личная памятка по темам, которые я обсуждал с коллегами и друзьями и в которых хотел разобраться поглубже…
Необходимость в обмене данными между UI и JS процессами в React Native неизбежно сказывается на производительности препятствуя выполнению JavaScript анимации с высокой частотой кадров. Современные библиотеки, такие как Animated, решают эту проблему минимизацией количества сообщений, передаваемых через мост. Следующий шаг — это элементы управления, которые непрерывно реагируют на жесты пользователя. Как мы можем анимировать их со скоростью 60 кадров в секунду?
Представляю вашему вниманию типичные варианты использования Observable объектов в компонентах и сервисах Angular 4.
Задача: При открытии страницы example.com/#/users/42, по userId получить данные пользователя.
Решение: При инициализации компоненты UserDetailsComponent мы подписываемся на параметры роутера. То есть если userId будет меняться — будер срабатывать наша подписка. Используя полученный userId, мы из сервиса userService получаем Observable с данными пользователя.
// UserDetailsComponent
ngOnInit() {
this.route.params
.pluck('userId') // получаем userId из параметров
.switchMap(userId => this.userService.getData(userId))
.subscribe(user => this.user = user);
}
Я всегда считал, что с flexbox довольно легко работать — глоток свежего воздуха после стольких лет float'ов и clearfix'ов.
Правда недавно я обнаружил что борюсь с ним; что-то растягивалось, когда я не думал, что оно должно тянуться. Я поправил здесь, другой элемент сжался. Я починил это, что-то другое ушло за экран. Какого Джорджа Буша тут происходит?
В конце концов, все заработало, но солнце село, а мой процесс был привычной игрой с CSS. Или… как называется та игра, где надо ударить крота, а затем другой крот выпрыгивает и надо ударить и его тоже?
Как бы там ни было, я решил что пора вести себя как взрослый разработчик и выучить flexbox должным образом. Но вместо того, чтобы прочитать 10 очередных блог-постов, я решил отправиться прямиком к исходнику и прочитать The CSS Flexible Box Layout Module Level 1 Spec
Вот хорошие отрывки.
Меня зовут Павел, я фронтенд-разработчик Tinkoff.ru. Наша команда занимается разработкой интернет-банка для юридических лиц. Фронтенд наших проектов был реализован с применением AngularJS, с которого мы перешли, частично с использованием Angular Upgrade, на новый Angular (ранее позиционировался как Angular 2).