Swift Backend with CouchDB: Kitura vs. Vapor vs. Node.js
I made a few test projects to implement an API for my simple app to run some benchmarks. It just makes 1 request to Database and returns JSON data.
All projects was executed on Linode VPS in London:
- 2 GB RAM
- 1 CPU Core
- SSD
- 125 MBPS Out
- Ubuntu 16.10
- MySQL and CouchDB with equal data (about 13k rows/documents)
Benchmarks was run on another, more powerful dedicated server in Germany using wrk:
wrk -t4 -c20 -d5m https://my_urlResults are very different from other benchmarks by Ryan Collins.
What did I try:
- Node.js 7.0 + MySQL 5.7.16
- Node.js 7.0 + CouchDB 2.0 (via node-couchdb)
- Vapor 1.1.11 + CouchDB 2.0 (via HTTP)
- Kitura 1.1.1 + CouchDB 2.0 (via Kitura-CouchDB)
Total requests
Requests per second
Average Latency
Results are very disappointing for me. Node.js was 50% faster than Swift. It looks like it's still not the right time to make backends on Swift right now, unless you don't expect high load and just want to write in Swift.
UPDATE: after about a month I ran another tests for the new version of Vapor (1.2.5) vs. Node.js and Vapor was very very fast. So now I'm very optimistic about using Swift as a backend.
comment commentsФреймворк Vapor для бэкэнда на Swift
В предыдущем посте я описывал свои впечатления от 4 фреймворков на Swift. Точнее написал я про 3, а 4 меня заинтересовал и руки до него дошли только сейчас. В кратце - я в восторге. Он прекрасен.
В первую очередь у проекта хорошая документация. Не идеальная, но очень хорошая. С примерами, обучающими материалами. Всё в одном месте на сайте, класс.
Во-первых, у фреймворка есть консольная тулза, которая позволяет очень просто создавать новые проекты, запускать существующие, билдить, деплоить на разные сервисы, и даже создавать Docker-контейнер. По-моему это офигенно, потому что когда начинаешь кодить какой-то, даже тестовый проект, сразу вспоминаешь разные тулзы из мира Node.js и хочется тут иметь что-то подобное.
Во-вторых, набор библиотек у фреймворка отличный. Тут и HTTP-клиент, и обёртки для баз данных, и поддержка WebSocket, шаблоны, по умолчанию предлагается хорошая структура проекта, всё по папочкам. Сразу из коробки отличная работа с JSON и данными, которые можно перегонять и из JSON, и в JSON. Даже есть механизм для локализации.
В-третьих, мне удалось сделать свой мини-клиент для CouchDB через просто HTTP-запросы, и он работает. Пока только на чтение, на запись ещё не успел проверить, но то, что всё заработало, очень понравилось.
В-четвёртых, по умолчанию идёт логирование всех запросов, примерно как это сделано у Express.js. То есть ты сделал роутинг, и в консоли видишь куда приходят запросы, хотя бы понимаешь что происходит. К тому же в комплекте идёт тулза для логирования.
В-пятых - весь мой небольшой тестовый проект скомпилился и заработал на Linux без проблем и падений. Компилился долго, но зато работает, это классно.
По памяти пока всё хуже, чем у Perfect. Perfect стартовал с 3.5 мб памяти, дорос до 5 мб. Vapor стартует с 11 мб памяти, растёт до 14.9 мб. Посмотрим что будет дальше, пока это всё равно в 2 раза меньше, чем у Node.js.
Пожалуй, пока на Vapor я и остановлюсь, по-моему он прекрасен :)
comment commentsФреймворки для серверного Swift
Пару месяцев назад мне попался пост про серверные фреймворки для Swift - сравнение производительности 4-х фреймворков на Swift для сервера между собой и с Node.js. Производительность меня заинтересовала. Судя по результатам, лучшим оказался Perfect. Через месяц автор выложил ещё одно сравнение производительности, но тестировал уже не в macOS, а в Linux. И снова Perfect оказался в лидерах.
На этих выходных я решил как следует его потрогать. Перед этим я бегло посмотрел в 4 сравниваемых фреймворка: Perfect, Kitura, Vapor и Zewo. Требований у меня к фреймворку было не много, кроме стандартного роутинга запросов и выдачи ответов, мне нужно:
- Поддержка шаблонизаторов, чтобы отдавать не только JSON, но и HTML.
- Поддержка сетевых запросов, т.к. в самом Foundation ничего для сетевых запросов ещё не готово.
- Желательно, чтобы были готовые библиотеки для работы с разными БД.
Естественно, всё это нужно под Linux.
comment commentsУстановка Swift 3 на Ubuntu Server 16.10
Записал видео-урок по установке Swift 3 на Ubuntu Server 16.10
comment comments
Shake effect animation for UIView
// MARK: - UIView Extension, or NSView
extension UIView {
/// Shake animation
func shake() {
let animation = CAKeyframeAnimation(keyPath: "transform.rotation")
animation.timingFunction = CAMediaTimingFunction(name: kCAMediaTimingFunctionLinear)
animation.duration = 1.0
animation.values = [-Double.pi / 6, Double.pi / 6, -Double.pi / 6, Double.pi / 6, -Double.pi / 7, Double.pi / 7, -Double.pi / 8, Double.pi / 8, 0.0 ]
layer.add(animation, forKey: "shake")
}
}
myView.shake()
Про переход на Swift 3 и Swift 2.4
За последние пару недель состоялся релиз новых версия macOS, iOS, tvOS и watchOS. Вместе с ними вышел новый Xcode и новая версия Swift.
При открытии проекта в новом Xcode он сразу предлагает конвертировать проект в новую версию Swift - или в версию 2.3, которая почти без изменений, как промежуточная версия, или сразу в новую версию Swift 3, в котором изменений прилично.
Сам проект конвертировать труда не составляет, ибо есть встроенный в Xcode конвертер. Я решил сначала попробовать 2.3, чтобы не углубляться в дебри изменений. Рабочий проект сконвертировался без проблем, а потом начался ад с зависимостями. Я пользуюсь Carthage, все зависимости компилируются в .framework, который ты импортируешь в свой проект. 1 раз импортировав, потом уже сам проект трогать не приходится, просто пересобирать зависимости. В первую неделю после релиза многие разработчики быстро выкатили обновления - и релиз на Swift 2.3, и релиз на Swift 3. Но не все. Например, SwiftyJSON - разработчики на какое-то время пропали, а их фреймворк очень популярен. Пришлось копать - те зависимости, которые не обновились, благо, подхватили сторонние разработчики. Они их форкнули, всё перевели на Swift 2.3 и отправили pull request'ы в оригинальные репозитории.
Пришлось потратить какое-то время и заменить некоторые зависимости на форки. И ура, проект собрался наконец. В течение следующей недели авторы всех зависимостей, которые я использую, уже выкатили релизы для Swift 2.3. Я с чистым сердцем вернул зависимости на оригинальные.
Само собой, есть смысл побыстрее перейти на Swift 3, потому что 2.3 - версия временная и поддержка её в будущих релизах Xcode исчезнет. Да и 3-й Swift обещают по возможности последней версией, которая сломает совместимость с предыдущими версиями.
Опять же - сам проект без особых проблем сконвертировался в Swift 3. Не всё, но многое. А то, что само не конвертнулось, Xcode сам при компиляции предлагал исправить, в основном надо было только тыкать мышкой и разрешать ему это поправить. Хоть я и дождался, когда все зависимости обновятся на Swift 3, пришлось немного попотеть. К слову - если framework скомпилен в Swift 2.3, то в проект на Swift 3 его нельзя включить. И обратно тоже. Разгрёб разные проблемы - начался гемор другой. AlamoFire для Swift 3 не просто обновился, а мажорно обновился - с переименованием классов и изменением API. В итоге пришлось некоторые методы вообще переписать на две трети. Хотя в большинстве случаев просто пришлось поменять местами аргументы и где-то что-то переименовать. Плюс, теперь чтобы передать get-параметры, нужно их ручками в строку URL добавлять, раньше это мог сделать аргумент parameters, но теперь эти данные шлются в теле запроса, как будто мы форму заполнили.
Но в итоге всё закончилось хорошо, хотя миграция и заняла время и силы. Вперёд, в будущее.
P.S. опенсорсная версия Swift 3, которую можно запускать на Linux, всё ещё не имеет полной реализации классов для работы с сетью. А фреймворк для бэкенда Perfect не компилится в Ubuntu 16.04. Пока Swift для бэкенда опять откладывается.
comment commentsЭлегантный extension для Notification.Name в Swift 3
В новой версии Swift 3 теперь другой конструктор для NSNotification (теперь уже просто Notification, префикс NS отбросили):
struct Config {
static let ShouldCloseBrowserNotification = "ShouldCloseBrowserNotification"
}
let notification = Notification(
name: Notification.Name(rawValue: Config.ShouldUpdateDialogNotification),
object: nil,
userInfo: nil
)
NotificationCenter.default.post(notification)Выглядит параметр name не очень то красиво теперь. Зато можно расширить Notification.Name, чтобы было красиво:
extension Notification.Name {
static let shouldCloseBrowserNotification = Notification.Name("ShouldCloseBrowserNotification")
}
let notification = Notification(
name: .ShouldUpdateDialogNotification,
object: nil,
userInfo: nil
)
NotificationCenter.default.post(notification)Примерно так же сделано и в самом UIKit:
