Разработка: что должно быть впереди фронтэнд или бекенд?

Question

[unkwua]

Разрабатываем веб-проект со сложной логикой как на клиенте, так и на бекенде. Постоянно возникает вопрос как формировать нагрузку: разрабатывать так, чтобы бекенд часть была всегда готова под текущие задачи фронтэнда или наоборот, фронтэнд разрабатывается на фейковых данных(т.е. данные на основе обговоренного API), а бекенд делается параллельно?

Comments

[aol-nnov]

> что должно быть впереди фронтэнд или бекенд
впереди должны быть соглашения (conventions) так как они склеивают эти две параллельные вселенные (фронт и бэк) и грамотно написанные тесты, так как их наличие уменьшает энтропию и отдаляет апокалипсис в отдельно взятом офисе.
всё остальное образуется :)

Answer 1

[xmoonlight]

Все, что написал Сергей Протько - несомненно верно, но несколько абстрактно.
Отвечу конкретно на вопрос.
После создания схемы взаимодействия всех блоков, выделяется отдельно 3 части:
1. Клиентская часть
2. Серверная часть
3. "Труба": от момента "это нужно передать" до момента "получены вот эти данные".
Т.е. к "трубе" относится: API, протокол передачи, сжатие/шифрование данных, организация защищенного канала передачи и т.д.
Вот, вначале описываем (документируем) "трубу" и создаём "заглушки" для проверки взаимодействия между клиентом и сервером: т.е. подготавливаем некий тест-кейс на статичных, заранее известных эталонных данных, для дальнейшей отладки формирования и передачи данных со стороны как клиента, так и сервера.
Т.е., после того, как обе проверочных "заглушки" (генератор запросов тест-кейса и генератор ответов тест-кейса) будут готовы - можно приступать к параллельной разработке клиента и сервера, добавляя в контрольный тест-кейс нужные запросы/ответы по мере необходимости.
После того, как клиент и сервер по-отдельности будут корректно работать с "заглушками" - можно их связывать напрямую между собой (убрав временно или совсем и навсегда заглушки из схемы взаимодействия).
PS: пример "клиента-заглушки":

Comments

[unkwua]

Т.е. фейковые данные отдаются бекендом пока он не будет готов, чтобы отдавать реальные?

[xmoonlight]

unkwua: да и так же для бэкенда: пишется "заглушка"-клиент - генератор заранее заданных клиентских запросов на основе тест-кейса (с возможностью изменять эти запросы по желанию) и по ней отлаживается серверная часть.

[Сергей Протько]

xmoonlight: описание "трубы" (сжатие, шифрование) это чуть другое, тут вы проектируете свой транспорт скорее нежели API. Его можно подменить на любой стадии разработки, оно никак не влияет на само API. Да и обычно все это уже реализовано на уровне фреймворков и операционной системы и разруливается абсолютно прозрачно для клиента.

И я категорически против, что бы мобильщики ждали пока бэкэндщик родит заглушку. Преимущество использования отдельных mock-серверов в том, что мобильщик может написать доку с частью API которая ему нужна прямо сейчас, скинуть бэкэндщику, и если тот заапрувит - просто начать работать не заставляя бэкэндщика "прерываться" на вашу задачу.

[Сергей Протько]

xmoonlight: ну и да, что бы "менее абстрактно" - берем apiary или любой подобный сервис и используем его для обявления слоя интеграции клиента и бэкэнда.

[xmoonlight]

Сергей Протько:
1. про "трубу": я создаю инструмент контроля взаимодействия клиента и сервера. Почему так? потому, что при шифрации/дешифрации данных, они могут быть некорректными на противоположной стороне.

2. "И я категорически против, что бы мобильщики ждали пока бэкэндщик родит заглушку. " - Ну так заглушка (сам скелет) разрабатывается 1-2 дня - максимум. Далее - просто таблица готовности функций идёт => никому не придётся ждать.

3. "берем apiary или любой подобный сервис и используем его для обявления слоя интеграции клиента и бэкэнда" - а вот тут, уже я категорически против, т.к.:
3.1 весь процесс разработки не должен быть завязан на сторонние интернет-сервисы и эта работа должна быть выполнена именно в рамках проекта.
3.2 это может сильно отличаться от того, что могут предложить сторонние веб-сервисы, например, потоковые сокеты с изменением данных во времени.
3.3 Как бонус - этот слой избавляет от большинства ошибок на этапе тестирования.

[Сергей Протько]

xmoonlight:

1. Это не относится к вопросу. Как я уже говорил - это реализуется один раз для всех методов API.

2. Заглушка для всего проекта может и пилится за 1-2 дня максимум (хотя все сильно зависит от размера проекта, есть проекты где я апишку могу за 1-2 дня в принципе реализовать а не загрушку). Вот только аджайлы, итеративная разработка, проектируем ровно столько сколько нужно... ну то есть "всей заглушки" всеравно не будет и всеравно придется тратить кучу времени на "переделки". А так я даю кусочек API и работай нехочу. А если делать заглушки то меня будут слишком часто дергать.

3.1. Ну так откажитесь от github/gitlab, мы же "завязываемся" на них. Если внезапно apiary умрет (мало ли) то проект от этого не пострадает. Есть от них же в опенсурсе все по отдельности, просто через один сервис удобнее.

3.2. сторонние вэб сервисы мы не рассматриваем. Если они "сторонние" значит они уже есть и "мокать" их не нужно. А вот с реалтаймами, сокетами и т.д. - тут сложнее согласен. Тут так просто не выйдет, и для этого обычно пилятся заглушки. Благо это не такой большой процент задач.

3.3 не вижу противоречий. Мы лишь говорим о том, как декларировать этот слой. В моем варианте так же многие ошибки устраняются еще до тестирования. В вашем - так же. Ваш способ чуть более затратен для более простых проектов, мой не работает при сложных случаях коих меньшинство.

p.s. по поводу "категорически против" это я пожалуй погорячился. Скорее "мне не нравится но делаю так иногда". Вообще категоричного ничего не должно быть в вопросах подобного рода.

[xmoonlight]

Сергей Протько: "Это не относится к вопросу. Как я уже говорил - это реализуется один раз для всех методов API." - согласен, что один раз для всех методов API, поэтому оно и стоит в заглушке, таким образом, я проверяю сразу и корректность алгоритма шифрования, и корректность обмена данными.
С остальным - полностью согласен!

Answer 2

[Сергей Протько]

В идеале второй вариант, если это возможно.

Скажем я на своих проектах пытаюсь делать так насколько это возможно. Перед началом разработки какой-то фичи разработчики просто договариваются между собой как будет организовано взаимодействие с сервером (по сути пишется описание API на каком api blueprint, сейчас будем переходить на raml).

После чего из этого описания разработчик серверной части может спокойно генерить себе тесты, json схемы респонсов и т.д. что бы быть уверенным что он делает так как договаривались, а мобильщики могут поднять себе из описания mock сервер.

Таким образом какие-то проблемы с серверным взаимодействием можно отловить задолго до того как разработчики в принципе реализуют эту часть api. Хотя если разработчики не используют какие-то средства для валидации реализации на предмет соответствию описанию, то в итоге на интеграцию может уйти больше времени.

p.s. этот подход я форсирую еще и потому, что при таком варианте можно легко наладить кодогенерацию как для клиента так и для бэкэнда. Скажем валидация запросов, маршрутизация, мэппинги и т.д. - все можно сгенерировать. RAML в этом плане дает из всех форматов максимальную гибкость, и поэтому я и планирую на него переходить. В очень простых случаях можно сгенерировать код хоть всего бэкэнда, но и так в целом скорость разработки неслабо увеличивается.

Comments

[Станислав Макаров]

О, вы тоже переходите на RAML? А OpenAPI смотрели? Честно говоря RAML мне нравится значительно больше, в частности введением типов, но все-таки хочется больше мнений)

Немного беспокоит сосредоточение сильных мира сего вокруг OpenAPI - не хочется чтобы RAML загнулся...

[Сергей Протько]

Станислав Макаров: Новая версия спецификации RAML дико радует теми фичами, коих мне не хватало в блупринтах.

OpenAPI это тот же сваггер. Чуть более многословная версия RAML зато больше вещей с ним работает. В силу того что для RAML еще не так много вещей из коробки с ним работающим, я сейчас пилю парсер + планирую конвертить пока либо в RAML 0.8 либо в OpenAPI.

[Станислав Макаров]

Сергей Протько ясно, ну в общем вы решили что пора выбрать что-то более богатое, чем blueprint)

Интересуюсь, т.к. хотелось бы прикрутить то или другое к одному из рабочих стеков (а именно, к новому asp.net), но как вы и сказали, много чего еще сыровато, и сидишь думаешь, в какой язык описания API вкладывать время и допиливать тулзы.

Что ж, спасибо за ответ, удачи вам)

[Сергей Протько]

Станислав Макаров: ну я делаю ставку на RAML + планирую схитрить и сделать свои тулзы под себя + сделать конвертер в OpenAPI так как в принципе я пока не нашел ни одной "не совместимой" вещи.

[Сергей Протько]

Станислав Макаров: но если что - OpenAPI самое богатое что есть. Просто некоторые вещи там не так удобно сделаны.

[Станислав Макаров]

Сергей Протько хм, т.е. они достаточно похожи, чтобы сделать конвертацию реальной? Это интересно, что ж, ознакомлюсь с OpenAPI детально) Конвертация - это хороший запасной путь)

Answer 3

[VDoskuSvoi]

Во время разработки фронтенда тебе начинают быть видными коррективы которые нужно внести. Во время разработки бекэнда ты создаешь основу, чтобы можно было фронтенд опробовать.
У нас так: делаем ядро бекенда, чтобы можно было начерно сделать фронтенд. Потом подтачиваем бекенд. И так по кругу

Answer 4

[Александр Косарев]

ИМХО, при разработке бекенд и фронтенд не должны зависеть друг от друга. Если используется итеративный подход к разработке, то перед началом очередной итерации проводится всеобщая планёрка, на которой обсуждается, что и как должно быть реализовано в рамках итерации. Результатом должен быть некий протокол, который согласует действия фронтенд-разработчиков и бекенд-разработчиков. Информации в протоколе должно быть достаточно для того, чтобы не возникало вопросов на тему "Что, как и с чем должно взаимодействовать". Например, при разработке веб-приложения, где есть набор Rest-сервисов и HTML/JS-фронтенд, должны оговариваться эндпоинты сервисов, их возможное поведение, включая HTTP-коды, описание классов сущностей, и т.д.
И тут да, фронтенд и бекенд разрабатываются на основе фейковых данных. Если всё организовано правильно, такой подход не будет давать осечек.

Answer 5

[unkwua]

Подводя итоги хочется отметить еще 1 момент, общался со знакомым человеком на эту тему который работал в Яндексе, он сказал, что у них однозначно бекенд на 2 недели в среднем идет впереди фронтэнда, вариант когда бекенд делается параллельно это типо удел нищих контор. Интересные вообщем мнения :)