Как появился FeathersJS и почему мы его создали.
Я знаю! Вы, вероятно, кричите Только не еще один фреймворк JavaScript!. Я также страдал от рамочной усталости (вероятно, больше, чем большинство других), поэтому я не буду винить вас за то, что вы не читаете. Но ... если вы решите втянуть кишку и надавить на нее, к концу этой статьи у вас, возможно, хватит энергии положить новый веб-фреймворк себе в задний карман.
Несколько лет назад Дэвид Люке и я начали работать над Feathers с целью упростить и ускорить создание мобильных и веб-приложений. Мы оба работаем с node с 0,2 дня, и мы запустили десятки приложений NodeJS в производство. За прошедшие годы, под влиянием других языков и веб-фреймворков, мы изменили способ создания приложений и API (как и следовало бы вам). Мы также извлекли несколько трудных уроков и нашли несколько архитектурных паттернов, которые нам действительно пригодились.
В результате этого опыта мы хотели создать структуру, которая будет расти вместе с вами по мере роста вашего продукта. Достаточно гибкий, чтобы быстро адаптироваться к меняющимся потребностям бизнеса, достаточно мощный, чтобы создавать современные приложения, и достаточно простой, чтобы быстро приступить к работе.
Мы перепробовали почти все остальные фреймворки (не только в JavaScript) и почувствовали, что либо было слишком сложно начать работу, это заняло слишком много времени, либо, когда вы начали масштабироваться, было больно выходить за пределы фреймворка. удобная песочница.
Мы обнаружили, что многие приложения, которые мы создали с использованием фреймворков MVC, быстро раздулись толстыми моделями или чрезмерно сложными контроллерами, и когда все, что нас заботит, это наши данные; настройка маршрутов, выполнение CRUD и обработка цикла запрос-ответ кажутся утомительными. В результате мы начали исследовать другой подход к созданию веб-приложений.
Немного истории
Первоначальное семя Feathers началось в 2010 году. Дэйв работал над своей университетской диссертацией в Германии и реализовал сервис-ориентированную архитектуру на Java - не любимый язык Дэйва, но это был академический язык… пожимает плечами. Вместо типичной парадигмы MVC он взял аспектно-ориентированные шаблоны программирования и остановился на использовании сервисов и сквозных проблем, или ловушек.
Перенесемся на несколько лет спустя. Дэйв встретил любовь всей своей жизни (нет, не меня и не JavaScript) и переехал в Калгари, Канада. Там мы с ним познакомились на местной встрече JS. Здесь мы также начали вместе работать над различными проектами, одним из которых был Feathers. В то время мы оба много работали с NodeJS и Express, поэтому решили расширить их. JavaScript - не наш любимый язык, но мы хорошо с ним знакомы, и возможность использовать один и тот же язык во всем стеке действительно приятно. Это снижает когнитивные издержки и позволяет использовать такие возможности, как совместное использование кода, чего вы просто не можете достичь при смешивании языков интерфейса и бэкенда.
После многократного внедрения таких вещей, как аутентификация, CRUD, разрешения и проверки, мы взяли концепции из дипломной работы Дэйва и разместили Feathers на Github в 2013 году. Сначала это было очень экспериментально и действительно предназначалось только для нас двоих. Мы работали над Feathers в свободное время до выпуска версии 1.0 в 2014 году. Некоторые люди ставили проект в главной роли на Github, а он был представлен на DailyJS, поэтому мы создали веб-страницу и сделали некоторые, задним числом, очень дрянные документы. На тот момент Feathers оставались просто хобби-проектом.
Мы продолжали время от времени работать над Feathers в 2015 году. Некоторые люди привыкли к нему достаточно, чтобы вызвать беспокойство, но в то время Feathers действительно не был таким, каким мы его себе представляли, и мы не уделяли ему достаточно внимания, чтобы получить его. там. Что-то нужно было изменить: либо убить его, либо начать уделять Перьям необходимое внимание.
В декабре 2015 года мы с Дэйвом обсудили, продолжать ли работу над Feathers. Мы задали себе 3 довольно важных вопроса:
- Действительно ли мы делаем что-то лучше или иначе?
- Нам действительно нужно или мы хотим создать и поддерживать нашу собственную структуру? Это много работы!
- Можем ли мы просто обойтись существующим решением?
Наши ответы на все эти вопросы - вот что побудило нас продолжать работать над Feathers и действительно прилагать последовательные усилия, чтобы сделать его той структурой, которой, как мы знаем, может быть. Это решение далось нелегко, и мы оба взяли на себя обязательство поработать свои задницы, чтобы воплотить в жизнь наше видение того, какой должна быть структура веб-приложений. Мы с гордостью запустили 2.0 в марте 2016 года, и это очень правильный путь.
Философия перьев
За последние несколько лет Feathers превратился из небольшой библиотеки в зрелую среду, которая с экосистемой плагинов делает создание впечатляющих приложений и API-интерфейсов в реальном времени действительно интересным. Ядро всего в несколько сотен строк кода не сильно изменилось, как и наша философия. Он до сих пор определяет направление развития Feathers:
«Монолитные приложения имеют тенденцию разваливаться при масштабировании либо из-за производительности, либо из-за того, что в коде слишком много людей. Что, если бы мы могли упростить создание приложений, которые могут естественным образом стать сервис-ориентированными с первого дня, вместо того, чтобы начинать с большого приложения и мучительно его дразнить?
Что, если бы мы могли создать фреймворк, который будет расти вместе с вами и вашим бизнесом и упростить вам переход к серии микросервисов или легко изменить базы данных, не разрывая наш код?
Что, если бы мы могли сделать режим реального времени менее пугающим, а не хитрым, сложным после размышлений? Что, если бы мы могли удалить шаблон, необходимый для создания REST API? Можем ли мы создать фреймворк, обеспечивающий достаточную структуру, чтобы легко работать, и добавить все общие элементы, необходимые современным приложениям, но при этом сохранить все гибкость и необязательность?
Сама структура не должна быть самоуверенной. Он должен состоять из небольших, многоразовых, необязательных компонентов, которые хорошо справляются с одной задачей, но при этом самоуверенно сочетаются. Сохраняя компоненты вашего приложения небольшими, гибкими и необязательными, вы устраняете многие инженерные препятствия, мешающие быстрому перемещению и масштабированию ».
Мы применили эту философию к Feathers и создали невероятно гибкий и мощный фреймворк. Мы ценим простоту и гибкость превыше всего, и, не рискуя при этом, мы по-прежнему стараемся не изобретать велосипед. Вместо этого мы стараемся максимально использовать возможности удивительной экосистемы JavaScript.
Мы твердо уверены, что ваш пользовательский интерфейс, данные и бизнес-логика являются основой любого веб-приложения или мобильного приложения. Ваш фреймворк должен позаботиться обо всем остальном, чтобы вы могли сосредоточиться на важных вещах. Вместо того, чтобы писать шаблон, беспокоиться о маршрутизации, логике контроллера, обработке ошибок или аутентификации, вы должны тратить время на разговоры с клиентами, тусоваться с друзьями и семьей, играть в настольный футбол и фактически создавать свое приложение. То, что действительно важно.
Мы считаем, что вы можете легко перейти от «монолитного» приложения к микросервисам, не вырывая волос. Мы считаем, что вы сможете сделать свое приложение работающим в режиме реального времени с минимальными усилиями. Мы считаем, что вы сможете легко создавать невероятные приложения, которые будут радовать ваших пользователей.
Если эта философия находит отклик у вас, то Feathers может быть и для вас. Если нет, то это тоже нормально. Мы просто хотим поделиться Feathers с другими в надежде, что это ваше лекарство от Framework Fatigue. Если вы решите попробовать, я почти уверен, что вы будете приятно удивлены.
В любом случае Дэйв, я и остальная часть основной команды хотели бы услышать, что вы думаете в Slack или Twitter.
Если вы хотите узнать больше о Feathers, ознакомьтесь с некоторыми другими нашими статьями в нашей публикации Medium.
