Зачем нужен еще один фреймворк?
У JavaScript огромное комьюнити, сотни тысяч пакетов в npm и десятки активно развивающихся фреймворков. Казалось бы, все на мази, но не тут то было. Как-то так получилось, что экосистема бекенд фреймворков на Node.js одна из самых неразвитых среди популярных языков.
Небольшое введение во фреймворки. Все фреймворки можно грубо разделить на две большие группы: микрофреймворки и просто фреймворки. В Node.js, в подавляющем большинстве случаев, в проектах используются именно микрофреймворки, например, expressjs, fastify и тому подобные.
Микрофреймворки обладают очень небольшим ядром и хорошо расширяются (в теории). На практике любой проект на микрофреймворке превращается во франкенштейна. В этом мире практически не существует единых подходов и стандартов. Каждую задачу приходится решать заново и часто с нуля (i18n, ресурсный роутинг, orm, обработка форм, защита от атак, генераторы). Из-за этого разработчики тратят уйму времени на вещи, которые делаются за часы или минуты в продвинутых фреймворках других экосистем.
Большие фреймворки на Node.js уже появились и набрали некоторую популярность, но, они очень далеки от того, каким должны быть фреймворки, которые по настоящему облегчают работу. Ближе всех к этому подобрался adonis.js, но к нему есть довольно много претензий по принципам работы. Еще больше претензий есть к Nest.js, который пошел вообще куда-то не туда. О том, что конкретно не так с ними, я расскажу где-нибудь отдельно.
Что происходит здесь? Nodos (название вероятно нужно поменять, а то щас оно напоминает операционную систему) экспериментальный фреймворк, который начался уже пару лет назад. В его архитектуру легли идеи множества других продвинутых фреймворков. Среди них:
- Rails (Ruby)
- Phoenix (Elixir)
- Django (Python)
- Laravel (PHP)
Генеральная идея, предоставить фреймворк, берущий на себя всю возможную рутину, так, чтобы программист мог сосредоточиться на бизнес-логике. Он не ставит собой целью гибкость, наоборот, многие вещи в нем достаточно фиксированы. Это позволяет сделать очень глубокую интеграцию всего со всем. Такой подход принято называть соглашениями вместо конфигурации.
С тех пор было сделано не очень много, но довольно быстро получился каркас, который сейчас уже доведен до состояния "работает". Более того, мы начали один проект Хекслета на этом фреймворке.