Сетевое ядро как часть приложения
Для начала немного поясню, о чем пойдет речь в данной статье. Сейчас большинство мобильных приложений, на мой взгляд, являются клиент-серверными. Это означает, что они содержат в составе кода сетевое ядро, отвечающее за пересылку запросов и получение ответов от сервера. Причем речь вовсе не о сетевых библиотеках, которые берут на себя ответственность по «низкоуровневому» управлению запросами вроде пересылки REST-запросов, построения multipart-тела, работы с сокетами, веб-сокетами, и так далее. Речь идет о дополнительной обвязке, которая позволяет управлять запросами, ответами и данными состояния, характерными конкретно для вашего сервера. Именно в вариантах реализации этой обвязки и заключены основные проблемы сетевого уровня во многих мобильных проектах, с которыми мне приходилось работать.
Данная статья ставит целью привести один из вариантов архитектурного решения по построению сетевого ядра приложения, к которому я пришел после долгого времени работы с разными моделями и различными серверными API, и который на данный момент является наиболее оптимальным для задач, встречающихся мне в процессе работы над проектами. Надеюсь, этот вариант поможет вам разработать хорошо структурированное и легко расширяемое сетевое ядро, если вы начинаете новый проект или модифицируете существующий. Также буду рад услышать ваши советы и комментарии по улучшению кода и/или предложенной архитектуры. И да, статья из-за большого объема будет выпущена в двух частях.
Подробности под катом.
Клиент-серверное взаимодействие
В процессе работы приходится разбирать множество самых разных проектов, так или иначе взаимодействующих с серверами, построенными по REST-протоколу. И в большинстве этих проектов наблюдается картина из разряда «кто в лес, кто по дрова», поскольку сетевое ядро везде реализуется по-разному (впрочем, как и другие архитектурные части приложения). Особенно плохо дела обстоят, когда в одном проекте видна рука нескольких разработчиков, сменявших друг друга (да еще и в условиях сжатых сроков, как правило). В таких случаях нередко получается «ядро» довольно жуткого вида, чуть ли не обладающее собственным интеллектом. Попробуем уберечься от таких проблем с помощью предложенного подхода.
С чего начнем?
- Для реализации будем использовать язык Swift версии 3.0.
- Условимся, что мы будем использовать гипотетический REST-сервер, работающий только с GET- и POST-запросами. В качестве ответов он будет нам возвращать либо JSON, либо некие данные (к сожалению, далеко не все сервера имеют унифицированную форму ответа, так что приходится предусматривать разные варианты).
- Также условимся, что для «низкоуровневого» сетевого общения нам не потребуется отдельная сетевая библиотека, мы напишем эту часть сами (тем более, на момент написания этой статьи сетевых библиотек, обновленных до версии языка 3.0, попросту нет).
- Предлагаемый подход является урезанной версией архитектуры SOA (Service-Oriented Architecture), с удаленными частями, не использующимися в небольших проектах (вроде отдельной подсистемы кэширования), адаптированной под условия строгой типизации языка Swift.
- Для реализации нам будет достаточно Xcode Playground, отдельный проект не обязателен.
Приступим. Для начала немного о самом процессе. Опишем пошаговую схему работы клиентского мобильного приложения с сервером:
- Пользователь совершает действие, требующее взаимодействия с сервером.
- Приложение через сетевое ядро отправляет GET либо POST-запрос на сервер, задавая определенный URL-адрес, набор заголовков, тело запроса, таймаут, кэш-политику и прочие параметры.
- Сервер обрабатывает запрос и присылает (либо не присылает, если что-то пошло не так с каналом связи) приложению ответ.
- Приложение анализирует полученную информацию, обновляет данные состояния и пользовательский интерфейс.
А в чем тут сложность?
И правда, пока все звучит довольно просто. Однако на деле эти 4 простых пункта содержат в себе дополнительные шаги, требующие дополнительных трудозатрат, и вот как раз тут начинается разнообразие в плане реализации этих самых промежуточных шагов. Немного расширим нашу последовательность, дополнив ее вопросами, возникающими в процессе работы:
- Пользователь совершает действие, требующее взаимодействия с сервером.
- Зависит ли действие пользователя от данных состояния, связанных с сервером? Например, требует ли действие наличия авторизационного токена? Если да, то где его хранить, как проверять?
- Серверное API может состоять из нескольких «точек доступа», например, узел авторизации, узел работы с пользовательскими данными, и так далее. Неплохо было бы как-то разделить эти действия на группы, чтобы не сваливать весь код в одну большую простыню.
- Пользователь может захотеть отменить свое действие (если приложение предоставляет ему такую возможность). Мы также должны уметь обрабатывать такие ситуации.
- Зависит ли действие пользователя от данных состояния, связанных с сервером? Например, требует ли действие наличия авторизационного токена? Если да, то где его хранить, как проверять?
- Приложение через сетевое ядро отправляет GET либо POST-запрос на сервер.
- Имеем отдельный базовый URL нашего сервера (их может быть несколько), относительно которого строится абсолютный адрес. Его нужно как-то задавать, чтобы не тратить много кода не это однотипное действие, но при этом сделать наше решение настраиваемым.
- Каждый запрос может иметь обязательный набор заголовков, а также дополнительные заголовки, требующиеся для конкретного запроса, включая типы отправляемых и принимаемых данных.
- Запрос может быть запущен в особой сессии (речь про URLSession), со специфическим таймаутом и политикой кэширования данных.
- Было бы неплохо иметь список всех асинхронных запросов, выполняемых в данный момент, это может быть полезно как с точки зрения аналитики, так и с точки зрения отладочной информации.
- Имеем отдельный базовый URL нашего сервера (их может быть несколько), относительно которого строится абсолютный адрес. Его нужно как-то задавать, чтобы не тратить много кода не это однотипное действие, но при этом сделать наше решение настраиваемым.
- Сервер обрабатывает запрос и присылает (либо не присылает, если что-то пошло не так с каналом связи) приложению ответ.
- Раз уж получение ответа — событие нестабильное, то нам определенно нужно уметь обрабатывать не только ответы, но и генерируемые ошибки. А учитывая, что серверные API зачастую не обладают сколько-нибудь унифицированной структурой ответов и выдачи ошибок, стоит приготовиться к получению самых разных форматов ошибок, включая системные.
- Поскольку в успешном ответе (в зависимости от реализации серверного API) нам может прийти как сам успешный ответ, так и отказ сервера в обработке операции (например, если мы забыли указать авторизационный токен для запроса, закрытого пользовательской авторизацией), то нам нужно уметь обрабатывать как успешные ответы, так и «успешные ошибки». При этом, сами обработчики желательно размещать в виде самодостаточных отдельных сущностей в коде, которые можно легко анализировать и сопровождать.
- Раз уж получение ответа — событие нестабильное, то нам определенно нужно уметь обрабатывать не только ответы, но и генерируемые ошибки. А учитывая, что серверные API зачастую не обладают сколько-нибудь унифицированной структурой ответов и выдачи ошибок, стоит приготовиться к получению самых разных форматов ошибок, включая системные.
- Приложение анализирует полученную информацию, обновляет данные состояния и пользовательский интерфейс.
- Этот пункт снова возвращает нас к вопросу хранения данных состояния. Мы должны выбрать данные из ответа сервера, которые необходимы нам для отображения пользовательского интерфейса, а также данные, которые могут понадобиться при дальнейших запросах к серверу, обработать их и сохранить в удобном для нас виде.
Казалось бы, достаточно несложный набор вопросов, но из-за их количества и разнообразия доступного в языке инструментария реализация всех этих этапов от проекта к проекту может отличаться до неузнаваемости. Кстати говоря, при небольшой модификации предлагаемый подход может применяться и в Objective-C (как языке с нестрогой типизацией), но это выходит за рамки данной статьи.
Проектирование
Для решения всех приведенных выше вопросов нам понадобятся несколько сущностей:
- Информация об «успешной ошибке». Эта сущность будет обеспечивать получение и хранение информации об «успешной ошибке», или «отказе сервера», как я чаще всего ее называю — например, об ошибке авторизации.
- Информация об ответе сервера. Будет хранить всю информацию, полученную от сервера, чтобы в ней гарантированно не возникало недостатка. Рано или поздно в проектах приходится анализировать то, что пришло с сервера, вплоть до параметров URLResponse, поэтому лучше все подобные данные держать в быстром доступе.
- Асинхронная сетевая задача. Собственно сам асинхронный таск, хранящий свое состояние, а также входные и выходные параметры, включая, разумеется, сам серверный запрос.
- Пул задач. Класс занимается отправкой и учетом активных асинхронных сетевых задач. Также хранит общие данные по серверному API, вроде базового URL, стандартного набора заголовков и так далее.
- Протокол обработки ответа. Данный протокол обеспечит нам возможность создавать строго типизированные сущности («парсеры», или обработчики), которые смогут принимать на вход поток данных (в том числе форматированный JSON) и трансформировать его в понятные приложению структуры, или модели данных (о них чуть ниже).
- Модели данных. Структуры данных, понятные и удобные для приложения. Являются отражением серверных данных в адаптированном для приложения виде.
- «Парсеры», или обработчики ответа. Сущности, преобразующие «сырые» данные в модели данных, и наоборот. Реализуют протокол обработки ответа.
- Сервис, или узел доступа к данным. Инкапсулирует управление группой логически связанных операций. Например, AuthService, UserService, ProfileService и так далее.
Если вам кажется, что тут слишком много звеньев — изначально я тоже так думал. Пока не попробовал несколько проектов с отсутствием спроектированного сетевого ядра в принципе. Без четкой структуры уже после реализации 5-10 запросов к серверу код начинает быстро превращаться в кашу, если оставить его неупорядоченным. Опять-таки, я предлагаю лишь один из подходов, и в данный момент именно он наиболее удобен для меня в работе над проектами.
Для наглядности я отразил весь процесс на схеме (изображение кликабельно):
Реализация ядра
Поехали. Создадим Playground и пойдем прямо по шагам из предыдущего раздела. Плюс, допустим, что в большинстве случаев мой сервер возвращает мне JSON. Какой парсер JSON использовать — это на ваше усмотрение, на момент написания статьи, опять-таки, адаптированных под третью версию языка библиотек еще не было, поэтому я использовал самописный парсер GJSON.
Информация об ошибке
Тут все довольно элементарно, класс с парой полей и инициализатором. Финализируем его, в рамках нашей задачи нам ни к чему расширения (конечно, в вашем проекте это может быть по-другому):
Информация об ошибке
final class ResponseError {
let code: NSNumber?
let message: String?
// MARK: - Root
init(json: Any?) {
if let obj = GJSON(json) {
code = obj.number("code")
message = obj.string("message")
}
else {
code = nil
message = nil
}
}
}Информация об ответе
Чуть более подробный класс, принцип тот же. В данном случае он также соответствует ответу, возвращаемому сервером, это бинарные данные на вход, код ответа, опциональное сообщение + распарсенная ошибка:
Информация об ответе
final class Response {
let data: Any?
let code: NSNumber?
let message: String?
let error: ResponseError?
// MARK: - Root
init?(json: Any?) {
guard let obj = GJSON(json) else { return nil }
code = obj.number("code")
message = obj.string("message")
data = json
error = ResponseError(json: json)
}
}Для удобства в вашем проекте, если вы работаете гарантированно с JSON в возвращаемых бинарных данных, то можно расширить этот класс через extension, например, добавив ему поле, возвращающее json-парсер (как пример):
Расширение для удобства
extension Response {
var parser: GJSON? {
return GJSON(data)
}
}Асинхронная сетевая задача
Вот это уже куда более интересная вещь. Назначение этого класса состоит в хранении всех отдаваемых данных, всех принимаемых данных и своего состояния (завершено/отменено). Также умеет отправлять себя в сеть и вызывать callback после завершения работы. При получении ответа от сервера записывает все полученные данные, в том числе делает попытку трансформации входных данных в JSON-объект, если это возможно, для упрощения последующей обработки. Также, поскольку в дальнейшем набор таких задач мы будем использовать внутри множества Set, нам понадобится реализовать пару системных протоколов.
Асинхронная сетевая задача
typealias DataTaskCallback = (DataTask) -> ()
final class DataTask: Hashable, Equatable {
let taskId: String
let request: URLRequest
let session: URLSession
private(set) var responseObject: Response?
private(set) var response: URLResponse?
private(set) var error: Error?
private(set) var isCancelled = false
private(set) var isCompleted = false
private var task: URLSessionDataTask?
// MARK: - Root
init(taskId: String, request: URLRequest, session: URLSession = URLSession.shared) {
self.taskId = taskId
self.request = request
self.session = session
}
// MARK: - Controls
func start(callback: DataTaskCallback?) {
task = session.dataTask(with: request) { [unowned self] (data, response, error) in
if self.isCancelled {
return
}
self.isCompleted = true
// transform if possible
var wrappedData: Any? = data
if data != nil {
if let json = try? JSONSerialization.jsonObject(with: data!, options: .allowFragments) {
wrappedData = json
}
}
// parse
self.responseObject = Response(json: wrappedData)
self.error = error
// callback
callback?(self)
}
task?.resume()
}
func cancel(callback: DataTaskCallback?) {
if task != nil && !isCompleted && !isCancelled {
isCancelled = true
task?.cancel()
// callback
callback?(self)
}
}
// MARK: - Equatable
static func ==(lhs: DataTask, rhs: DataTask) -> Bool {
return lhs.taskId == rhs.taskId
}
// MARK: - Hashable
var hashValue: Int {
return taskId.hashValue
}
}Пул задач
Как и говорилось ранее, этот класс будет вести учет активных асинхронных задач, что может быть полезно при анализе или отладке. Бонусом он позволяет найти задачу по идентификатору и, например, отменить ее. Через пул задач производится отправка всех тасков в сеть (можно и без него, но тогда таск вам придется хранить где-то самостоятельно, что не очень удобно). Класс делаем синглтоном, разумеется.
Пул задач
final class TaskPool {
static let instance = TaskPool() // singleton
let session = URLSession.shared // default session
let baseURLString = "https://myserver.com/api/v1/" // default base URL
var defaultHeaders: [String: String] { // default headers list
return ["Content-Type": "application/json"]
}
private(set) var activeTasks = Set<DataTask>()
// MARK: - Root
private init() { } // forbid multi-instantiation
// MARK: - Controls
func send(task: DataTask, callback: DataTaskCallback?) {
// check for existing task
if taskById(task.taskId) != nil {
print("task with id \"\(task.taskId)\" is already active.")
return
}
// start
activeTasks.insert(task)
print("start task \"\(task.taskId)\". URL: \(task.request.url!.absoluteString)")
task.start { [unowned self] (task) in
self.activeTasks.remove(task)
print("task finished \"\(task.taskId)\". URL: \(task.request.url!.absoluteString)")
callback?(task)
}
}
func send(taskId: String, request: URLRequest, callback: DataTaskCallback?) {
let task = DataTask(taskId: taskId, request: request, session: session)
send(task: task, callback: callback)
}
func taskById(_ taskId: String) -> DataTask? {
return activeTasks.first(where: { (task) -> Bool in
return task.taskId == taskId
})
}
}Протокол
И завершающая часть, относящаяся непосредственно к сетевому ядру, — обработка ответов. Строгая типизация языка вносит свои коррективы. Мы хотим, чтобы наши классы-парсеры обрабатывали данные и отдавали нам определенный тип данных, а не какой-нибудь Any?. Для этих целей сделаем небольшой генерик-протокол, который в дальнейшем будем реализовывать:
Протокол
protocol JSONParser {
associatedtype ModelType
func parse(json: Any?) -> ModelType?
}Что дальше?
Собственно, на этом создание сетевого ядра завершено. Его можно спокойно переносить между проектами, только слегка подрихтовывая структуры информации об ответе и ошибке, а также адрес API cервера.
Во второй части данной статьи мы рассмотрим, как применить созданное сетевое ядро в проекте, чтобы максимально использовать преимущества предложенной архитектуры.
Поделиться с друзьями
Комментарии (20)
s1dd0k
15.09.2016 12:50+1Есть еще вот такой фреймворк, призванный помочь в организации сетевого кода
https://github.com/Moya/Moya
GDXRepo
15.09.2016 12:52Посмотрел, спасибо, интересное решение. Отчасти похоже на то, что мы в статье разбираем.
DenHeadless
15.09.2016 14:32+1А вот еще =)
https://github.com/MLSDev/TRONGDXRepo
15.09.2016 14:34Вот это уже значительно больше похоже на то, чего я пытаюсь добиться с помощью описываемого способа) Очень любопытно, спасибо! Изучу, как только его обновят до третьей версии языка, пока что, опять-таки, не получится им воспользоваться в моих проектах. Но реализация прямо похожа на то, что нужно. Благодарю!
DenHeadless
15.09.2016 14:35Мы обновим его до свифт 3 на этих выходных =) Пока что есть девелопмент версия в бранче swift3, она почти готова к релизу, осталось отполировать использование Alamofire 4.0 до нормального вида.
Florelit
15.09.2016 13:53Неплохой фреймворк для таких целей https://github.com/Alamofire/Alamofire
GDXRepo
15.09.2016 13:54Вы невнимательно прочитали первые два абзаца в моей статье. Поэтому немножко не поняли, о чем она, и почему Alamofire не касается темы статьи.
Florelit
15.09.2016 17:58Простите, воспаленный мозг выразился абсолютно не верно. Цель обвязки описанной в статье очевидно совершенна другая. А моя фраза была отсылом к пункту 3 секции «С чего начнем?»
Также условимся, что для «низкоуровневого» сетевого общения нам не потребуется отдельная сетевая библиотека, мы напишем эту часть сами (тем более, на момент написания этой статьи сетевых библиотек, обновленных до версии языка 3.0, попросту нет).
:)
askl
16.09.2016 09:48Хотелось бы увидеть удобную реализацию решения на базе этого ядра такой популярной проблемы как обновление токена авторизации к апи и повторение запросов, которые привели к обновлению. Т.е. допустим токен авторизации протухает каждые 3 часа. Соответсвенно, следующий запрос вернет ошибку авторизации (что-то типа session token expired). Обычно, в такой ситуации, все следующие запросы становятся в очередь до момента обновления токена.
GDXRepo
16.09.2016 14:25Да, полезный кейс. Можно попробовать его рассмотреть во второй части, я подумаю, спасибо. Насчет очереди — скорее, все запросы просто должны отвалиться, если пришла отвалившаяся сессия, т.к. не факт, что после переавторизации я захочу отправить снова всю тучку запросов ровно в том же порядке. Но кейс рассмотрим.
house2008
Мне кажется enum для ResponseError было бы удобнее
Почему бы не использовать struct вместо классов?
GDXRepo
На мой взгляд, по поводу enum — тут больше вопрос вкуса. Я пока не привык к таким конструкциям. Кроме того, получится ли сделать нормальную обработку входного JSON в такого рода перечислениях? Можно попробовать, но я особо преимуществ пока не вижу. А по поводу структур — нет, не стоит. Здесь копирование данных ни к чему, ссылки здесь более корректны, на мой взгляд. Структуры — вещь хорошая, но их не стоит использовать прямо везде, насколько я понял из советов Apple в WWDC. В нашей архитектуре вполне уместны классы.