Спустя почти 4,5 года и около 400 релизов только основного проекта Vapor, Vapor 4 начинает показывать свой возраст. Пару лет назад мы обсуждали расплывчатый план для Vapor 5, что мы хотели бы добавить и как, по нашему мнению, будет выглядеть будущее экосистемы. За эти годы многое изменилось, и мы немного рисковали со сроками выхода Swift 6, которые не оправдались. Но такова жизнь!
Изменения в экосистеме были существенными: появился async/await, добавилась поддержка Sendable с использованием большого количества блокировок. Это было не очень красиво, но работало. Мы добавили потоковые тела async для запроса и ответа, у нас было 0 предупреждений со строгой проверкой параллелизма в Swift 6.
Теперь, когда известно время выхода Swift 6, пришло время смотреть в будущее.
Vapor 5
Сейчас началась работа над следующей версией Vapor, Vapor 5. Несмотря на то, что API-системы могут быть изменены, у нас есть несколько основных целей, которые мы хотим достичь. Наша абсолютная цель - сделать Vapor не только одним из фреймворков де-факто при создании Swift-приложений, но и де-факто выбором для создания бэкенда на любом языке.
Основные цели включают:
- Тот же самый, отличный, опыт Vapor
- Полностью структурированный параллелизм
- Полная интеграция с современной экосистемой
- Обеспечить основу для современного бэкенда
- Переработка API WebSocket и MultipartKit
Тот же опыт Vapor
Компания Vapor всегда была известна тем, что предоставляла разработчикам отличный опыт работы с API, с которым легко работать, и чувствовала себя Swifty. Мы хотим, чтобы это осталось неизменным и стало еще лучше. Это включает в себя API, которые имеют смысл, понятную документацию и учебные пособия, которым легко следовать, опираясь на наше фантастическое сообщество.
Это то, что сделало Vapor таким популярным, и это не изменится. Мы хотим попытаться развить этику прогрессивного раскрытия Swift, поэтому, несмотря на то, что с Vapor легко начать работу и просто написать базовый API, крючки для написания более сложных и комплексных приложений уже есть, и вы не ограничены рамками фреймворка.
Полностью структурированный параллелизм
В Vapor 3 был представлен EventLoopFuture, и хотя это было правильное направление развития и настраивало нас на следующие несколько лет, это была сложная кривая обучения. Я помню, как писал оригинальную книгу по Vapor и пытался понять эти новые API, и мне было очень трудно в самом начале! К счастью, появились async/await и решили проблему удобства использования. Но он всегда был прикручен к существующим API EventLoopFuture и не был полноценным структурированным параллелизмом.
С новой основной версией мы сможем все это изменить! В Vapor не будет API, возвращающих EventLoopFuture, и мы сможем обеспечить полноценный структурированный параллелизм. Это упростит написание и осмысление кода, обеспечит более производительный фреймворк и сделает более безопасной работу в мире async.
Это начнется со Swift Service Lifecycle, с которым Vapor интегрируется нативно, чтобы упростить управление всеми различными сервисами и заставить их работать слаженно.
Полная интеграция с современной экосистемой
Помимо Swift service lifecycle, есть ряд новых библиотек, которыми мы можем воспользоваться. Есть новый HTTP-сервер, на котором мы можем строить, основываясь на замечательной работе Адама из Hummingbird. В настоящее время ведется работа над новым пакетом Middleware, который позволит нам легко обмениваться промежуточным ПО между различными фреймворками.
Также есть новая библиотека HTTP Types и Swift Argument Parser, на которые мы можем опираться. Меньше вещей для Vapor, которые нужно поддерживать, и лучшая интеграция с остальной экосистемой Swift - беспроигрышный вариант.
Наконец, новый Swift Foundation обеспечит еще меньшую площадь для приложений, и мы сможем перейти на использование преимущественно FoundationEssentials. Кроме того, он наконец-то обеспечит согласованное поведение на всех платформах, уменьшая путаницу для разработчиков и способствуя достижению цели сделать Vapor отличным выбором для создания бэкендов на любом языке.
Обеспечьте основу для современного бэкенда
Vapor используется большими и малыми компаниями и служит основой для некоторых очень крупных приложений. Мы хотим, чтобы Vapor хорошо работал не только для небольших, простых API, но и для самых требовательных бэкендов. Это включает в себя обеспечение полной наблюдаемости, с логированием, метриками и трассировкой, поддерживаемыми из коробки.
Новый HTTP-сервер позволит нам легко обеспечить первоклассную поддержку gRPC, асинхронной потоковой передачи тел и SSE. OpenAPI также будет первоклассной системой, как для генерации документации из маршрутов, так и для генерации маршрутов из спецификации OpenAPI.
И, конечно, благодаря структурированному параллелизму и Sendable проблемы с потоками и гонками данных уйдут в прошлое. Vapor 5 обеспечит высокопроизводительную основу для удовлетворения самых требовательных пользователей.
Переработка API WebSocket и MultipartKit
MultipartKit был выделен в отдельный пакет на заре Vapor 4, но еще до появления Swift Concurrency. Несмотря на то, что он хорошо работает, в настоящее время мы не предоставляем API для потоковой передачи многочастичных тел, ни для разбора запросов, ни для потоковой передачи ответов. Это может затруднить работу с очень большими файлами или с такими API, как NIOFileSystem. В рамках Vapor 5 мы выпустим новую версию MultipartKit, которая предоставит потоковый API для многочастичных тел.
Вебсокеты в Vapor всегда были сложны при работе с асинхронным кодом. Это стало еще сложнее с появлением Swift Concurrency, и в настоящее время он не очень хорошо работает в асинхронном мире. Поэтому мы также выпустим новый релиз WebsocketKit с обновленным API. Не беря на себя никаких обязательств, я бы хотел иметь возможность делать что-то вроде
https://gist.github.com/Chidorin/18e364e654bdc71a1637c98b50ebff7e
Следующие шаги и сроки
Путь к Vapor 5 будет проходить по приблизительному плану:
- Удалить все старые API, основанные на будущем (это уже сделано).
- Внедрить «новую» архитектуру сервисов, AKA инъекция зависимостей
- Исправить все технические недочеты с Sendable, перейти на ценностные типы запросов и ответов и т.д.
- Заменить HTTP-сервер, чтобы обеспечить полный асинхронный стек
- Переход на жизненный цикл сервисов Swift
- Переход на Swift Testing
- Перепишите API WebSocket и MultipartKit
- Исследуйте новые API для маршрутизации, валидации и других областей, которые мы хотим затронуть.
Обратите внимание, что Fluent 5 - это отдельная тема, о которой Гвинн расскажет в отдельном посте, но вполне вероятно, что FluentKit 4 будет работать с Vapor 5.
Мы планируем выпустить начальную альфа-версию к моменту выхода Swift 6. Она будет сфокусирована на обеспечении асинхронного стека и удалении всех API EventLoopFuture, а дальше мы сможем работать над реализацией вышеперечисленных целей и изучением некоторых новых API. Вы можете следить за развитием событий на GitHub и в канале #vapor-5 в Discord.
Сроки поддержки
Vapor 4 выходит (и стабильно работает) уже почти 4,5 года. Надеемся, это развеет миф о том, что Vapor постоянно вносит изменения! Сейчас Vapor 4 находится в режиме обслуживания и не будет получать никаких новых функций, если в них нет острой необходимости. Однако PR-обращения по-прежнему принимаются, и я постараюсь их рассмотреть. Мы будем продолжать исправлять ошибки и проблемы безопасности в Vapor 4 в течение как минимум 6 месяцев после выхода Vapor 5.
Срок поддержки Vapor 5 составит не менее 3 лет. Как и в случае с Vapor 4, он вполне может быть и дольше, но мы хотим обеспечить определенную стабильность экосистемы и, изначально установив длительный период поддержки, надеемся, что это побудит всех к миграции, больше людей к внедрению и, что важно, убедит авторов библиотек обновить свои фреймворки.
Подведение итогов
Vapor 5 станет огромным релизом, который заложит основу для Vapor на ближайшие годы в мире Swift Concurrency. Мы с нетерпением ждем начала работы и с нетерпением ждем обсуждения изменений в Discord. Если вы хотите быть на передовой, пожалуйста, не стесняйтесь пробовать альфы по мере их появления! Как только все основные API будут реализованы, мы сможем начать помечать некоторые бета-версии, которые должны быть более стабильными.