Недавно выпущенный Feathers Auk был посвящен улучшению сгенерированного приложения и более гибкому плагину аутентификации. В этом посте я хотел бы рассказать вам о том, что нас ждет в следующем выпуске Feathers под кодовым названием Buzzard! 🎉

В этом выпуске основное внимание будет уделено техническим улучшениям и улучшениям удобства использования, таким как:

  • Лучшее разделение серверных и клиентских модулей
  • Больше гибкости, сделав зависимость от Express необязательной
  • Повышена производительность, особенно при фильтрации событий в реальном времени.
  • Очистите некоторые API и крайние случаи, которые вызывали путаницу.

Что на самом деле означают релизы Feathers?

Как Эрик уже упоминал в сообщении о выпуске Auk, в течение прошлого года, когда мы работали над выпуском, нам было труднее ответить на этот вопрос, чем казалось на первый взгляд.

Поскольку большая часть Feathers состоит из дополнительных модулей, вы можете использовать перья без перьев-аутентификации, перья-примус вместо перья-сокетыо, создавать REST API без реального времени и выбирать любой из Существующие адаптеры баз данных (или напишите свои). Поскольку каждый модуль имеет собственное семантическое управление версиями, объявление Feathers v3 не имело особого смысла (фактически, ядро ​​Feathers выпустило только два небольших релиза 2.x за последние полтора года).

У нас также есть фантастическая экосистема, развивающаяся вокруг Feathers, и члены команды запускают проекты в рамках организации Feathers, которые не обязательно являются основной частью Feathers. Вот почему мы решили сосредоточить и выпуски, и основную документацию на основных модулях и их зависимостях, которые, когда в них есть критические изменения, влияют на многие другие:

Мы по-прежнему собираемся использовать семантические версии и имена птиц в качестве кодовых имен выпуска. Это скорее пояснение того, какие основные выпуски будут охватывать. 🐧 🦉🦆

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

Рамочная независимость

Для получения дополнительной информации см. Перья / перья № 258.

Одна из лучших особенностей Feathers заключается в том, что его можно использовать как на сервере, так и на клиенте. Это означает, что, в отличие от большинства других фреймворков, Feathers не просто предоставляет клиентскую библиотеку JavaScript. Это клиентская библиотека. В браузере или React Native вы просто создаете другое приложение Feathers со службами, которые взаимодействуют с сервером Feathers через REST или веб-сокеты (конечно, сервер Feathers все еще может использоваться с любым другим клиентом REST или веб-сокетом).

В настоящее время серверные Feathers расширяются и являются заменой Express. У нас уже есть клиентская версия, в которой мы просто заглушаем некоторые функции Express для клиента. В этой следующей версии больше не будет разделения между Feathers на стороне сервера и на стороне клиента.

Почему мы его меняем?

Ядро Feathers не полагается ни на что, связанное с Express, поэтому имеет смысл удалить жесткую зависимость и перенести эту функциональность в собственный плагин. Это также откроет возможности для создания в будущем плагинов для других фреймворков, таких как Koa или Hapi. Это также помогает Feathers сосредоточиться на том, о чем идет речь: на предоставлении независимых от транспорта услуг, рабочих процессов (перехватчиков) и событий в реальном времени.

Если вы правильно используете Feathers, вам уже не нужно беспокоиться о том, какую структуру HTTP он использует под капотом.

Что изменится?

На самом деле не так уж и много. Для вашего серверного приложения Feathers теперь вам нужно будет установить и потребовать feathers-express, а затем «выразить» объект Feathers app. Это превратит его в уже знакомое вам приложение, совместимое с Express.

перья-крючки станут частью стержня

Для получения дополнительной информации см. Перья / перья # 408.

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

Почему мы его меняем?

Это имеет еще один полезный побочный эффект: мы можем удалить основную зависимость от Rubberduck, который ранее отвечал за отправку служебных событий. Теперь эти события отправляются в обычном хуке Feathers, который уменьшает зависимости и упрощает базовую архитектуру. Беспроигрышный вариант! Поступая так, как Feathers, мы можем уменьшить его ядро ​​с меньшим количеством зависимостей и меньшим количеством кода, который нужно поддерживать. 🙌

Что изменится?

Меньше кода и меньше зависимостей. Больше не нужно устанавливать, требовать и настраивать feathers-hooks.

Реорганизация клиентских модулей

Для получения дополнительной информации см. Перья / перья-клиент №137.

Теперь, когда ядро ​​Feathers по умолчанию становится независимым от фреймворка, а хуки больше не являются отдельным плагином, мы считаем, что это также хорошее время для перемещения всех других клиентских модулей в их собственные репозитории.

Почему мы его меняем?

Мы изо всех сил старались задокументировать, как можно использовать Feathers на клиенте, но разница между импортом feathers/client, модуля перья-клиент и таких вещей, как feathers-socketio/client, является очень распространенным источником путаницы.

Что изменится?

Все импортированные на стороне клиента feathers/client будут заменены только на feathers. Клиентские модули, такие какfeathers-rest/client, feathers-socketio/client и feathers-primus/client, будут перемещены в свои собственные репозитории (feathers-rest-client и т. Д.) И предоставят свою собственную версию браузера. Вы включаете только те части Feathers, которые используете, и нам больше не нужно поддерживать отдельный feathers-client репозиторий.

Улучшенная фильтрация событий в реальном времени

Для получения дополнительной информации см. Перья / перья # 388.

В Feathers фильтрация событий определяет, какой из подключенных клиентов получает событие в реальном времени и с какими данными.

Почему мы его меняем?

В целом Feathers неплохо справляется с тестами производительности, и мы также вполне довольны тем, как лежащие в его основе шаблоны проектирования позволяют упростить создание REST и API реального времени. Однако фильтры событий могут быть улучшены:

  1. В настоящее время фильтры событий работают для каждого соединения при каждом событии. Для многих подключений (и особенно когда задействована асинхронная обработка) это может значительно повлиять на производительность сервера Feathers.
  2. Поскольку данные публикуются для всех клиентов, так как они возвращаются службой по умолчанию, слишком легко забыть зарегистрировать правильные фильтры событий и случайно утечка конфиденциальной информации.

Что изменится?

Приложения Feathers будут поддерживать каналы. Каналы похожи на комнаты Socket.io, которые позволяют существующему соединению присоединяться и выходить. Это все еще WIP, но пока что каналы выглядят следующим образом:

Фильтры событий (теперь называемые диспетчерами) будут запускаться только один раз для каждого события и возвращать один или несколько каналов. Событие будет отправлено на комбинированные подключения из канала (ов). Если соединение установлено в обоих каналах, оно будет отправлено только один раз.

Поскольку у нас есть возможность фильтровать все соединения, также можно создать обратно совместимую оболочку для существующих фильтров событий. Мы все еще обсуждаем некоторые особенности предложения, поэтому не стесняйтесь комментировать или следить за вопросом предложения. Ждем ваших отзывов!

Устаревшие

Мы также планируем внести некоторые другие критические изменения в API:

  • Обратные вызовы в стиле узла больше не поддерживаются в службах. Все официальные версии Node полностью поддерживают Promises, а Node 8 поддерживает async/await, обе из которых работают с вызовами служб Feathers.
  • service.before и service.after будут заменены на новые service.hooks({ before, after }). Созданные приложения, начиная с Auk, уже используют этот синтаксис.
  • Регистрация новой службы теперь возможна только через app.use(path, service), а не через app.service(path, service), который теперь используется исключительно для получения услуги (например, app.service('myservice')).
  • Параметризованные маршруты REST, такие как /users/:userId/posts, теперь будут отображаться непосредственно в params.query вместо params. Это то, что мы обычно хотим (поскольку указанный выше маршрут эквивалентен /posts?userId=<userId>).

Предварительные релизы и сроки

Работы по разработке для каждого модуля можно найти в соответствующих репозиториях GitHub в ветке major.

За исключением фильтрации событий, описанные выше изменения уже были реализованы в основном репозитории по адресу перья / перья / дерево / мажор. Следующие шаги - реализация фильтрации событий и обновление транспортных модулей (Socket.io, Primus, REST). В ближайшие месяцы мы сделаем и объявим о нескольких предварительных релизах, чтобы вы могли опробовать их и оставить свои отзывы. Для окончательной версии мы также планируем предоставить оболочку обратной совместимости для большинства критических изменений API.

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

За последние три года и после запуска в производство по крайней мере с десятками приложений (о которых мы знаем) базовый архитектурный паттерн и философия Feathers показали себя очень хорошо. Это не только позволило людям очень быстро создавать масштабируемые и гибкие приложения, но и нам не пришлось вносить какие-либо принципиальные критические изменения. Это было одновременно немного удивительно, но также подтвердило, что все мысли и планирование, вложенные в Feathers, окупаются.

Мы надеемся, что показанные здесь изменения - еще один шаг в эволюции, который сделает Feathers более доступным и поможет его экосистеме расти еще дальше, оставаясь при этом такой же надежной и гибкой, как и прежде! Спасибо за вашу поддержку. ❤️

Если вы еще не пробовали FeathersJS, попробуйте его и дайте нам знать, что вы думаете, в Slack или Twitter.