Как поиграть с бэкендом с помощью TypeScript?

Node.js задняя часть Программа перевода самородков TypeScript

Как поиграть с бэкендом с помощью TypeScript?

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

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

TL;DR — стек делает ваши серверные приложения такими же мощными, как и многие корпоративные статические решения на других языках:

  • Библиотека маршрутов и контроллеров с использованием декораторов, параметров, инъекций тела

  • Библиотеки для внедрения зависимостей и сервисы с использованием декораторов

  • ORM, использующие декораторы, такие как Doctrine/Hibernate, для удобного манипулирования сущностями.

  • Небольшой совет для тех, кто еще не знаком с написанием бэкендов на TypeScript

Маршрутизаторы-контроллеры: контроллеры, действия, запросы и т. д.

pleerock/routing-controllersrouting-controllers — создавайте структурированные, декларативные и хорошо организованные контроллеры на основе классов.

Хотя эта библиотека написана как помощник TypeScript для Express/Koa, она также поможет вам написать контроллеры, которые вы бы использовали в корпоративных средах Java/PHP/C#.

Вот небольшой пример контроллера:

import {JsonController, Param, Body, Get, Post, Put, Delete} from "routing-controllers";

@JsonController()
export class UserController {

    @Get("/users")
    getAll() {
       return userRepository.findAll();
    }

    @Get("/users/:id")
    getOne(@Param("id") id: number) {
       return userRepository.findById(id);
    }

    @Post("/users")
    post(@Body() user: User) {
       return userRepository.insert(user);
    }

}

Для некоторых людей это похоже на избавление от кошмара: больше никаких компонентов с маршрутами, полно вложенных промежуточных программ и реализаций промежуточных программ с параметрами инъекции, проверки и запроса (да, вы даже можете определить типы параметров и нужно ли их передавать! Такие как @Body({ required: true, validate: true }) это будет работать хорошо, если есть отсутствующий параметр или неверный запрос, будет выдано исключение)

Декоратор имеет много полезных функций, таких как @Controller базового контроллера, возможность определять тип содержимого в действиях, а также обслуживание и получение JSON с помощью @JsonController.

Я использую его в Express, и теперь, когда у нас есть async/await (я не могу не хвалить разработку TS Node.js в течение нескольких месяцев), нам больше не нужен Koa (контроллеры маршрутизации могут быть лучше, теперь Express поддерживается). И у Express есть больший набор @types.

Вот пример использования роутинг-контроллеров и других библиотек @pleerock (VSCode, если интересно, со ссылкой на плагин TypeLens) в моем проекте:

Как видите, роутинг-контроллеры даже предоставляют неопределенные коды возврата (а также пустые и нулевые декораторы) и многие другие возможности. Об this.playerService — это еще одна интересная библиотека, о которой я расскажу позже.

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

Конечно, вы также можете использовать много промежуточного программного обеспечения Express/Koa для извлечения вашего приложения, а также для настройки представления (в библиотеке также есть декораторы для представлений), аутентификации (которую можно применить ко всему уровню управления через промежуточное программное обеспечение), ошибки обработка и др. Комплектация.

Обычно я храню их в папке /controllers.

TypeDI: внедрение зависимостей, сервисы

GitHub.com/P Lee rock/Тяня…

Эта библиотека помогает мне структурировать мой проект, упрощает кодирование и не заставляет думать: «Хорошо, а где существует сервис, это сервис? Ну, может, это другой, но как он зависит от другого сервиса? он ссылается на другие сервисы?»

Возвращаясь к моему PlayerService, в этом разделе можно увидеть, от чего он зависит (другие сервисы):

@Inject для меня лучший декоратор, который можно использовать при работе с сервисами и логически завершенными серверными приложениями.

(Если вы хотите узнать о @OrmEntityManager — еще одной библиотеке от @pleerock, я расскажу об этом позже)

Да, у вас может быть много служб, которые зависят от других служб. И если у вас есть циклические зависимости службы, вы можете обойти это, явно определив типы (документация библиотеки охватывает большинство проблем и сценариев).

Для тех, кто не знаком со службами, контейнерами служб, внедрением зависимостей служб и т. д. Короткое описание:

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

Мое описание этой библиотеки не охватывает весь ее потенциал (вы можете сами проверить ее документацию — доступно гораздо больше функций): вы можете дать ей имя при определении сервисов, вы можете определить внедрение конструктора и т. д.

Обычно я храню свои сервисы в папке /services.

TypeORM: используйте ORM для определения реляционных сущностей, разные типы столбцов и разные схемы хранения данных очень удобны (реляционные, нереляционные)

typeorm/typeorm_typeorm — Data-Mapper ORM, который можно использовать в средах TypeScript и JavaScript (ES7, ES6, ES5). Поддержка MySQL, PostgreSQL, MariaDB, SQLite

Это дает мне ощущение, что написание Node.js на TypeScript наконец-то может конкурировать с другими языками и ORMS.

Мощный ORM позволяет легко писать сущности в понятной форме. Я не фанат многих других ORMS Node.js, таких как эта:

module.exports = { id: SomeORM.Integer, name: SomeOrm.String({ …})}

Я всегда хочу, чтобы сущности записывались как классы. Класс, которому задано типизированное свойство, будет обнаружен ORM с помощью простого декоратора. Даже не напечатал.

TypeORM дает вам эту возможность. Другой пример из моего проекта:

Как видите, я даже не написал тип свойства в декораторе (вы можете это сделать, не волнуйтесь, укажите тип явно, по умолчанию, с нулевым значением и т. д.)! TypeORM делает всю эту работу за меня, зная, какой тип (благодаря отражению TypeScript: расширения метаданных) и применяя его к моей базе данных.

Это очень мощный инструмент, и у вас будет все, что вы имеете/видите в других ORM, таких как (Doctrine, Hibernate).

При использовании роутинг-контроллеров и TypeDI он предоставляет очень полезные декораторы для внедрения менеджеров сущностей (как вы можете видеть на снимке экрана PlayerService) или подключения ваших контроллеров к сервисам (этоОченьУдобство).

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

Обычно я помещаю конфигурацию моей базы данных в папку /config, а объекты — в папку /entities.

  • Почему в одной статье рассматриваются все эти библиотеки?

Это самое интересное.

Контроллеры маршрутизации — это основа вашего приложения. Это дает вам возможность легко связать эти две библиотеки (см. документацию по библиотеке). Конечно, вы не обязаны, если не хотите. Его можно использовать с любым ORM.

Однако, когда вы используете все три из этих библиотек, вы делаете фреймворк слишком мощным по сравнению с другими решениями (по крайней мере, для меня). У вас есть контроллеры, внедрение параметров, внедрение тела, проверка параметров, внедрение зависимостей, и с этим вы можете забыть о ручном предоставлении зависимостей и определении типов, украшении сущностей свойствами, запросах построителя. Это все о TypeScript! Таким образом, бэкэнд также будет иметь проверку типов во время компиляции!

  • Да, благодаря библиотеке, которая охватывает эти функции. Но опять же, как использовать TypeScript с узлом?

Что ж, проще некуда. Вы можете написать машинописный текст как обычно, настроить его для компиляции в ES2015 (теперь в узле много фич, нет необходимости компилировать его в версию до ES2015) и использовать стандарт CommonJS для реализации модулей.

И используйте pm2 или что-то еще, чтобы запустить index/server/app.js после компиляции. В основном производственный код готов. Нет необходимости в ts-узле или что-то в этом роде.

Если вам нравятся эти библиотеки, не забудьте выразить свою любовь

Как видите, мало кто знает о роутинг-контроллерах и TypeDI, это самые мощные и полезные библиотеки, которые я использую для своего проекта TypeScript Node.js. Если они вам нравятся, пожалуйста, найдите секунду, чтобы отметить их и распространить информацию. Они мне очень помогли, поэтому я надеюсь, что они помогут вам и другим пользователям TypeScript!

У этих библиотек также есть сообщества gitter, которые вы можете легко найти, введя в Google «имя библиотеки gitter».

Спасибо за чтение и получайте удовольствие от использования TypeScript. Комментарии или вопросы приветствуются~

Программа перевода самородковэто сообщество, которое переводит высококачественные технические статьи из Интернета сНаггетсДелитесь статьями на английском языке на . Охват контентаAndroid,iOS,внешний интерфейс,задняя часть,блокчейн,товар,дизайн,искусственный интеллектЕсли вы хотите видеть более качественные переводы, пожалуйста, продолжайте обращать вниманиеПрограмма перевода самородков,официальный Вейбо,Знай колонку.

Категории