Недавно размышлял о том, чем же отличается хороший API библиотеки от плохого. Пытался сравнить свои субъективные ощущения от Litestar и FastAPI. Почему Litestar мне не нравится, и в чем феномен успеха FastAPI при всем его минимализме?

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

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

Т.е. задача хорошего продукта (а API – это тоже продукт) – закрыть потребность пользователя минимально необходимым набор фич. Но очень многие это не понимают. Часто сталкиваюсь с утверждением "больше = лучше". Давайте воткнем больше информации в UI, давайте запилим 5 способов сделать то же самое. И в итоге получаются монстры, которыми просто невозможно пользоваться. Чтобы этого не случилось как раз и нужны UX / DX специалисты.

Но как закрыть потребность меньшим набором фич, чем у конкурентов? Тут дело в СИНЕРГИИ

Хороший API – это синергирующий API.

Представим, что у нас есть фича X1, которая закрывает потребность Y1. И фича X2, закрывающаю Y2.

Тогда синергиющий API дает нам следующую формулу:

X1 + X2 = Y1 + Y2 + Y3 (сумма двух фич позволяет закрыть потребность Y3, которую фичи не закрывают по отдельности).

Плохой дизайн – это когда сумма X1 + X2 = Y1 + Y2. Т.е. на каждую потребность пользователя у нас есть своя фича, которую пользователю нужно освоить. Именно этим мне и не нравится Litestar – там слишком много уникальных механизмов и зон ответственности, куда он лезет.

Ужасный дизайн – когда фича X1 = 0.8Y1. Т.е фича даже не закрывает кейс, ради которого была создана, а ломается на краевых ситуациях и вынуждает костылить.

#программирование