Я большой поклонник NodeJS за его тонкий упрощенный подход. Я использую Node.js с 2011–2012 гг., И Express был моей средой по умолчанию для быстрого прототипирования или написания API микросервисов. Со временем я поигрался с некоторыми другими фреймворками Node.js, такими как sails, koa, loopback и т. Д. В конце дня мне всегда приходилось возвращаться в Express.
Но с конца 2018 года я использую NestJS и вроде как чувствую: наконец-то я нашел правильный фреймворк, который искал так долго. Этот пост посвящен самоанализу, почему я предпочитаю Nest Express или другим фреймворкам.
Крайне самоуверенная и неискренняя структура
Express - это неформальный, минималистичный фреймворк. Фреймворки без мнения доверяют разработчикам, которые сделают правильный выбор. Это позволяет разработчикам выбирать любые инструменты или технологии, промежуточное программное обеспечение и хуки, которые они хотят использовать. Разработчики структурируют свои коды без какой-либо конкретной структуры, навязанной фреймворком.
Express, будучи неискренним фреймворком, не имеет какого-либо конкретного механизма шаблонов, парсера тела, обработчика ошибок и т. Д. Это своего рода хорошо для компьютерного разработчика. Раньше я любил эту свободу. Каждый раз, когда мне приходилось строить новый проект, я украшал его инструментами по своему выбору. Но сделать выбор в пользу команды всегда сложно. Если в вашей команде есть еще два разработчика, одному может понравиться ejs, а другому - blade как движок шаблонов. Таким образом, каждый экспресс-проект со временем становится уникальным.
Даже в рамках одного большого проекта структура проекта и инструменты разных микросервисных команд становятся разными. Из-за этого нельзя просто перескакивать с одной микросервисной команды на другую.
Я думаю, что «свобода» - это не то, чего заслуживают все. Неискренние фреймворки позволяют разработчикам кодировать что угодно где угодно. Я видел много беспорядочных проектов с уродливой структурой проектов. Я видел много проектов с ненужными шаблонами проектирования, в которых больше усилий уделялось ненужной абстракции.
Nest - очень самоуверенный фреймворк. Он следует парадигме дизайна «соглашение превыше конфигурации». Он настоятельно рекомендует разработчикам использовать определенные инструменты и кодировать определенным образом. За кулисами он уже обертывает контроллер блоком try-catch, уже анализирует тело запроса, добавляет обработчик ошибок, промежуточное ПО, регистратор и т. Д. Таким образом, мне не нужно делать эти обычные вещи каждый раз при создании нового проекта. . Разработчики должны определенным образом писать контроллер, сервис, репозитории в определенных местах.
Итак, я думаю, что любой, кто знаком с Nest, может сразу перейти к проекту, не тратя много времени на то, как организован код или какие инструменты используются. Если вы не разработчик, который очень креативен в написании беспорядочного кода, код в проекте Nest должен быть гораздо более удобным в сопровождении, чем в неискреннем проекте Express.
Машинопись
Я знаю, что многим разработчикам JS не нравится TypeScript. Они могут придумать действительно странную логику. Как будто Typescript - это продукт Microsoft, поэтому мы не можем на него полагаться! В любом случае, я считаю, что Typescript - самая приятная вещь, представленная в недавнем возрождении JavaScript.
С помощью слабо типизированных языков, таких как PHP, Python или JavaScript, разработчики могут быстро написать кучу кода. Но без строгой типизации всегда есть шанс создать ошибки. По мере роста проектов вам нужно всегда возвращаться к нескольким служебным файлам или файлам компонентов, чтобы проверить, какие методы доступны или какие параметры они ожидают. Большинство ошибок возникает, когда вы ожидаете объект пользователя, но вы передали идентификатор пользователя. Возможно, вы неправильно написали имя атрибута объекта. Без подсказок типа вам придется потратить часы и часы на отладку такого рода глупых ошибок. А если вы новый разработчик и только что присоединились к проекту годичной давности, вы просто потерялись.
Но с Typescript от тела запроса к ответу - если мы используем строгую типизацию, вы можете кодировать намного быстрее, и шансы на создание такого рода глупых ошибок снижаются почти до 0%.
Nest, вероятно, единственный доступный хорошо структурированный фреймворк, полностью написанный на Typescript. Несмотря на то, что вы можете использовать Typescript в Express (путем некоторой настройки), но это не 100% Typescript.
Использование декораторов, нестандартных декораторов
Декораторы - это предлагаемая функция JavaScript. Но в Typescript уже есть эта функция. Все основные серверные фреймворки Java, Python, Php активно используют декораторы / аннотации. Декораторы позволяют программировать метаданные, механизм для изменения классов, членов классов декларативным образом.
В NEST я могу привязать контроллер к маршрутам, установить метод запроса, ввести тело запроса или параметры синтаксического анализа, красиво управлять защитой аутентификации / ролей с помощью декораторов. Независимо от того, требуется ли входной атрибут, проверять электронную почту или сериализовать атрибут в JSON или нет - всем можно управлять с помощью декораторов.
/**
* A typical example of using different decorators in
* a nest controller method
*/
@Get('/me')
@ApiBearerAuth()
@UseGuards(RolesGuard)
@Roles('user', 'admin')
@UseInterceptors(ClassSerializerInterceptor)
async getMe(
@AuthUser() user: IAuthUser,
): Promise<User> {}
Nest также предоставляет простой способ объявления пользовательских декораторов. Итак, если есть какая-то общая задача, которую можно использовать в разных частях моего проекта, я могу легко написать ее как декоратор и использовать в нескольких местах.
Доменная разработка
Nest позволяет определять несколько модулей в одном корневом модуле. Модули инкапсулируют поставщиков, контроллеры, репозитории, перехватчики, промежуточное программное обеспечение и т. Д. Благодаря этому мы можем логически распределить весь код проекта по логическим доменам. Если поставщик / сервис не определен в одном модуле, его нельзя внедрить в контроллер или класс обслуживания. Если нам нужно использовать службу из другого модуля, эту службу необходимо экспортировать, и этот модуль необходимо включить в этот модуль. Благодаря этому мы можем создавать четкие границы предметной области, писать повторно используемые модули и писать слабо связанный и поддерживаемый код.
Угловая архитектура
Основная причина растущей популярности Node.js - это использование одного и того же языка как в серверной части, так и во внешнем интерфейсе. К сожалению, единственное преимущество, которое мы получили до сих пор, - это тот же синтаксис. Архитектура кодирования, философия, термины - все было совершенно иначе.
С точки зрения архитектуры NEST в значительной степени вдохновлен Angular. Это модуль, служба, контроллер, конвейер, декораторы - все синтаксис, использование и философия в точности соответствуют Angular. Фронтенд-разработчик на Angular может легко перейти к бэкэнд-проекту NEST - чувствуя себя так, как будто он работает над одним и тем же проектом. С той же концепцией и философией как для бэкэнда, так и для внешнего интерфейса, не тратя много времени на переключение контекста.
Интерфейс командной строки (CLI)
Nest поставляется с собственным интерфейсом командной строки для быстрого запуска и поддержки проекта. Благодаря этому мы можем легко создавать модули, контроллеры, каналы и промежуточное программное обеспечение, чтобы облегчить разработчикам боль.
Тестирование
Программа запуска приложений, сгенерированная Nest CLI, поставляется со средой тестирования по умолчанию, настроенной с помощью Jest framework. Каждый раз, когда мы генерируем сервис, контроллер, средний провод, перехватчики и т. Д. - CLI генерирует файл спецификации вместе с ним. Он предоставляет автоматически сгенерированный код для тестирования, поэтому разработчикам не нужно писать код, необходимый для модульного тестирования. Таким образом, с NestJs писать модульное тестирование становится намного проще.
Представление
В переполнении стека есть несколько потоков, в которых люди сравнивают тест производительности hello world между Express и Nest. Поскольку сам Nest использует Express внизу, было бы глупо сравнивать эти два. Чтобы получить гораздо лучшую производительность, Nest предлагает альтернативный способ изменения внутренней реализации фреймворка с Express на Fastify (фреймворк другого узла).
$ npm i --save @nestjs/platform-fastify
https://docs.nestjs.com/techniques/performance
Используя Fastify, мы можем получить от Nest даже лучшую производительность, чем простой простой Express «привет, мир».
Вы можете получить отчет о тестировании производительности здесь.
Заключение
NestJS - один из самых быстрорастущих фреймворков Node.js в 2018/2019 годах. До сегодняшнего дня (август 2019 года) у него более 18 тысяч звезд на GitHub и более 91 тысячи загрузок npm в неделю. Быть разработчиком Angular + TypeScript Nest было моим очевидным выбором. Но кому-то, кто не знаком с TypeScript или философией Angular, может быть сложно начать с ними.
Если вы не используете Angular или Typescript, попробуйте NestJS, я хотел бы узнать ваше мнение с нейтральной позиции.
Вы можете узнать больше о NestJS на его официальном сайте и в документации. Не стесняйтесь оставлять здесь свои комментарии или ловить меня в твиттере @asad_rahman.
Посетите наш сайт, чтобы узнать о нас больше:
www.monstar-lab.co.bd
