Как улучшить ваш API сервис на node.js. Часть 1

[AriesUa]

Статья и заголовок расходятся в значениях. Из заголовка, я ожидаю прочитать что-то, что поможет мне улучшить мой API сервис (application public interface). Т.е предполагается, что сервис как бы у меня уже есть и пара советов, таких, которые бы помогли бы улучшить стабильность и нагрузку, или дельные советы по REST итд, я бы нашел в статье.

Но увы, статья о банальном «starter kit». И ничего общего с API не имеет.

Рекомендую переименовать статью, типа «NodeJS Starter Kit для новичков». Это бы помогло понять о чем действительно идет речь.

[evkochurov]

Не могу не оставить это здесь: Node.js Лучшие практики

[evkochurov]

Что касается содержания статьи. Вы в первом же совете предлагаете типичные грабли: структурирование файлов по техническим ролям, а не по компонентам. Почему это плохо? Читайте ссылку выше. Но и здравого смысла должно быть достаточно, чтобы увидеть: если вы захотите разобраться, как работают Users, то будете метаться минимум по трем папкам (controllers, models, routes). И так, разумеется, будет с любой компонентой.

По моему опыту, единственный период жизни проект, когда такая структура дает хоть какой-то профит — это когда устаканивается инфраструктура и частно нужно «проходить рубанком» по всем компонентам скопом, внося однотипные правки. Но тут надо понимать, что этот период устаканивания временный (и он тем короче, чем больше опыта), а вот компоненты будут правиться всегда, пока проект жив.

[savostin]

Симлинки — наше всё. И так, и этак можно получить доступ к файлам…

[ladanovn]

evkochurov Хочется немного защитить разбиение файловой структуры по техническим ролям, аргументируя распространенностью данной практики среди express/koa/hapi/fastify. Привычная структура позволяет быстрее соориентироваться.
Это никак не противоречит с вышесказанным: это усложняет поддержку проекта. Модульная система в этом плане гибче. И, возможно, она заменить привычную структуру по ролям особенно с ростом популярности nest.

[webdevium]

Не подумайте, что реклама, но… начинаем свой проект на nest и всё. Стандартизация и хорошие практики с коробки, без бубнов.

[ladanovn]

За nest +, а вот что делать со старыми проектами…

[webdevium]

Если существующий код не может без проблем перенестись на nest, то лучше такой код сразу выбросить и заново написать, используя хорошие практики.
Если же ваш код переносится без проблем — у вас хороший код. Не на nest ли часом?

[balajahe]

Мой проект на Deno, и тоже ничего )

[Akuma]

О, интересно. Много проблем было при переходе? Используете потому что надо или «почему бы и нет»?

[balajahe]

Для pet-проекта решил поэкспериментировать с pet-рантаймом :). Очень нравится базовое API, все типизированное, на промисах. На баги не наталкивался, документация правда слабовата, писал им ишью, но начальник ответил, что пока не стабилизировали API, и подробную доку писать не будут. Зато исходники STD на удивление хорошо откомментированы, и дока особо не нужна — по щелчку из редактора проваливаешься в исходники любой либы, хоть сторонней хоть системной, очень удобно (преимущество импорта по URL). Производительность ввода-вывода вроде не выше чем у ноды, но детальных бенчей не делал. Главный вопрос — как будет развиваться экосистема, например, портирование экспресса, и т.д. Ну и понятно, в 21 веке писать на голом JS это моветон, тайпскрипт чудесный язык, хотя и к ноде он легко прикручивается. Я так понял, главная фишка Deno — это единственный портируемый бинарник самого рантайма + финальный бандл твоего приложения, просто 2 файлика, не нужно никаких инсталов, сторонних бандлеров, обновления каталога зависимостей, всей этой нодовской сложности.
Резюме — продукт отличный, но опаздал лет эдак на 5.

[alex_blank]

Рассмотрим добавление babel`я в проект

Бабель для Node сегодня уже немодно, вместо него можно установить esm — легковесный загрузчик ES модулей, и запускать проект так:

node -r esm index.js

С mocha:

mocha -r esm