$ grep -r Tag: «vapor»

Основные изменения

• Проведен рефакторинг внутреннего устройства выполнения запросов в CouchDBClient для использования более чистых потоков в стиле async/await и уменьшения дублирования логики обработки ответов.
• Улучшены пути буферизации и декодирования для сырых и типизированных запросов с упором на более безопасное выполнение в EventLoopGroup и повышение производительности при обработке ответов.
• Расширено тестовое покрытие для выполнения запросов на базе EventLoopGroup, включая сырые и типизированные get, сырые и типизированные find, загрузку вложений, вывод списков индексов Mango и объяснение запросов Mango.
• Обновлена документация для пользователей: README, статьи DocC и руководства (tutorials).
• Обновлены инструменты документирования для новых рабочих процессов DocC, включая поддержку экспорта в Markdown.

Улучшения API и поведения

• Добавлена и доработана поддержка EventLoopGroup для большего количества путей запросов в CouchDBClient.
• Улучшены внутренние пути обработки ошибок и поведение декодирования ответов для операций CouchDB.
• Упрощена многоуровневая структура помощников запросов и уменьшено дублирование кода обработки запросов/ответов.
• Улучшено поведение, связанное с вложениями, и соответствующие тесты.
• В манифест пакета добавлена поддержка visionOS.

Документация

• Исправлены и обновлены примеры в README для использования CRUD и запросов Mango.
• Обновлены целевые страницы DocC для лучшего отражения текущего API.
• Исправлены фрагменты кода в руководстве по продвинутым запросам Mango, чтобы они соответствовали текущему типизированному API запросов.
• Исправлены примеры в руководстве по Vapor.
• Исправлена настройка пакета и зависимостей в руководстве по Hummingbird.
• Обновлен buildDocs.sh для поддержки:
  • настраиваемого пути вывода и базового пути хостинга;
  • встраивания контента для статического хостинга;
  • экспериментального вывода в Markdown;
  • генерации манифеста Markdown.
• Добавлен этап постобработки в buildDocs.sh, который внедряет относительную ссылку на Markdown в сгенерированные HTML-страницы DocC.

Инструменты и зависимости

• Обновлены зависимости пакета в Package.resolved.
• Обновлена матрица версий Swift для процесса сборки под Ubuntu.

CouchDB Client на GitHub | Документация с примерами и руководствами.

Star Fork

Недавно я реализовал функцию, которую давно хотел добавить в CouchDB Swift client. Это поддержка Mango Queries. Наконец-то всё готово в версии 2.3.0. Кажется, это последняя крупная функция.

Список изменений:

• Представлен надежный и типобезопасный MangoQuery API для построения сложных селекторов, проекций, сортировки и пагинации в CouchDB.
• Добавлена поддержка указания индексов через useIndex в запросах для оптимизации производительности.
• Добавлена полноценная поддержка загрузки, скачивания и удаления вложений документов (файлов/изображений).
• Комплексный набор тестов для Attachments API обеспечивает надежность операций с файлами.
• Добавлены модели и API для создания, перечисления и управления индексами Mango (MangoIndex, IndexDefinition).
• В документацию теперь включены обучающие примеры и фрагменты кода для создания индексов.
• Добавлена поддержка эндпоинта CouchDB Mango _explain через MangoExplainResponse, чтобы можно было проверить, как выполняются запросы и какие индексы используются.

CouchDB Client на GitHub | Документация с примерами и руководствами.

Star Fork

Этот сайт работает на Vapor — серверном фреймворке для Swift. Он довольно старый, популярный и известный.

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

Я поддерживаю все зависимости в актуальном состоянии. Но недавно я заметил, что сайт начал потреблять слишком много памяти. Использование начинается примерно с 20 МБ, но спустя несколько недель я обнаружил, что на сервере оно разрослось до 750 МБ.

Для такого простого сайта это очень много, поэтому я начал копать. Изучив код сайта (который я долгое время не менял), я не смог найти никаких проблем (как и AI-агенты).

Для рендеринга HTML я использую Leaf — шаблонизатор от команды Vapor. И в их репозитории на GitHub как раз был открытый тикет, описывающий точно такую же проблему.

Поэтому я попросил Copilot помочь мне разобраться, в чем дело. Он довольно быстро добавил в мой форк новые тесты, которые выполняли множество рендерингов в цикле. И утилита leak обнаружила циклы сильных ссылок (retain cycles). Я исправил это с помощью аннотации weak, но во время проверки моего PR мейнтейнер предложил просто использовать unowned.

И вот и всё. 2 строки кода исправили рост потребления памяти. Трудно поверить, но спустя несколько часов после деплоя сайт всё еще потребляет всего 2 МБ памяти. Так что сегодня я очень собой горжусь.

Мораль: вносите вклад в Open Source проекты, которыми вы пользуетесь.

Недавно я выпустил несколько новых версий CouchDB клиента для Swift. Последняя версия — 2, и она включает в себя несколько ключевых изменений:

• Обновлена минимально необходимая версия Swift до 6.0.
• Внедрена поддержка Swift Concurrency. CouchDBClient был обновлен и теперь является actor.
• Библиотека была переименована из couchdb-vapor в couchdb-swift, чтобы лучше отражать её назначение как универсального клиента CouchDB для Swift, а не только для использования с Vapor.
• Внесены изменения в инициализатор. Вместо передачи множества параметров теперь используется структура Config.
• Теперь вы можете передать собственный экземпляр HTTPClient для использования в клиенте.
• Добавлены переводы сообщений об ошибках.
• Представлен специальный туториал по интеграции CouchDBClient с серверным фреймворком Hummingbird.
• Добавлен метод shutdown() для корректного освобождения ресурсов, связанных с HTTPClient.

CouchDB Client на GitHub | Документация с примерами и руководствами.

Star Fork

И вот, ещё одна новая версия библиотеки CouchDB client. После недавнего поста про версию 1.4.0, в Swift on Server вышла новая версия async-http-client, которая включает новую реализацию синглтона клиента. Теперь это HTTPClient.shared, поэтому я обновил библиотеку CouchDB, чтобы адаптировать её к этому изменению. Это также означает, что вам больше не нужно вызывать httpClient.syncShutdown(), если используется синглтон. Кроме того, они подняли минимальную версию Swift до 5.8 (что я также сделал в версии 1.4.0 клиента для CouchDB). Так что я продолжаю поддерживать библиотеку в актуальном состоянии.

Список изменений:

• Обновил минимальную версию async-http-client до новой 1.21.0. Если вы не можете использовать её в своем проекте, вы всё еще можете оставаться на версии 1.4.0.
• Теперь библиотека будет внутри использовать HTTPClient.shared (новое в async-http-client 1.21.0) для запросов, если не предоставлен EventLoopGroup.
• Больше нет внутренних вызовов httpClient.syncShutdown() при использовании HTTPClient.shared.

CouchDB Client на GitHub | Документация с примерами и руководствами.

Вышла новая версия CouchDB Client:

• Библиотека перешла с HTTPClient.Response на HTTPClientResponse, что похоже на HTTPClient.Response, но предназначено для Swift Concurrency API. Также был выполнен переход с HTTPClient.Body на HTTPClientRequest.Body. Эти изменения влияют на методы get и find. Старые методы помечены как устаревшие (deprecated), для миграции смотрите документацию для получения информации об обновленных методах.
• Минимальная версия Swift теперь 5.8.
• Протокол CouchDBRepresentable теперь помечен как Codable.
• Кроме того, была добавлена новая модель данных под названием RowsResponse. Она принимает обобщённый тип CouchDBRepresentable, что упрощает получение строк из базы данных. Например:

  let decodeResponse = try JSONDecoder().decode(RowsResponse<MyApp>.self, from: data)

• Наконец, внесены небольшие улучшения в документацию и обучающие примеры.

CouchDB Client на GitHub | Документация с примерами и руководствами.

Для веб-сайта или бэкенда — обычное дело, когда такие URL, как mySite.com/webpage и mySite.Com/webpage/, ведут на одну и ту же страницу. Для поисковых систем это разные адреса. Чтобы избежать дублирования контента, можно добавить простую middleware, которая будет удалять завершающий слеш и перенаправлять пользователя.

Вот пример кода для такого класса middleware в Vapor 4:

final class TrimSlashInPathMiddleware: Middleware {
    func respond(to request: Request, chainingTo next: Responder) -> EventLoopFuture<Response> {
        if request.url.path.count > 1, request.url.path.hasSuffix("/") {
            let newPath = String(request.url.path.trimmingSuffix(while: { $0 == "/" }))
            let response = request.redirect(to: newPath, redirectType: .permanent)
            return request.eventLoop.makeSucceededFuture(response)
        }
        return next.respond(to: request)
    }
}

Просто добавьте его в файл configure.swift:

import Vapor

public func configure(_ app: Application) throws {
    app.middleware.use(TrimSlashInPathMiddleware())

    app.http.server.configuration.port = 8081

    try routes(app)
}

Работает с Vapor 4.92.5.

Недавно вышло несколько новых версий моей библиотеки Swift CouchDB. Вот последние изменения:

• dateDecodingStrategy и dateEncodingStrategy теперь можно передавать в качестве параметров для методов get, update и insert.
• Добавлена проверка для обработки истекших cookie аутентификации.
• Сравнение заголовка set-cookie в ответе теперь выполняется в нижнем регистре.
• Представлены новые методы для использования API _find, позволяющие искать документы с помощью декларативного синтаксиса JSON-запросов.
• Исправлена ошибка, из-за которой метод update не использовал параметр dateEncodingStrategy.

CouchDB Client на GitHub | Документация с примерами и руководствами.

Небольшое обновление библиотеки Swift CouchDB client с парой новых методов, которые понадобились мне самому:

• Новый метод для создания базы данных [docs].
• Новый метод для удаления базы данных [docs].
• Новый метод для проверки существования базы данных [docs].
• Каждый запрос теперь обрабатывает ошибки unauthorised.
• У модели CouchDBClientError теперь есть текстовое описание.

CouchDB Client на GitHub | документация с примерами и туториалами.

Пару месяцев назад я начал разбираться с Apple’овским DocC — инструментом, который генерирует документацию из исходного кода. Я решил задействовать максимум возможностей, поэтому взял свою небольшую библиотеку CouchDB Client и добавил документацию к каждому методу, включая примеры использования, которые Xcode будет показывать в попапе автодополнения. Как часто бывает, в процессе написания доков и примеров я обнаружил, что многие вещи в библиотеке можно сделать гораздо лучше. Поэтому я обновил существующие методы и добавил несколько новых — таких, что принимают документ параметром и используют дженерики.

Следующим шагом были руководства. Apple даёт разработчикам возможность создавать ровно такие же руководства, как у них самих для SwiftUI. Так что я добавил парочку, и они тоже лежат в репозитории на GitHub.

Уверен, что на документацию я потратил больше времени, чем на саму библиотеку, но надеюсь, что оно того стоило.

CouchDB Client на GitHub | документация с примерами и туториалами.

Закончил новую версию Swift CouchDB client. Теперь она использует только async-http-client в качестве зависимости для http/https-запросов. Совместима с Vapor 4.

Проект на GitHub: https://github.com/makoni/couchdb-swift

После миграции (а по факту почти переписывания) своего небольшого проекта с Vapor 2 на Vapor 3 я прогнал бенчмарки, чтобы сравнить производительность. Я не запускал бенчмарки на последней версии Vapor 2.x, поэтому буду сравнивать Vapor 2.1.0 с результатами Vapor 3.1.0.

Конфигурация моего сервера:

• 2 ГБ RAM
• 1 ядро CPU
• SSD
• 125 Мбит/с исходящего трафика
• Ubuntu 16.04.2 LTS
• CouchDB

Бенчмарк с другого сервера запускался так:

wrk -t4 -c20 -d5m https://my_url

API просто берёт данные из CouchDB и отдаёт их как JSON. Проект на Vapor собирался Swift 4.2.

Всего запросов

Запросов в секунду

Средняя задержка

Использование памяти

Vapor 3 был переписан и теперь основан на NIO от Apple. Он быстрее Vapor 2, но потребляет больше памяти, что не критично.

Предыдущие бенчмарки:
Бенчмарки: Vapor 2 vs. Vapor 1
Бенчмарки Vapor 1.2.5
Swift-бэкенд с CouchDB: Kitura vs. Vapor vs. Node.js

Столкнулся с тем, что перестал компилиться проект на Ubuntu на Vapor 2. Точнее, одна из зависимостей - Crypto. Оказалось, что из-за добавленного репозитория, в котором были более новые версии некоторых библиотек, оно и не компилилось. Запишу сюда - пришлось даунгрейдиться:

apt install libssl-dev=1.0.2g-1ubuntu4.10
apt install openssl=1.0.2g-1ubuntu4.10

После миграции своего пет-проекта с Vapor 1 на Vapor 2 я прогнал бенчмарки, чтобы сравнить производительность. Я не запускал бенчмарки на последней версии ветки 1.x (1.5.15), поэтому буду сравнивать Vapor 2.1.0 с результатами Vapor 1.2.5 из прошлого замера.

Мой сервер:

• 2 ГБ RAM
• 1 ядро CPU
• SSD
• 125 Мбит/с исходящего трафика
• Ubuntu 16.04.2 LTS
• CouchDB

Бенчмарк с другого сервера запускался так:

wrk -t4 -c20 -d5m https://my_url

API просто берёт данные из CouchDB и отдаёт их как JSON. Проект на Vapor собирался Swift 3.1.1.

Всего запросов

Запросов в секунду

Средняя задержка

Использование памяти

Vapor 2 примерно на 14–15% быстрее Vapor 1.2.5. И что важно — потребление памяти Vapor 1.2.5 после бенчмарков выросло с 13,4 МБ до 59,1 МБ, а Vapor 2 стартовал всего с 3,6 МБ и его потребление выросло лишь до 5,3 МБ. Очень впечатляюще.

Решил информацию о своих приложениях вынести с apps.arm1.ru на отдельный домен. Раз я их когда-то начал публиковать под именем Space In Box, то и домен соответствующий: spaceinbox.me. Решил убрать уже не актуальные и не доступные приложения и максимально везде использовать векторную графику (иконки, логотипы), ибо на ретине глаз сильно режет.

Был отличный повод сделать что-то на Swift на фреймворке Vapor, пока всё нужное получилось. Обновлять, если что-то меняется в логике, конечно, тяжелее, т.к. приходится билдить на сервере всё заново, а это происходит минуты 3-4 каждый раз. А если что-то касается оформления (подправить html), то шаблоны подхватываются бинарником на лету и компилить заново не надо. Скорость работы и потребляемая память (пока 8.8 мб) радуют. Теперь можно обновлять старые и фигачить новые приложения.

UPDATE: С простым обновлением до Vapor 1.5.14 без изменения какого либо кода сайт стал есть ещё меньше памяти - 6.7-7.7 мб.

Примерно месяц назад я прогонял бенчмарки для серверных Swift-фреймворков. Вчера я обновил свой проект до новой версии Vapor — 1.2.5. Раньше использовал 1.1.11.

Одно из самых важных изменений в Vapor 1.2.x — то, что Vapor теперь использует неблокирующий сервер.

Сегодня я решил прогнать новый бенчмарк проекта, обновлённого до Vapor 1.2, и результаты меня удивили. Он не только быстрее версии 1.1.x — он сравнялся с результатами Node.js!

Vapor vs. Node.js

Мой сервер:

• 2 ГБ RAM
• 1 ядро CPU
• SSD
• 125 Мбит/с исходящего трафика
• Ubuntu 16.10
• CouchDB

Бенчмарк с другого сервера запускался так:

wrk -t4 -c20 -d5m https://my_url

API просто берёт данные из CouchDB и отдаёт их как JSON.

Всего запросов

Запросов в секунду

Средняя задержка

Эти результаты выглядят гораздо лучше предыдущих, так что я уверен — бэкенд на Swift может быть хорошим выбором. Последний вопрос для меня сейчас — потребление памяти. После бенчмарков Vapor вырос с 13,4 МБ до 59,1 МБ. Возможно, у меня где-то утечки в коде, посмотрим.

Я написал несколько тестовых проектов, реализующих API для моего простого приложения, чтобы прогнать бенчмарки. Они делают всего один запрос к базе данных и возвращают JSON.

Все проекты гонялись на VPS Linode в Лондоне:

• 2 ГБ RAM
• 1 ядро CPU
• SSD
• 125 Мбит/с исходящего трафика
• Ubuntu 16.10
• MySQL и CouchDB с одинаковыми данными (около 13к строк/документов)

Сами бенчмарки прогонялись с другого, более мощного выделенного сервера в Германии при помощи wrk:

wrk -t4 -c20 -d5m https://my_url

Результаты сильно отличаются от бенчмарков Райана Коллинза.

Что я попробовал:

• Node.js 7.0 + MySQL 5.7.16
• Node.js 7.0 + CouchDB 2.0 (через node-couchdb)
• Vapor 1.1.11 + CouchDB 2.0 (через HTTP)
• Kitura 1.1.1 + CouchDB 2.0 (через Kitura-CouchDB)

Всего запросов

Запросов в секунду

Средняя задержка

Результаты для меня очень разочаровывающие. Node.js оказался на 50% быстрее Swift. Похоже, что писать бэкенды на Swift пока ещё рановато — разве что вы не ждёте высокой нагрузки и просто хотите писать на Swift.

UPDATE: примерно через месяц я прогнал ещё одни тесты для новой версии Vapor (1.2.5) против Node.js, и 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 я и остановлюсь, по-моему он прекрасен :)

Пару месяцев назад мне попался пост про серверные фреймворки для Swift - сравнение производительности 4-х фреймворков на Swift для сервера между собой и с Node.js. Производительность меня заинтересовала. Судя по результатам, лучшим оказался Perfect. Через месяц автор выложил ещё одно сравнение производительности, но тестировал уже не в macOS, а в Linux. И снова Perfect оказался в лидерах.

На этих выходных я решил как следует его потрогать. Перед этим я бегло посмотрел в 4 сравниваемых фреймворка: Perfect, Kitura, Vapor и Zewo. Требований у меня к фреймворку было не много, кроме стандартного роутинга запросов и выдачи ответов, мне нужно:

• Поддержка шаблонизаторов, чтобы отдавать не только JSON, но и HTML.
• Поддержка сетевых запросов, т.к. в самом Foundation ничего для сетевых запросов ещё не готово.
• Желательно, чтобы были готовые библиотеки для работы с разными БД.

Естественно, всё это нужно под Linux.

Kitura

Kitura один из самых прокачанных фреймворков. Есть библиотеки для MySQL, CouchDB, MongoDB и других. Вот только результаты тестов производительности неутешительные - он плетётся в хвосте. Правда, делают его могучие IBM, которые не только его пилят, но и активно контрибьютят в сам Swift. Вроде бы есть библиотека для сетевых запросов. Есть поддержка шаблонов, но с ними всё плохо. Есть Mustache, который работает только в macOS и его всего 3 дня назад перевели на Swift 3. Есть ещё Stencil, но с ним, когда смотрел, тоже был какой-то гемор, связанный с тем, что на последних Swift и Xcode его ещё нельзя использовать.

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

Сегодня я решил сделать тестовый проект на нём, увидев, что у них есть библиотека для работы с CouchDB, захотел посмотреть работает ли она (потому что написанная мною за вечер не работает, об этом ниже), так swift build даже не смог разрезолвить зависимости после добавления туда зависимости Kitura-CouchDB, у которой есть в зависимостях какой-то логгер, у которого в зависимостях ещё какой-то логгер. Всё от IBM. Это какой-то ад, когда это от одного производителя и оно не работает вместе. Создал им Issue на GitHub, на этом попытка что-то закодить на нём закончилась. Пока отложил.

Начали они всего лишь в феврале этого года, надеюсь, допилят всё как следует, к тому же у IBM есть все ресурсы для этого. Буквально сегодня смотрел видео с конференции по Swift, где они продвигают бэкенд на Swift и свой фреймворк.

Update: Чтобы проект сбилдился надо было указать у зависимости версию 1.1 в Package.swift, как ответили мне на мой issue на GitHub. Может что теперь и получится. Хотя осадочек остался.

Zewo

Открываешь страницу на GitHub - показывается опять очередной примитивный роутинг запросов. Если покопаться в списке репозиториев, то видишь, что вроде бы есть и клиент для PostgreSQL, и HTTP-клиент для сетевых запросов, и ещё какая-то куча обёрток вокруг сишных либ.

Опять же, документации нет, популярность его сильно ниже, судя по количеству звёзд на GitHub. Заходя на сайт проекта хочется видеть документацию, а не 1-страничный Hello World.

Для шаблонов есть Mustache, но до сих пор не переведён на Swift 3. Непонятно, насколько активно он развивается, вроде бы компонентов много, но если они не поспевают за выходом новых версий Xcode и Swift, которые обновились уже полтора месяца назад, как-то не вызывает он доверия. Совсем. Даже попробовать не получится из-за отставаний.

Vapor

Выглядит презентабельно. Есть библиотеки для работы с MySQL, PostgreSQL, MongoDB, свой ORM. Есть HTTP-клиент для запросов. Есть шаблонизатор Leaf.

Шикарно выглядит документация. Есть текстовые и видео уроки на отдельном сайте.

Попробовать не успел, но очень хочу, несмотря на то, что у него не лучшие результаты в тесте производительности.

Update: пост про Vapor.

Perfect

Самый популярный (пока) фреймворк на Swift. По крайней мере, судя по количеству звёзд на GitHub. В тесте производительности оказался лидером. Поэтому сразу захотелось посмотреть именно на него.

На сайте классная документация по всему, что есть. Т.к. она собрана в одном месте на сайте (и дублируется на GitHub), сразу увидел что есть и обёртка над cURL для сетевых запросов, и библиотеки для баз данных - SQLite, MySQL, PostgreSQL, MongoDB и свой ORM. У этого фреймворка я у первого увидел всё, что мне было нужно (потому что у некоторых других просто нет нормальной документации) и именно его и решил попробовать.

Как я пытался написать бэкенд на Perfect

С банальным роутингом Perfect справляется отлично. Синтаксис простой. Я сразу решил попробовать запилить API на нём. Для API я хотел использовать CouchDB. Поскольку готовой библиотеки у них нет, я решил быстренько набросать свою, ибо работать с CouchDB можно простыми HTTP-запросами, а в комплекте есть обёртка над сишным cURL.

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

Вот тут то начался гемор. На macOS данные никак не хотят писаться в базу. То есть я отправляю просто POST-запрос:

let curlObject = CURL(url: url)

curlObject.setOption(CURLOPT_HTTPHEADER, s: "Content-Type: application/json; charset=utf-8")
curlObject.setOption(CURLOPT_POST, int: 1)
curlObject.setOption(CURLOPT_POSTFIELDS, s: jsonString)

curlObject.perform { code, header, body in
    // code
}

CouchDB постоянно возвращал ошибку, что приходит невалидный UTF-8 JSON. Я вставлял строку, которую отправляю в базу, в отдельное приложение для тестирования REST и там данные отлично принимались. Что самое странное, если сделать много запросов из моего кода, то 1-2 запроса с одними и теми же данными база принимала и записывала, на остальные приходила ошибка. Так и не понял в чём беда. То ли это чей-то глюк, то ли я не умею использовать CURL.

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

То, что прекрасно билдится командой swift build в консоли в macOS, может не билдиться в Ubuntu. Более того, то, что билдится в Xcode, может не билдиться в консоли в macOS.

Потратив много времени на проблемные места, в основном связанные с доставанием данных из Dictionary с несколькими уровнями вложенности, сделал всё-таки, чтобы в Ubuntu код собирался.

Собрал, сделал запрос - приложение на сервере упало. Так я эту проблему и не решил, да ещё и расстроился, что то, что прекрасно работает в macOS, просто падает в Ubuntu, при том что и там, и там использовался Swift 3.0.1.

После этого есть какое-то чувство разочарования. Столько времени потратил, что бросать как-то не хочется.

Но одно приятное наблюдение я сделал - по сути я переписал уже сделанный ранее на Node.js API для своего приложения. API на Node.js с помощью фреймворка Restify занимает 35 мб памяти. Тот же API, написанный на Swift, у меня в macOS разогнался только до 5.2 мб памяти. На Ubuntu он стартует с 3.5 мб, но увеличивается ли потребление проверить я не смог, т.к. бинарник просто падает когда отправляешь запрос.

Вывод

Опять надо ждать новых версий Swift и новых версий фреймворков, чтобы что-то всё-таки сделать на них. К тому же, в конце октября Apple сформировали рабочую группу для развития инструментов для бэкенда, написанных на Swift, так что есть надежда. Пока писал пост ещё раз посмотрел внимательно на Vapor и очень приятно удивился. Следующим попробую именно его.

Итого:

Kitura не собирается и показал плохие результаты по производительности, но активно пилится IBM.

Perfect собирается, но то, что я написал, не работает на Ubuntu, но работает в macOS, видимо надо ждать новых версий Swift и Perfect.

Zewo отстаёт и как-то надежд на него совсем не возлагаю.

Vapor надо срочно потрогать. (Update: потрогал)

Если ваш код компилится в macOS, то не факт, что скомпилится в Ubuntu. Если работает в Ubuntu, то не факт, что будет работать, даже если работает в macOS.