Первая публикация в году, и она будет на одну из моих любимых тем - TypeScript. Но не там, где вы ожидаете, нет, мы не будем говорить о Frontend. Поговорим о Backend!
Короче говоря, несколько месяцев назад мне поручили создать простой API. Требования заключались в том, что он должен быть поддерживаемым (база кода будет совместно использоваться несколькими группами разработчиков), масштабируемым и хорошо документированным (в идеале он должен генерировать свои документы Swagger). И здесь возникает конфликт, обычно, когда дело доходит до масштабируемых API, я бы использовал Java или Kotlin и Spring, но в этом случае это было бы немного излишним - бизнес-логика была довольно простой. С другой стороны, когда дело доходит до простых API, моей первой мыслью будет NodeJS. Тем не менее, хорошо известно, что NodeJS и Javascript (хотя мы все его любим ❤) на самом деле не масштабируемы, и может стать проблематичным разделение чистой (небезопасной по типу) кодовой базы Javascript между разными командами.
Так как же совместить простоту NodeJS с масштабируемостью Java?
И именно здесь появляется TypeScript. На всякий случай, если вы новичок в этой области:
TypeScript - это надмножество JavaScript, которое в первую очередь предоставляет необязательную статическую типизацию, классы и интерфейсы, как это делают Java и другие языки ООП.
Я называю это версией Javascript JAVAfied. Разве не было бы замечательно, если бы мы смогли создать NodeJS API со всеми преимуществами Typescript? Ответ - да, однако мне не удалось найти на GitHub полноценный и полноценный исходный проект для начала. Вот почему я создал один! (вы сможете перейти по ссылке чуть позже - просто оставайтесь со мной)
Исходный проект, который я создал, содержит:
- Сохранение данных с помощью MongoDB (с использованием мангуста)
- Мокинг базы данных (во время разработки и тестирования - mockgoose)
- Разработка и производственные потоки
- Модульные тесты Mocha (для моделей и контроллеров)
- Документы Swagger (автоматически создаются декораторами)
- Примеры конечных точек, которые обрабатывают запросы GET и POST
- анализ машинописного текста с помощью TSLint
Важное примечание об этом посевном проекте. Имейте в виду, что структура и другие вещи (например, правила линтинга) основаны на моих личных предпочтениях и на том, как я люблю кодировать. Не стесняйтесь разветвлять его и настраивать под свои нужды.
Просмотр файловой структуры
Корневая папка содержит в основном файлы конфигурации, сервер и тестовую папку. Папка server содержит наш сервер, а в папке test вы можете найти конфигурацию тестов mocha (по умолчанию путь для конфигураций mocha - ./test/mocha.opts).
В процессе разработки я использую nodemon для отслеживания изменений в файлах TS и перезапускаю сервер с помощью tsnode. Конфигурация nodemon находится внутри nodemon.json.
Приложение доступно для порта в server.ts, tsconfig.json содержит конфигурацию машинописного текста и tslint.json правила линтинга. Я использую YARN в качестве диспетчера зависимостей (как и во всех моих личных проектах RIP npm), поэтому необходимые зависимости и сценарии пряжи определены в package.json и созданный yarn.lock.
Теперь в папке сервера находится наше экспресс-приложение. Основа нашего сервера находится в app.ts. Туда мы помещаем конфигурацию приложения и маршруты. Как видите, мы подключаем маршруты к контроллерам, куда собираемся поместить соответствующую логику. Два дополнительных маршрута используются для открытия документации swagger и пользовательского интерфейса swagger.
Папка с ресурсами содержит только HTML-файл, который используется Swagger.
Наш API будет обрабатывать создание пользователей и возвращать созданных пользователей по запросу. Он также имеет маршрут работоспособности, который гарантирует, что API работает (любой, кто работал с Kube, знает о его необходимости).
Мы хотим использовать возможность разработки, ориентированной на интерфейс, которую дает нам Typescript, поэтому в папке models вы можете найти модель User. Декораторы (разработчики с опытом Spring уже чувствуют себя как дома) помогут swagger-express-ts сгенерировать документацию по модели (подробнее). В конце файла мы определяем схему мангуста (которая, к сожалению, должна иметь другую структуру, чем та, которую объявляет интерфейс IUser), и экспортируем ее, чтобы мы могли использовать ее в контроллере. для сохранения и извлечения пользователей из базы данных. Модульные тесты пользовательской модели в ./server/tests/models/user.spec.ts гарантируют, что необходимая логика сохраняемости не сломается в будущем.
Говоря о базе данных, очень важно отметить, что мы не хотим зависеть от внешней базы данных (которая может быть недоступна и т. Д.) Во время разработки или тестирования. Вот почему мы загружаем mongoose из ./server/config/database, а не из пакета mongoose. В этом файле мы создаем фиктивную базу данных или подключаемся к внешнему источнику, в зависимости от переменной NODE.ENV. Это делает процесс разработки возможным даже без подключения к Интернету! Вы можете легко настроить свою базу данных prod, изменив переменную MONGODB_CONNECTION_URL.
Наконец, контроллеры (в разделе ./server/controllers/) содержат логику запросов. Например, пользовательский контроллер может обрабатывать запросы GET и POST и использует модель мангуста пользователя, которую мы определили ранее, для взаимодействия с базой данных. Мы снова используем декораторы, так что swagger-express-ts сможет сгенерировать для нас документы swagger (подробнее). Модульное тестирование контроллера в разделе ./server/tests/controllers/user.spec.ts гарантирует, что базовая функциональность нашего контроллера не выйдет из строя в будущем.
Чтобы запустить сервер локально, просто проверьте репо и следуйте инструкциям в файле README! Не забывайте, что вы можете легко проверять конечные точки и создавать фиктивные запросы, открыв пользовательский интерфейс swagger по адресу localhost: ‹port› / api-docs / swagger.
Ну вот и все! Это был мой API семян Typescript и его краткое объяснение. Я надеюсь, что это поможет вам создать свой следующий API в приятной форме. Конечно, я понимаю, что он может быть не на 100% идеальным, поэтому не стесняйтесь размещать любые PR с предложениями по улучшениям или дополнительным функциям!
Желаю вам удачного 2019 года с большим количеством красивого кода!
