Мнение разработчиков: послание для бэка, ч1.🔙

Hola, Amigos! С вами Саша Чаплыгин, Flutter-dev Amiga. Сегодня поделюсь примерами из практики в работе с back-end.

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

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

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

Кейс из практики: бэк заказчика отдавал разные форматы даты и времени – timestamp и ISO 8601. В итоге сделали обработку и того и другого формата сразу.

Послание бэкендщикам от мобильщиков:
1. Делайте поля объекта такими, какими они должны быть. К примеру, из того что я встречал:
• Присылали булево значение строкой. “false” вместо false;
• Если значение поля всегда число – делайте это поле числом, а не строкой.

2. Тестируйте API самостоятельно или же подключите автотестирование. Мобильщики не должны проверять его.

Кейс из практики: подключение нескольких новых методов в МП привело к тому, что почти все методы не работали должным образом. В итоге потрачено время на проверку API, но никак не на подключение новых методов.

3. Всегда нужно чтобы API придерживалось схеме «ключ» – «значение».

Пример:
Плохая реализация поля fullName
{
“id”: “124314dfsdffd”,
“fullName” : [“John”, “Jameson”]
}

Правильная реализация
{
“id”: “124314dfsdffd”,
“fullName” : {“name”: “John”, “surname” : “Jameson”}