Вот вы снова упускаете важнейшую деталь. Для какого конкретно фронта нужно реализовать АПИ? каждому фронту нужно свое, уникальное АПИ.
Отвечая на вопрос: Всегда дешевле реализовать все в одном месте, собрать прототип "на коленке" и выдать заказчику в качестве продакшен решения. Все будут просто без ума от вашей скорости и професионализма, но когда этот же заказчик придет к вам и скажет, что к вашему отличному решению теперь нужно написать мобильное приложение, и еще рядом такой же интерфейс, но допустим для пенсионеров. Вы во первых пойдете писать новую спецификацию под уже реализованные фичи, во вторых начнете привлекать вторую команду (помимо вашей) для реализации нового АПИ, и если вдруг, недайбог каким-либо образом реализация нового АПИ повлияет на существующее (а мы понимаем, что вносим изменения в код уже работающего решения и кто его знает, кто там в чем также сэкономил и решил не разделять код на отдельные модули) вам придется еще и перетестировать ту часть решения, которая вроди бы и не менялась. Все это вместе да, конечно будет значительно дороже, чем написать сервис-адаптер влияние которого будет ограничего конкретным потребителем.
На мой взгляд, в данном контексте термин "царек" неуместен, так как речь идет не о власти, а о ответственности. Вы же не ожидаете, что уборщица в вашем доме начнет готовить вам еду (хотя вероятно могла бы), или сотрудник ДПС на дороге не только выпишет протокол, но и примет у вас оплату втрафа на месте (хотя вероятно мог бы :) ).
Ну так собственно о таком варианте и шла реч в моём первом сообщении. То что вы описали полностью попадает под описанного мною BFF-пасположенном не в виде отдельного сервиса (приложения) а в виде отдельного адресного пространства того же сервиса.
для каждого фронта можно создаеть свою модель представления (набор отображаемых в ней сущностей и действий с ними) и использовать API, основанный на этой модели.
Разве не выглядит это как дополнительная обязанность, которая вполне может быть выделена в отдельный микросервис например? Заниматься ей в этом случае может как команда основного фронта, так и выделенная команда, что в савокупности повышает гибкость процесса разработки в целом. И я уже не говорю о том, что такой сервис может быть написан на стеке, отличном от стека основного бэка.
Вот например я как поставщик продукта и выбрал единственный приемлемый для себя ( тот за работу и актуальность которого я готов отвечать головой) способ предоставления доступа, пускай это будет REST. И пускай все возможные потребители сами решают как и в каком виде они будут его потреблять. Кто-то будет слать запросы на прямую, кто-то напишет BFF-сервисы для преобразования запросов/ответов. Кто-то вообще приделает CLI и буде радоваться консоли. Это уже не моя забота как поставщика. Моя задача гарантировать работоспособность того единственного канала, который я предоставил.
Все ваши утверждения строятся на убеждении, что у бэка в сеть ровно один фронт. Это в корне не верно и в реальных проектах даже у одного продукта есть множество различных фронтов (веб, мобильный веб, мобильное приложение, разный веб для разных регионов) во что превратится ваш API если каждый из представленных потребителей начнет требовать свои уникальные методы выполняющие по факту одни и те же действия? Этот API в итоге не возможно будет ни поддерживать, ни развивать. Задача ядра системы предоставить полный набор методов для работы с бизнес-сущностями системы и реализовать их поведение согласно бизнес-логики системы безотносительно того как и где эти сущности будут представлены. Следовательно бэк не может и должен ничего знать о конкретном фронте, и тем более подстраиваться под него.
В свою очередь задача фронта, используя представленные методы показать интерфейс системы обеспечивающий удобный способ взаимодействия для конкретной, часто узкой части аудитории, при том что пользовательский интерфейс очень редко использует весь спектр возможностей системы. Фронт не может и не должен ничего знать о деталях реализации системы, только представленный АПИ.
Под кашей я имел ввиду то, что вы перемешиваете (размазываете) ответственности компонентов системы повышая тем самым связанность. Ваш фронт начинает влиять (а значит заботиться) о бэке, а бэку при развитии приходится учитывать особенности каждого фронта. Цена развития в такой системе лавинообразно растет с появлением нового фронта, и это уже не говоря о поиске и исправлении дефектов.
Отвечая на вопрос - я действительно верю в spec-first и активно продвигаю его в своих командах
Переходя к тексту статьи.
Мне лично кажется, что у вас в голове каша из множества различных областей процессов разработки и управления. Попробую систематизировать и предложить примеров.
Давайте попробуем обозначить основные компоненты вашего повествования, ими являются бэкэнд и фронтэнд. Какие у них роли? Бэкэнд можно сравнить с поставщиком некой продукции/данных (автопроизводитель, молочная ферма, онлайн ресурс) в свою очередь фронтэнд - это потребитель данной продукции (автовладелец, покупатель в магазине, клиент сервиса), чем же в данной аналогии является спецификация? Все верно спецификация это - "инструкция по эксплуатации" автомобиля. Исходя из предложенных аналогий выходит, что существует конкретный предложенный продукт и множество разнообразных его потребителей. Становится видна на мой взгляд вся абсурдность вашего требования, которое подразумевает обязанность производителя в согласовании инструкции с каждым возможным потребителем. Как вы представляете себе процесс согласования API какого-нибудь Aviasales или Reddit с сайтом-визиткой отображающим цены на последний перелет или количество комментариев reddit, странно звучит, не правда ли?
Переходя к процессу актуализации спецификации тут все тоже становится прозрачнее, стоит лишь определить ее владельца. Кто является владельцем API, ну конечно же сервис который его предоставляет и реализует - бэкэнд. А значит достаточно иметь один файл спецификации (json, yml) в репозитории бэкэнда. Где все внутренние потребители смогут его прочитать, предложить свои комментарии/исправления по средствам merge request.
Ситуация когда конкретному потребителю нужно оптимизировать/кастомизировать некие запросы для удобства восприятия ответов, не является уникальной и для ее разрешения с сохранением ответственностей описан паттерн BFF ( back for front) задачей которого и является удовлетворение потребности конкретного потребителя. Приходя к аналогиям его можно сравнить с тюнинг-анелье, которое на вход получает "голый" продукт от производителя, а на выход выдает то, что попросил отнего конкретный клиент. В этом случае спецификацию bff сервиса может составлять и фронтэнд, ровно в том виде который ему нужен. Причем не обязательно воспринимать bff как отдельный сервис (хотя очень желательно) это вполне может быть и отдельное адресное пространство оригинального бэка.
P.S. сразу попрошу прощения. Неожиданно длинный получился комментарий.
Отличная статья, спасибо!
А может подскажете, какая библиотека компонентов использовалась для визуализации графиков?
Извините, но мы ходим по кругу, вынужден завершить эту ветку обсуждения.
Основные арументы с обоих сторон уже высказаны.
Вот вы снова упускаете важнейшую деталь. Для какого конкретно фронта нужно реализовать АПИ? каждому фронту нужно свое, уникальное АПИ.
Отвечая на вопрос: Всегда дешевле реализовать все в одном месте, собрать прототип "на коленке" и выдать заказчику в качестве продакшен решения. Все будут просто без ума от вашей скорости и професионализма, но когда этот же заказчик придет к вам и скажет, что к вашему отличному решению теперь нужно написать мобильное приложение, и еще рядом такой же интерфейс, но допустим для пенсионеров. Вы во первых пойдете писать новую спецификацию под уже реализованные фичи, во вторых начнете привлекать вторую команду (помимо вашей) для реализации нового АПИ, и если вдруг, недайбог каким-либо образом реализация нового АПИ повлияет на существующее (а мы понимаем, что вносим изменения в код уже работающего решения и кто его знает, кто там в чем также сэкономил и решил не разделять код на отдельные модули) вам придется еще и перетестировать ту часть решения, которая вроди бы и не менялась. Все это вместе да, конечно будет значительно дороже, чем написать сервис-адаптер влияние которого будет ограничего конкретным потребителем.
На мой взгляд, в данном контексте термин "царек" неуместен, так как речь идет не о власти, а о ответственности. Вы же не ожидаете, что уборщица в вашем доме начнет готовить вам еду (хотя вероятно могла бы), или сотрудник ДПС на дороге не только выпишет протокол, но и примет у вас оплату втрафа на месте (хотя вероятно мог бы :) ).
Ну так собственно о таком варианте и шла реч в моём первом сообщении. То что вы описали полностью попадает под описанного мною BFF-пасположенном не в виде отдельного сервиса (приложения) а в виде отдельного адресного пространства того же сервиса.
Разве не выглядит это как дополнительная обязанность, которая вполне может быть выделена в отдельный микросервис например? Заниматься ей в этом случае может как команда основного фронта, так и выделенная команда, что в савокупности повышает гибкость процесса разработки в целом. И я уже не говорю о том, что такой сервис может быть написан на стеке, отличном от стека основного бэка.
Вот например я как поставщик продукта и выбрал единственный приемлемый для себя ( тот за работу и актуальность которого я готов отвечать головой) способ предоставления доступа, пускай это будет REST. И пускай все возможные потребители сами решают как и в каком виде они будут его потреблять. Кто-то будет слать запросы на прямую, кто-то напишет BFF-сервисы для преобразования запросов/ответов. Кто-то вообще приделает CLI и буде радоваться консоли. Это уже не моя забота как поставщика. Моя задача гарантировать работоспособность того единственного канала, который я предоставил.
Все ваши утверждения строятся на убеждении, что у бэка в сеть ровно один фронт. Это в корне не верно и в реальных проектах даже у одного продукта есть множество различных фронтов (веб, мобильный веб, мобильное приложение, разный веб для разных регионов) во что превратится ваш API если каждый из представленных потребителей начнет требовать свои уникальные методы выполняющие по факту одни и те же действия? Этот API в итоге не возможно будет ни поддерживать, ни развивать. Задача ядра системы предоставить полный набор методов для работы с бизнес-сущностями системы и реализовать их поведение согласно бизнес-логики системы безотносительно того как и где эти сущности будут представлены. Следовательно бэк не может и должен ничего знать о конкретном фронте, и тем более подстраиваться под него.
В свою очередь задача фронта, используя представленные методы показать интерфейс системы обеспечивающий удобный способ взаимодействия для конкретной, часто узкой части аудитории, при том что пользовательский интерфейс очень редко использует весь спектр возможностей системы. Фронт не может и не должен ничего знать о деталях реализации системы, только представленный АПИ.
Под кашей я имел ввиду то, что вы перемешиваете (размазываете) ответственности компонентов системы повышая тем самым связанность. Ваш фронт начинает влиять (а значит заботиться) о бэке, а бэку при развитии приходится учитывать особенности каждого фронта. Цена развития в такой системе лавинообразно растет с появлением нового фронта, и это уже не говоря о поиске и исправлении дефектов.
Проблема как раз в том, что будет ли реддит расширять свой публичный api под ваш "уникальный" запрос, или предложит воспользоваться уже существующим.
Отвечая на вопрос - я действительно верю в spec-first и активно продвигаю его в своих командах
Переходя к тексту статьи.
Мне лично кажется, что у вас в голове каша из множества различных областей процессов разработки и управления. Попробую систематизировать и предложить примеров.
Давайте попробуем обозначить основные компоненты вашего повествования, ими являются бэкэнд и фронтэнд. Какие у них роли? Бэкэнд можно сравнить с поставщиком некой продукции/данных (автопроизводитель, молочная ферма, онлайн ресурс) в свою очередь фронтэнд - это потребитель данной продукции (автовладелец, покупатель в магазине, клиент сервиса), чем же в данной аналогии является спецификация? Все верно спецификация это - "инструкция по эксплуатации" автомобиля. Исходя из предложенных аналогий выходит, что существует конкретный предложенный продукт и множество разнообразных его потребителей. Становится видна на мой взгляд вся абсурдность вашего требования, которое подразумевает обязанность производителя в согласовании инструкции с каждым возможным потребителем. Как вы представляете себе процесс согласования API какого-нибудь Aviasales или Reddit с сайтом-визиткой отображающим цены на последний перелет или количество комментариев reddit, странно звучит, не правда ли?
Переходя к процессу актуализации спецификации тут все тоже становится прозрачнее, стоит лишь определить ее владельца. Кто является владельцем API, ну конечно же сервис который его предоставляет и реализует - бэкэнд. А значит достаточно иметь один файл спецификации (json, yml) в репозитории бэкэнда. Где все внутренние потребители смогут его прочитать, предложить свои комментарии/исправления по средствам merge request.
Ситуация когда конкретному потребителю нужно оптимизировать/кастомизировать некие запросы для удобства восприятия ответов, не является уникальной и для ее разрешения с сохранением ответственностей описан паттерн BFF ( back for front) задачей которого и является удовлетворение потребности конкретного потребителя. Приходя к аналогиям его можно сравнить с тюнинг-анелье, которое на вход получает "голый" продукт от производителя, а на выход выдает то, что попросил отнего конкретный клиент. В этом случае спецификацию bff сервиса может составлять и фронтэнд, ровно в том виде который ему нужен. Причем не обязательно воспринимать bff как отдельный сервис (хотя очень желательно) это вполне может быть и отдельное адресное пространство оригинального бэка.
P.S. сразу попрошу прощения. Неожиданно длинный получился комментарий.