Как продолжать разработку, если бэкенд еще не готов

Представьте сборку сложного пазла — мозаики из взаимосвязанных кусочков, которые складываются в целостную картину. Точно так же разработка программного обеспечения может продвигаться вперед, несмотря на зависимости, подобно тому как пазл складывается, даже если некоторые его части отсутствуют или расположены не по порядку.

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

Разработка мобильных приложений в первую очередь состоит из двух компонентов — фронт-энда и бэк-энда. Часто можно столкнуться с ситуацией, когда, будучи front-end инженером, необходимо работать над приложением, а back-end еще не готов.

Что делать, если бэкенд не готов

Попытаемся ответить на этот вопрос на примере. Допустим, вы создаете приложение, которое выводит список фильмов на основе поиска, а бэкэнд не готов и не имеет API, который вы могли бы использовать. Ниже перечислены шаги, которые можно предпринять.

1. Создать запрос/ответ для API с серверной командой

Мы можем обсудить с командой сервера, как выглядит модель данных для нашего приложения.

Придумать модель данных для фильма:

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

{
    "movies": [
        {
            "id": "tt0076759",
            "Title": "Title 1",
            "Year": "1977",
            "Poster": "https://abc.com/url1"
        },
        {
            "id": "tt2527336",
            "Title": "Title 2",
            "Year": "2017",
            "Poster": "https://abc.com/url2"
        },
        {
            "id": "tt2488496",
            "Title": "Title 3",
            "Year": "2015",
            "Poster": "https://abc.com/url3"
        },
        {
            "id": "tt0120915",
            "Title": "Title 4",
            "Year": "1999",
            "Poster": "https://abc.com/url4"
        },
        {
            "id": "tt1185834",
            "Title": "Title 5",
            "Year": "2008",
            "Poster": "https://abc.com/url5"
        }
    ]
}

Мы можем обсудить с нашей серверной командой тип пагинации, который будет иметь смысл для проекта, будь то пагинация со смещением, KeySet или Cursor Based.

2. Кодирование модели и структуры зависимостей

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

struct Movie {
 let id:UUID
 let title:String
 let year: Int
 let poster:URL
}

protocol MovieLoader {
 func fetchMovies(completion: @escaping (Result<[Movie],Error>)->Void)
}

Поскольку на данный момент мы не уверены в том, что приложение должно поддерживать автономные/локальные списки фильмов в качестве резервной копии на случай отказа Сети, наш подход, основанный на протоколе, поможет реализовать локальный и онлайн-загрузчик, когда это будет необходимо.

На приведенной схеме показан возможный подход, который мы можем использовать.

3. Добавление жестко прописанного ответа

После реализации базового сетевого уровня мы можем прописать ответ несколькими способами.

a) Локальный JSON

Добавлением локального JSON в проект Xcode и получение ответа от локального JSON.

б) Использование прокси Charles с локальной картой

Вы можете использовать любой фиктивный URL, который пытается получить клиент, и с помощью Charles proxy вернуть локальный JSON. В будущем я постараюсь написать подробную реализацию этого в отдельном блоге.

в) Запуск локального сервера

Мы можем запустить локальный сервер и вернуть желаемый ответ. Для доставки ответа можно использовать такие средства, как node js или MAMP.

Заключение

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

Источник