2021-01-22 13:31:00
Пятничное чтивоМедленно прихожу в норму, поэтому пока только ссылки. Старые записи стримов как обычно можно найти на ютубе. Так же буду рад предложениям, вопросам и идеям. Можно написать в личку, а можно в анонимную форму.
—————————————
Сергей Константинов. API
Вместо ссылки - книга о проектировании API, но хочется остановиться только на 11 главе, которая тянет на отдельную статью. В главе описывается 20 советов для проектирования апи, которые помогут в стандартизации API.
Что лично практикую:
- использование uuid вместо id;
- возвращение полного состояния системы после мутаций;
Что запомнилось:
- люди явно пишут что объектов нет, вместо отдачи пустого списка.
- понравилась идея с порядком ошибок: от критических до некритических. Возник вопрос: можно ли подобную идею использовать в условном dry-v?
- понравилась идея с указанием политики кэширования в документации. почему-то сам так не делал до этого момента.
Что воспринял скептически:
- пункт о локализации. Как показывает практика, локализация бывает избыточной по определению (особенно если рынок только русский или только английский).
- много вопросов возникало вокруг 14 пункта об атомарных операциях, не понятно как батч запросы делать (если это надо).
—————————————
Работа с унаследованным кодом: Риски, анализ проекта и стратегии работы
Подробный лонгридов о легаси что я видел (хоть и написан в 2014 году), который пытается ответить на вопрос: что можно сделать со старой и (или) плохо работающей системой.
Понравилось, что автор разделяет “плохую” и “хорошую” унаследованную систему, дает список признаков, по которым можно определить “плохую” систему, а также размышляет о том, как системы становятся унаследованными. Кроме того, описываются возникающие риски, а так же приводятся (с пояснениями) 10 вопросов, которые помогут в анализе легаси системы.
В конце статьи описывается 4 стратегии изменения легаси систем: "Переписать", "Оставляем как было", "Strangler Application" (создать новое, поверх старого), "Переработка по модулям". Для каждой стратегии приводится описание, плюсы, минусы и рекомендации. Если мало - бонусом идет 11 историй работы с легаси системами от сторонних авторов.
—————————————
Kafka is Not a Database
Кафка не только стримит данные, но и хранит сообщения, а также имеет из коробки projections для сбора состояния по сообщениям (kSQL). Поэтому велик риск использовать message broker как базу данных и хранить там данные (сам с таким сталкивался). Авторы статьи рассуждают, как отсутствие isolation levels в кафке может помешать этой идее. На примере онлайн магазина собирается система которая показывает нарушение concurrency control между чтением данных и записью мутаций с этими данными. Как решение, приводится вариант “change-data-capture”, который использует стриминг через кафку для наполнения “традиционных” баз данных.
2.0K views10:31