Swagger first development
Вышло новое видео. Как и всегда, раскрываю очень важную и системную вещь: Как работать с API
Я уже 6 лет разрабатываю. Все эти 6 лет пробую разные подходы для работы с API и большую часть из этого времени страдаю.
Такую судьбу нам, фронтендерам, уготовили современные форматы разработки, в которых мы – придаток бекенда. Он что-то меняет, мы подстраиваемся. Ой, что то сломалось? Поди докажи, что это не ты косячник 😂 (Здесь описана лютая дисфункция разделения на бек и фронт, но это правда жизни)
Когда начал углубляться в теме архитектуры, стало очевидно: по-другому быть и не может
Если почитаете чистую архитектуру, то там будет 2 утверждения:
1. Уровень абстракции тем выше, чем мы дальше от ввода и вывода. Так вот для бэка База данных и API – это низкий уровень абстракции
2. Направление зависимостей должно быть направлено в сторону увеличения абстракции
Вот и получается: мы ссылаемся на API (низкий уровень абстракции) всем нашим приложением. Что противоречит второму утверждению выше. Это обрекает нас на постоянные страдания и синхронизацию кода с выводом бекенда.
Но есть решение: Давайте отделим контракты от бекенда. Будем описывать сначала open api схему, а после уже ипользовать её и на фронте, и на беке.
Так мы реализуем классический принцип программирования DIP из soliD (Мы должны зависеть от абстракции, а не от реализации)
В результате мы ссылаемся уже не на конкретный бэк, а на контракт. Контракт априори более абстрактен, чем контретный бекенд, поэтому проблем при разработке в таком формате значительно меньше.
В общем, мой опыт: на проектах с таким подходом работать с api было комфортнее всего.
Ребят, не страдайте. Посмотрите видос и попробуйте внедрить. Не пожалеете.
Если есть вопросы, прошу в комментарии)
Вышло новое видео. Как и всегда, раскрываю очень важную и системную вещь: Как работать с API
Я уже 6 лет разрабатываю. Все эти 6 лет пробую разные подходы для работы с API и большую часть из этого времени страдаю.
Такую судьбу нам, фронтендерам, уготовили современные форматы разработки, в которых мы – придаток бекенда. Он что-то меняет, мы подстраиваемся. Ой, что то сломалось? Поди докажи, что это не ты косячник 😂 (Здесь описана лютая дисфункция разделения на бек и фронт, но это правда жизни)
Когда начал углубляться в теме архитектуры, стало очевидно: по-другому быть и не может
Если почитаете чистую архитектуру, то там будет 2 утверждения:
1. Уровень абстракции тем выше, чем мы дальше от ввода и вывода. Так вот для бэка База данных и API – это низкий уровень абстракции
2. Направление зависимостей должно быть направлено в сторону увеличения абстракции
Вот и получается: мы ссылаемся на API (низкий уровень абстракции) всем нашим приложением. Что противоречит второму утверждению выше. Это обрекает нас на постоянные страдания и синхронизацию кода с выводом бекенда.
Но есть решение: Давайте отделим контракты от бекенда. Будем описывать сначала open api схему, а после уже ипользовать её и на фронте, и на беке.
Так мы реализуем классический принцип программирования DIP из soliD (Мы должны зависеть от абстракции, а не от реализации)
В результате мы ссылаемся уже не на конкретный бэк, а на контракт. Контракт априори более абстрактен, чем контретный бекенд, поэтому проблем при разработке в таком формате значительно меньше.
В общем, мой опыт: на проектах с таким подходом работать с api было комфортнее всего.
Ребят, не страдайте. Посмотрите видос и попробуйте внедрить. Не пожалеете.
Если есть вопросы, прошу в комментарии)