Архитектура сетевого ядра в iOS-приложении на Swift 3. Часть 1

[house2008]

Мне кажется enum для ResponseError было бы удобнее

enum ResponseError {
    case Success()
    case Fail(ErrorType, Int)
}

ResponseError.Fail(NSError(domain: "AppDomain", code: -1, userInfo: nil) , 500)

Почему бы не использовать struct вместо классов?

[GDXRepo]

На мой взгляд, по поводу enum — тут больше вопрос вкуса. Я пока не привык к таким конструкциям. Кроме того, получится ли сделать нормальную обработку входного JSON в такого рода перечислениях? Можно попробовать, но я особо преимуществ пока не вижу. А по поводу структур — нет, не стоит. Здесь копирование данных ни к чему, ссылки здесь более корректны, на мой взгляд. Структуры — вещь хорошая, но их не стоит использовать прямо везде, насколько я понял из советов Apple в WWDC. В нашей архитектуре вполне уместны классы.

[house2008]

Здесь копирование данных ни к чему

На самом деле структуры очень эффективны если все поля в них value types, что мы как раз видим в случае с ResponseError классом. Счетчик ссылок для ref types создает достаточно большие накладные расходы, если мы говорим о производительности. То есть в данном случае дешевле скопировать, чем сделать инкремент и декремент счетчика. Насколько мне известно, есть некоторые оптимизации для value types на уровне стека методов, чтобы как можно реже обращаться в heap.

[GDXRepo]

Совершенно согласен, и поскольку в нашем случае в состав входят далеко не value-типы, я предпочел не пользоваться структурами) Так-то верно, при использовании value-типов структуры становятся куда более оптимальным решением.

[IgorFedorchuk]

Можно вместо ResponseError использовать NSError, так как поля code и message уже есть у NSError.

[GDXRepo]

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

[house2008]

Всё верно. Некоторые добавляют map/flatMap чтобы выстраивать цепочку трансформаций.

enum Result<E> {
    case Success(E)
    case Fail(Error)
    
    func map<V>(_ fn: (E) -> V) -> Result<V> {
        switch self {
        case .Success(let result): return .Success(fn(result))
        case .Fail(let error): return .Fail(error)
        }
    }
}

[s1dd0k]

Есть еще вот такой фреймворк, призванный помочь в организации сетевого кода

https://github.com/Moya/Moya

[GDXRepo]

Посмотрел, спасибо, интересное решение. Отчасти похоже на то, что мы в статье разбираем.

[DenHeadless]

А вот еще =)

https://github.com/MLSDev/TRON

[GDXRepo]

Вот это уже значительно больше похоже на то, чего я пытаюсь добиться с помощью описываемого способа) Очень любопытно, спасибо! Изучу, как только его обновят до третьей версии языка, пока что, опять-таки, не получится им воспользоваться в моих проектах. Но реализация прямо похожа на то, что нужно. Благодарю!

[DenHeadless]

Мы обновим его до свифт 3 на этих выходных =) Пока что есть девелопмент версия в бранче swift3, она почти готова к релизу, осталось отполировать использование Alamofire 4.0 до нормального вида.

[GDXRepo]

Супер! Определенно нужно посмотреть)

[Florelit]

Неплохой фреймворк для таких целей https://github.com/Alamofire/Alamofire

[GDXRepo]

Вы невнимательно прочитали первые два абзаца в моей статье. Поэтому немножко не поняли, о чем она, и почему Alamofire не касается темы статьи.

[Florelit]

Простите, воспаленный мозг выразился абсолютно не верно. Цель обвязки описанной в статье очевидно совершенна другая. А моя фраза была отсылом к пункту 3 секции «С чего начнем?»

Также условимся, что для «низкоуровневого» сетевого общения нам не потребуется отдельная сетевая библиотека, мы напишем эту часть сами (тем более, на момент написания этой статьи сетевых библиотек, обновленных до версии языка 3.0, попросту нет).

:)

[GDXRepo]

А))) Тогда понятно. В данном случае я не стал использовать прослойку, во-первых, для упрощения кода и упрощения объяснений, а во-вторых, потому что и стандартного URLSession нам будет более, чем достаточно, да и реализуется он очень быстро)) В реальном проекте, конечно, зачастую предпочтительнее использовать специализированное решение.

[Ariandr]

Интересно!
А когда выйдет 2 часть статьи и о чем там собственно будет написано?

[GDXRepo]

Я уже занимаюсь второй частью. Там я расскажу о практическом применении созданной архитектуры.

[Ariandr]

Окей, будем ждать. :)

[eserikov7]

А не проще использовать AFNetworking + ObjectMapper? И описывать только модели.

[GDXRepo]

Не совсем проще. Так и происходит в проектах, как правило, и за неимением толковой структуры это обычно превращается в мусорку (сколько я успел понаблюдать).

[eserikov7]

А чем эта альтернативная реализация библиотеки AFNetworking решает проблему?

[GDXRepo]

Это НЕ альтернатива AFNetworking. Смысл решения из статьи совершенно другой.

[askl]

Хотелось бы увидеть удобную реализацию решения на базе этого ядра такой популярной проблемы как обновление токена авторизации к апи и повторение запросов, которые привели к обновлению. Т.е. допустим токен авторизации протухает каждые 3 часа. Соответсвенно, следующий запрос вернет ошибку авторизации (что-то типа session token expired). Обычно, в такой ситуации, все следующие запросы становятся в очередь до момента обновления токена.

[GDXRepo]

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

[ChapayHabr]

Если session token expired отвалился, то на клиенте есть refresh token который посылается на сервак и сервак отдает новый session token
у нас этот так реализовано:
— запрос на котором он отвалился мы «запомнили»
— попробовали обновить токен
— если токен обновился, то снова выполняем запрос на котором он отвалился

Сбрасывать всю очередь запросов есть смысл когда от юзера просим перелогин, вы наверное имели ввиду такой кейс

[GDXRepo]

любопытно. А на основе чего генерите рефреш токен? Безопасно ли его хранение в приложении, если он статический?

[ChapayHabr]

вроде тут описано нормально
https://geektimes.ru/post/77648/undefined/?checklogin=true

[FirsofMaxim]

Спасибо, идеи хорошие! Можно еще добавить статический конструктор для сервиса (в «chain» стиле), в котором можно указать внешние модули: парсер данных, низкоуровневая сетевая библиотека, обработчик ошибок, логгер и т/д — как вишенка на торт.